doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc6005.txt b/doc/rfc/rfc6005.txt
new file mode 100644
index 0000000..19f2c11
--- /dev/null
+++ b/doc/rfc/rfc6005.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         L. Berger
+Request for Comments: 6005                                          LabN
+Category: Standards Track                                       D. Fedyk
+ISSN: 2070-1721                                           Alcatel-Lucent
+                                                            October 2010
+
+
+       Generalized MPLS (GMPLS) Support for Metro Ethernet Forum
+                and 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 in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 1]
+
+RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 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 Contents
+
+   1. Introduction ....................................................3
+      1.1. Overview ...................................................4
+      1.2. Conventions Used in This Document ..........................5
+   2. Common Signaling Support ........................................5
+      2.1. UNI Addressing .............................................5
+      2.2. Ethernet Endpoint (UNI) Identification .....................6
+           2.2.1. Address Resolution ..................................6
+      2.3. Connection Identification ..................................7
+   3. EPL Service .....................................................7
+   4. EVPL Service ....................................................7
+      4.1. Egress VLAN ID Control and VLAN ID Preservation ............7
+   5. IANA Considerations .............................................8
+      5.1. Error Value: Routing Problem/Unknown Endpoint ..............8
+   6. Security Considerations .........................................8
+   7. References ......................................................8
+      7.1. Normative References .......................................8
+      7.2. Informative References .....................................9
+   Acknowledgments ....................................................9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 2]
+
+RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010
+
+
+1.  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 Model
+
+1.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 and
+
+
+
+Berger & 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
+   in Section 2 of this document.  Procedures related to signaling
+   switching in support of EPL services are described in Section 3.
+   Procedures related to signaling switching in support of EVPL services
+   are described in Section 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 in Section 7.2 of [RFC4974] and modified
+   below in Section 2.2.1.
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                    [Page 5]
+
+RFC 6005          GMPLS Support for MEF and G.8011 UNI      October 2010
+
+
+2.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 in Section 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 to Section 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 in Section 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 in Section 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 2010
+
+
+5.  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 at http://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 in Section 2.2
+   above, parallels the replacement of information that occurs per
+   Section 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.  References
+
+7.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", RFC
+              4974, 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 2010
+
+
+Authors' 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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger & Fedyk               Standards Track                   [Page 10]
+