A Framework for MPLS in
Transport NetworksAlcatel-LucentVoyager Place, Shoppenhangers RoadMaidenheadBerksSL6 2PJUnited Kingdommatthew.bocci@alcatel-lucent.comCisco Systems250 Longwater AveReadingRG2 6GBUnited Kingdomstbryant@cisco.comCisco Systemsdanfrost@cisco.comAlcatel-Lucent7-9, Avenue Morane SulnierVelizy78141Francelieven.levrau@alcatel-lucent.comLabN+1-301-468-9228lberger@labn.net
Routing
MPLS Working Groupmpls-tpMPLSInternet-DraftThis document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the construction
of packet-switched transport networks. It describes a common set of
protocol functions - the MPLS Transport Profile (MPLS-TP) - that
supports the operational models and capabilities typical of such
networks, including signalled or explicitly provisioned bi-directional
connection-oriented paths, protection and restoration mechanisms,
comprehensive Operations, Administration and Maintenance (OAM)
functions, and network operation in the absence of a dynamic control
plane or IP forwarding support. Some of these functions are defined in
existing MPLS specifications, while others require extensions to
existing specifications to meet the requirements of the MPLS-TP.This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this
document.This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the
capabilities and functionalities of a packet transport network as
defined by the ITU-T.This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that meet
the requirements in , and that together
constitute the MPLS Transport Profile (MPLS-TP) for point-to-point
paths. The remaining MPLS-TP functions, applicable specifically to
point-to-multipoint paths, are out of scope of this document.Historically the optical transport infrastructure - Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical
Transport Network (OTN) - has provided carriers with a high benchmark
for reliability and operational simplicity. To achieve this, transport
technologies have been designed with specific characteristics:Strictly connection-oriented connectivity, which may be
long-lived and may be provisioned manually (i.e. configuration of
the node via a command line interface) or by network
management.A high level of availability.Quality of service.Extensive OAM capabilities. Carriers wish to evolve such transport networks to take
advantage of the flexibility and cost benefits of packet switching
technology and to support packet based services more efficiently.
While MPLS is a maturing packet technology that already plays an
important role in transport networks and services, not all MPLS
capabilities and mechanisms are needed in or consistent with the
transport network operational model. There are also transport
technology characteristics that are not currently reflected in
MPLS.There are thus two objectives for MPLS-TP:To enable MPLS to be deployed in a transport network and
operated in a similar manner to existing transport
technologies.To enable MPLS to support packet transport services with a
similar degree of predictability to that found in existing
transport networks.In order to achieve these objectives, there is a need to define a
common set of MPLS protocol functions - an MPLS Transport Profile -
for the use of MPLS in transport networks and applications. Some of
the necessary functions are provided by existing MPLS specifications,
while others require additions to the MPLS tool-set. Such additions
should, wherever possible, be applicable to MPLS networks in general
as well as those that conform strictly to the transport network
model.This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunications Union
Telecommunications Standardization Sector (ITU-T) effort to include an
MPLS Transport Profile within the IETF MPLS and PWE3 architectures to
support the capabilities and functionalities of a packet transport
network as defined by the ITU-T.This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that meet
the requirements in , and that together
constitute the MPLS Transport Profile (MPLS-TP) for point-to-point
MPLS-TP transport paths. The remaining MPLS-TP functions, applicable
specifically to point-to-multipoint transport paths, are out of scope
of this document.TermDefinitionLSPLabel Switched PathMPLS-TPMPLS Transport ProfileSDHSynchronous Digital HierarchyATMAsynchronous Transfer ModeOTNOptical Transport Networkcl-psConnectionless - Packet Switchedco-csConnection Oriented - Circuit Switchedco-psConnection Oriented - Packet SwitchedOAMOperations, Administration and MaintenanceG-AChGeneric Associated ChannelGALGeneric Alert LabelMEPMaintenance End PointMIPMaintenance Intermediate PointAPSAutomatic Protection SwitchingSCCSignalling Communication ChannelMCCManagement Communication ChannelEMFEquipment Management FunctionFMFault ManagementCMConfiguration ManagementPMPerformance ManagementLSRLabel Switching RouterMPLS-TP PEMPLS-TP Provider Edge LSRMPLS-TP PMPLS-TP Provider LSRPWPseudowireAdaptationThe mapping of client information into a format suitable for
transport by the server layerNative ServiceThe traffic belonging to the client of the MPLS-TP networkT-PEPW Terminating Provider EdgeS-PEPW Switching provider EdgeA Transport Network provides transparent transmission of client
user plane traffic between attached client devices by establishing
and maintaining point-to-point or point-to-multipoint connections
between such devices. The architecture of networks supporting point
to multipoint connections is out of scope of this document. A
Transport Network is independent of any higher-layer network that
may exist between clients, except to the extent required to supply
this transmission service. In addition to client traffic, a
Transport Network may carry traffic to facilitate its own operation,
such as that required to support connection control, network
management, and Operations, Administration and Maintenance (OAM)
functions.See also the definition of Packet Transport Service in .The MPLS Transport Profile (MPLS-TP) is the subset of MPLS
functions that meet the requirements in . Note that MPLS is defined to include any
present and future MPLS capability specified by the IETF, including
those capabilities specifically added to support transport network
requirements .An MPLS-TP Section is defined in Section 1.2.2 of .An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses
a subset of the capabilities of an MPLS LSP in order to meet the
requirements of an MPLS transport network as set out in . The characteristics of an MPLS-TP LSP are
primarily that it:Uses a subset of the MPLS OAM tools defined as described in
.Supports 1+1, 1:1, and 1:N protection functions.Is traffic engineered.May be established and maintained via the management plane,
or using GMPLS protocols when a control plane is used.Is either point-to-point or point-to-multipoint. Multipoint
to point and multipoint to multipoint LSPs are not
permitted.Note that an MPLS LSP is defined to include any present and
future MPLS capability, including those specifically added to
support the transport network requirements.An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP
Provider Edge (PE) router or an MPLS-TP Provider (P) router for a
given LSP, as defined below. The terms MPLS-TP PE router and MPLS-TP
P router describe logical functions; a specific node may undertake
only one of these roles on a given LSP.Note that the use of the term "router" in this context is
historic and neither requires nor precludes the ability to perform
IP forwarding.An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that
adapts client traffic and encapsulates it to be transported over
an MPLS-TP LSP. Encapsulation may be as simple as pushing a label,
or it may require the use of a pseudowire. An MPLS-TP PE exists at
the interface between a pair of layer networks. For an MS-PW, an
MPLS-TP PE may be either an S-PE or a T-PE, as defined in .An MPLS-TP Provider router is an MPLS-TP LSR that does not
provide MPLS-TP PE functionality for a given LSP. An MPLS-TP P
router switches LSPs which carry client traffic, but does not
adapt client traffic and encapsulate it to be carried over an
MPLS-TP LSP.An LSR that exists at the endpoints of an LSP and therefore
pushes or pops a label, i.e. does not perform a label swap on the
particular LSP under consideration.A Customer Edge (CE) is the client function sourcing or sinking
native service traffic to or from the MPLS-TP network. CEs on either
side of the MPLS-TP network are peers and view the MPLS-TP network
as a single point-to-point or point-to-multipoint link.An Edge-to-Edge LSP is an LSP between a pair of PEs that may
transit zero of more provider LSRs.A service LSP is an LSP that caries a single client service.A layer network is defined in and
described in .Detailed definitions and additional terminology may be found in
.MPLS-TP can be used to construct packet transport networks and is
therefore applicable in any packet transport network context. It is
also applicable to subsets of a packet network where the transport
network operational model is deemed attractive. The following are
examples of MPLS-TP applicability models:MPLS-TP provided by a network that only supports MPLS-TP LSPs
and PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or
LSRs), acting as a server for other layer 1, layer 2 and layer 3
networks ().MPLS-TP provided by a network that also supports non-MPLS-TP
LSPs and PWs (i.e. both LSPs and PWs that conform to the transport
profile and those that do not, exist between the PEs), acting as a
server for other layer 1, layer 2 and layer 3 networks ().MPLS-TP as a server layer for client layer traffic of IP or
MPLS networks which do not use functions of the MPLS transport
profile. For MPLS traffic, the MPLS-TP server layer network uses
PW switching or LSP stitching at the PE that terminates the MPLS-TP
server layer ().These models are not mutually exclusive.The requirements for MPLS-TP are specified in , , and . This section provides a brief
reminder to guide the reader and is therefore not normative. It is not
intended as a substitute for these documents.MPLS-TP must not modify the MPLS forwarding architecture and must be
based on existing pseudowire and LSP constructs.Point to point LSPs may be unidirectional or bi-directional, and it
must be possible to construct congruent Bi-directional LSPs.MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
must be possible to detect if a merged LSP has been created.It must be possible to forward packets solely based on switching the
MPLS or PW label. It must also be possible to establish and maintain
LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there must be no
dependency on dynamic routing or signalling.OAM, protection and forwarding of data packets must be able to
operate without IP forwarding support.It must be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate path
recovery actions at either the PW or LSP layers.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 inherit a number of characteristics, defined in :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.The service provided by the MPLS-TP network to the client is
guaranteed not to fall below the agreed level regardless of other
client activity.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.Where a client network makes use of an MPLS-TP server that
provides a packet transport service, the level of co-ordination
required between the client and server layer networks is minimal
(preferably no co-ordination will be required).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 packets
used by the control/management plane of the client MPLS(-TP) layer
network), are transported by the MPLS-TP server layer network.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.Such packet transport services are very similar to Layer 2 Virtual
Private Networks as defined by the IETF. 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 . This includes MPLS functions that were
defined prior to but that meet the
requirements of , together with
additional functions defined to meet those requirements. Some MPLS
functions defined before such as Equal
Cost Multi-Path, LDP signalling 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-TP comprises the following architectural elements:A standard MPLS data plane as
profiled in [draft-fbb-mpls-tp-data-plane].Sections, LSPs and PWs that provide a packet transport service
for a client network.Proactive and on-demand Operations, Administration and
Maintenance (OAM) functions to monitor and diagnose the MPLS-TP
network, such as connectivity check, connectivity verification,
performance monitoring and fault localisation.Optional control planes for LSPs and PWs, as well as support
for static provisioning and configuration.Optional path protection mechanisms to ensure that the packet
transport service survives anticipated failures and degradations
of the MPLS-TP network.Network management functions.The MPLS-TP architecture for LSPs and PWs includes the following
two sets of functions:MPLS-TP client adaptationMPLS-TP forwardingThe adaptation functions interface the native 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 client traffic over an MPLS-TP server
layer network, for example PW and LSP labels.The MPLS-TP native service adaptation functions interface the
client service to MPLS-TP. For pseudowires, these adaptation
functions are the payload encapsulation described in Section 4.4 of
and Section 6 of . For network layer client services, the
adaptation function uses the MPLS encapsulation format as defined in
.The purpose of this encapsulation is to abstract the client
service data plane 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 must therefore provide the necessary QoS to
ensure that the MPLS-TP client QoS commitments can be satisfied.The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client over an MPLS-TP server layer
network, for example PW and LSP labels.MPLS-TP LSPs use the MPLS label switching operations and TTL
processing procedures defined in and
. These operations are highly
optimised for performance and are not modified by the MPLS-TP
profile.In addition, MPLS-TP PWs use the SS-PW and MS-PW forwarding
operations defined in and . The PW label is processed by a PW
forwarder and is always at the bottom of the label stack for a given
MPLS-TP layer network.Per-platform label space is used for PWs. Either per-platform,
per-interface or other context-specific label space 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 that require
packets (e.g. OAM 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 at the top of stack. Otherwise the
packet is forwarded according to the procedures in .Point-to-point MPLS-TP LSPs can be either unidirectional or
bidirectional.It must be possible to configure an MPLS-TP LSP such that the
forward and backward directions of a bidirectional MPLS-TP LSP are
co-routed, i.e. follow the same path. The pairing relationship
between the forward and the backward directions must be known at
each LSR or LER on a bidirectional LSP.In normal conditions, all the packets sent over a PW or an LSP
follow the same path through the network and those that belong to a
common ordered aggregate are delivered in order. For example
per-packet equal cost multi-path (ECMP) load balancing is not
applicable to MPLS-TP LSPs.Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by
default.MPLS-TP supports Quality of Service capabilities via the MPLS
Differentiated Services (DiffServ) architecture . Both E-LSP and L-LSP MPLS DiffServ modes
are supported. The Traffic Class field (formerly the EXP field) of
an MPLS label follows the definition and processing rules of and . Note
that packet reordering between flows belonging to different traffic
classes may occur if more than one traffic class is supported on a
single LSP.Only the Pipe and Short Pipe DiffServ tunnelling and TTL
processing models described in and
are supported in MPLS-TP.This document describes the architecture for two types of native
service adaptation:A PW: PW Demultiplexer and PW encapsulationAn MPLS Label (for example carrying a layer 2 VPN , a layer 3 VPN , or a TE-LSP )An IP packetA PW provides any emulated service that the IETF has defined to be
provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
registry of PW types is maintained by IANA. When the client adaptation
is via a PW, the mechanisms described in
are used.An MPLS LSP Label can also be used as the adaptation, in which case
any client supported by is allowed, for
example a MPLS LSP, PW, or IP. When the client adaptation is via an
MPLS label, the mechanisms described in are used.The MPLS-TP client server relationship 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
client traffic type of the MPLS-TP network is an MPLS LSP or a PW,
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 one (i.e. there can
only one S bit set in a label stack).The data plane behaviour of MPLS-TP is the same as the best
current practise for MPLS. This includes the setting of the S-Bit.
In each case, the S-bit is set to indicate the bottom (i.e.
inner-most) label in the label stack that is contiguous between the
MPLS-TP server and the client layer. Note that this best current
practise differs slightly from 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
.The data plane behaviour of MPLS-TP is the same as the best
current practise for MPLS. This includes the setting of the S-Bit.
In each case, the S-bit is set to indicate the bottom (i.e.
inner-most) label in the label stack that is contiguous between the
MPLS-TP server and the client layer.Note that the label stacks shown above 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.The architecture for an MPLS-TP network that provides PW emulated
services is based on the MPLS and
pseudowire 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 . If
MS-PWs are used, then the MS-PW architecture also applies. shows the architecture for an
MPLS-TP network using single-segment PWs. 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.The corresponding MPLS-TP protocol stacks including PWs are shown
in . In this figure protocol the
Transport Service Layer is identified
by the PW demultiplexer (Demux) label and the Transport Path Layer
is identified by the LSP Demux
Label.PWs and their underlying labels may be configured or signaled.
See for additional details related to
configured service types. See
for additional details related to signaled service types.When providing a Virtual Private Wire Service (VPWS) , Virtual
Private Local Area Network Service (VPLS), Virtual Private
Multicast Service (VPMS) or Internet Protocol Local Area Network
Service (IPLS) pseudowires must be used to carry the client
service. VPWS, VLPS, and IPLS are described in . VPMS is described in 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 and . The network layer protocols supported by
and
can be transported between service interfaces. Examples are shown in
Figure 5 above. Support for network layer clients follows the MPLS
architecture for support of network layer protocols as specified in
and .With network layer adaptation, the MPLS-TP domain provides either
a uni-directional 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 ,
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 Layer1/Layer2 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.At the ingress service interface the client packets are received
. The PE pushes one or more labels onto the client packets which 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.In this figure the Transport Service Layer is identified by the Service LSP (SvcLSP)
demultiplexer (Demux) label and the Transport Path Layer is identified by the LSP Demux Label. Note
that the functions of the Encapsulation label and the Service Label
shown above as SvcLSP Demux may be represented by a single label
stack entry. Additionally, the S-bit will always be zero when the
client layer is MPLS labelled.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. 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 per network layer protocol payload type that is to be
transported is required. When multiple protocol payload types are to
be carried over a single service a unique label stack entry must be
present for each payload type. Such labels are referred to as
"Encapsulation Labels", one of which is shown in . 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, as shown in , then two Encapsulation Labels are
mapped on to a common Service Label.Note: The Encapsulation Label may be omitted when the transport
service 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.Service labels are typically carried over an MPLS-TP LSP
edge-to-edge (or transport path layer). An MPLS-TP edge-to-edge LSP
is represented as an LSP Demux label as shown in . An edge-to-edge LSP is commonly
used when more than one service exists between two PEs.Note, the edge-to-edge LSP may be omitted when only one service
exists between two PEs. For example, if only one service is carried
between two PEs then a single Service Label could be used to provide
both the service indication and the MPLS-TP edge-to-edge 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
edge-to-edge 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 must 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) which have Media Access Control (MAC) addresses. In
cases where a MAC address is needed, the sending node must set 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
covered in this document. In some technologies the MAC address will
need to be configured (Examples for the Ethernet case include a
configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the MAC
destination address for all packets sent over the service
interface.)Note that when two CEs, which peer with each other, operate over
a network layer transport service 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 for additional details.The CE to CE service types and corresponding labels may be
configured or signaled . See for
additional details related to configured service types. See for additional details related to
signaled service types.Identifiers are used to uniquely distinguish entities in an MPLS-TP
network. These include operators, nodes, LSPs, pseudowires, and their
associated maintenance entities. defines a set of
identifiers that are compatible with existing MPLS control plane
identifiers, as well as a set of identifiers that may be used when no
IP control plane is available.For correct operation of the OAM it is important that the 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 Signalling
Communication Channel (SCC), or a channel used for Automatic
Protection Switching (APS) data. This is achieved by carrying such
packets on a generic control channel associated to the LSP, PW or
section.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, APS, SCC, MCC or
other packet types in-band over LSPs or PWs. The G-ACh is defined in
and is similar to the Pseudowire
Associated Channel , which is used to
carry OAM packets over pseudowires. The G-ACh is indicated by a
generic associated channel header (ACH), similar to the Pseudowire
VCCV control word; this header is present for all Sections, LSPs and
PWs making use of FCAPS functions supported by the G-ACh.For pseudowires, the G-ACh uses the first four bits of the
pseudowire control word to provide the initial discrimination between
data packets and packets belonging to the associated channel, as
described in . When this first nibble of
a packet, immediately following the label at the bottom of stack, has
a value of '1', then this packet belongs to a G-ACh. The first 32 bits
following the bottom of stack label then have a defined format called
an associated channel header (ACH), which further defines the content
of the packet. The ACH is therefore both a demultiplexer for G-ACh
traffic on the PW, and a discriminator for the type of G-ACh
traffic.When the OAM or other control message is carried over an LSP,
rather than over a pseudowire, it is necessary to provide an
indication in the packet that the payload is something other than a
user data packet. This is achieved by including a reserved label with
a value of 13 in the label stack. This reserved label is referred to
as the 'Generic Alert Label (GAL)', and is defined in . When a GAL is found, it indicates that the
payload begins with an ACH. The GAL is thus a demultiplexer for G-ACh
traffic on the LSP, and the ACH is a discriminator for the type of
traffic carried on the G-ACh. Note however that MPLS-TP forwarding
follows the normal MPLS model, and that a GAL is invisible to an LSR
unless it is the top label in the label stack. The only other
circumstance under which the label stack may be inspected for a GAL is
when the TTL has expired. Any MPLS-TP component that intentionally
performs this inspection must assume that it is asynchronous with
respect to the forwarding of other packets. All operations on the
label stack are in accordance with and
.In MPLS-TP, the 'G-ACh Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1).The G-ACh must only be used for channels that are an adjunct to the
data service. Examples of these are OAM, APS, 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 must take into consideration the impact they have on the user
data that they are sharing resources with. Conversely, capacity must
be made available for important G-ACh uses such as protection and OAM.
In addition, protocols using the G-ACh must conform to the security
and congestion considerations described in . 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 .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. shows the reference
model depicting how the control channel is associated with the LSP
protocol stack.MPLS-TP must be able to operate in environments where IP is not
used in the forwarding plane. Therefore, the default mechanism for OAM
demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated
Channel (). Forwarding based on IP
addresses for user or OAM packets is not required for MPLS-TP. and BFD for MPLS LSPs have defined alert mechanisms that
enable an MPLS LSR to identify and process MPLS OAM packets when the
OAM packets are encapsulated in an IP header. These alert mechanisms
are based on TTL expiration and/or use an IP destination address in
the range 127/8 for IPv4 and that same range embedded as IPv4 mapped
IPv6 addresses for IPv6 . When the OAM
packets are encapsulated in an IP header, these mechanisms are the
default mechanisms for MPLS networks in general for identifying MPLS
OAM packets. MPLS-TP must be able to operate in an environments where
IP forwarding is not supported, and thus the GACH/GAL is the default
mechanism to demultiplex OAM packets in MPLS-TP.MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those provided
in SONET/SDH.MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the
same transport path (i.e. section, LSP or PW). These mechanisms are
described in .MPLS-TP requires that a set of OAM
capabilities is available to perform fault management (e.g. fault
detection and localisation) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in .MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel
mechanism . This uses a combination of
an Associated Channel Header (ACH) and a Generic Alert Label (GAL) to
create a control channel associated to an LSP, Section or PW.OAM and monitoring in MPLS-TP is based on the concept of
maintenance entities, as described in . A Maintenance Entity
can be viewed as the association of two Maintenance End Points (MEPs).
A Maintenance Entity Group (MEG) is a collection of one or more MEs
that belongs to the same transport path and that are maintained and
monitored as a group. The MEPs that form an ME limit the OAM
responsibilities of an OAM flow to within the domain of a transport
path or segment, in the specific layer network that is being monitored
and managed.An ME may also include a set of Maintenance Intermediate Points
(MIPs). Maintenance End Points (MEPs) are capable of sourcing and
sinking OAM flows, while Maintenance Intermediate Points (MIPs) can
only sink or respond to OAM flows from within a MEG, or originate
notifications as a result of specific network conditions.The following MPLS-TP MEs are specified in :A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs).A LSP Maintenance Entity (LME), allowing monitoring and
management of an edge-to-edge LSP (between LERs).A PW Maintenance Entity (PME), allowing monitoring and
management of an edge-to-edge SS/MS-PWs (between T-PEs).An LSP Tandem Connection Maintenance Entity (LTCME).A G-ACH packet may be directed to an individual MIP along the path
of an LSP or MS-PW by setting the appropriate TTL in the label for the
G-ACH packet, as per the traceroute mode of LSP Ping and the vccv-trace mode of. Note that this works when
the location of MIPs along the LSP or PW path is known by the MEP.
There may be circumstances where this is not the case, e.g. following
restoration using a facility bypass LSP. In these cases, tools to
trace the path of the LSP may be used to determine the appropriate
setting for the TTL to reach a specific MIP.Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
layer processing is performed on a packet. The architecture mandates
that this must occur at least once.MEPs may only act as a sink of OAM packets when the label
associated with the LSP or PW for that ME is popped. MIPs can only be
placed where an exception to the normal forwarding operation occurs. A
MEP may act as a source of OAM packets wherever a label is pushed or
swapped. For example, on an MS-PW, a MEP may source OAM within an S-PE
or a T-PE, but a MIP may only be associated with a S-PE and a sink MEP
can only be associated with a T-PE.The MPLS-TP OAM architecture supports a wide range of OAM functions
to check continuity, to verify connectivity and to monitor the
preformance of the path, to generate, filter and manage local and
remote defect alarms. These functions are applicable to any layer
defined within MPLS-TP, i.e. to MPLS-TP Sections, LSPs and PWs.The MPLS-TP OAM tool-set must be able to operate without relying on
a dynamic control plane or IP functionality in the datapath. In the
case of an MPLS-TP deployment in a network in which IP functionality
is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD
and VCCV, may be used.Management, control and OAM protocol functions may require response
packets to be delivered from the receiver back to the originator of a
message exchange. This section provides a summary of the return path
options in MPLS-TP networks.In this discussion we assume that A and B are terminal LSRs (i.e.
LERs) for an MPLS-TP LSP and that Y is an intermediate LSR along the
LSP. In the unidirectional case, A is taken to be the upstream and B
the downstream LSR with respect to the LSP. We consider the following
cases for the various types of LSPs:Packet transmission from B to APacket transmission from Y to APacket transmission from B to YNote that a return path may not always exist, and that packet
transmission in one or more of the above cases may not be possible. In
general the existence and nature of return paths for MPLS-TP LSPs is
determined by operational provisioning.There are two types of return path that may be used for the
delivery of traffic from a downstream node D to an upstream node U
either:D maintains an MPLS-TP LSP back to U which is specifically
designated to carry return traffic for the original LSP, orD has some other unspecified means of directing traffic back
to U.The first option is referred to as an "in-band" return path, the
second as an "out-of-band" return path.There are various possibilities for "out-of-band" return paths.
Such a path may, for example, be based on ordinary IP routing. In
this case packets would be forwarded as usual to a destination IP
address associated with U. In an MPLS-TP network that is also an
IP/MPLS network, such a forwarding path may traverse the same
physical links or logical transport paths used by MPLS-TP. An
out-of-band return path may also be indirect, via a network
management system; or it may be via one or more other MPLS-TP
LSPs.In this situation, either an in-band or
out-of-band return path may be used to deliver traffic from B
back to A.In the in-band case there is in essence an associated
bidirectional LSP between A and B, and the discussion for such
LSPs below applies. It is therefore recommended for reasons of
operational simplicity that point-to-point unidirectional LSPs
be provisioned as associated bidirectional LSPs (which may also
be co-routed) whenever return traffic from B to A is required.
Note that the two directions of such an LSP may have differing
bandwidth allocations and QoS characteristics.In this case only the out-of-band return
path option is available. However, an additional out-of-band
possibility is worthy of note here: if B is known to have a
return path to A, then Y can arrange to deliver return traffic
to A by first sending it to B along the original LSP. The
mechanism by which B recognises the need for and performs this
forwarding operation is protocol-specific.In this case only the out-of-band return
path option is available. However, if B has a return path to A,
then in a manner analogous to the previous case B can arrange to
deliver return traffic to Y by first sending it to A along that
return path. The mechanism by which A recognises the need for
and performs this forwarding operation is protocol-specific.For Case 1, B has a natural in-band return path to A, the use of
which is typically preferred for return traffic, although
out-of-band return paths are also applicable.For Cases 2 and 3, the considerations are the same as those for
point-to-point unidirectional LSPs.For all of Cases 1, 2, and 3, a natural in-band return path
exists in the form of the LSP itself, and its use is typically
preferred for return traffic. Out-of-band return paths, however, are
also applicable.A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements
specified in can be met, the MPLS
Transport Profile uses existing standard control plane protocols for
LSPs and PWs.Note that a dynamic control plane is not required in an MPLS-TP
network. See for further details on
statically configured and provisioned MPLS-TP services. illustrates the relationship between
the MPLS-TP control plane, the forwarding plane, the management plane,
and OAM for point-to-point MPLS-TP LSPs or PWs.The MPLS-TP control plane is based on existing MPLS and PW control
plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signalling
(, , ) for LSPs and Targetted LDP (T-LDP) for
pseudowires. When T-LDP is used as the PW control protocol, MPLS-TP
requires that it is capable of being carried over an out of band
signalling network or a signalling control channel . References to T-LDP in this document do not
preclude the definition of alternative PW control protocols for use in
MPLS-TP.Note that if MPLS-TP is being used in a multi-layer network, a
number of control protocol types and instances may be used. This is
consistent with the MPLS architecture which permits each label in the
label stack to be allocated and signalled by its own control
protocol.The distributed MPLS-TP control plane may provide the following
functions:SignallingRoutingTraffic engineering and constraint-based path computationIn a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the
domains. These include the User-Network Interface (UNI), Internal
Network Node Interface (I-NNI), and External Network Node Interface
(E-NNI). Note that different policies may be defined that control the
information exchanged across these interface types.The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document , e.g. for fault detection and localisation in the
event of a failure in order to efficiently restore failed transport
paths.The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport
paths, including protected paths as described in . Examples of the MPLS-TP data plane
connectivity patterns are LSPs utilising the fast reroute backup
methods as defined in and
ingress-to-egress 1+1 or 1:1 protected LSPs.The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures and
degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data plane
may be achieved.A number of methods exist to support inter-domain operation of
MPLS-TP, for example:Inter-domain TE LSPs Multi-segment Pseudowires LSP stitching back-to-back ACs An important consideration in selecting an inter-domain
connectivity mechanism is the degree of layer network isolation and
types of OAM required by the operator. The selection of which
technique to use in a particular deployment scenario is outside the
scope of this document.A PW or LSP may be statically configured without the support of a
dynamic control plane. This may be either by direct configuration of
the PEs/LSRs, or via a network management system. Static operation is
independent for a specific PW or LSP instance. Thus it should be
possible for a PW to be statically configured, while the LSP
supporting it is set up by a dynamic control plane. When static
configuration mechanisms are used, care must be taken to ensure that
loops are not created.Survivability requirements for MPLS-TP are specified in .A wide variety of resiliency schemes have been developed to meet
the various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels (),
while pseudowire redundancy supports scenarios where the
protection for the PW cannot be fully provided by the underlying LSP
(i.e. where the backup PW terminates on a different target PE node
than the working PW in dual homing scenarios, or where protection of
the S-PE is required). Additionally, GMPLS provides a well known set
of control plane driven protection and restoration mechanisms . MPLS-TP provides additional protection
mechanisms that are optimised for both linear topologies and ring
topologies, and that operate in the absence of a dynamic control
plane. These are specified in .Different protection schemes apply to different deployment
topologies and operational considerations. Such protection schemes may
provide different levels of resiliency, for example:Two concurrent traffic paths (1+1).one active and one standby path with guaranteed bandwidth on
both paths (1:1).one active path and a standby path the resources or which are
shared by one or more other active paths (shared protection).The applicability of any given scheme to meet specific requirements
is outside the current scope of this document.The characteristics of MPLS-TP resiliency mechanisms are as
follows:Optimised for linear, ring or meshed topologies.Use OAM mechanisms to detect and localise network faults or
service degenerations.Include protection mechanisms to coordinate and trigger
protection switching actions in the absence of a dynamic control
plane. This is known as an Automatic Protection Switching (APS)
mechanism.MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment
and end-to-end recovery.MPLS-TP recovery mechanisms support the coordination of
protection switching at multiple levels to prevent race conditions
occurring between a client and its server layer.MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based.MPLS-TP supports revertive and non-revertive behaviour.In order to monitor, protect and manage a portion of an LSP, a new
architectural element is defined. This the Path Segment Tunnel (PST).
A PST is an LSP defined and used for the purposes of OAM monitoring,
protection or management of LSP segment or concatenated LSP segments,
and based on MPLS hierarchical nested LSP defined in .A PST is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. Maintenance messages can
be initiated at the edge of the PST and sent to the peer edge of the
PST or to an intermediate point along the PST setting the TTL value at
the PST level accordingly.For example in , three PSTs are
configured to allow monitoring, protection and management of the LSP
concatenated segments. One PST is defined between PE1 and PE2, the
second between PE2 and PE3 and a third PST is set up between PE3 and
PE4. Each of these three PSTs may be monitored, protected, or managed
independently.The end-to-end traffic of the LSP, including data-traffic and
control traffic (OAM, Protection Switching Control, management and
signalling messages) is tunneled within the PST by means of label
stacking as defined in .The mapping between an LSP and a PST can be 1:1, in which it is
similar to the ITU-T Tandem Connection element . The mapping can also be 1:N to allow
aggregated monitoring, protection and management of a set of LSP
segments or concatenated LSP segments. shows a PST which is used to aggregate a
set of concatenated LSP segments for the LSP from PEx to PEt and the
LSP from PEa to PEd. Note that such a construct is useful, for
example, when the LSPs traverse a common portion of the network and
they have the same Traffic Class.PSTs can be either provisioned statically or using control plane
signalling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a PST on existing LSPs
in-service without traffic disruption. A PST can be defined
corresponding to one or more end-to-end tunneled LSPs. New
end-to-end LSPs which are tunneled within the PST can be setup.
Traffic of the existing LSPs is switched over to the new end-to-end
tunneled LSPs. The old end-to-end LSPs can be tore down.Pseudowire segment tunnels are for further study.The network management architecture and requirements for MPLS-TP
are specified in
and . These derive from
the generic specifications described in ITU-T G.7710/Y.1701 for transport technologies. It also
incorporates the OAM requirements for MPLS Networks and MPLS-TP Networks and expands on
those requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.The Equipment Management Function (EMF) of an MPLS-TP Network
Element (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means
through which a management system manages the NE. The Management
Communication Channel (MCC), realised by the G-ACh, provides a logical
operations channel between NEs for transferring Management
information. For the management interface from a management system to
an MPLS-TP NE, there is no restriction on which management protocol is
used. The MCC is used to provision and manage an end-to-end connection
across a network where some segments are created/managed by, for
example, Netconf or SNMP and other segments by XML or CORBA
interfaces. Maintenance operations are run on a connection (LSP or PW)
in a manner that is independent of the provisioning mechanism. An
MPLS-TP NE is not required to offer more than one standard management
interface. In MPLS-TP, the EMF must be capable of statically
provisioning LSPs for an LSR or LER, and PWs for a PE, as well as any
associated MEPs and MIPs, as per .Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission
(such as continuity, connectivity, etc.), software processing,
hardware, and environment. Alarm handling includes alarm severity
assignment, alarm suppression/aggregation/correlation, alarm reporting
control, and alarm reporting.Configuration Management (CM) provides functions to control,
identify, collect data from, and provide data to MPLS-TP NEs. In
addition to general configuration for hardware, software protection
switching, alarm reporting control, and date/time setting, the EMF of
the MPLS-TP NE also supports the configuration of maintenance entity
identifiers (such as MEP ID and MIP ID). The EMF also supports the
configuration of OAM parameters as a part of connectivity management
to meet specific operational requirements. These may specify whether
the operational mode is one-time on-demand or is periodic at a
specified frequency.The Performance Management (PM) functions within the EMF of an
MPLS-TP NE support the evaluation and reporting of the behaviour of
the NEs and the network. One particular requirement for PM is to
provide coherent and consistent interpretation of the network
behaviour in a hybrid network that uses multiple transport
technologies. Packet loss measurement and delay measurements may be
collected and used to detect performance degradation. This is reported
via fault management to enable corrective actions to be taken (e.g.
protection switching), and via performance monitoring for Service
Level Agreement (SLA) verification and billing. Collection mechanisms
for performance data should be capable of operating on-demand or
pro-actively.The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to those
transport networks. Furthermore, when general MPLS networks that utilise
functionality outside of the strict MPLS Transport Profile are used to
support packet transport services, the security considerations of that
additional functionality also apply.For pseudowires, the security considerations of and apply.Packets that arrive on an interface with a given label value should
not be forwarded unless that label value is assigned to an LSP or PW to
a peer LSR or PE that is reachable via that interface.Each MPLS-TP solution must specify the additional security
considerations that apply. This is discussed further in .IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that
functionality.This document introduces no additional IANA considerations in
itself.The editors wish to thank the following for their contribution to
this document: Rahul AggarwalDieter BellerMalcolm BettsItalo BusiJohn E DrakeHing-Kam LamMarc LasserreVincenzo SestitoNurit SprecherMartin VigoureuxYaacov WeingartenThe participants of ITU-T SG15This section contains a list of issues that must be resolved before
last call.ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment
management function requirements"ITU-T Recommendation G.805 (11/95), "Generic Functional
Architecture of Transport Networks"