Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI)
Extracted elements (17)
Support for Multipoint-to-Multipoint (MP2MP) Ethernet service is deliberately left for future study; only Point-to-Point (P2P) service delivery is addressed, following the same scope limitation as RFC6004.
The document is scoped to MEF UNI Type 3 signaling (dynamic service establishment via a signaling interface) and explicitly does not address MEF UNI Types 1 (manual) or 2 (manual or link management), consistent with the companion RFC6004 for Ethernet service switching.
This document is a UNI companion to RFC6004 (GMPLS Support for MEF and G.8011 Ethernet Service Switching) and does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI.
For EVPL services, VLAN ID mapping from ingress UNI to a different VLAN ID at egress (where bundling and VLAN ID preservation are not both supported) MUST be requested and signaled using the explicit label control mechanism defined in RFC4208, not the mechanisms in RFC6004.
LSPs providing Ethernet connections controlled via the mechanisms defined in this document MUST use the addressing and other procedures defined in RFC4208, including use of the egress edge node's IP address in the endpoint address field in the SESSION object.
The procedures defined in RFC6004, as modified by this document, MUST be followed when signaling LSPs supporting an EPL service; there are no additional UNI-specific requirements for EPL.
UNI identification MUST follow Ethernet endpoint (UNI) identification as defined in RFC6004, except as noted for cases where the scope of the Ethernet endpoint identifier extends beyond ingress and egress nodes.
UNI signaling for Ethernet connections MUST follow the Connection Identification procedures defined in RFC6004, with the exception that RFC4974 Section 7.2 procedures MAY be used for Call ID allocation by the first core node.
When a UNI-N core node receives a Notify message with the SESSION object tunnel endpoint address set to zero, it MUST locate the Endpoint ID TLV in the CALL_ATTRIBUTES object; if the object or TLV are not present, the node MUST discard the message and MUST NOT send a Message ID Acknowledgment.
When an edge node (UNI-C) initiates an LSP and has the egress Ethernet endpoint identifier but not its IP address, the edge node MUST create a Notify message including the CALL_ATTRIBUTES object with the Endpoint ID TLV, with the tunnel endpoint address field of the SESSION object set to zero, addressed to the first core node.
When the explicit label control mechanism is not used, VLAN IDs MUST be preserved (not modified) across the LSP, consistent with RFC6004.
When the UNI-N is unable to obtain an egress address from the Endpoint ID TLV, it MUST issue an error response Notify message; the Error code and value SHOULD be 'Routing Problem/Unknown Endpoint' (Error code 24, Error value 35).
When the UNI-N successfully obtains an egress address, the endpoint address field of the SESSION object MUST be set to the obtained address, and the returned address MUST be used in all subsequent messages associated with the Ethernet connection.
The EVPL service supports optional VLAN ID translation at the egress UNI, signaled via the explicit label control mechanism of RFC4208, allowing a different VLAN ID at egress than at ingress when bundling and VLAN ID preservation are not simultaneously required.
The UNI address resolution procedure uses a Notify message (per RFC4974) with a CALL_ATTRIBUTES object containing the Endpoint ID TLV (defined in RFC6004), with the SESSION object tunnel endpoint address set to zero, to request IP address resolution from the first core node.
IANA assigned Error Value sub-code 35 ('Unknown Endpoint') under Error Code 24 (Routing Problem) in the 'Error Codes and Globally-Defined Error Value Sub-Codes' section of the RSVP Parameters registry.
This document does not change the security models offered by RFC6004 or RFC4974; the address resolution procedure in Section 2.2 parallels the information replacement described in RFC4974 Section 7.2. Implementors should refer to RFC6004 and RFC4974 for the applicable security considerations.