One document matched: draft-ietf-mpls-tp-framework-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="3"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-ietf-mpls-tp-framework-06"
ipr="trust200902">
<front>
<title abbrev="MPLS TP Framework">A Framework for MPLS in Transport
Networks</title>
<author fullname="Matthew Bocci" initials="M" role="editor"
surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Voyager Place, Shoppenhangers Road</street>
<city>Maidenhead</city>
<region>Berks</region>
<code>SL6 2PJ</code>
<country>United Kingdom</country>
</postal>
<phone></phone>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" role="editor"
surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>250 Longwater Ave</street>
<city>Reading</city>
<code>RG2 6GB</code>
<country>United Kingdom</country>
</postal>
<phone></phone>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Dan Frost" initials="D" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>danfrost@cisco.com</email>
<uri></uri>
</address>
</author>
<author fullname="Lieven Levrau" initials="L" surname="Levrau">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>7-9, Avenue Morane Sulnier</street>
<city>Velizy</city>
<code>78141</code>
<country>France</country>
</postal>
<phone></phone>
<email>lieven.levrau@alcatel-lucent.com</email>
</address>
</author>
<date day="16" month="October" year="2009" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>mpls-tp</keyword>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an architectural framework for the
application of Multi Protocol Label Switching (MPLS) in transport
networks, by enabling the construction of packet switched equivalents to
traditional circuit switched carrier 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 for point-to-point paths, including signaled 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
exist in existing MPLS specifications, while others require extensions
to existing specifications to meet the requirements of the MPLS-TP.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC2119</xref>.</t>
<t>Although this document is not a protocol specification, these key
words are to be interpreted as instructions to the protocol designers
producing solutions that satisfy the architectural concepts set out in
this document.</t>
</note>
</front>
<middle>
<section title="Introduction">
<section title="Motivation and Background">
<!--Updated in line with the requirements draft intro-->
<t>This document describes a framework for a Multiprotocol Label
Switching Transport Profile (MPLS-TP). It presents the architectural
framework for MPLS-TP, defining those elements of MPLS applicable to
supporting the requirements in <xref target="RFC5654"></xref> and what
new protocol elements are required.</t>
<t>Historically the optical transport infrastructure (Synchronous
Optical Networking (SONET)/Synchronous Digital Hierarchy (SDH),
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 :</t>
<t><list style="symbols">
<t>Strictly connection-oriented connectivity, which may be
long-lived and may be provisioned manually or by network
management.</t>
<t>A high level of protection and availability.</t>
<t>Quality of service.</t>
<t>Extended OAM capabilities.</t>
</list>Carriers wish to evolve such transport networks to support
packet based services, and to take advantage of the flexibility and
cost benefits of packet switching technology. While MPLS is a maturing
packet technology that is already playing an important role in
transport networks and services, not all of MPLS's capabilities and
mechanisms are needed and/or consistent with transport network
operations. There are also transport technology characteristics that
are not currently reflected in MPLS.</t>
<t>The types of packet transport services delivered by transport
networks are very similar to Layer 2 Virtual Private Networks defined
by the IETF.</t>
<t>There are thus two objectives for MPLS-TP:</t>
<t><list style="numbers">
<t>To enable MPLS to be deployed in a transport network and
operated in a similar manner to existing transport
technologies.</t>
<t>To enable MPLS to support packet transport services with a
similar degree of predictability to that found in existing
transport networks.</t>
</list></t>
<t>In order to achieve these objectives, there is a need to create a
common set of new functions that are applicable to both MPLS networks
in general, and those belonging to the MPLS-TP profile.</t>
<t>MPLS-TP therefore defines a profile of MPLS targeted at transport
applications and networks. This profile specifies the specific MPLS
characteristics and extensions required to meet transport
requirements.</t>
</section>
<section title="Scope">
<t>This document describes an architectural framework for the
application of MPLS to transport networks. It specifies the common set
of protocol functions that meet the requirements in <xref
target="RFC5654"></xref>, and that together constitute the MPLS
Transport Profile (MPLS-TP). The architecture for point-to-point
MPLS-TP paths is described. The architecture for point-to-multipoint
paths is outside the scope of this document.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>LSP</c>
<c>Label Switched Path</c>
<c>MPLS-TP</c>
<c>MPLS Transport profile</c>
<c>SDH</c>
<c>Synchronous Digital Hierarchy</c>
<c>ATM</c>
<c>Asynchronous Transfer Mode</c>
<c>OTN</c>
<c>Optical Transport Network</c>
<c>cl-ps</c>
<c>Connectionless - Packet Switched</c>
<c>co-cs</c>
<c>Connection Oriented - Circuit Switched</c>
<c>co-ps</c>
<c>Connection Oriented - Packet Switched</c>
<c>OAM</c>
<c>Operations, Administration and Maintenance</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>Generic Alert Label</c>
<c>MEP</c>
<c>Maintenance End Point</c>
<c>MIP</c>
<c>Maintenance Intermediate Point</c>
<c>APS</c>
<c>Automatic Protection Switching</c>
<c>SCC</c>
<c>Signaling Communication Channel</c>
<c>MCC</c>
<c>Management Communication Channel</c>
<c>EMF</c>
<c>Equipment Management Function</c>
<c>FM</c>
<c>Fault Management</c>
<c>CM</c>
<c>Configuration Management</c>
<c>PM</c>
<c>Performance Management</c>
<c>LSR</c>
<c>Label Switch Router.</c>
<c>MPLS-TP PE</c>
<c>MPLS-TP Provider Edge</c>
<c>MPLS-TP P Router</c>
<c>An MPLS-TP Provider (P) router</c>
<c>PW</c>
<c>Pseudowire</c>
</texttable>
<section title="MPLS Transport Profile. ">
<t>The MPLS Transport Profile (MPLS-TP) is the subset of MPLS
functions that meet the requirements in <xref
target="RFC5654"></xref>. Note that MPLS is defined to include any
present and future MPLS capability specified by the IETF, including
those capabilities specifically added to support the transport
network requirement <xref target="RFC5654"></xref>.</t>
</section>
<section title="MPLS-TP Section">
<t>An MPLS-TP Section is defined in Section 1.1.2 of <xref
target="RFC5654"></xref>.</t>
</section>
<section title="MPLS-TP Label Switched Path">
<t>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 <xref
target="RFC5654"></xref>. The characteristics of an MPLS-TP LSP are
primarily that it:</t>
<t><list style="numbers">
<t>Uses a subset of the MPLS OAM tools defined as described in
<xref target="I-D.ietf-mpls-tp-oam-framework"></xref>.</t>
<t>Supports only 1+1, 1:1, and 1:N protection functions.</t>
<t>Is traffic engineered.</t>
<t>Is established and maintained using GMPLS protocols when a
control plane is used.</t>
<t>LSPs can only be point to point or point to multipoint, i.e.
the merging of LSPs is not permitted.</t>
</list>Note that an MPLS LSP is defined to include any present and
future MPLS capability include those specifically added to support
the transport network requirements.</t>
</section>
<section title="MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER)">
<t>An MPLS-TP Label Switching Router (MPLS-TP LSR) is either an
MPLS-TP Provider Edge (MPLS-TP PE) or an MPLS-TP Provider (MPLS-TP P
Router) router for a given LSP, as defined below. The terms MPLS-TP
PE and MPLS-TP P router describe functions and specific node may
undertake both roles.</t>
<t>Note that the use of the term "router" in this context is
historic and neither requires nor precludes the ability to perform
IP forwarding.</t>
<section title="MPLS-TP Provider Edge Router (PE)">
<t>An MPLS-TP Provider Edge Router is an MPLS-TP LSR that adapts
client traffic and encapsulates it to be carried 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.</t>
<t>A layer network is defined in <xref target="G.805"></xref>.</t>
</section>
<section title="MPLS-TP Provider Router (P)">
<t>An MPLS-TP Provider router is an MPLS-TP LSR that does not
provide MPLS-TP PE functionality. An MPLS-TP P router switches
LSPs which carry client traffic, but do not adapt the client
traffic and encapsulate it to be carried over an MPLS-TP LSP.</t>
</section>
</section>
<section title="MPLS-TP Customer Edge (CE)">
<t>An MPLS-TP Customer Edge is the client function sourcing or
sinking client 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 multi-point link. These
clients have no knowledge of the presence of the interveining
MPLS-TP network.</t>
</section>
<section title="Additional Definitions and Terminology">
<t>Detailed definitions and additional terminology may be found in
<xref target="RFC5654"></xref>.</t>
</section>
</section>
<section title="Applicability">
<t>MPLS-TP can be used to construct a packet transport networks and is
therefore applicable in any packet transport network application. It
is also as an alternative architecture for subsets of a packet network
where the transport network model is deemed attractive. The following
are examples of MPLS-TP applicability models:</t>
<t><list style="numbers">
<t>MPLS-TP provided by a network that only supports MPLS-TP,
acting as a server for other layer 1, layer 2 and layer 3 networks
(<xref target="tp-server"></xref>).</t>
<t>MPLS-TP provided by a network that also supports non-MPLS-TP
functions, acting as a server for other layer 1, layer 2 and layer
3 networks (<xref target="tp-in-mpls"></xref>).</t>
<t>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 (<xref target="tp-client-service"></xref>).</t>
</list>These models are not mutually exclusive.</t>
<t><figure anchor="tp-server" title="MPLS-TP Server Layer Example">
<artwork><![CDATA[MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as a server
for other layer 1, layer 2 and layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->|
Only
MPLS-TP
+---+ LSP +---+
+---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+
+---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ]
[-TP LSP ]
b) [ IP ] [ IP ] [ IP ]
[ LSP ]
[-TP LSP ]
]]></artwork>
</figure><figure anchor="tp-in-mpls"
title="MPLS-TP in MPLS Network Example">
<artwork><![CDATA[MPLS-TP LSP, provided by a network that also supports non-MPLS-TP functions,
acting as a server for other layer 1, layer 2 and layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS -->|<-- L1/2/3 -->|
MPLS-TP
+---+ LSP +---+
+---+ Client | |----------| | Client +---+
|CE1|==Traffic=|PE2|==========|PE3|=Traffic==|CE1|
+---+ | |----------| | +---+
+---+ +---+
Example a) [Ethernet] [Ethernet] [Ethernet]
layering [ PW ]
[-TP LSP ]
b) [ IP ] [ IP ] [ IP ]
[ LSP ]
[-TP LSP ]]]></artwork>
</figure><figure anchor="tp-client-service"
title="MPLS-TP Transporting Client Service Traffic">
<artwork><![CDATA[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.
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
Only
+---+ +---+ Non-TP +---+ MPLS-TP +---+ Non-TP +---+ +---+
|CE1|---|PE1|====LSP===|PE2|====LSP===|PE3|====LSP===|PE4|-----|CE2|
+---+ +---+ +---+ +---+ +---+ +---+
(a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ]
[ MS-PW ] [ MS-PW ] [ MS-PW ]
[ LSP ] [-TP LSP ] [ LSP ]
(a) [ IP ] [ IP ] [ IP ] [ IP ] [ IP ]
[ LSP ] [-TP LSP ] [ LSP ] ]]></artwork>
</figure></t>
</section>
</section>
<section title="Introduction to Requirements">
<t>The requirements for MPLS-TP are specified in <xref
target="RFC5654"></xref>, <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref>, and <xref
target="I-D.ietf-mpls-tp-nm-req"></xref>. 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.</t>
<t>MPLS-TP must not modify the MPLS forwarding architecture and must be
based on existing pseudowire and LSP constructs. </t>
<t>Point to point LSPs may be unidirectional or bi-directional, and it
must be possible to construct congruent Bi-directional LSPs.</t>
<t>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.</t>
<t>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 signaling.</t>
<t>OAM, protection and forwarding of data packets must be able to
operate without IP forwarding support.</t>
<t>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.</t>
</section>
<section title="Transport Profile Overview ">
<t></t>
<section title="Packet Transport Services">
<t>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 <xref
target="RFC5654"></xref>:</t>
<t><list style="symbols">
<t>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 the server or
client layer network.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>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 CNLS packets
used by the control/management plane of the client MPLS(-TP) layer
network), are transported by the MPLS-TP server layer network.</t>
<t>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.</t>
</list>Therefore, a packet transport service doe not support a
connectionless packet switched forwarding mode. However, this does not
preclude it carrying client traffic associated with a connectionless
service.</t>
</section>
<section title="Scope of MPLS Transport Profile">
<t><xref target="mpls-tp-scope"></xref> illustrates the scope of
MPLS-TP. MPLS-TP solutions are primarily intended for packet transport
applications. MPLS-TP is a strict sub-set of MPLS, and comprises those
functions that meet the requirements of <xref
target="RFC5654"></xref>. This includes MPLS functions that were
defined prior to <xref target="RFC5654"></xref> but that meet the
requirements of <xref target="RFC5654"></xref>, together with
additional functions defined to meet those requirements. Some MPLS
functions defined before <xref target="RFC5654"></xref> e.g. Equal
Cost Multi-Path, LDP signaling used in such a way that it creates
multi-point to point LSPs, and IP forwarding in the data plane are
explicitly excluded from MPLS-TP by that requirements
specification.</t>
<t>Note that this does not preclude the future definition of MPLS
functions that do not meet the requirements of <xref
target="RFC5654"></xref> and thus fall outside the scope of MPLS-TP as
defined by this document.</t>
<t><figure anchor="mpls-tp-scope" title="Scope of MPLS-TP">
<artwork><![CDATA[
{Additional Transport Functions}
|<============== MPLS-TP ==================>|
{ ECMP, mp2p LDP, IP fwd }
|<====== Pre-RFC5654 MPLS ===========>|
|<============================== MPLS ==============================>|
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="arch" title="Architecture">
<t>MPLS-TP comprises the following</t>
<t><list style="symbols">
<t>Sections, LSPs and PWs that provide a packet transport service
for a client network.</t>
<t>Proactive and on demand Operations Administration and
Maintenance (OAM) functions to monitor and diagnose the MPLS-TP
network. e.g. connectivity check, connectivity verification, and
performance monitoring.</t>
<t>Optional control planes for LSPs and PWs, as well as static
configuration.</t>
<t>Path protection mechanisms to ensure that the packet transport
service survives anticipated failures and degradations of the
MPLS-TP network.</t>
<t>Network management functions.</t>
</list></t>
<t>The MPLS-TP architecture for LSPs and PWs includes the the
following two sets of functions:</t>
<t><list style="symbols">
<t>MPLS-TP adaptation </t>
<t>MPLS-TP forwarding </t>
</list></t>
<t>The adaptation functions interface the client service to MPLS-TP.
This includes the case where the client service is an MPLS-TP LSP.</t>
<t>The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client over an MPLS-TP server layer
network E.g. PW label and LSP label.</t>
<section anchor="FWD" title="MPLS-TP Adaptation " toc="default">
<t>The MPLS-TP adaptation interfaces the client service to MPLS-TP.
For pseudowires, these adaptation functions are the payload
encapsulation shown in Figure 7 of <xref target="RFC3985"></xref>
and Figure 7 of <xref target="I-D.ietf-pwe3-ms-pw-arch"></xref>. For
network layer client services, the adaptation function uses the MPLS
encapsulation format as defined in RFC 3032<xref
target="RFC3032"></xref>.</t>
<t>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.</t>
<t>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 QoS from the MPLS-TP network, which
in turn inherits its QoS from the server layer. The server layer
must therefore provide the necessary Quality of Service (QoS) to
ensure that the MPLS-TP client QoS commitments are satisfied.</t>
</section>
<section title="MPLS-TP Forwarding Functions">
<t>The forwarding functions comprise the mechanisms required for
forwarding the encapsulated client over an MPLS-TP server layer
network E.g. PW label and LSP label.</t>
<t>MPLS-TP LSPs use the MPLS label switching operations and TTL
processing procedures defined in <xref target="RFC3031"></xref> and
<xref target="RFC3032"></xref>. These operations are highly
optimized for performance and are not modified by the MPLS-TP
profile.</t>
<t>In addition, MPLS-TP PWs use the PW and MS-PW forwarding
operations defined in<xref target="RFC3985"></xref> and <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref>. 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.</t>
<t>Per-platform label space is used for PWs. Either per-platform,
per-interface or other context-specific label space may be used for
LSPs.</t>
<t>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 design protocol extensions that requires
packets (e.g. OAM packets) to be sent to an intermediate LSR.</t>
<t>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.
Otherwise the packet is forwarded according to the procedures in
<xref target="RFC3032"></xref>.</t>
<t>Point to point MPLS-TP LSPs can be either unidirectional or
bidirectional.</t>
<t>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. they 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.</t>
<t>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.</t>
<t>Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by
default.</t>
<t>Both E-LSP and L-LSP are supported in MPLS-TP, as defined in
<xref target="RFC3270"></xref>.</t>
<t>The Traffic Class field (formerly the MPLS EXP field) follows the
definition and processing rules of <xref target="RFC5462"></xref>
and <xref target="RFC3270"></xref>.</t>
<t>Only the pipe and short-pipe models are supported in MPLS-TP.</t>
</section>
</section>
<section title="MPLS-TP Client Adaptation">
<t>This document specifies the architecture for two types of client
adaptation:</t>
<t><list style="symbols">
<t>A PW</t>
<t>An MPLS Label</t>
</list></t>
<t>When the client is a PW, the MPLS-TP client adaptation functions
include the PW encapsulation mechanisms, including the PW control
word. When the client is operating at the network layer the mechanism
described in <xref target="NLTS-sec"></xref> is used.</t>
<section title="Adaptation using Pseudowires ">
<t>The architecture for a transport profile of MPLS (MPLS-TP) that
uses PWs is based on the MPLS <xref target="RFC3031"></xref> and
pseudowire <xref target="RFC3985"></xref> architectures. If
multi-segment pseudowires are used to provide a packet transport
service, motivated by, for example, the requirements specified in
<xref target="RFC5254"></xref> then the MS-PW architecture <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref> also applies.</t>
<t><xref target="tp-arch"></xref> shows the architecture for an
MPLS-TP network using single-segment PWs.</t>
<t><figure anchor="tp-arch"
title="MPLS-TP Architecture (Single Segment PW)">
<artwork><![CDATA[ |<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | encapsulated | |
| | Pkt Xport Service | |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|======:=X=:=======| PE2| | +-----+
| |----------|...........:PW1:............|----------| |
| CE1 | | | | | : | | | | CE2 |
| |----------|...........:PW2:............|----------| |
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+
^ | +----+ +---+ +----+ | | ^
| | Provider Edge 1 ^ Provider Edge 2 | |
| | | | |
Customer | P Router | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
]]></artwork>
</figure></t>
<t><xref target="ms-pw-arch"></xref> 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.</t>
<t><figure anchor="ms-pw-arch"
title="MPLS-TP Architecture (Multi-Segment PW)">
<artwork><![CDATA[ |<-------------------Pseudowire-------------------->|
| encapsulated |
| Pkt Xport Service |
| |
| PSN |
AC | |<------- PSN tun1------>| |<--tun2-->| | AC
| V V V V V V |
| +----+ +-----+ +----+ +----+ |
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |---|......PW.Seg't1... | \ / | ......X...PW.Seg't3.....|---| |
|CE1| | | | | X | | | | | | |CE2|
| |---|......PW.Seg't2... | / \ | ......X...PW.Seg't4.....|---| |
+---+ | | |===============/ \=====| |==========| | | +---+
^ +----+ ^ +-----+ +----+ ^ +----+ ^
| | ^ | |
| TE LSP | TE LSP |
| P-router |
| |
|<-------------------- Emulated Service ------------------->|
]]></artwork>
</figure></t>
<t>The corresponding domain of the MPLS-TP protocol stack including
PWs is shown in <xref target="MPLS-TP-Defn"></xref>.</t>
<t><figure anchor="MPLS-TP-Defn"
title="MPLS-TP Layer Network using Pseudowires">
<artwork><![CDATA[
+-------------------+
| Client Layer |
/===================\ /===================\
H PW Encap H H PW OAM H
H-------------------H H-------------------H /===================\
H PW Demux (S=1) H H PW Demux (S=1) H H LSP OAM H
H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM
Note: Transport Service Layer = PW Demux
Transport Path Layer = LSP Demux
]]></artwork>
</figure></t>
<t>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. These
PWs can be configured either statically or via the control plane
defined in <xref target="RFC4447"></xref>.</t>
<t>Note that in MPLS-TP environments where IP is used for control or
OAM purposes, IP MAY be carried over the LSP demultiplexers as per
RFC3031 <xref target="RFC3031"></xref>, or directly over the
server.</t>
</section>
<section anchor="NLTS-sec" title="Network Layer Clients">
<t>MPLS-TP LSPs can be used to transport network layer clients. Any
network layer protocol can be transported between service
interfaces. Examples of network layer protocols include IP, MPLS and
MPLS-TP.</t>
<t>With network layer transport, the MPLS-TP domain provides a
bidirectional point-to-point connection between two customer edge
(CE) nodes. Note that a CE may be an an IP, MPLS or MPLS-TP node. As
shown in <xref target="tp-ip-lsp-arch"></xref>, there is an
attachment circuit between the CE node on the left and its
corresponding provider edge (PE) node that provides the service
interface, a bidirectional LSP across the MPLS-TP service 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.</t>
<t><figure anchor="tp-ip-lsp-arch"
title="MPLS-TP Architecture for Network Layer Clients">
<artwork><![CDATA[ |<------------- Client Network Layer-------------->|
| |
| |<---- Pkt Xport Service --->|
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +---+ +----+ AC V
+-----+ | | PE1|======:=X=:=======| PE2| | +-----+
| |----------|...........:LSP:............|----------| |
| CE1 | | | | | : | | | | CE2 |
| |----------|...........: IP:............|----------| |
+-----+ ^ | | |======:=X=:=======| | | ^ +-----+
^ | +----+ +---+ +----+ | | ^
| | Provider Edge 1 ^ Provider Edge 2 | |
| | | | |
Customer | P Router | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
]]></artwork>
</figure></t>
<t>At the ingress service interface the PE transforms the ingress
packet to the format that will be carried over the transport
network, and similarly the corresponding service interface at the
egress PE transforms the packet to the format needed by the attached
CE. 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.</t>
<t><figure anchor="MPLS-TP-NL-Stack"
title="Domain of MPLS-TP Layer Network for IP and LSP Clients">
<artwork><![CDATA[
+-------------------+
| Client Layer |
/===================\ /===================\
H Encap Label (S=1) H H SvcLSP OAM H
H-------------------H H-------------------H /===================\
H SvcLSP Demux H H SvcLSP Demux (S=1)H H LSP OAM H
H-------------------H H-------------------H H-------------------H
H LSP Demux(s) H H LSP Demux(s) H H LSP Demux(s) H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic Service LSP OAM LSP OAM
Note: Transport Service Layer = SvcLSP Demux
Transport Path Layer = LSP Demux
Note that the functions of the Encap label and the Service Label may represented
by a single label
]]></artwork>
</figure></t>
<t>Within the MPLS-TP transport network, the network layer protocols
are carried over the MPLS-TP LSP using a 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. In accordance with <xref
target="RFC3032"></xref>, the bottom label, with the 'bottom of
stack' bit set to '1', defines the network layer protocol being
transported. <xref target="MPLS-TP-NL-Stack"></xref> shows how an a
client network protocol stack (which may be an MPLS label stack and
payload) is carried over as a network layer transport service over
an MPLS-TP transport network.</t>
<t>A label per network layer protocol payload type that is to be
transported is REQUIRED. Such labels are referred to as "Service
Labels", one of which is shown in <xref
target="MPLS-TP-NL-Stack"></xref>. The mapping between protocol
payload type and Service Label is either configured or signaled.</t>
<t>Service labels are typically carried over an MPLS-TP edge-to-edge
LSP, which is also shown in <xref target="MPLS-TP-NL-Stack"></xref>.
The use of an edge-to-edge LSP is RECOMMENDED when more than one
protocol payload type is to be transported. For example, if only
MPLS is carried then a single Service Label would be used to
provided both payload type indication and the MPLS-TP edge-to-edge
LSP. Alternatively, if both IP and MPLS is to be carried then two
Service Labels would be mapped on to a common MPLS-TP edge-to-edge
LSP.</t>
<t>As noted above, any layer 2 and layer 1 protocols used to carry
the network layer protocol over the attachment circuit is terminated
at the service interface and is not transported across the MPLS-TP
network. This enables the use of different layer 2 / layer 1
technologies at two service interfaces.</t>
<t>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.)</t>
<t>Note that when the two CEs operating over the network layer
transport service are running a routing protocol such as ISIS 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.</t>
<t>[Editors Note we need to confer with ISIS and OSPF WG to verify
that the cautionary note above is necessary and sufficient.]</t>
<t>The CE to CE service types and corresponding labels may be
configured or signaled. When they are signaled the CE to PE control
channel may be either out-of-band or in-band. An out-of-band control
channel uses standard GMPLS out-of-band signaling techniques. There
are a number of methods that can be used to carry this
signalling:</t>
<t><list style="symbols">
<t>It can be carried via an out-of-band control channel. (As is
commonly done in today's GMPLS controlled transport
networks.)</t>
<t>It could be carried over the attachment circuit with MPLS
using a reserved label.</t>
<t>It could be carried over the attachment circuit with MPLS
using a normal label that is agreed between CE and PE.</t>
<t>It could be carried over the attachment circuit in an
ACH.</t>
<t>It could be carried over the attachment circuit in IP.</t>
</list>In the MPLS and ACH cases above, this label value is used
to carry LSP signaling without any further encapsulation. This
signaling channel is always point-to-point and MUST use local CE and
PE addressing.</t>
<t>The method(s) to be used will be described in a future version of
the document.</t>
</section>
</section>
<section anchor="addr" title="Identifiers">
<t>Identifiers to be used in within MPLS-TP where compatibility with
existing MPLS control plane conventions are necessary are described in
[draft-swallow-mpls-tp-identifiers-00]. The MPLS-TP requirements <xref
target="RFC5654"></xref> require that the elements and objects in an
MPLS-TP environment are able to be configured and managed without a
control plane. In such an environment many conventions for defining
identifiers are possible. However it is also anticipated that
operational environments where MPLS-TP objects, LSPs and PWs will be
signaled via existing protocols such as the Label Distribution
Protocol <xref target="RFC4447"></xref> and the Resource Reservation
Protocol as it is applied to Generalized Multi-protocol Label
Switching ( <xref target="RFC3471"></xref> and <xref
target="RFC3473"></xref>) (GMPLS).
[draft-swallow-mpls-tp-identifiers-00] defines a set of identifiers
for MPLS-TP which are both compatible with those protocols and
applicable to MPLS-TP management and OAM functions.</t>
<t>MPLS-TP distinguishes between addressing used to identify nodes in
the network, and identifiers used for demultiplexing and
forwarding.</t>
<t>Whilst IP addressing is used by default, 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.</t>
<t><xref target="RFC4379"></xref>and BFD for MPLS LSPs <xref
target="I-D.ietf-bfd-mpls"></xref> 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. These mechanisms are the default mechanisms for MPLS
networks in general for identifying MPLS OAM packets when the OAM
packets are encapsulated in an IP header. MPLS-TP is unable to rely on
the availability of IP and thus uses the GACH/GAL to demultiplex OAM
packets.</t>
</section>
<section anchor="OAM"
title="Operations, Administration and Maintenance (OAM)">
<t></t>
<t>MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those provided
in SONET/SDH.</t>
<t>MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the
same LSP. These mechanisms are described in <xref
target="RFC5586"></xref>.</t>
<t>MPLS-TP requires <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref> that a set of OAM
capabilities is available to perform fault management (e.g. fault
detection and localization) 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 <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>.</t>
<t>MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel
mechanism <xref target="RFC5586"></xref>. 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.</t>
<section title="OAM Architecture">
<t></t>
<t>OAM and monitoring in MPLS-TP is based on the concept of
maintenance entities, as described in <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>. A Maintenance
Entity can be viewed as the association of two (or more) Maintenance
End Points (MEPs) (see example in <xref target="tp-oam-ex"></xref>
). The MEPs that form an ME should be configured and managed to
limit the OAM responsibilities of an OAM flow within a network or
sub- network, or a transport path or segment, in the specific layer
network that is being monitored and managed.</t>
<t>Each OAM flow is associated with a single ME. Each MEP within an
ME resides at the boundaries of that ME. An ME may also include a
set of zero or more Maintenance Intermediate Points (MIPs), which
reside within the Maintenance Entity. 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.</t>
<t><figure anchor="tp-oam-ex" title="Example of MPLS-TP OAM "
width="72">
<artwork><![CDATA[
========================== End to End LSP OAM ==========================
..... ..... ..... .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
''''' ''''' ''''' '''''
|<-------- Carrier 1 --------->| |<--- Carrier 2 ----->|
---- --- --- ---- ---- --- ----
NNI | | | | | | | | NNI | | | | | | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |----
| | | | | | | | | | | | | |
---- --- --- ---- ---- --- ----
==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM ===
(Carrier 1) LSP OAM (Carrier 2)
(inter-carrier)
..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
''''' ''''' ''''' '''''''''' '''''''''' ''''' '''''
<------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope
of this figure.
]]></artwork>
</figure><xref target="oam-arch"></xref> illustrates how the
concept of Maintenance Entities can be mapped to sections, LSPs and
PWs in an MPLS-TP network that uses MS-PWs.</t>
<t><figure anchor="oam-arch" title="MPLS-TP OAM archtecture">
<artwork><![CDATA[ Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | |
|CE1|------|........PW1.....X..|...PW3...|.X......PW5........|-----|CE2|
| | | |=========| |=========| |=========| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+
|<- Subnetwork 123->| |<- Subnetwork XYZ->|
.------------------- PW15 PME -------------------.
.---- PW1 PTCME ----. .---- PW5 PTCME ---.
.---------. .---------.
PSN13 LME PSNXZ LME
.--. .--. .--------. .--. .--.
Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity
LME: LSP Maintenance Entity
PME: PW Maintenance Entity
]]></artwork>
</figure></t>
<t>The following MPLS-TP MEs are specified in <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>:</t>
<t><list style="symbols">
<t>A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs).</t>
<t>A LSP Maintenance Entity (LME), allowing monitoring and
management of an end-to-end LSP (between LERs).</t>
<t>A PW Maintenance Entity (PME), allowing monitoring and
management of an end-to-end SS/MS-PWs (between T-PEs).</t>
<t>An LSP Tandem Connection Maintenance Entity (LTCME), allowing
estimation of OAM fault and performance metrics of a single LSP
segment or of an aggregate of LSP segments. It also enables any
OAM function applied to segment(s) of an LSP to be independent
of the OAM function(s) operated on the end-to-end LSP. This can
be achieved by including a label representing the LTCME on one
or more LSP label stacks for 1:1 or N:1 monitoring of LSPs,
respectively. Note that the term Tandem Connection Monitoring
has historical significance dating back to the early days of the
telephone network, but is equally applicable to the hierarchal
architectures commonly employed in todays packet networks.</t>
</list></t>
<t>Individual MIPs along the path of an LSP or PW are addressed by
setting the appropriate TTL in the label for the OAM packet, as per
<xref target="I-D.ietf-pwe3-segmented-pw"></xref>. Note that this
works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be cases where this is not the case in general
MPLS networks 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.</t>
<t>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. </t>
<t>There is only one MIP on an LSP or PW in each node. That MIP is
for all applicable OAM functions on its associated LSP or PW. This
document does not specify the default position of the MIP within the
node. Therefore, this document does not specify where the exception
mechanism resides (i.e. at the ingress interface, the egress
interface, or some other location within the node). An optional
protocol may be developed that sets the position of a MIP along the
path of an LSP or PW within the node (and thus determines the
exception processing location). </t>
<t>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 whereever a label
is pushed or swapped. For example, on a 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.</t>
</section>
<section title="OAM Functions">
<t>The MPLS-TP OAM architecture support a wide range of OAM
functions, including the following <list style="symbols">
<t>Continuity Check</t>
<t>Connectivity Verification</t>
<t>Performance monitoring (e.g. loss and delay)</t>
<t>Alarm suppression</t>
<t>Remote Integrity</t>
</list></t>
<t>These are applicable to any layer defined within MPLS-TP, i.e.
MPLS Section, LSP and PW.</t>
<t>The MPLS-TP OAM toolset needs to be able to operate without
relying on a dynamic control plane or IP functionality in the
datapath. In the case of MPLS-TP deployment with IP functionality,
all existing IP-MPLS OAM functions, e.g. LSP-Ping, BFD and VCCV, may
be used. This does not preclude the use of other OAM tools in an IP
addressable network.</t>
<t>One use of OAM mechanisms is to detect link failures, node
failures and performance outside the required specification which
then may be used to trigger recovery actions, according to the
requirements of the service.</t>
</section>
</section>
<section anchor="GENERICACH" title="Generic Associated Channel (G-ACh)">
<t>For correct operation of the OAM it is important that the OAM
packets fate share with the data packets. In addition in MPSL-TP it is
necessary to discriminate between user data payloads and other types
of payload. For example the packet may contain a Signaling
Communication Channel (SCC), or a channel used for Automatic
Protection Switching (APS) data. Such packets are carried on a control
channel associated to the LSP, Section or PW. This is achieved by
carrying such packets on a generic control channel associated to the
LSP, PW or section.</t>
<t>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
<xref target="RFC5586"></xref> and it is similar to the Pseudowire
Associated Channel <xref target="RFC4385"></xref>, which is used to
carry OAM packets across pseudowires. The G-ACH is indicated by a
generic associated channel header (ACH), similar to the Pseudowire
VCCV control word, and this is present for all Sections, LSPs and PWs
making use of FCAPS functions supported by the G-ACH.</t>
<t>For pseudowires, the G-ACh use the first nibble of the pseudowire
control word to provide the initial discrimination between data
packets a packets belonging to the associated channel, as described
in<xref target="RFC4385"></xref>. When the first nibble of a packet,
immediately following the label at the bottom of stack, has a value of
one, 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.</t>
<t>When the OAM, or a similar 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 <xref
target="RFC5586"></xref>. When a GAL is found anywhere within the
label stack 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 <xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref>.</t>
<t>In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1), however this does not
preclude its use elsewhere in the label stack in other
applications.</t>
<t>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 those names 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.</t>
<t>Since the G-ACh traffic is indistinguishable from the user data
traffic at the server layer, bandwidth and QoS commitments apply to
the gross traffic on the LSP, PW or section. Protocols using the G-ACh
must therefore take into consideration the impact they have on the
user data that they are sharing resources with. In addition, protocols
using the G-ACh MUST conform to the security and congestion
considerations described in <xref target="RFC5586"></xref>. .</t>
<t><xref target="PWE3-stack"></xref> 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 <xref target="RFC5085"></xref>.</t>
<t></t>
<t><figure anchor="PWE3-stack"
title="PWE3 Protocol Stack Reference Model including the G-ACh "
width="72">
<artwork><![CDATA[
+-------------+ +-------------+
| Payload | < Service / FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
]]></artwork>
</figure></t>
<t></t>
<t>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.</t>
<t><xref target="MPLS-PS-inc-LSP-ACH"></xref> shows the reference
model depicting how the control channel is associated with the LSP
protocol stack.</t>
<t></t>
<figure anchor="MPLS-PS-inc-LSP-ACH"
title="MPLS Protocol Stack Reference Model including the LSP Associated Control Channel ">
<artwork><![CDATA[
+-------------+ +-------------+
| Payload | < Service > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<section anchor="CONTROLPLANE" title="Control Plane">
<t>MPLS-TP should be capable of being operated with centralized
Network Management Systems (NMS). The NMS may be supported by a
distributed control plane, but MPLS-TP can operated in the absence of
such a control plane. A distributed control plane may be used to
enable dynamic service provisioning in multi-vendor and multi-domain
environments using standardized protocols that guarantee
interoperability. Where the requirements specified in <xref
target="RFC5654"></xref> can be met, the MPLS transport profile uses
existing control plane protocols for LSPs and PWs.</t>
<t><xref target="cp-arch"></xref> 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.</t>
<t></t>
<t><figure anchor="cp-arch"
title="MPLS-TP Control Plane Architecture Context">
<artwork><![CDATA[ +------------------------------------------------------------------+
| |
| Network Management System and/or |
| |
| Control Plane for Point to Point Connections |
| |
+------------------------------------------------------------------+
| | | | | |
.............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
--+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
/: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note:
1) NMS may be centralised or distributed. Control plane is
distributed
2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server
layer, and LSP or a G-ACh.
]]></artwork>
</figure></t>
<t></t>
<t>The MPLS-TP control plane is based on a combination of the
LDP-based control plane for pseudowires <xref target="RFC4447"></xref>
and the RSVP-TE based control plane for MPLS-TP LSPs <xref
target="RFC3471"></xref>. Some of the RSVP-TE functions that are
required for LSP signaling for MPLS-TP are based on GMPLS.</t>
<t>The distributed MPLS-TP control plane provides the following
functions:</t>
<t><list style="symbols">
<t>Signaling</t>
<t>Routing</t>
<t>Traffic engineering and constraint-based path computation</t>
</list></t>
<t>In 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.</t>
<t>The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document <xref
target="OAM"></xref> e.g. for fault detection and localization in the
event of a failure in order to efficiently restore failed transport
paths.</t>
<t>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 the survivability section
<xref target="SURVIVE"></xref> of this document. Examples of the
MPLS-TP data plane connectivity patterns are LSPs utilizing the fast
reroute backup methods as defined in <xref target="RFC4090"></xref>
and ingress-to-egress 1+1 or 1:1 protected LSPs.</t>
<t>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.</t>
<section title="PW Control Plane">
<t>An MPLS-TP network provides many of its transport services using
single-segment or multi-segment pseudowires, in compliance with the
PWE3 architecture (<xref target="RFC3985"></xref> and <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref> ). The setup and
maintenance of single-segment or multi- segment pseudowires uses the
Label Distribution Protocol (LDP) as per <xref
target="RFC4447"></xref> and extensions for MS-PWs <xref
target="I-D.ietf-pwe3-segmented-pw"></xref> and <xref
target="I-D.ietf-pwe3-dynamic-ms-pw"></xref>.</t>
</section>
<section title=" LSP Control Plane">
<t>MPLS-TP provider edge nodes aggregate multiple pseudowires and
carry them across the MPLS-TP network through MPLS-TP tunnels
(MPLS-TP LSPs). Applicable functions from the Generalized MPLS
(GMPLS) protocol suite supporting packet-switched capable (PSC)
technologies are used as the control plane for MPLS-TP transport
paths (LSPs).</t>
<t>The LSP control plane includes:<list style="symbols">
<t>RSVP-TE for signalling</t>
<t>OSPF-TE or ISIS-TE for routing</t>
</list>RSVP-TE signaling in support of GMPLS, as defined in <xref
target="RFC3473"></xref>, is used for the setup, modification, and
release of MPLS-TP transport paths and protection paths. It supports
unidirectional, bi-directional and multicast types of LSPs. The
route of a transport path is typically calculated in the ingress
node of a domain and the RSVP explicit route object (ERO) is
utilized for the setup of the transport path exactly following the
given route. GMPLS based MPLS-TP LSPs must be able to inter-operate
with RSVP-TE based MPLS-TE LSPs, as per <xref
target="RFC5146"></xref></t>
<t>OSPF-TE routing in support of GMPLS as defined in <xref
target="RFC4203"></xref> is used for carrying link state information
in a MPLS-TP network. ISIS-TE routing in support of GMPLS as defined
in <xref target="RFC5307"></xref> is used for carrying link state
information in a MPLS-TP network.</t>
</section>
</section>
<section anchor="static" title="Static Operation of LSPs and PWs ">
<t>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. The collateral
damage that loops can cause during the time taken to detect the
failure may be severe. When static configuration mechanisms are used,
care must be taken to ensure that loops to not form.</t>
</section>
<section anchor="SURVIVE" title="Survivability">
<t>Survivability requirements for MPLS-TP are specified in <xref
target="I-D.ietf-mpls-tp-survive-fwk"></xref>.</t>
<t>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 (<xref target="RFC4090"></xref>),
while pseudowire redundancy <xref
target="I-D.ietf-pwe3-redundancy"></xref> supports scenarios where the
protection for the PW can not be fully provided by the PSN layer (i.e.
where the backup PW terminates on a different target PE node than the
working PW). Additionally, GMPLS provides a well known set of control
plane driven protection and restoration mechanisms <xref
target="RFC4872"></xref>. 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 <xref
target="I-D.ietf-mpls-tp-survive-fwk"></xref>.</t>
<t>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) or one active path and a standby path
that is 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.</t>
<t>The characteristics of MPLS-TP resiliency mechanisms are listed
below.<list style="symbols">
<t>Optimised for linear, ring or meshed topologies.</t>
<t>Use OAM mechanisms to detect and localize network faults or
service degenerations.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based.</t>
<t>MPLS-TP supports revertive and non-revertive behavior.</t>
</list></t>
</section>
<section anchor="NETMGT" title="Network Management">
<t>The network management architecture and requirements for MPLS-TP
are specified in <xref target="I-D.ietf-mpls-tp-nm-req"></xref>. It
derives from the generic specifications described in ITU-T
G.7710/Y.1701 <xref target="G.7710"></xref> for transport
technologies. It also incorporates the OAM requirements for MPLS
Networks <xref target="RFC4377"></xref> and MPLS-TP Networks <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref> and expands on
those requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.</t>
<t>The Equipment Management Function (EMF) of a 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), realized by the G-ACh, provides a logical
operations channel between NEs for transferring Management
information. For the management interface from a management system to
a MPLS-TP NE, there is no restriction on which management protocol
should be used. It is used to provision and manage an end-to-end
connection across a network where some segments are create/managed,
for examples by 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 per <xref
target="static"></xref>.</t>
<t>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.</t>
<t>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.</t>
<t>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 should be capable of operating
on-demand or proactively.</t>
</section>
</section>
<section title="Security Considerations">
<t>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-TP profile are used to support
packet transport services, the security considerations of that
additional functionality also apply.</t>
<t>For pseudowires, the security considerations of <xref
target="RFC3985"></xref> and <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref> apply.</t>
<t>Packets that arrive on an interface with a given label value should
not be forwarded unless that label value was previously assigned to an
LSP or PW to a peer LSR or PE that it reachable via that interface.</t>
<t>Each MPLS-TP solution must specify the additional security
considerations that apply.</t>
</section>
<section title="IANA Considerations">
<t>IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that
functionality.</t>
<t>This document introduces no additional IANA considerations in
itself.</t>
</section>
<section title="Acknowledgements">
<t>The editors wish to thank the following for their contribution to
this document: <list style="symbols">
<t>Rahul Aggarwal</t>
<t>Dieter Beller</t>
<t>Lou Berger</t>
<t>Malcolm Betts</t>
<t>Italo Busi</t>
<t>John E Drake</t>
<t>Hing-Kam Lam</t>
<t>Marc Lasserre</t>
<t>Vincenzo Sestito</t>
<t>Martin Vigoureux</t>
</list></t>
</section>
<section title="Open Issues">
<t>This section contains a list of issues that must be resolved before
last call.</t>
<t><list style="symbols">
<t>Add addition detail on survivability architectures.</t>
<t>Consider whether there is too much detail in the OAM, network
management, identifiers and control plane sections. Should this
framework document reduce the discussion on these topics in order to
minimise the dependency on other components not yet ready for
publication.</t>
<t>There is some text missing from the network layer clients
section. Text is invited covering the use of out of band signaling
on the AC. </t>
<t>Need text to address how the LSR next hop MAC address is
determined for Ethernet link layers when no IP (i.e. ARP) is
available. If statically configured, what is the default?</t>
<t>Are there any other invariants of a typical LSR/PE architecture
that need to be clarified in the context of MPLS-TP.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3031'?>
<?rfc include='reference.RFC.3032'?>
<?rfc include='reference.RFC.3270'?>
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.4385'?>
<?rfc include='reference.RFC.4090'?>
<?rfc include='reference.RFC.4203'?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.RFC.4872'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.5462'?>
<?rfc include='reference.RFC.3471'?>
<?rfc include='reference.RFC.5307'?>
<?rfc include='reference.RFC.5332'?>
<?rfc include='reference.RFC.3473'?>
<reference anchor="G.7710">
<front>
<title>ITU-T Recommendation G.7710/Y.1701 (07/07), "Common equipment
management function requirements"</title>
<author>
<organization></organization>
</author>
<date year="2005" />
</front>
</reference>
<reference anchor="G.805">
<front>
<title>ITU-T Recommendation G.805 (11/95), "Generic Functional
Architecture of Transport Networks"</title>
<author>
<organization></organization>
</author>
<date month="November" year="1995" />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4377'?>
<?rfc include='reference.I-D.ietf-pwe3-redundancy'?>
<?rfc include='reference.I-D.ietf-pwe3-ms-pw-arch'?>
<?rfc include='reference.RFC.5654'?>
<?rfc include='reference.I-D.ietf-mpls-tp-oam-requirements'?>
<?rfc include='reference.I-D.ietf-mpls-tp-nm-req'?>
<?rfc include='reference.RFC.4379'?>
<?rfc include='reference.I-D.ietf-bfd-mpls'?>
<?rfc include='reference.RFC.5146'?>
<?rfc include='reference.I-D.ietf-mpls-tp-survive-fwk'?>
<?rfc include='reference.I-D.ietf-mpls-tp-oam-framework'?>
<?rfc include='reference.I-D.ietf-pwe3-dynamic-ms-pw'?>
<?rfc include='reference.I-D.ietf-pwe3-segmented-pw'?>
<?rfc include='reference.I-D.ietf-mpls-tp-rosetta-stone'?>
<?rfc include='reference.I-D.ietf-l2vpn-arp-mediation'?>
<?rfc include='reference.RFC.5254'?>
<?rfc include='reference.RFC.0826'?>
<?rfc include='reference.RFC.2390'?>
<?rfc include='reference.RFC.2461'?>
<?rfc include='reference.RFC.3122'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 04:54:47 |