RFC 6215

MPLS Transport Profile User-to-Network and Network-to-Network Interfaces

📅 published April 2011, from ietf

MPLS Transport Profile User-to-Network and Network-to-Network Interfaces 🦋

Okay bestie, this is RFC 6215 🎀. It's by M. Bocci and L. Levrau from Alcatel-Lucent, with D. Frost from Cisco. It's an Informational doc, not a Standards Track one, with ISSN 2070-1721, dated April 2011. It updates RFC 5921 ✨, and it doesn't list anything it obsoletes.

Abstract 🌸

So the framework for MPLS in transport networks (RFC 5921) gives 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 doc updates those models to show detailed reference points for these interfaces, plus it clarifies the functional architecture of MPLS-TP at a UNI and an NNI 💅.

It's also a joint IETF / ITU-T project 🌈. The goal is to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so they can support what a packet transport network can do as defined by the ITU-T.

Status of This Memo 📜

Not an Internet Standards Track spec, it's published just for information 💜.

This is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 🤓.

For the current status, errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc6215 🔗.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📖. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚠️.

1. Introduction 🌸

Okay so the framework for MPLS in transport networks [RFC5921] gives 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 doc updates those models to show detailed reference points for these interfaces, and it clarifies the functional architecture of MPLS-TP at a UNI and an NNI 🫶.

It's a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort. The idea is to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures, so they support the capabilities and functions of a packet transport network as the ITU-T defines them 🧚.

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]. Those definitions get illustrated by showing MPLS-TP Provider Edges (PEs) that contain a UNI and an NNI. The figures show the UNI and the NNI as a span, but it's convention to draw these interfaces as reference points instead 📐. For a UNI in particular, it's useful to show how the UNI functions are split between the Customer Edge (CE) side and the PE side. That's the UNI-C (User-to-User Interface, Client side) and the UNI-N (User-to-Network Interface, Network side), so you can see how they relate to each other 👀.

This doc has updated illustrations of the MPLS-TP UNI and MPLS-TP NNI that show these extra details. These illustrations obsolete the matching ones in [RFC5921]. The doc also defines extra terminology used in the illustrations. No other updates are made by this doc 💖.

Only PE nodes need to be aware of the Transport Service layer, so only PE nodes get drawn in the figures. MPLS-TP Provider (P) nodes don't need any awareness of that layer 🙈. Both PE and P nodes take part in the Transport Path layer. A PE terminates the transport paths it supports (i.e., it is a Label Edge Router (LER) with respect to them), and it handles multiplexing and demultiplexing of Transport Service Instance traffic over those transport paths 🔥.

1.2. Terminology and Abbreviations 📚

The terminology and abbreviations of [RFC5921] apply here, and this doc adds a few more 🌷:

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

The big one is Transport Service Instance (TSI): a single logical point-to-point connection at the Transport Service layer, between the ingress PE that gives a packet transport service to a CE, and the matching egress PE that the peer CE is attached to 💜.

2. MPLS-TP User-to-Network Interface 🎀

The MPLS-TP User-to-Network Interface (UNI) is shown in Figure 1 🎀. This figure obsoletes Figure 3 of [RFC5921]. Quick heads up: "MPLS-TP UNI" means a UNI to an MPLS-TP network. It does NOT refer to whatever protocol is crossing the UNI 🙃. A UNI for a particular client flow may involve signaling between the CE and the PE. If signaling is used, it may go over the same attachment circuit that supports the client flow 🦋.

                       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

3. MPLS-TP Network-to-Network Interface 🔥

The MPLS-TP Network-to-Network Interface (NNI) is shown 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 go over 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

4. Security Considerations ✨

okay bestie, security time 🔒 The security considerations of [RFC5921] apply, so go read that one too 📖 The updated reference models in this document don't add any new security considerations 💖 Nothing new to panic about, but the older rules from [RFC5921] still matter, so don't skip them 💅

5. Acknowledgements 🫶

The editors want to give a shoutout to these amazing people for helping make this document happen 🎀

  • Eve Varma 🌸
  • Dieter Beller 🦋
  • Lou Berger 💜
  • Stewart Bryant 👑
  • Italo Busi ✨
  • The experts of ITU-T Study Group 15 and the IETF MPLS and PWE3 working groups 🌈 (the whole squad, honestly iconic 😭)

6. Normative References 📚

Here's the reference you need to know about, so bookmark it 🔖

[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 💌

These are the people who wrote it, and how to reach them 💖

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

That's the whole RFC, bestie 🌈✨ It's giving tidy, precise, and genuinely brilliant 👑💅

📦 where this page comes from