Movatterモバイル変換

Internet Engineering Task Force (IETF)                         L. BergerRequest for Comments: 6005                                          LabNCategory: Standards Track                                       D. FedykISSN: 2070-1721                                           Alcatel-Lucent                                                            October 2010Generalized MPLS (GMPLS) Support for Metro Ethernet Forumand G.8011 User Network Interface (UNI)Abstract   This document describes a method for controlling two specific types   of Ethernet switching via a GMPLS-based User Network Interface (UNI).   This document supports the types of switching required by the   Ethernet services that have been defined in the context of the Metro   Ethernet Forum (MEF) and International Telecommunication Union (ITU)   G.8011.  This document is the UNI companion to "Generalized MPLS   (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service   Switching".  This document does not define or limit the underlying   intra-domain or Internal NNI (I-NNI) technology used to support the   UNI.Status of This Memo   This is an Internet Standards Track document.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Further information on   Internet Standards is available inSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6005.Berger & Fedyk               Standards Track                    [Page 1]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010Copyright Notice   Copyright (c) 2010 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document must   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.Table of Contents1. Introduction ....................................................31.1. Overview ...................................................41.2. Conventions Used in This Document ..........................52. Common Signaling Support ........................................52.1. UNI Addressing .............................................52.2. Ethernet Endpoint (UNI) Identification .....................62.2.1. Address Resolution ..................................62.3. Connection Identification ..................................73. EPL Service .....................................................74. EVPL Service ....................................................74.1. Egress VLAN ID Control and VLAN ID Preservation ............75. IANA Considerations .............................................85.1. Error Value: Routing Problem/Unknown Endpoint ..............86. Security Considerations .........................................87. References ......................................................87.1. Normative References .......................................87.2. Informative References .....................................9   Acknowledgments ....................................................9Berger & Fedyk               Standards Track                    [Page 2]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 20101.  Introduction   [MEF6] and [G.8011] provide parallel frameworks for defining network-   oriented characteristics of Ethernet services in transport networks.   The framework discusses general Ethernet connection characteristics,   Ethernet User Network Interfaces (UNIs), and Ethernet Network-Network   Interfaces (NNIs).  Within this framework, [G.8011.1] defines the   Ethernet Private Line (EPL) service and [G.8011.2] defines the   Ethernet Virtual Private Line (EVPL) service. [MEF6] covers both   service types.  [MEF10.1] defines service parameters and [MEF11]   provides UNI requirements and framework.   This document provides a method for GMPLS-based control of Label   Switched Paths (LSPs) that support the transport services defined in   the above documents at the UNI network reference points.  This   document does not define or limit the underlying intra-domain or   Internal NNI (I-NNI) technology used to support the UNI.  This   document makes use of the GMPLS extensions defined in [RFC6004] and   [RFC6002].   The scope of this document covers Ethernet UNI applications, and it   is intended to be consistent with the GMPLS overlay model presented   in [RFC4208] and aligned with GMPLS Core Network signaling.  The   scope and reference model used in this document are represented in   Figure 1, which is based on Figure 1 of [RFC4208].   Figure 1 shows two core networks, each containing two core nodes.   The core nodes are labeled 'CN'.  Connected to each CN is an edge   node.  The edge nodes are labeled 'EN'.  Each EN supports Ethernet   Networks and use Ethernet services provided by the core nodes via a   UNI.  Two services are represented: one EPL and one EVPL type   service.  Signaling within the core network is out of scope of this   document and may include any technology that supports overlay UNI   services.  The UNI function in the edge node can be referred to as   the UNI client, or UNI-C, and in the CN as UNI network, or UNI-N.Berger & Fedyk               Standards Track                    [Page 3]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010        Ethernet                                          Ethernet        Network       +----------+    +-----------+       Network      +---------+     |          |    |           |     +---------+      |  +----+ |     |  +-----+ |    |  +-----+  |     | +----+  |   ------+    | | EPL |  |     | |    |  |     |  | EPL | |    +------   ------+ EN +-+-----+--+ CN  +---------+  CN +--+-----+-+ EN +------      |  |    | |  +--+--|     +---+  |  |     +--+-----+-+    |  |      |  +----+ |  |  |  +--+--+ | |  |  +--+--+  |     | +----+  |      |         |  |  |     |    | |  |     |     |     |         |      +---------+  |  |     |    | |  |     |     |     +---------+                   |  |     |    | |  |     |     |      +---------+  |  |     |    | |  |     |     |     +---------+      |         |  |  |  +--+--+ | |  |  +--+--+  |     |         |      |  +----+ |  |  |  |     | | +-----+     |  |     | +----+  |   ------+    +-+--+  |  | CN  +---------+ CN  |  |     | |    +------   ------+ EN +-+-----+--+     | |    |  |     +--+-----+-+ EN +------      |  |    | |EVPL |  +-----+ |    |  +-----+  |EVPL | |    |  |      |  +----+ |     |          |    |           |     | +----+  |      |         |     +----------+    |-----------+     |         |      +---------+            Core Network(s)            +---------+        Ethernet  UNI                               UNI   Ethernet        Network <----->                           <-----> Network                          Scope of This Document                        Legend:   EN  -  Edge Node                                  CN  -  Core Node                  Figure 1: Ethernet UNI Reference Model1.1.  Overview   This document uses a common approach to supporting the switching   implied by the Ethernet services defined in [MEF6], [G.8011.1], and   [G.8011.2].  The approach builds on standard GMPLS mechanisms to   deliver the required control capabilities.  This document reuses the   GMPLS mechanisms specified in [RFC6004], [RFC4208], and [RFC4974].   Support for Point-to-Point (P2P) and Multipoint-to-Multipoint (MP2MP)   service is required by [G.8011] and [MEF11].  P2P service delivery   support is based on the GMPLS support for Ethernet services covered   in [RFC6004].  As with [RFC6004], the definition of support for MP2MP   service is left for future study and is not addressed in this   document.   [MEF11] defines multiple types of control for UNI Ethernet services.   In MEF UNI Type 1, services are configured manually.  In MEF UNI Type   2, services may be configured manually or via a link management   interface.  In MEF UNI Type 3, services may be established andBerger & Fedyk               Standards Track                    [Page 4]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010   managed via a signaling interface.  As with [RFC6004], this document   is aimed at supporting the MEF UNI Type 3 mode of operation (and not   MEF UNI Types 1 and 2).  As mentioned above, this document is limited   to covering UNI-specific topics.   Common procedures used to signal Ethernet connections are described   inSection 2 of this document.  Procedures related to signaling   switching in support of EPL services are described inSection 3.   Procedures related to signaling switching in support of EVPL services   are described inSection 4.1.2.  Conventions Used in This Document   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in [RFC2119].2.  Common Signaling Support   This section describes the common mechanisms for supporting a UNI   reference point for LSPs that provide the Ethernet Services described   in [RFC6004].   Except as specifically modified in this document, the procedures   related to the processing of Resource ReSerVation Protocol (RSVP)   objects is not modified by this document.  The relevant procedures in   existing documents, notably [RFC6002], [RFC6004], [RFC4208], and   [RFC4974], MUST be followed in all cases not explicitly described in   this document.2.1.  UNI Addressing   LSPs providing Ethernet connections controlled via the mechanisms   defined in this document MUST use the addressing and other procedures   defined in [RFC4208].  Of note, this includes the use of the egress   edge node's IP address in the endpoint address field in the SESSION   object.   One issue that presents itself with the addressing approach taken in   [RFC4208] is that an ingress edge node may not receive the egress   edge node's IP address as part of the management, or other, request   that results in the initiation of a new Ethernet connection.  This   case is covered as described inSection 7.2 of [RFC4974] and modified   below inSection 2.2.1.Berger & Fedyk               Standards Track                    [Page 5]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 20102.2.  Ethernet Endpoint (UNI) Identification   UNI identification, except as noted below, MUST follow Ethernet   endpoint (UNI) identification as defined in [RFC6004].  There is one   additional case that is covered in this document where the scope of   the Ethernet endpoint identifier is relevant beyond the typical case   of just ingress and egress nodes.2.2.1.  Address Resolution   At the UNI reference point, it is possible for the ingress edge node   to not have the egress edge node's IP address when initiating an LSP.   This presents an issue as the egress edge node's IP address is   carried in the SESSION object.  This case is handled leveraging the   approach described inSection 7.2 of [RFC4974] to address call ID   assignment by the first core node.   When an edge node (the UNI-C) initiates an LSP and it has the egress   Ethernet endpoint identifier, but does not have its IP address, the   edge node MUST create a Notify message as described in [RFC4974].   The Notify message MUST include the CALL_ATTRIBUTES object with the   Endpoint ID TLV defined [RFC6004].  The tunnel endpoint address field   of the SESSION object in the Notify message MUST be set to zero (0).   The message MUST be addressed and sent to an address associated with   the first core node.   When a core node, i.e., the node providing the network side of the   UNI (the UNI-N), receives a Notify message with the tunnel endpoint   address field of the SESSION object 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.  In this case, a   Message ID Acknowledgment MUST NOT be sent for the Notify message.   When the Endpoint ID TLV is located, the node MUST map the Endpoint   ID into an IP address associated with the egress edge node.  If the   node is unable to obtain an egress address, it MUST issue an error   response Notify messages according toSection 6.2.2. of [RFC4974].   The Error code and value SHOULD be "Routing Problem/Unknown Endpoint"   (Error code 24, Error value 35).   When the node is able to obtain an egress address, the endpoint   address field of the SESSION object MUST be set to the obtained   address, and the Notify message should be sent according to the   standard processing defined in [RFC4974].  The downstream nodes will   then process the Notify according to standard processing rules.Berger & Fedyk               Standards Track                    [Page 6]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010   When the ingress receives the response Notify message, it SHOULD   identify the call based on the Endpoint ID TLV and, when not set to   zero on the corresponding setup Notify message, the short and long   Call IDs.  The endpoint address field of the SESSION object carried   in the response Notify message will include the egress's IP address.   This returned address MUST be used in all subsequent messages   associated with the Ethernet connection.   Note that the procedure described in this section MAY be used when   the Call IDs are generated by the initiating UNI or generated by the   first core node.2.3.  Connection Identification   With one exception, UNI signaling for Ethernet connections MUST   follow the Connection Identification procedures defined in [RFC6004].   The exception is that the procedures defined inSection 7.2 of   [RFC4974] MAY be used to provide support for allocation of Call IDs   by the first core node rather than by the initiating edge node.3.  EPL Service   There are no additional UNI-specific requirements for signaling LSPs   supporting Ethernet Private Line (EPL) services.  The procedures   defined in [RFC6004], as modified above, MUST be followed when   signaling an LSPs supporting an EPL Service.4.  EVPL Service   There is one additional UNI-specific requirement for signaling LSPs   supporting an EVPL type service as described inSection 4.1.  Except   as modified above and by this section, the procedures defined in   [RFC6004] MUST be followed when signaling an EVPL Service.4.1.  Egress VLAN ID Control and VLAN ID Preservation   Per [MEF6], the mapping of the single VLAN ID used at the ingress UNI   to a different VLAN ID at the egress UNI is allowed for EVPL services   that do not support both bundling and VLAN ID preservation.  Such a   mapping MUST be requested and signaled based on the explicit label   control mechanism defined in [RFC4208], and not the mechanisms   defined in [RFC6004].   As is the case in [RFC6004], when the explicit label control   mechanism is not used VLAN IDs MUST be preserved, i.e., not modified,   across the LSP.Berger & Fedyk               Standards Track                    [Page 7]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 20105.  IANA Considerations   IANA has assigned new values for namespaces defined in this document   and summarized in this section.5.1.  Error Value: Routing Problem/Unknown Endpoint   IANA has made the following assignment in the "Error Codes and   Globally-Defined Error Value Sub-Codes" section of the "RSVP   Parameters" registry located athttp://www.iana.org:   Error Code      Meaning     24  Routing Problem                             [RFC3209]   Under "This Error Code has the following globally-defined Error          Value sub-codes:"         35 =  Unknown Endpoint                      [RFC6005]6.  Security Considerations   This document makes use of the mechanisms defined in [RFC6004] and   [RFC4974].  It does not in itself change the security models offered   in each.  (Note that the address resolution discussed inSection 2.2   above, parallels the replacement of information that occurs perSection 7.2 of [RFC4974].)  See [RFC6004] and [RFC4974] for the   security considerations that are relevant to and introduced by the   base mechanisms used by this document.7.  References7.1.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP              Tunnels",RFC 3209, December 2001.   [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,              "Generalized Multiprotocol Label Switching (GMPLS) User-              Network Interface (UNI): Resource ReserVation Protocol-              Traffic Engineering (RSVP-TE) Support for the Overlay              Model",RFC 4208, October 2005.Berger & Fedyk               Standards Track                    [Page 8]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010   [RFC4974]  Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)              RSVP-TE Signaling Extensions in Support of Calls",RFC4974, August 2007.   [RFC6002]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Data              Channel Switching Capable (DCSC) and Channel Set Label              Extensions",RFC 6002, October 2010.   [RFC6004]  Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support              for Metro Ethernet Forum and G.8011 Ethernet Service              Switching",RFC 6004, October 2010.7.2.  Informative References   [G.8011]   ITU-T G.8011/Y.1307, "Ethernet over Transport Ethernet              services framework", August 2004.   [G.8011.1] ITU-T G.G.8011.1/Y.1307.1, "Ethernet private line              service", August 2004.   [G.8011.2] ITU-T G.8011.2/Y.1307.2, "Ethernet virtual private line              service", September 2005.   [MEF6]     The Metro Ethernet Forum, "Ethernet Services Definitions -              Phase I", MEF 6, June 2004.   [MEF10.1]  The Metro Ethernet Forum, "Ethernet Services Attributes              Phase 2", MEF 10.1, November 2006.   [MEF11]    The Metro Ethernet Forum , "User Network Interface (UNI)              Requirements and Framework", MEF 11, November 2004.Acknowledgments   Dimitri Papadimitriou provided substantial textual contributions to   this document and coauthored earlier versions of this document.   The authors would like to thank Evelyne Roch and Stephen Shew for   their valuable comments.Berger & Fedyk               Standards Track                    [Page 9]

RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010Authors' Addresses   Lou Berger   LabN Consulting, L.L.C.   Phone: +1-301-468-9228   EMail: lberger@labn.net   Don Fedyk   Alcatel-Lucent   Groton, MA 01450   Phone: +1-978-467-5645   EMail: donald.fedyk@alcatel-lucent.comBerger & Fedyk               Standards Track                   [Page 10]