Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching
Extracted elements (21)
Ethernet endpoint identifiers are character-based (per MEF/G.8011) rather than IP-address-based (the GMPLS norm). The document bridges this by reusing RFC 4974's long Call ID mechanism — carrying the Ethernet endpoint identifier in CALL_ATTRIBUTES while SENDER_TEMPLATE and SESSION carry IP addresses and a short Call ID.
Multiple LSPs may be associated with a single EVPL Call primarily to handle the case where carrying multiple VLAN IDs causes a Path message to grow larger than a single unfragmented IP packet. This avoids IP fragmentation while preserving GMPLS signaling integrity.
This document covers only point-to-point (E-Line/EPL/EVPL) Ethernet services mappable to GMPLS P2P TE LSPs. Support for multipoint-to-multipoint (E-LAN/MP2MP) services is explicitly deferred for future study, as no clear correspondence exists with GMPLS TE LSPs.
Any node that supports Ethernet connections MUST be able to accept and process Call setups per RFC 4974. Ethernet connections MUST treat the Ethernet (virtual) connection identifier as the long Call ID described in RFC 4974.
Ethernet connections established according to this document MUST include the L2CP TLV in the RFC 6003 traffic parameters carried in the FLOWSPEC and TSPEC objects.
For MEF services, the EL2CP field in the L2CP TLV MUST be set to a value of 1 (Based on IL2CP Value).
LSPs that provide EVPL service type Ethernet switching MUST use the EVPL Generalized Label Format per Section 4.1 and the Generalized Channel_Set Label Objects per RFC 6002.
The EPL service parameters (Switching Type DCSC, G-PID Ethernet PHY, and appropriate LSP Encoding Type) MUST be used when establishing and controlling LSPs that provide EPL service type Ethernet switching.
When a Call is established or torn down per RFC 4974, a CALL_ATTRIBUTES object containing an Endpoint ID TLV MUST be included in the Notify message along with the long Call ID.
When establishing an Ethernet connection, the initiator MUST first establish a Call per the procedures defined in RFC 4974. Both network-initiated and user-initiated Calls MUST be supported.
When using multiple LSPs to support an EVPL service connection, all LSPs MUST be established within the same Call per Section 2.2, and all LSPs associated with the same Call/EVPL connection MUST be signaled with the same LSP objects except for SENDER_TEMPLATE, SESSION, and label-related objects.
When VLAN ID mapping is used (EVPL service not configured for both bundling and VLAN ID preservation), such mapping MUST be requested and signaled based on the explicit label control mechanism defined in RFC 3473 and clarified in RFC 4003. When explicit label control is not used, VLAN IDs MUST be preserved across an LSP.
EPL Type 1/MEF service uses LSP Encoding Type Ethernet (2) with Switching Type DCSC (125) and G-PID Ethernet PHY (33). EPL Type 2 service uses the newly defined LSP Encoding Type Line (e.g., 8B/10B) with value 14.
EVPL connections MUST use Switching Type EVPL (30), LSP Encoding Type Ethernet (2), and G-PID Ethernet PHY (33). EVPL service allows multiple Ethernet connections per port, each supporting a specific set of VLAN IDs.
The Endpoint ID TLV (Type 30, variable length) carries a character-based Ethernet endpoint identifier within the CALL_ATTRIBUTES object, bridging the gap between MEF/G.8011 endpoint identifiers and GMPLS IP-address-based identifiers. The Endpoint ID field is null-padded as defined in RFC 6001.
IANA assigned Endpoint ID TLV Type=2 in the 'Call Attributes TLV' section of the RSVP Parameters registry.
IANA assigned LSP Encoding Type value 14 for 'Line (e.g., 8B/10B)' in the 'LSP Encoding Types' section of the GMPLS Signaling Parameters registry.
IANA assigned Switching Type value 30 for 'Ethernet Virtual Private Line (EVPL)' in the 'Switching Types' section of the GMPLS Signaling Parameters registry, also reflected in IANAGmplsSwitchingTypeTC of the IANA-GMPLS-TC-MIB.
This document introduces new message object formats for use in GMPLS signaling (RFC 3473) but does not introduce new signaling messages or change the relationship between adjacent LSRs in the control plane. No additional security considerations beyond those in RFC 3473 are introduced.
The EVPL Generalized Label (Label Type value 2) is a 16-bit field consisting of 4 reserved bits followed by a 12-bit VLAN ID. The reserved bits MUST be set to zero on transmission and MUST be ignored on receipt.
The L2 Control Protocol (L2CP) TLV has Type=3 and Length=8, containing a 4-bit Ingress L2CP (IL2CP) field, a 4-bit Egress L2CP (EL2CP) field, and 24 reserved bits. It is carried within RFC 6003 traffic parameters in FLOWSPEC and TSPEC objects.