tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5921

 
 
 

A Framework for MPLS in Transport Networks

Part 2 of 3, p. 12 to 36
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
3.  MPLS Transport Profile Overview

3.1.  Packet Transport Services

   One objective of MPLS-TP is to enable MPLS networks to provide packet
   transport services with a similar degree of predictability to that
   found in existing transport networks.  Such packet transport services
   exhibit a number of characteristics, defined in [RFC5654]:

   o  In an environment where an MPLS-TP layer network is supporting a
      client layer network, and the MPLS-TP layer network is supported
      by a server layer network then operation of the MPLS-TP layer
      network must be possible without any dependencies on either the
      server or client layer network.

   o  The service provided by the MPLS-TP network to a given client will
      not fall below the agreed level as a result of the traffic loading
      of other clients.

   o  The control and management planes of any client network layer that
      uses the service is isolated from the control and management
      planes of the MPLS-TP layer network, where the client network
      layer is considered to be the native service of the MPLS-TP
      network.

   o  Where a client network makes use of an MPLS-TP server that
      provides a packet transport service, the level of coordination
      required between the client and server layer networks is minimal
      (preferably no coordination will be required).

   o  The complete set of packets generated by a client MPLS(-TP) layer
      network using the packet transport service, which may contain
      packets that are not MPLS packets (e.g., IP or CLNS
      (Connectionless Network Service) packets used by the control/
      management plane of the client MPLS(-TP) layer network), are
      transported by the MPLS-TP server layer network.

   o  The packet transport service enables the MPLS-TP layer network
      addressing and other information (e.g., topology) to be hidden
      from any client layer networks using that service, and vice-versa.

Top      Up      ToC       Page 13 
   These characteristics imply that a packet transport service does not
   support a connectionless packet-switched forwarding mode.  However,
   this does not preclude it carrying client traffic associated with a
   connectionless service.

3.2.  Scope of the MPLS Transport Profile

   Figure 1 illustrates the scope of MPLS-TP.  MPLS-TP solutions are
   primarily intended for packet transport applications.  MPLS-TP is a
   strict subset of MPLS, and comprises only those functions that are
   necessary to meet the requirements of [RFC5654].  This includes MPLS
   functions that were defined prior to [RFC5654] but that meet the
   requirements of [RFC5654], together with additional functions defined
   to meet those requirements.  Some MPLS functions defined before
   [RFC5654] such as Equal Cost Multi-Path (ECMP), LDP signaling when
   used in such a way that it creates multipoint-to-point LSPs, and IP
   forwarding in the data plane are explicitly excluded from MPLS-TP by
   that requirements specification.

   Note that MPLS as a whole will continue to evolve to include
   additional functions that do not conform to the MPLS Transport
   Profile or its requirements, and thus fall outside the scope of
   MPLS-TP.

  |<============================== MPLS ==============================>|
                                                     { Post-RFC5654    }
                                                     { non-Transport   }
                                                     {   Functions     }
  |<========== Pre-RFC5654 MPLS ===========>|
  {      ECMP       }
  { LDP/non-TE LSPs }
  {  IP forwarding  }

                    |<======== MPLS-TP ============>|
                                       { Additional }
                                       {  Transport }
                                       {  Functions }

                        Figure 1: Scope of MPLS-TP

   MPLS-TP can be used to construct packet networks and is therefore
   applicable in any packet network context.  A subset of MPLS-TP is
   also applicable to ITU-T-defined packet transport networks, where the
   transport network operational model is deemed attractive.

Top      Up      ToC       Page 14 
3.3.  Architecture

   MPLS-TP comprises the following architectural elements:

   o  A standard MPLS data plane [RFC3031] as profiled in [DATA-PLANE].

   o  Sections, LSPs, and PWs that provide a packet transport service
      for a client network.

   o  Proactive and on-demand Operations, Administration, and
      Maintenance (OAM) functions to monitor and diagnose the MPLS-TP
      network, as outlined in [OAM-FRAMEWORK].

   o  Control planes for LSPs and PWs, as well as support for static
      provisioning and configuration, as outlined in [CP-FRAMEWORK].

   o  Path protection mechanisms to ensure that the packet transport
      service survives anticipated failures and degradations of the
      MPLS-TP network, as outlined in [SURVIVE-FWK].

   o  Control-plane-based restoration mechanisms, as outlined in
      [SURVIVE-FWK].

   o  Network management functions, as outlined in [NM-FRAMEWORK].

   The MPLS-TP architecture for LSPs and PWs includes the following two
   sets of functions:

   o  MPLS-TP native service adaptation

   o  MPLS-TP forwarding

   The adaptation functions interface the native service (i.e., the
   client layer network service) to MPLS-TP.  This includes the case
   where the native service is an MPLS-TP LSP.

   The forwarding functions comprise the mechanisms required for
   forwarding the encapsulated native service traffic over an MPLS-TP
   server layer network, for example, PW and LSP labels.

3.3.1.  MPLS-TP Native Service Adaptation Functions

   The MPLS-TP native service adaptation functions interface the client
   layer network service to MPLS-TP.  For pseudowires, these adaptation
   functions are the payload encapsulation described in Section 4.4 of
   [RFC3985] and Section 6 of [RFC5659].  For network layer client
   services, the adaptation function uses the MPLS encapsulation format
   as defined in [RFC3032].

Top      Up      ToC       Page 15 
   The purpose of this encapsulation is to abstract the data plane of
   the client layer network from the MPLS-TP data plane, thus
   contributing to the independent operation of the MPLS-TP network.

   MPLS-TP is itself a client of an underlying server layer.  MPLS-TP is
   thus also bounded by a set of adaptation functions to this server
   layer network, which may itself be MPLS-TP.  These adaptation
   functions provide encapsulation of the MPLS-TP frames and for the
   transparent transport of those frames over the server layer network.
   The MPLS-TP client inherits its Quality of Service (QoS) from the
   MPLS-TP network, which in turn inherits its QoS from the server
   layer.  The server layer therefore needs to provide the necessary QoS
   to ensure that the MPLS-TP client QoS commitments can be satisfied.

3.3.2.  MPLS-TP Forwarding Functions

   The forwarding functions comprise the mechanisms required for
   forwarding the encapsulated native service traffic over an MPLS-TP
   server layer network, for example, PW and LSP labels.

   MPLS-TP LSPs use the MPLS label switching operations and Time-to-Live
   (TTL) processing procedures defined in [RFC3031], [RFC3032], and
   [RFC3443], as profiled in [DATA-PLANE].  These operations are highly
   optimized for performance and are not modified by the MPLS-TP
   profile.

   In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW
   forwarding operations defined in [RFC3985] and [RFC5659].

   Per-platform label space is used for PWs.  Either per-platform, per-
   interface, or other context-specific label space [RFC5331] may be
   used for LSPs.

   MPLS-TP forwarding is based on the label that identifies the
   transport path (LSP or PW).  The label value specifies the processing
   operation to be performed by the next hop at that level of
   encapsulation.  A swap of this label is an atomic operation in which
   the contents of the packet after the swapped label are opaque to the
   forwarder.  The only event that interrupts a swap operation is TTL
   expiry.  This is a fundamental architectural construct of MPLS to be
   taken into account when designing protocol extensions (such as those
   for OAM) that require packets to be sent to an intermediate LSR.

   Further processing to determine the context of a packet occurs when a
   swap operation is interrupted in this manner, or a pop operation
   exposes a specific reserved label at the top of the stack, or the

Top      Up      ToC       Page 16 
   packet is received with the GAL (Section 3.6) at the top of stack.
   Otherwise, the packet is forwarded according to the procedures in
   [RFC3032].

   MPLS-TP supports Quality of Service capabilities via the MPLS
   Differentiated Services (Diffserv) architecture [RFC3270].  Both
   E-LSP and L-LSP MPLS Diffserv modes are supported.

   Further details of MPLS-TP forwarding can be found in [DATA-PLANE].

3.4.  MPLS-TP Native Service Adaptation

   This document describes the architecture for two native service
   adaptation mechanisms, which provide encapsulation and demultiplexing
   for native service traffic traversing an MPLS-TP network:

   o  A PW

   o  An MPLS LSP

   MPLS-TP uses IETF-defined pseudowires to emulate certain services,
   for example, Ethernet, Frame Relay, or PPP / High-Level Data Link
   Control (HDLC).  A list of PW types is maintained by IANA in the
   "MPLS Pseudowire Type" registry.  When the native service adaptation
   is via a PW, the mechanisms described in Section 3.4.4 are used.

   An MPLS LSP can also provide the adaptation, in which case any native
   service traffic type supported by [RFC3031] and [RFC3032] is allowed.
   Examples of such traffic types include IP packets and MPLS-labeled
   packets.  Note that the latter case includes TE-LSPs [RFC3209] and
   LSP-based applications such as PWs, Layer 2 VPNs [RFC4664], and Layer
   3 VPNs [RFC4364].  When the native service adaptation is via an MPLS
   label, the mechanisms described in Section 3.4.5 are used.

3.4.1.  MPLS-TP Client/Server Layer Relationship

   The relationship between the client layer network and the MPLS-TP
   server layer network is defined by the MPLS-TP network boundary and
   the label context.  It is not explicitly indicated in the packet.  In
   terms of the MPLS label stack, when the native service traffic type
   is itself MPLS-labeled, then the S bits of all the labels in the
   MPLS-TP label stack carrying that client traffic are zero; otherwise,
   the bottom label of the MPLS-TP label stack has the S bit set to 1.
   In other words, there can be only one S bit set in a label stack.

   The data-plane behavior of MPLS-TP is the same as the best current
   practice for MPLS.  This includes the setting of the S bit.  In each
   case, the S bit is set to indicate the bottom (i.e., innermost) label

Top      Up      ToC       Page 17 
   in the label stack that is contiguous between the MPLS-TP LSP and its
   payload, and only one label stack entry (LSE) contains the S bit
   (Bottom of Stack bit) set to 1.  Note that this best current practice
   differs slightly from [RFC3032], which uses the S bit to identify
   when MPLS label processing stops and network layer processing starts.

   The relationship of MPLS-TP to its clients is illustrated in
   Figure 2.  Note that the label stacks shown in the figure are divided
   between those inside the MPLS-TP network and those within the client
   network when the client network is MPLS(-TP).  They illustrate the
   smallest number of labels possible.  These label stacks could also
   include more labels.

   PW-Based               MPLS Labeled                 IP
   Services                  Services                Transport
 |------------|  |-----------------------------|  |------------|

   Emulated        PW over LSP      IP over LSP         IP
   Service
                  +------------+
                  | PW Payload |
                  +------------+  +------------+               (CLIENTS)
                  |PW Lbl(S=1) |  |     IP     |
 +------------+   +------------+  +------------+  +------------+
 | PW Payload |   |LSP Lbl(S=0)|  |LSP Lbl(S=1)|  |     IP     |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 |PW Lbl (S=1)|   |LSP Lbl(S=0)|  |LSP Lbl(S=0)|  |LSP Lbl(S=1)|
 +------------+   +------------+  +------------+  +------------+
 |LSP Lbl(S=0)|         .               .               .
 +------------+         .               .               .      (MPLS-TP)
        .               .               .               .
        .
        .

~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary

                  Figure 2: MPLS-TP - Client Relationship

3.4.2.  MPLS-TP Transport Layers

   An MPLS-TP network consists logically of two layers: the Transport
   Service layer and the Transport Path layer.

   The Transport Service layer provides the interface between Customer
   Edge (CE) nodes and the MPLS-TP network.  Each packet transmitted by
   a CE node for transport over the MPLS-TP network is associated at the
   receiving MPLS-TP Provider Edge (PE) node with a single logical
   point-to-point connection at the Transport Service layer between this

Top      Up      ToC       Page 18 
   (ingress) PE and the corresponding (egress) PE to which the peer CE
   is attached.  Such a connection is called an MPLS-TP Transport
   Service Instance, and the set of client packets belonging to the
   native service associated with such an instance on a particular CE-PE
   link is called a client flow.

   The Transport Path layer provides aggregation of Transport Service
   Instances over MPLS-TP transport paths (LSPs), as well as aggregation
   of transport paths (via LSP hierarchy).

   Awareness of the Transport Service layer need exist only at PE nodes.
   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 an 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.

3.4.3.  MPLS-TP Transport Service Interfaces

   An MPLS-TP PE node can provide two types of interface to the
   Transport Service layer.  The MPLS-TP User-Network Interface (UNI)
   provides the interface between a CE and the MPLS-TP network.  The
   MPLS-TP Network-Network Interface (NNI) provides the interface
   between two MPLS-TP PEs in different administrative domains.

   When MPLS-TP is used to provide a transport service for, e.g., IP
   services that are a part of a Layer 3 VPN, then packets are
   transported in the same manner as specified in [RFC4364].

3.4.3.1.  User-Network Interface

   The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3.
   The UNI for a particular client flow may or may not involve signaling
   between the CE and PE, and if signaling is used, it may or may not
   traverse the same attachment circuit that supports the client flow.

Top      Up      ToC       Page 19 
    :          User-Network Interface        :           MPLS-TP
    :<-------------------------------------->:           Network <----->
    :                                        :
   -:-------------             --------------:------------------
    :             |           |              : Transport        |
    :             |           |  Transport   :   Path           |
    :             |           |   Service    : Mux/Demux        |
    :             |           |   Control    :    --            |
    :             |           |    Plane     :   |  |  Transport|
    : ----------  | Signaling |  ----------  :   |  |    Path   |
    :|Signaling |_|___________|_|Signaling | :   |  |    --------->
    :|Controller| |           | |Controller| :   |  |   |
    : ----------  |           |  ----------  :   |  |    --------->
    :      :......|...........|......:       :   |  |           |
    :             |  Control  |              :   |  |  Transport|
    :             |  Channel  |              :   |  |    Path   |
    :             |           |              :   |  |    --------->
    :             |           |              :   |  |  -+----------->TSI
    :             |           |  Transport   :   |  | |  --------->
    :             |  Client   |   Service    :   |  | |         |
    :             |  Traffic  |  Data Plane  :   |  | |         |
    : ----------  |  Flows    |  --------------  |  | |Transport|
    :|Signaling |-|-----------|-|Client/Service|-|  |-   Path   |
    :|Controller|=|===========|=|    Traffic   | |  |    --------->
    : ----------  |           | |  Processing  |=|  |===+===========>TSI
    :      |      |           |  --------------  |  |    --------->
    :      |______|___________|______|       :   |  |           |
    :             | Data Link |              :   |  |           |
    :             |           |              :    --            |
    :             |           |              :        Transport |
    :             |           |              :         Service  |
    :             |           |              :        Data Plane|
   ---------------             ---------------------------------
   Customer Edge Node              MPLS-TP Provider Edge Node


    TSI = Transport Service Instance

                   Figure 3: MPLS-TP PE Containing a UNI

Top      Up      ToC       Page 20 
        --------------From UNI------->            :
       -------------------------------------------:------------------
      |                     | Client Traffic Unit :                  |
      | Link-Layer-Specific | Link Decapsulation  : Service Instance |
      |    Processing       |         &           :    Transport     |
      |                     |  Service Instance   :  Encapsulation   |
      |                     |   Identification    :                  |
       -------------------------------------------:------------------
                                                  :
                                                  :
       -------------------------------------------:------------------
      |                     |                     : Service Instance |
      |                     |                     :    Transport     |
      | Link-Layer-Specific | Client Traffic Unit :  Decapsulation   |
      |    Processing       | Link Encapsulation  :        &         |
      |                     |                     : Service Instance |
      |                     |                     :  Identification  |
       -------------------------------------------:------------------
        <-------------To UNI ---------            :

       Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages

   Figure 4 shows the logical processing steps involved in a PE both for
   traffic flowing from the CE to the MPLS-TP network (left to right),
   and from the network to the CE (right to left).

   In the first case, when a packet from a client flow is received by
   the PE from the CE over the data-link, the following steps occur:

   1.  Link-layer-specific pre-processing, if any, is performed.  An
       example of such pre-processing is the PREP function illustrated
       in Figure 3 of [RFC3985].  Such pre-processing is outside the
       scope of MPLS-TP.

   2.  The packet is extracted from the data-link frame, if necessary,
       and associated with a Transport Service Instance.  At this point,
       UNI processing has completed.

   3.  A transport service encapsulation is associated with the packet,
       if necessary, for transport over the MPLS-TP network.

   4.  The packet is mapped to a transport path based on its associated
       Transport Service Instance, the transport path encapsulation is
       added, if necessary, and the packet is transmitted over the
       transport path.

Top      Up      ToC       Page 21 
   In the second case, when a packet associated with a Transport Service
   Instance arrives over a transport path, the following steps occur:

   1.  The transport path encapsulation is disposed of.

   2.  The transport service encapsulation is disposed of and the
       Transport Service Instance and client flow identified.

   3.  At this point, UNI processing begins.  A data-link encapsulation
       is associated with the packet for delivery to the CE based on the
       client flow.

   4.  Link-layer-specific postprocessing, if any, is performed.  Such
       postprocessing is outside the scope of MPLS-TP.

3.4.3.2.  Network-Network Interface

   The MPLS-TP NNI is illustrated in Figure 5.  The NNI for a particular
   Transport Service Instance may or may not involve signaling between
   the two PEs; and if signaling is used, it may or may not traverse the
   same data-link that supports the service instance.

Top      Up      ToC       Page 22 
                   :      Network-Network Interface    :
                   :<--------------------------------->:
                   :                                   :
       ------------:-------------         -------------:------------
      |  Transport :             |       |             : Transport  |
      |    Path    : Transport   |       |  Transport  :   Path     |
      |  Mux/Demux :  Service    |       |   Service   : Mux/Demux  |
      |      --    :  Control    |       |   Control   :    --      |
      |     |  |   :   Plane     |Sig-   |    Plane    :   |  |     |
      |TP   |  |   : ----------  | naling|  ---------- :   |  |   TP|
    <---    |  |   :|Signaling |_|_______|_|Signaling |:   |  |    --->
   TSI<-+-  |  |   :|Controller| |       | |Controller|:   |  |   |
    <---  | |  |   : ----------  |       |  ---------- :   |  |    --->
      |   | |  |   :      :......|.......|......:      :   |  |     |
      |   | |  |   :             |Control|             :   |  |     |
      |TP | |  |   :             |Channel|             :   |  |   TP|
    <---  | |  |   :             |       |             :   |  |    --->
        | | |  |   :             |       |             :   |  |  -+->TSI
    <---  | |  |   : Transport   |       |  Transport  :   |  | |  --->
      |   | |  |   :  Service    |Service|   Service   :   |  | |   |
      |   | |  |   : Data Plane  |Traffic|  Data Plane :   |  | |   |
      |   | |  |  -------------  | Flows |  -------------  |  | |   |
      |TP  -|  |-|   Service   |-|-------|-|   Service   |-|  |-  TP|
    <---    |  | |   Traffic   | |       | |   Traffic   | |  |    --->
   TSI<=+===|  |=|  Processing |=|=======|=|  Processing |=|  |===+=>TSI
    <---    |  |  -------------  |       |  -------------  |  |    --->
      |     |  |   :      |______|_______|______|      :   |  |     |
      |     |  |   :             | Data  |             :   |  |     |
      |      --    :             | Link  |             :    --      |
      |            :             |       |             :            |
       --------------------------         --------------------------
       MPLS-TP Provider Edge Node         MPLS-TP Provider Edge Node


    TP  = Transport Path
    TSI = Transport Service Instance

                  Figure 5: MPLS-TP PE Containing an NNI

Top      Up      ToC       Page 23 
                                                   :
        --------------From NNI------->             :
       --------------------------------------------:------------------
      |                     | Service Traffic Unit :                  |
      | Link-Layer-Specific |  Link Decapsulation  : Service Instance |
      |    Processing       |          &           :  Encapsulation   |
      |                     |   Service Instance   :  Normalization   |
      |                     |    Identification    :                  |
       --------------------------------------------:------------------
                                                   :
                                                   :
       --------------------------------------------:------------------
      |                     |                      : Service Instance |
      |                     |                      :  Identification  |
      | Link-Layer-Specific | Service Traffic Unit :        &         |
      |    Processing       |  Link Encapsulation  : Service Instance |
      |                     |                      :  Encapsulation   |
      |                     |                      :  Normalization   |
       --------------------------------------------:------------------
        <-------------To NNI ---------             :

          Figure 6: MPLS-TP NNI Service Traffic Processing Stages

   Figure 6 shows the logical processing steps involved in a PE for
   traffic flowing both from the peer PE (left to right) and to the peer
   PE (right to left).

   In the first case, when a packet from a Transport Service Instance is
   received by the PE from the peer PE over the data-link, the following
   steps occur:

   1.  Link-layer specific pre-processing, if any, is performed.  Such
       pre-processing is outside the scope of MPLS-TP.

   2.  The packet is extracted from the data-link frame if necessary,
       and associated with a Transport Service Instance.  At this point,
       NNI processing has completed.

   3.  The transport service encapsulation of the packet is normalized
       for transport over the MPLS-TP network.  This step allows a
       different transport service encapsulation to be used over the NNI
       than that used in the internal MPLS-TP network.  An example of
       such normalization is a swap of a label identifying the Transport
       Service Instance.

Top      Up      ToC       Page 24 
   4.  The packet is mapped to a transport path based on its associated
       Transport Service Instance, the transport path encapsulation is
       added, if necessary, and the packet is transmitted over the
       transport path.

   In the second case, when a packet associated with a Transport Service
   Instance arrives over a transport path, the following steps occur:

   1.  The transport path encapsulation is disposed of.

   2.  The Transport Service Instance is identified from the transport
       service encapsulation, and this encapsulation is normalized for
       delivery over the NNI (see Step 3 above).

   3.  At this point, NNI processing begins.  A data-link encapsulation
       is associated with the packet for delivery to the peer PE based
       on the normalized Transport Service Instance.

   4.  Link-layer-specific postprocessing, if any, is performed.  Such
       postprocessing is outside the scope of MPLS-TP.

3.4.3.3.  Example Interfaces

   This section considers some special cases of UNI processing for
   particular transport service types.  These are illustrative, and do
   not preclude other transport service types.

3.4.3.3.1.  Layer 2 Transport Service

   In this example the MPLS-TP network is providing a point-to-point
   Layer 2 transport service between attached CE nodes.  This service is
   provided by a Transport Service Instance consisting of a PW
   established between the associated PE nodes.  The client flows
   associated with this Transport Service Instance are the sets of all
   Layer 2 frames transmitted and received over the attachment circuits.

   The processing steps in this case for a frame received from the CE
   are:

   1.  Link-layer specific pre-processing, if any, is performed,
       corresponding to the PREP function illustrated in Figure 3 of
       [RFC3985].

   2.  The frame is associated with a Transport Service Instance based
       on the attachment circuit over which it was received.

   3.  A transport service encapsulation, consisting of the PW control
       word and PW label, is associated with the frame.

Top      Up      ToC       Page 25 
   4.  The resulting packet is mapped to an LSP, the LSP label is
       pushed, and the packet is transmitted over the outbound interface
       associated with the LSP.

   For PW packets received over the LSP, the steps are performed in the
   reverse order.

3.4.3.3.2.  IP Transport Service

   In this example, the MPLS-TP network is providing a point-to-point IP
   transport service between CE1, CE2, and CE3, as follows.  One point-
   to-point Transport Service Instance delivers IPv4 packets between CE1
   and CE2, and another instance delivers IPv6 packets between CE1 and
   CE3.

   The processing steps in this case for an IP packet received from CE1
   are:

   1.  No link-layer-specific processing is performed.

   2.  The IP packet is extracted from the link-layer frame and
       associated with a Service LSP based on the source MAC address
       (CE1) and the IP protocol version.

   3.  A transport service encapsulation, consisting of the Service LSP
       label, is associated with the packet.

   4.  The resulting packet is mapped to a tunnel LSP, the tunnel LSP
       label is pushed, and the packet is transmitted over the outbound
       interface associated with the LSP.

   For packets received over a tunnel LSP carrying the Service LSP
   label, the steps are performed in the reverse order.

3.4.4.  Pseudowire Adaptation

   MPLS-TP uses pseudowires to provide a Virtual Private Wire Service
   (VPWS), a Virtual Private Local Area Network Service (VPLS), a
   Virtual Private Multicast Service (VPMS), and an Internet Protocol
   Local Area Network Service (IPLS).  VPWS, VLPS, and IPLS are
   described in [RFC4664].  VPMS is described in [VPMS-REQS].

   If the MPLS-TP network provides a layer 2 interface (that can carry
   both network-layer and non-network-layer traffic) as a service
   interface, then a PW is required to support the service interface.
   The PW is a client of the MPLS-TP LSP server layer.  The architecture
   for an MPLS-TP network that provides such services is based on the
   MPLS [RFC3031] and pseudowire [RFC3985] architectures.  Multi-segment

Top      Up      ToC       Page 26 
   pseudowires may optionally be used to provide a packet transport
   service, and their use is consistent with the MPLS-TP architecture.
   The use of MS-PWs may be motivated by, for example, the requirements
   specified in [RFC5254].  If MS-PWs are used, then the MS-PW
   architecture [RFC5659] also applies.

   Figure 7 shows the architecture for an MPLS-TP network using single-
   segment PWs.  Note that, in this document, the client layer is
   equivalent to the emulated service described in [RFC3985], while the
   Transport LSP is equivalent to the Packet Switched Network (PSN)
   tunnel of [RFC3985].

            |<----------------- Client Layer ------------------->|
            |                                                    |
            |          |<-------- Pseudowire -------->|          |
            |          |      encapsulated, packet    |          |
            |          |      transport service       |          |
            |          |                              |          |
            |          |          Transport           |          |
            |          |    |<------ LSP ------->|    |          |
            |          V    V                    V    V          |
            V    AC    +----+      +-----+       +----+     AC   V
      +-----+    |     | PE1|=======\   /========| PE2|     |    +-----+
      |     |----------|.......PW1.| \ / |............|----------|     |
      | CE1 |    |     |    |      |  X  |       |    |     |    | CE2 |
      |     |----------|.......PW2.| / \ |............|----------|     |
      +-----+  ^ |     |    |=======/   \========|    |     | ^  +-----+
            ^  |       +----+   ^  +-----+       +----+       |  ^
            |  |      Provider  |     ^         Provider      |  |
            |  |       Edge 1   |     |           Edge 2      |  |
     Customer  |                |  P Router                   | Customer
      Edge 1   |             TE LSP                           |  Edge 2
               |                                              |
               |                                              |
         Native service                                 Native service

            Figure 7: MPLS-TP Architecture (Single Segment PW)

   Figure 8 shows the architecture for an MPLS-TP network when multi-
   segment pseudowires are used.  Note that as in the SS-PW case,
   P-routers may also exist.

Top      Up      ToC       Page 27 
     |<--------------------- Client Layer ------------------------>|
     |                                                             |
     |                  Pseudowire encapsulated,                   |
     |    |<---------- Packet Transport Service ------------->|    |
     |    |                                                   |    |
     |    |              Transport               Transport    |    |
     | AC |     |<-------- LSP1 --------->|    |<--LSP2-->|   | AC |
     | |  V     V                         V    V          V   V |  |
     V |  +----+              +-----+    +----+          +----+ |  V
 +---+ |  |TPE1|===============\   /=====|SPE1|==========|TPE2| |  +---+
 |   |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----|   |
 |CE1| |  |    |              |  X  |    |    |          |    | |  |CE2|
 |   |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----|   |
 +---+  ^ |    |===============/   \=====|    |==========|    | | ^+---+
        | +----+     ^        +-----+    +----+     ^    +----+   |
        |            |           ^                  |             |
        |          TE LSP        |                TE LSP          |
        |                      P-router                           |
 Native Service                                          Native Service


 PW1-segment1 and PW1-segment2 are segments of the same MS-PW,
 while PW2-segment1 and PW2-segment2 are segments of another MS-PW.

             Figure 8: MPLS-TP Architecture (Multi-Segment PW)

   The corresponding MPLS-TP protocol stacks including PWs are shown in
   Figure 9.  In this figure, the Transport Service layer [RFC5654] is
   identified by the PW demultiplexer (Demux) label, and the Transport
   Path layer [RFC5654] is identified by the LSP Demux Label.

Top      Up      ToC       Page 28 
  +-------------------+    /===================\   /===================\
  |  Client Layer     |    H     OAM PDU       H   H     OAM PDU       H
  /===================\    H-------------------H   H-------------------H
  H     PW Encap      H    H      GACh         H   H      GACh         H
  H-------------------H    H-------------------H   H-------------------H
  H   PW Demux (S=1)  H    H PW Demux (S=1)    H   H    GAL (S=1)      H
  H-------------------H    H-------------------H   H-------------------H
  H Trans LSP Demux(s)H    H Trans LSP Demux(s)H   H Trans LSP Demux(s)H
  \===================/    \===================/   \===================/
  |    Server Layer   |    |   Server Layer    |   |   Server Layer    |
  +-------------------+    +-------------------+   +-------------------+

      User Traffic                PW OAM                  LSP OAM

 Note: H(ighlighted) indicates the part of the protocol stack considered
 in this document.

              Figure 9: MPLS-TP Label Stack Using Pseudowires

   PWs and their associated labels may be configured or signaled.  See
   Section 3.11 for additional details related to configured service
   types.  See Section 3.9 for additional details related to signaled
   service types.

3.4.5.  Network Layer Adaptation

   MPLS-TP LSPs can be used to transport network-layer clients.  This
   document uses the term Network Layer in the same sense as it is used
   in [RFC3031] and [RFC3032].  The network-layer protocols supported by
   [RFC3031] and [RFC3032] can be transported between service
   interfaces.  Support for network-layer clients follows the MPLS
   architecture for support of network-layer protocols as specified in
   [RFC3031] and [RFC3032].

   With network-layer adaptation, the MPLS-TP domain provides either a
   unidirectional or bidirectional point-to-point connection between two
   PEs in order to deliver a packet transport service to attached
   customer edge (CE) nodes.  For example, a CE may be an IP, MPLS, or
   MPLS-TP node.  As shown in Figure 10, there is an attachment circuit
   between the CE node on the left and its corresponding provider edge
   (PE) node (which provides the service interface), a bidirectional LSP
   across the MPLS-TP network to the corresponding PE node on the right,
   and an attachment circuit between that PE node and the corresponding
   CE node for this service.

   The attachment circuits may be heterogeneous (e.g., any combination
   of SDH, PPP, Frame Relay, etc.) and network-layer protocol payloads
   arrive at the service interface encapsulated in the Layer 1 / Layer 2

Top      Up      ToC       Page 29 
   encoding defined for that access link type.  It should be noted that
   the set of network-layer protocols includes MPLS, and hence MPLS-
   encoded packets with an MPLS label stack (the client MPLS stack) may
   appear at the service interface.

   The following figures illustrate the reference models for network-
   layer adaptation.  The details of these figures are described further
   in the following paragraphs.

            |<------------- Client Network Layer --------------->|
            |                                                    |
            |          |<----------- Packet --------->|          |
            |          |         Transport Service    |          |
            |          |                              |          |
            |          |                              |          |
            |          |          Transport           |          |
            |          |    |<------ LSP ------->|    |          |
            |          V    V                    V    V          |
            V    AC    +----+      +-----+       +----+     AC   V
      +-----+    |     | PE1|=======\   /========| PE2|     |    +-----+
      |     |----------|..Svc LSP1.| \ / |............|----------|     |
      | CE1 |    |     |    |      |  X  |       |    |     |    | CE2 |
      |     |----------|..Svc LSP2.| / \ |............|----------|     |
      +-----+  ^ |     |    |=======/   \========|    |     | ^  +-----+
            ^  |       +----+  ^   +-----+       +----+     | |  ^
            |  |      Provider |       ^         Provider     |  |
            |  |       Edge 1  |       |          Edge 2      |  |
      Customer |               |    P Router                  | Customer
       Edge 1  |             TE LSP                           |  Edge 2
               |                                              |
               |                                              |
         Native service                                 Native service

         Figure 10: MPLS-TP Architecture for Network-Layer Clients

Top      Up      ToC       Page 30 
    |<--------------------- Client Layer ------------------------>|
    |                                                             |
    |                                                             |
    |    |<---------- Packet Transport Service ------------->|    |
    |    |                                                   |    |
    |    |              Transport               Transport    |    |
    | AC |     |<-------- LSP1 --------->|    |<--LSP2-->|   | AC |
    | |  V     V                         V    V          V   V |  |
    V |  +----+              +-----+    +----+          +----+ |  V
+---+ |  | PE1|===============\   /=====| PE2|==========| PE3| |  +---+
|   |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----|   |
|CE1| |  |    |              |  X  |    |    |          |    | |  |CE2|
|   |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----|   |
+---+  ^ |    |===============/   \=====|    |==========|    | | ^+---+
       | +----+     ^        +-----+    +----+     ^    +----+   |
       |            |           ^         ^        |             |
       |          TE LSP        |         |      TE LSP          |
       |                      P-router    |                      |
Native Service               (LSR for     |               Native Service
                             T'port LSP1) |
                                          |
                                  LSR for Service LSPs
                                  LER for Transport LSPs

   Figure 11: MPLS-TP Architecture for Network Layer Adaptation, Showing
                           Service LSP Switching

   Client packets are received at the ingress service interface.  The PE
   pushes one or more labels onto the client packets that are then label
   switched over the transport network.  Correspondingly, the egress PE
   pops any labels added by the MPLS-TP networks and transmits the
   packet for delivery to the attached CE via the egress service
   interface.

Top      Up      ToC       Page 31 
                           /===================\
                           H     OAM PDU       H
  +-------------------+    H-------------------H   /===================\
  |  Client Layer     |    H      GACh         H   H     OAM PDU       H
  /===================\    H-------------------H   H-------------------H
  H    Encap Label    H    H      GAL (S=1)    H   H      GACh         H
  H-------------------H    H-------------------H   H-------------------H
  H   SvcLSP Demux    H    H SvcLSP Demux (S=0)H   H    GAL (S=1)      H
  H-------------------H    H-------------------H   H-------------------H
  H Trans LSP Demux(s)H    H Trans LSP Demux(s)H   H Trans LSP Demux(s)H
  \===================/    \===================/   \===================/
  |   Server Layer    |    |   Server Layer    |   |   Server Layer    |
  +-------------------+    +-------------------+   +-------------------+

      User Traffic           Service LSP OAM             LSP OAM


 Note: H(ighlighted) indicates the part of the protocol stack considered
 in this document.

           Figure 12: MPLS-TP Label Stack for IP and LSP Clients

   In the figures above, the Transport Service layer [RFC5654] is
   identified by the Service LSP (SvcLSP) demultiplexer (Demux) label,
   and the Transport Path layer [RFC5654] is identified by the Transport
   (Trans) LSP Demux Label.  Note that the functions of the
   Encapsulation Label (Encap Label) and the Service Label (SvcLSP
   Demux) shown above may alternatively be represented by a single label
   stack entry.  Note that the S bit is always zero when the client
   layer is MPLS-labeled.  It may be necessary to swap a service LSP
   label at an intermediate node.  This is shown in Figure 11.

   Within the MPLS-TP transport network, the network-layer protocols are
   carried over the MPLS-TP network using a logically separate MPLS
   label stack (the server stack).  The server stack is entirely under
   the control of the nodes within the MPLS-TP transport network and it
   is not visible outside that network.  Figure 12 shows how a client
   network protocol stack (which may be an MPLS label stack and payload)
   is carried over a network layer client service over an MPLS-TP
   transport network.

   A label may be used to identify the network-layer protocol payload
   type.  Therefore, when multiple protocol payload types are to be
   carried over a single service LSP, a unique label stack entry needs
   to be present for each payload type.  Such labels are referred to as
   "Encapsulation Labels", one of which is shown in Figure 12.  An
   Encapsulation Label may be either configured or signaled.

Top      Up      ToC       Page 32 
   Both an Encapsulation Label and a Service Label should be present in
   the label stack when a particular packet transport service is
   supporting more than one network-layer protocol payload type.  For
   example, if both IP and MPLS are to be carried, then two
   Encapsulation Labels are mapped on to a common Service Label.

   Note: The Encapsulation Label may be omitted when the service LSP is
   supporting only one network-layer protocol payload type.  For
   example, if only MPLS labeled packets are carried over a service,
   then the Service Label (stack entry) provides both the payload type
   indication and service identification.  The Encapsulation Label
   cannot have any of the reserved label values [RFC3032].

   Service labels are typically carried over an MPLS-TP Transport LSP
   edge-to-edge (or transport path layer).  An MPLS-TP Transport LSP is
   represented as an LSP Transport Demux label, as shown in Figure 12.
   Transport LSP is commonly used when more than one service exists
   between two PEs.

   Note that, if only one service exists between two PEs, the functions
   of the Transport LSP label and the Service LSP Label may be combined
   into a single label stack entry.  For example, if only one service is
   carried between two PEs, then a single label could be used to provide
   both the service indication and the MPLS-TP Transport LSP.
   Alternatively, if multiple services exist between a pair of PEs, then
   a per-client Service Label would be mapped on to a common MPLS-TP
   Transport LSP.

   As noted above, the Layer 2 and Layer 1 protocols used to carry the
   network-layer protocol over the attachment circuits are not
   transported across the MPLS-TP network.  This enables the use of
   different Layer 2 and Layer 1 protocols on the two attachment
   circuits.

   At each service interface, Layer 2 addressing needs to be used to
   ensure the proper delivery of a network-layer packet to the adjacent
   node.  This is typically only an issue for LAN media technologies
   (e.g., Ethernet) that have Media Access Control (MAC) addresses.  In
   cases where a MAC address is needed, the sending node sets the
   destination MAC address to an address that ensures delivery to the
   adjacent node.  That is, the CE sets the destination MAC address to
   an address that ensures delivery to the PE, and the PE sets the
   destination MAC address to an address that ensures delivery to the
   CE.  The specific address used is technology type specific and is not
   specified in this document.  In some technologies, the MAC address
   will need to be configured.

Top      Up      ToC       Page 33 
   Note that when two CEs, which peer with each other, operate over a
   network layer transport service and run a routing protocol such as
   IS-IS or OSPF, some care should be taken to configure the routing
   protocols to use point-to-point adjacencies.  The specifics of such
   configuration is outside the scope of this document.  See [RFC5309]
   for additional details.

   The CE-to-CE service types and corresponding labels may be configured
   or signaled.

3.5.  Identifiers

   Identifiers are used to uniquely distinguish entities in an MPLS-TP
   network.  These include operators, nodes, LSPs, pseudowires, and
   their associated maintenance entities.  MPLS-TP defined two types of
   sets of identifiers: those that are compatible with IP, and those
   that are compatible with ITU-T transport-based operations.  The
   definition of these sets of identifiers is outside the scope of this
   document and is provided by [IDENTIFIERS].

3.6.  Generic Associated Channel (G-ACh)

   For correct operation of OAM mechanisms, it is important that OAM
   packets fate-share with the data packets.  In addition, in MPLS-TP it
   is necessary to discriminate between user data payloads and other
   types of payload.  For example, a packet may be associated with a
   Signaling Communication Channel (SCC) or a channel used for a
   protocol to coordinate path protection state.  This is achieved by
   carrying such packets in either:

   o  A generic control channel associated to the LSP, PW, or section,
      with no IP encapsulation, e.g., in a similar manner to
      Bidirectional Forwarding Detection for Virtual Circuit
      Connectivity Verification (VCCV-BFD) with PW ACH encapsulation
      [RFC5885]).

   o  An IP encapsulation where IP capabilities are present, e.g., PW
      ACH encapsulation with IP headers for VCCV-BFD [RFC5885] or IP
      encapsulation for MPLS BFD [RFC5884].

   MPLS-TP makes use of such a generic associated channel (G-ACh) to
   support Fault, Configuration, Accounting, Performance, and Security
   (FCAPS) functions by carrying packets related to OAM, a protocol used
   to coordinate path protection state, SCC, MCC or other packet types
   in-band over LSPs, PWs, or sections.  The G-ACh is defined in
   [RFC5586] and is similar to the Pseudowire Associated Channel
   [RFC4385], which is used to carry OAM packets over pseudowires.  The
   G-ACh is indicated by an Associated Channel Header (ACH), similar to

Top      Up      ToC       Page 34 
   the Pseudowire VCCV control word; this header is present for all
   sections, LSPs, and PWs that make use of FCAPS functions supported by
   the G-ACh.

   As specified in [RFC5586], the G-ACh must only be used for channels
   that are an adjunct to the data service.  Examples of these are OAM,
   a protocol used to coordinate path protection state, MCC, and SCC,
   but the use is not restricted to these services.  The G-ACh must not
   be used to carry additional data for use in the forwarding path,
   i.e., it must not be used as an alternative to a PW control word, or
   to define a PW type.

   At the server layer, bandwidth and QoS commitments apply to the gross
   traffic on the LSP, PW, or section.  Since the G-ACh traffic is
   indistinguishable from the user data traffic, protocols using the
   G-ACh need to take into consideration the impact they have on the
   user data with which they are sharing resources.  Conversely,
   capacity needs to be made available for important G-ACh uses such as
   protection and OAM.  In addition, the security and congestion
   considerations described in [RFC5586] apply to protocols using the
   G-ACh.

   Figure 13 shows the reference model depicting how the control channel
   is associated with the pseudowire protocol stack.  This is based on
   the reference model for VCCV shown in Figure 2 of [RFC5085].

Top      Up      ToC       Page 35 
          +-------------+                                +-------------+
          |  Payload    |           < FCAPS >            |  Payload    |
          +-------------+                                +-------------+
          |   Demux /   |         < ACH for PW >         |   Demux /   |
          |Discriminator|                                |Discriminator|
          +-------------+                                +-------------+
          |     PW      |             < PW >             |     PW      |
          +-------------+                                +-------------+
          |    PSN      |             < LSP >            |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|        MPLS-TP Network          |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

     Figure 13: PWE3 Protocol Stack Reference Model Showing the G-ACh

   PW-associated channel messages are encapsulated using the PWE3
   encapsulation, so that they are handled and processed in the same
   manner (or in some cases, an analogous manner) as the PW PDUs for
   which they provide a control channel.

   Figure 14 shows the reference model depicting how the control channel
   is associated with the LSP protocol stack.

Top      Up      ToC       Page 36 
          +-------------+                                +-------------+
          |  Payload    |           < FCAPS >            |   Payload   |
          +-------------+                                +-------------+
          |Discriminator|         < ACH on LSP >         |Discriminator|
          +-------------+                                +-------------+
          |Demultiplexer|         < GAL on LSP >         |Demultiplexer|
          +-------------+                                +-------------+
          |    PSN      |            < LSP >             |    PSN      |
          +-------------+                                +-------------+
          |  Physical   |                                |  Physical   |
          +-----+-------+                                +-----+-------+
                |                                              |
                |             ____     ___       ____          |
                |           _/    \___/   \    _/    \__       |
                |          /               \__/         \_     |
                |         /                               \    |
                +--------|        MPLS-TP Network          |---+
                          \                               /
                           \   ___      ___     __      _/
                            \_/   \____/   \___/  \____/

      Figure 14: MPLS Protocol Stack Reference Model Showing the LSP
                        Associated Control Channel



(page 36 continued on part 3)

Next RFC Part