RFC 5921
A Framework for MPLS in Transport Networks
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.
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.
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].
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
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
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 Relationship3.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
(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.
: 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
--------------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.
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.
: 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
: --------------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.
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.
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
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.
|<--------------------- 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.
+-------------------+ /===================\ /===================\ | 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
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
|<--------------------- 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.
/===================\ 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.
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.
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
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].
+-------------+ +-------------+ | 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.
+-------------+ +-------------+ | 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)
