diff options
Diffstat (limited to 'doc/rfc/rfc6215.txt')
| -rw-r--r-- | doc/rfc/rfc6215.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6215.txt b/doc/rfc/rfc6215.txt new file mode 100644 index 0000000..fdec02c --- /dev/null +++ b/doc/rfc/rfc6215.txt @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Bocci +Request for Comments: 6215 L. Levrau +Updates: 5921 Alcatel-Lucent +Category: Informational D. Frost +ISSN: 2070-1721 Cisco + April 2011 + + + MPLS Transport Profile User-to-Network + and Network-to-Network Interfaces + +Abstract + + The framework for MPLS in transport networks (RFC 5921) provides + reference models for the MPLS Transport Profile (MPLS-TP) Transport + Service Interfaces, which are a User-to-Network Interface (UNI), and + a Network-to-Network Interface (NNI). This document updates those + reference models to show detailed reference points for these + interfaces, along with further clarification of the functional + architecture of MPLS-TP at a UNI and NNI. + + This document is a product of a joint Internet Engineering Task Force + (IETF) / International Telecommunication Union Telecommunication + Standardization Sector (ITU-T) effort to include an MPLS Transport + Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge + (PWE3) architectures to support the capabilities and functionalities + of a packet transport network as defined by the ITU-T. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see 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/rfc6215. + + + + + + + + +Bocci, et al. Informational [Page 1] + +RFC 6215 MPLS-TP UNI and NNI April 2011 + + +Copyright Notice + + Copyright (c) 2011 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. + +1. Introduction + + The framework for MPLS in transport networks [RFC5921] provides + reference models for the MPLS Transport Profile (MPLS-TP) Transport + Service Interfaces, which are a User-to-Network Interface (UNI) and a + Network-to-Network Interface (NNI). This document updates those + reference models to show detailed reference points for these + interfaces, along with further clarification of the functional + architecture of MPLS-TP at a UNI and NNI. + + This document is a product of a joint Internet Engineering Task Force + (IETF) / International Telecommunication Union Telecommunication + Standardization Sector (ITU-T) effort to include an MPLS Transport + Profile within the IETF MPLS and PWE3 architectures to support the + capabilities and functionalities of a packet transport network as + defined by the ITU-T. + +1.1. Updates to the MPLS-TP UNI and NNI + + The Transport Service Interfaces for MPLS-TP are defined in Section + 3.4.3 of [RFC5921]. These definitions are illustrated by showing + MPLS-TP Provider Edges (PEs) containing a UNI and an NNI. The + figures illustrate the UNI and the NNI as a span. However, it is + convention to illustrate these interfaces as reference points. + Furthermore, in the case of a UNI, it is useful to illustrate the + distribution of UNI functions between the Customer Edge (CE) side and + the PE side of the UNI, i.e., the UNI-C (User-to-User Interface, + Client side) and UNI-N (User-to-Network Interface, Network side), in + order to show their relationship to one another. + + + + + + + +Bocci, et al. Informational [Page 2] + +RFC 6215 MPLS-TP UNI and NNI April 2011 + + + This document provides updated illustrations of the MPLS-TP UNI and + MPLS-TP NNI to show these additional details. These illustrations + obsolete the corresponding ones in [RFC5921]. This document also + defines additional terminology referenced in the illustrations. No + other updates are made by this document. + + Awareness of the Transport Service layer need exist only at PE nodes, + and so only these nodes are illustrated in the figures. MPLS-TP + Provider (P) nodes need have no awareness of this layer. Both PE and + P nodes participate in the Transport Path layer. A PE terminates + (i.e., is a Label Edge Router (LER) with respect to) the transport + paths it supports, and is responsible for multiplexing and + demultiplexing of Transport Service Instance traffic over such + transport paths. + +1.2. Terminology and Abbreviations + + The terminology and abbreviations of [RFC5921] apply. + + The following additional terminology is used in this document. + + Term Definition + ----- --------------------------------------- + CP Control Plane + NNI Network-to-Network Interface + TSI Transport Service Instance + UNI User-to-Network Interface + UNI-C User-to-Network Interface, Client side + UNI-N User-to-Network Interface, Network side + + Transport Service Instance: A single logical point-to-point + connection at the Transport Service layer between the ingress PE + providing a packet transport service to a CE, and the + corresponding egress PE to which the peer CE is attached. + +2. MPLS-TP User-to-Network Interface + + The MPLS-TP User-to-Network Interface (UNI) is illustrated in + Figure 1. This figure obsoletes Figure 3 of [RFC5921]. Note that + the term "MPLS-TP UNI" is to be interpreted as a UNI to an MPLS-TP + network and does not refer to the protocol transiting the UNI. The + UNI for a particular client flow may involve signaling between the CE + and PE. If signaling is used, it may traverse the same attachment + circuit that supports the client flow. + + + + + + + +Bocci, et al. Informational [Page 3] + +RFC 6215 MPLS-TP UNI and NNI April 2011 + + + UNI + : MPLS-TP + :<-- UNI-C -->: : :<-- UNI-N ->: Network <-----> + : function : : : function : + --------------- : ------------:-------------------- + : | : | : Transport | + : | V | Client : Path | + : | | Service : Mux/Demux | + : | | Control : -- | + : ---------- | | ----------: | | Transport| + :| | | | | | | | Path | + :|Signaling |_|___________|_|Signaling | | | ---------> + :|Controller| | | |Controller| | | | + : ---------- | | ---------- | | ---------> + : :......|...........|......: : | | | + : | Control | : | | Transport| + : | Channel | : | | Path | + : | | : | | ---------> + : | | : | | -+----------->TSI + : | | Transport : | | | ---------> + : | Client | Service : | | | | + : | Traffic | Data Plane: | | | | + : ---------- | Flows | -------------- | | |Transport| + :| Client |-|-----------|-|Client/Service|-| |- Path | + :| Traffic |=|===========|=| Traffic | | | ---------> + :|Processing| | | | Processing |=| |===+===========>TSI + : ---------- | | -------------- | | ---------> + : |______|___________|______| : | | | + : | Data Link | : | | | + : | | : -- | + : | | : Transport | + : | | : Path | + : | | : Data Plane| + --------------- --------------------------------- + + Customer Edge Node MPLS-TP Provider Edge Node + +Note: The client service control plane may be a control protocol + belonging to the native service, or GMPLS. + + Figure 1: UNI between CE Node and MPLS-TP PE Node + + + + + + + + + + +Bocci, et al. Informational [Page 4] + +RFC 6215 MPLS-TP UNI and NNI April 2011 + + +3. MPLS-TP Network-to-Network Interface + + The MPLS-TP Network-to-Network Interface (NNI) is illustrated in + Figure 2. This figure obsoletes Figure 5 of [RFC5921]. The NNI for + a particular Transport Service Instance may involve signaling between + the two PEs. If signaling is used, it may traverse the same data- + link that supports the service instance. + NNI + :<--- NNI --->: : :<--- NNI ---->: + : Function : : : Function : + --------------------------- : -------------------------- + | : Transport | : | Transport : | + | : Service CP | V | Service CP : | + | : ---------- |Signaling| ---------- : | + | : |Signaling |_| _______ |_|Signaling | : | + | : |Controller| | | |Controller| : | + | : ---------- | | ---------- : | + | : :....... Control .......: : | + | : | Channel | : | + | - : Transport | | Transport : - | + | | | : Path CP | | Path CP : | | | + | | | : ---------- |Signaling| ---------- : | | | + -----| | : |Signaling |_| _______ |_|Signaling | : | |----- + ---+-| | : |Controller| | | |Controller| : | |-+--- + -----| | : ---------- | | ---------- : | |----- + | | | : :....... Control .......: : | | | + | | | : | Channel | : | | | + | | | Transport Path | | Transport Path | | | + | | | / mux/demux \ | | / mux/demux \| | | + | | |/ : \-- | | -- / : | | | + | | | ---------- | | |Transport| | | ---------- | | | + | | |--|Transport |---| | | Path | | |---|Transport |--| | | + -----| | | Service | | |-------------| | | Service | | |----- + TSI+=| |==|Processing|===| |<+===TSI===+>| |===|Processing|==| |=+TSI + -----| | ---------- | |-------------| | ---------- | |----- + | | | : | | | | | | : | | | + | | | : | | | | | | : | | | + | - : -- | | -- : - | + | : | | : | + | Transport Path | | Transport Path | + | Data Plane | Data Plane | + --------------------------- -------------------------- + MPLS-TP Provider MPLS-TP Provider + Edge Node A Edge Node B + + Figure 2: NNI between MPLS-TP PE Nodes + + + + + +Bocci, et al. Informational [Page 5] + +RFC 6215 MPLS-TP UNI and NNI April 2011 + + +4. Security Considerations + + The security considerations of [RFC5921] apply. The updated + reference models provided by this document introduce no new security + considerations. + +5. Acknowledgements + + The editors wish to thank the following for their contribution to + this document: + + o Eve Varma + + o Dieter Beller + + o Lou Berger + + o Stewart Bryant + + o Italo Busi + + o The experts of ITU-T Study Group 15 and the IETF MPLS and PWE3 + working groups. + +6. Normative References + + [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. + Berger, "A Framework for MPLS in Transport Networks", + RFC 5921, July 2010. + +Authors' Addresses + + Matthew Bocci + Alcatel-Lucent + + EMail: matthew.bocci@alcatel-lucent.com + + + Lieven Levrau + Alcatel-Lucent + + EMail: lieven.levrau@alcatel-lucent.com + + + Dan Frost + Cisco + + EMail: danfrost@cisco.com + + + +Bocci, et al. Informational [Page 6] + |