One document matched: draft-ietf-mpls-tp-framework-12.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="info" docName="draft-ietf-mpls-tp-framework-12"
ipr="trust200902">
<front>
<title abbrev="MPLS Transport Profile 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" role="editor" 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>
<author fullname="Lou Berger" initials="L" surname="Berger">
<organization>LabN</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone>+1-301-468-9228</phone>
<facsimile></facsimile>
<email>lberger@labn.net</email>
<uri></uri>
</address>
</author>
<date day="5" month="May" year="2010" />
<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 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 signaled or explicitly provisioned bidirectional
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.</t>
<t>This document defines the subset of the MPLS-TP applicable in general
and to point-to-point transport paths. The remaining subset, applicable
specifically to point-to-multipoint transport paths, is outside the
scope of this document.</t>
<t>This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
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.</t>
<t>This Informational Internet-Draft is aimed at achieving IETF
Consensus before publication as an RFC and will be subject to an IETF
Last Call.</t>
<t>[RFC Editor, please remove this note before publication as an RFC and
insert the correct Streams Boilerplate to indicate that the published
RFC has IETF Consensus.]</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Motivation and Background">
<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 <xref target="RFC5654"></xref>, and that together
constitute the MPLS Transport Profile (MPLS-TP) for point-to-point
transport paths. The remaining MPLS-TP functions, applicable
specifically to point-to-multipoint transport paths, are outside the
scope of this document.</t>
<t>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:</t>
<t><list style="symbols">
<t>Strictly connection-oriented connectivity, which may be
long-lived and may be provisioned manually, for example by network
management systems or direct node configuration using a command
line interface.</t>
<t>A high level of availability.</t>
<t>Quality of service.</t>
<t>Extensive Operations, Administration and Maintenance (OAM)
capabilities.</t>
</list> 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.</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 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.</t>
<t>This document is a product of a joint Internet Engineering Task
Force (IETF) / International Telecommunication Union Telecommunication
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.</t>
</section>
<section title="Scope">
<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 <xref target="RFC5654"></xref>, 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 outside the
scope of this document.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>AC</c>
<c>Attachment Circuit</c>
<c>ACH</c>
<c>Associated Channel Header</c>
<c>Adaptation</c>
<c>The mapping of client information into a format suitable for
transport by the server layer</c>
<c>APS</c>
<c>Automatic Protection Switching</c>
<c>ATM</c>
<c>Asynchronous Transfer Mode</c>
<c>BFD</c>
<c>Bidirectional Forwarding Detection</c>
<c>CE</c>
<c>Customer Edge</c>
<c>CL-PS</c>
<c>Connectionless - Packet Switched</c>
<c>CM</c>
<c>Configuration Management</c>
<c>CO-CS</c>
<c>Connection Oriented - Circuit Switched</c>
<c>CO-PS</c>
<c>Connection Oriented - Packet Switched</c>
<c>DCN</c>
<c>Data Communication Network</c>
<c>EMF</c>
<c>Equipment Management Function</c>
<c>FCAPS</c>
<c>Fault, Configuration, Accounting, Performance and Security</c>
<c>FM</c>
<c>Fault Management</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>G-ACh Label</c>
<c>LER</c>
<c>Label Edge Router</c>
<c>LSP</c>
<c>Label Switched Path</c>
<c>LSR</c>
<c>Label Switching Router</c>
<c>MAC</c>
<c>Media Access Control</c>
<c>MCC</c>
<c>Management Communication Channel</c>
<c>ME</c>
<c>Maintenance Entity</c>
<c>MEG</c>
<c>Maintenance Entity Group</c>
<c>MEP</c>
<c>Maintenance Entity Group End Point</c>
<c>MIP</c>
<c>Maintenance Entity Group Intermediate Point</c>
<c>MPLS</c>
<c>Multiprotocol Label Switching</c>
<c>MPLS-TP</c>
<c>MPLS Transport Profile</c>
<c>MPLS-TP P</c>
<c>MPLS-TP Provider LSR</c>
<c>MPLS-TP PE</c>
<c>MPLS-TP Provider Edge LSR</c>
<c>MS-PW</c>
<c>Multi-Segment Pseudowire</c>
<c>Native Service</c>
<c>The traffic belonging to the client of the MPLS-TP network</c>
<c>OAM</c>
<c>Operations, Administration and Maintenance (see <xref
target="I-D.ietf-opsawg-mpls-tp-oam-def"></xref>)</c>
<c>OSI</c>
<c>Open Systems Interconnection</c>
<c>OTN</c>
<c>Optical Transport Network</c>
<c>PDU</c>
<c>Protocol Data Unit</c>
<c>PM</c>
<c>Performance Monitoring</c>
<c>PSN</c>
<c>Packet Switching Network</c>
<c>PW</c>
<c>Pseudowire</c>
<c>SCC</c>
<c>Signaling Communication Channel</c>
<c>SDH</c>
<c>Synchronous Digital Hierarchy</c>
<c>S-PE</c>
<c>PW Switching Provider Edge</c>
<c>SPME</c>
<c>Sub-Path Maintenance Element</c>
<c>T-PE</c>
<c>PW Terminating Provider Edge</c>
<c>VCCV</c>
<c>Virtual Circuit Connectivity Verification</c>
</texttable>
<section title="Transport Network">
<t>A 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 outside the 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.</t>
<t>See also the definition of Packet Transport Service in <xref
target="pts"></xref>.</t>
</section>
<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 transport network
requirements <xref target="RFC5654"></xref>.</t>
</section>
<section title="MPLS-TP Section">
<t>MPLS-TP Sections are defined in <xref
target="I-D.ietf-mpls-tp-data-plane"></xref>. See also the
definition of "section layer network" in Section 1.2.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 1+1, 1:1, and 1:N protection functions.</t>
<t>Is traffic engineered.</t>
<t>May be established and maintained via the management plane,
or using GMPLS protocols when a control plane is used.</t>
<t>Is either point-to-point or point-to-multipoint.
multipoint-to-point and multipoint-to-multipoint LSPs are not
supported.</t>
<t>It is either unidirectional, associated bidirectional, or
co-routed bidirectional (i.e. the forward and reverse components
of a bidirectional LSP follow the same path and the intermediate
nodes are aware of their association). These are further defined
in <xref target="I-D.ietf-mpls-tp-data-plane"></xref>.</t>
</list>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.</t>
<t>See <xref target="I-D.ietf-mpls-tp-data-plane"></xref> for
further details on the types and data-plane properties of MPLS-TP
LSPs.</t>
<t>The lowest server layer provided by MPLS-TP is an MPLS-TP LSP.
The client layers of an MPLS-TP LSP may be network layer protocols,
MPLS LSPs, or PWs. The relationship of an MPLS-TP LSP to its client
layers is described in detail in <xref
target="native-services"></xref>.</t>
</section>
<section title="MPLS-TP Label Switching Router">
<t>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.</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="Label Edge Router">
<t>An MPLS-TP Label Edge Router (LER) is an LSR that exists at the
endpoints of an LSP and therefore pushes or pops the LSP label,
i.e. does not perform a label swap on the particular LSP under
consideration.</t>
</section>
<section title="MPLS-TP Provider Edge Router">
<t>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 <xref
target="RFC5659"></xref> (see below). A PE that pushes or pops an
LSP label is an LER for that LSP.</t>
<t>The term Provider Edge refers to the node's role within a
provider's network. A provider edge router resides at the edge of
a given MPLS-TP network domain, in which case it has links to
another MPLS-TP network domain or to a CE, except for the case of
a pseudowire switching provider edge (S-PE) router, which is not
restricted to the edge of an MPLS-TP network domain.</t>
</section>
<section title="MPLS-TP Provider Router">
<t>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. The term Provider Router refers to the node's role
within a provider's network. A provider router does not have links
to other MPLS-TP network domains.</t>
</section>
<section title="Pseudowire Switching Provider Edge Router (S-PE)">
<t>RFC5659<xref target="RFC5659"></xref> defines an S-PE as:</t>
<t><list style="hanging">
<t>"A PE capable of switching the control and data planes of
the preceding and succeeding PW segments in an MS-PW. The S-PE
terminates the PSN tunnels of the preceding and succeeding
segments of the MS-PW. It therefore includes a PW switching
point for an MS-PW. A PW switching point is never the S-PE and
the T-PE for the same MS-PW. A PW switching point runs
necessary protocols to set up and manage PW segments with
other PW switching points and terminating PEs. An S-PE can
exist anywhere a PW must be processed or policy applied. It is
therefore not limited to the edge of a provider network.</t>
<t>"Note that it was originally anticipated that S-PEs would
only be deployed at the edge of a provider network where they
would be used to switch the PWs of different service
providers. However, as the design of MS-PW progressed, other
applications for MS-PW were recognized. By this time S-PE had
become the accepted term for the equipment, even though they
were no longer universally deployed at the provider edge."</t>
</list></t>
</section>
<section title="Pseudowire Terminating Provider Edge Router (T-PE)">
<t>RFC5659<xref target="RFC5659"></xref> defines a T-PE as:</t>
<t><list style="hanging">
<t>"A PE where the customer- facing attachment circuits (ACs)
are bound to a PW forwarder. A terminating PE is present in
the first and last segments of an MS-PW. This incorporates the
functionality of a PE as defined in RFC 3985."</t>
</list></t>
</section>
</section>
<section title="Customer Edge (CE)">
<t>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 link.</t>
</section>
<section title="Transport LSP">
<t>A Transport LSP is an LSP between a pair of PEs that may transit
zero or more MPLS-TP provider routers. When carrying PWs, the
transport LSP is equivalent to the PSN tunnel LSP in <xref
target="RFC3985"></xref> terminology.</t>
</section>
<section title="Service LSP">
<t>A service LSP is an LSP that carries a single client service.</t>
</section>
<section title="Layer Network">
<t>A layer network is defined in <xref target="G.805"></xref> and
described in <xref target="RFC5654"></xref>. A layer network
provides for the transfer of client information and independent
operation of the client OAM. A layer network may be described in a
service context as follows: one layer network may provide a
(transport) service to a higher client layer network and may, in
turn, be a client to a lower-layer network. A layer network is a
logical construction somewhat independent of arrangement or
composition of physical network elements. A particular physical
network element may topologically belong to more than one layer
network, depending on the actions it takes on the encapsulation
associated with the logical layers (e.g., the label stack), and thus
could be modeled as multiple logical elements. A layer network may
consist of one or more sublayers.</t>
</section>
<section title="Network Layer">
<t>This document uses the term Network Layer in the same sense as it
is used in <xref target="RFC3031"></xref> and <xref
target="RFC3032"></xref>. Network layer protocols are synymous with
those beloging to layer 3 of the Open System Interconnect (OSI)
network model <xref target="X.200"></xref>.</t>
</section>
<section title="Service Interface">
<t>The packet transport service provided by MPLS-TP is provided at a
service interface. Two types of service interfaces are defined:</t>
<t><list style="symbols">
<t>User-Network Interface (UNI) (see <xref
target="uni-section"></xref>).</t>
<t>Network-Network Interface (NNI) (see <xref
target="nni-section"></xref>).</t>
</list>A UNI service interface may be a layer 2 interface that
carries only network layer clients. MPLS-TP LSPs are both necessary
and sufficient to support this service interface as described in
section 3.4.3. Alternatively, it may be a layer 2 interface that
carries both network layer and non-network layer clients. To support
this service interface, a PW is required to adapt the client traffic
received over the service interface. This PW in turn is a client of
the MPLS-TP server layer. This is described in section 3.4.2.</t>
<t>An NNI service interface may be to an MPLS LSP or a PW. To
support this case an MPLS-TP PE participates in the service
interface signaling.</t>
</section>
<section title="Native Service">
<t>The native service is the client layer network service that is
transported by the MPLS-TP network, whether a pseudowire or an LSP
is used for the adaptation (see <xref
target="native-services"></xref>).</t>
</section>
<section title="Additional Definitions and Terminology">
<t>Detailed definitions and additional terminology may be found in
<xref target="RFC5654"></xref> and <xref
target="I-D.ietf-mpls-tp-rosetta-stone"></xref>.</t>
</section>
</section>
</section>
<section title="MPLS Transport Profile 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. It is not normative or 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 bidirectional, and it
must be possible to construct congruent bidirectional 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="MPLS Transport Profile Overview">
<section anchor="pts" 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 exhibit 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 either the
server or client layer network.</t>
<t>The service provided by the MPLS-TP network to a given client
will not to fall below the agreed level as a result of the traffic
loading of other clients.</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, where the client network
layer is considered to be the native service of the MPLS-TP
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 CLNS 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>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.</t>
</section>
<section title="Scope of the 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 subset of MPLS, and comprises only
those functions that are necessary to 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> such as Equal
Cost Multi-Path, LDP signaling when used in such a way that it creates
multipoint-to-point LSPs, and IP forwarding in the data plane are
explicitly excluded from MPLS-TP by that requirements
specification.</t>
<t>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.</t>
<t><figure anchor="mpls-tp-scope" title="Scope of MPLS-TP">
<artwork><![CDATA[ |<============================== MPLS ==============================>|
{ Post-RFC5654 }
{ non-Transport }
{ Functions }
|<========== Pre-RFC5654 MPLS ===========>|
{ ECMP }
{ LDP/non-TE LSPs }
{ IP fwd }
|<======== MPLS-TP ============>|
{ Additional }
{ Transport }
{ Functions }
]]></artwork>
</figure></t>
<t>MPLS-TP can be used to construct packet networks and is therefore
applicable in any packet network context. A subset of MPLS-TP is also
applicable to ITU-T defined packet transport networks, where the
transport network operational model is deemed attractive.</t>
</section>
<section anchor="arch" title="Architecture">
<t>MPLS-TP comprises the following architectural elements:</t>
<t><list style="symbols">
<t>A standard MPLS data plane <xref target="RFC3031"></xref> as
profiled in <xref
target="I-D.ietf-mpls-tp-data-plane"></xref>.</t>
<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, as outlined in <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>.</t>
<t>Control planes for LSPs and PWs, as well as support for static
provisioning and configuration, as outlined in <xref
target="I-D.ietf-ccamp-mpls-tp-cp-framework"></xref>.</t>
<t>Path protection mechanisms to ensure that the packet transport
service survives anticipated failures and degradations of the
MPLS-TP network, as outlined in <xref
target="I-D.ietf-mpls-tp-survive-fwk"></xref>.</t>
<t>Control plane based restoration mechanisms, as outlined in
<xref target="I-D.ietf-mpls-tp-survive-fwk"></xref>.</t>
<t>Network management functions, as outlined in <xref
target="I-D.ietf-mpls-tp-nm-framework"></xref>.</t>
</list></t>
<t>The MPLS-TP architecture for LSPs and PWs includes the following
two sets of functions:</t>
<t><list style="symbols">
<t>MPLS-TP native service adaptation</t>
<t>MPLS-TP forwarding</t>
</list></t>
<t>The adaptation functions interface the native service (i.e. the
client layer network service) to MPLS-TP. This includes the case where
the native service is an MPLS-TP LSP.</t>
<t>The forwarding functions comprise the mechanisms required for
forwarding the encapsulated native service traffic over an MPLS-TP
server layer network, for example PW and LSP labels.</t>
<section title="MPLS-TP Native Service Adaptation Functions"
toc="default">
<t>The MPLS-TP native service adaptation functions interface the
client layer network service to MPLS-TP. For pseudowires, these
adaptation functions are the payload encapsulation described in
Section 4.4 of <xref target="RFC3985"></xref> and Section 6 of <xref
target="RFC5659"></xref>. For network layer client services, the
adaptation function uses the MPLS encapsulation format as defined in
<xref target="RFC3032"></xref>.</t>
<t>The purpose of this encapsulation is to abstract the client layer
network 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 Quality of Service (QoS) from the
MPLS-TP network, which in turn inherits its QoS from the server
layer. The server layer therefore needs to provide the necessary QoS
to ensure that the MPLS-TP client QoS commitments can be
satisfied.</t>
</section>
<section title="MPLS-TP Forwarding Functions">
<t>The forwarding functions comprise the mechanisms required for
forwarding the encapsulated native service traffic over an MPLS-TP
server layer network, for example PW and LSP labels.</t>
<t>MPLS-TP LSPs use the MPLS label switching operations and TTL
processing procedures defined in <xref target="RFC3031"></xref>,
<xref target="RFC3032"></xref> and <xref target="RFC3443"></xref>,
as profiled in <xref target="I-D.ietf-mpls-tp-data-plane"></xref>.
These operations are highly optimised for performance and are not
modified by the MPLS-TP profile.</t>
<t>In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW
forwarding operations defined in <xref target="RFC3985"></xref> and
<xref target="RFC5659"></xref>.</t>
<t>Per-platform label space is used for PWs. Either per-platform,
per-interface or other context-specific label space <xref
target="RFC5331"></xref> 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 designing protocol extensions (such as those
for OAM) that require 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,
or the packet is received with the GAL (<xref
target="GENERICACH"></xref>) at the top of stack. Otherwise the
packet is forwarded according to the procedures in <xref
target="RFC3032"></xref>.</t>
<t>MPLS-TP supports Quality of Service capabilities via the MPLS
Differentiated Services (DiffServ) architecture <xref
target="RFC3270"></xref>. Both E-LSP and L-LSP MPLS DiffServ modes
are supported.</t>
<t>Further details of MPLS-TP forwarding can be found in <xref
target="I-D.ietf-mpls-tp-data-plane"></xref>.</t>
</section>
</section>
<section anchor="native-services"
title="MPLS-TP Native Service Adaptation">
<t>This document describes the architecture for two native service
adaptation mechanisms, which provide encapsulation and demultiplexing
for native service traffic traversing an MPLS-TP network:</t>
<t><list style="symbols">
<t>A PW</t>
<t>An MPLS LSP</t>
</list></t>
<t>MPLS-TP uses IETF-defined pseudowires to emulate certain services,
for example Ethernet, Frame Relay, or PPP/HDLC. A list of PW types is
maintained by IANA in the the "MPLS Pseudowire Type" registry. When
the native service adaptation is via a PW, the mechanisms described in
<xref target="PW-sec"></xref> are used.</t>
<t>An MPLS LSP can also provide the adaptation, in which case any
native service traffic type supported by <xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref> is
allowed. Examples of such traffic types include IP, and MPLS-labeled
packets. Note that the latter case includes TE-LSPs <xref
target="RFC3209"></xref> and LSP based applications such as PWs, Layer
2 VPNs <xref target="RFC4664"></xref>, and Layer 3 VPNs <xref
target="RFC4364"></xref>. When the native service adaptation is via an
MPLS label, the mechanisms described in <xref
target="NLTS-sec"></xref> are used.</t>
<section title="MPLS-TP Client/Server Layer Relationship">
<t>The relationship between the client layer network and the MPLS-TP
server layer network is defined by the MPLS-TP network boundary and
the label context. It is not explicitly indicated in the packet. In
terms of the MPLS label stack, when the native service traffic type
is itself MPLS-labeled, then the S bits of all the labels in the
MPLS-TP label stack carrying that client traffic are zero; otherwise
the bottom label of the MPLS-TP label stack has the S-bit set to 1.
In other words, there can be only one S-bit set in a label
stack.</t>
<t>The data plane behaviour of MPLS-TP is the same as the best
current practice for MPLS. This includes the setting of the S-bit.
In each case, the S-bit is set to indicate the bottom (i.e.
inner-most) label in the label stack that is contiguous between the
MPLS-TP LSP and its payload, and only one LSE contains the S (Bottom
of Stack) bit set to 1. Note that this best current practice differs
slightly from <xref target="RFC3032"></xref> which uses the S-bit to
identify when MPLS label processing stops and network layer
processing starts.</t>
<t>The relationship of MPLS-TP to its clients is illustrated in
<xref target="clients"></xref>. Note that the label stacks shown in
the figure are divided between those inside the MPLS-TP Network and
those within the client network when the client network is
MPLS(-TP). They illustrate the smallest number of labels possible.
These label stacks could also include more labels.</t>
<t><figure anchor="clients" title="MPLS-TP - Client Relationship">
<artwork><![CDATA[
PW-Based MPLS Labelled IP
Services Services Transport
|------------| |-----------------------------| |------------|
Emulated PW over LSP IP over LSP IP
Service
+------------+
| PW Payload |
+------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)| . . .
+------------+ . . . (MPLS-TP)
. . . .
.
.
~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
]]></artwork>
</figure></t>
<t></t>
</section>
<section title="MPLS-TP Transport Layers">
<t>An MPLS-TP network consists logically of two layers: the
Transport Service layer and the Transport Path layer.</t>
<t>The Transport Service layer provides the interface between
Customer Edge (CE) nodes and the MPLS-TP network. Each packet
transmitted by a CE node for transport over the MPLS-TP network is
associated at the receiving MPLS-TP Provider Edge (PE) node with a
single logical point-to-point connection at the Transport Service
layer between this (ingress) PE and the corresponding (egress) PE to
which the peer CE is attached. Such a connection is called an
MPLS-TP Transport Service Instance, and the set of client packets
belonging to the native service associated with such an instance on
a particular CE-PE link is called a client flow.</t>
<t>The Transport Path layer provides aggregation of Transport
Service Instances over MPLS-TP transport paths (LSPs), as well as
aggregation of transport paths (via LSP hierarchy).</t>
<t>Awareness of the Transport Service layer need exist only at PE
nodes. MPLS-TP Provider (P) nodes need have no awareness of this
layer. Both PE and P nodes participate in the Transport Path layer.
A PE terminates (i.e., is an LER with respect to) the transport
paths it supports, and is responsible for multiplexing and
demultiplexing of Transport Service Instance traffic over such
transport paths.</t>
</section>
<section title="MPLS-TP Transport Service Interfaces">
<t>An MPLS-TP PE node can provide two types of interface to the
Transport Service layer. The MPLS-TP User-Network Interface (UNI)
provides the interface between a CE and the MPLS-TP network. The
MPLS-TP Network-Network Interface (NNI) provides the interface
between two MPLS-TP PEs in different administrative domains.</t>
<t>When MPLS-TP is used to provide a transport service for e.g. IP
services that are a part of a Layer 3 VPN, then packets are
transported in the same manner as specified in <xref
target="RFC4364"></xref>.</t>
<section anchor="uni-section" title="User-Network Interface">
<t>The MPLS-TP User-Network interface (UNI) is illustrated in
<xref target="PE-UNI-FIG"></xref>. The UNI for a particular client
flow may or may not involve signaling between the CE and PE, and
if signaling is used, it may or may not traverse the same
attachment circuit that supports the client flow.</t>
<t><figure anchor="PE-UNI-FIG" title="MPLS-TP PE Containing a UNI">
<artwork><![CDATA[ : User-Network Interface : MPLS-TP
:<-------------------------------------->: Network <----->
: :
-:------------- --------------:------------------
: | | : Transport |
: | | Transport : Path |
: | | Service : Mux/Demux |
: | | Control : -- |
: | | Plane : | | Transport|
: ---------- | Signaling | ---------- : | | Path |
:|Signaling |_|___________|_|Signaling | : | | --------->
:|Controller| | | |Controller| : | | |
: ---------- | | ---------- : | | --------->
: :......|...........|......: : | | |
: | Control | : | | Transport|
: | Channel | : | | Path |
: | | : | | --------->
: | | : | | -+----------->TSI
: | | Transport : | | | --------->
: | Client | Service : | | | |
: | Traffic | Data Plane : | | | |
: ---------- | Flows | -------------- | | |Transport|
:|Signaling |-|-----------|-|Client/Service|-| |- Path |
:|Controller|=|===========|=| Traffic | | | --------->
: ---------- | | | Processing |=| |===+===========>TSI
: | | | -------------- | | --------->
: |______|___________|______| : | | |
: | Data Link | : | | |
: | | : -- |
: | | : Transport |
: | | : Service |
: | | : Data Plane|
--------------- ---------------------------------
Customer Edge Node MPLS-TP Provider Edge Node
TSI = Transport Service Instance
]]></artwork>
</figure></t>
<t></t>
<t><figure anchor="uni-traffic-processing"
title="MPLS-TP UNI Client-Server Traffic Processing Stages">
<artwork><![CDATA[ --------------From UNI-------> :
-------------------------------------------:------------------
| | Client Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Transport |
| | Service Instance : Encapsulation |
| | Identification : |
-------------------------------------------:------------------
:
:
-------------------------------------------:------------------
| | : Service Instance |
| | : Transport |
| Link-Layer-Specific | Client Traffic Unit : Decapsulation |
| Processing | Link Encapsulation : & |
| | : Service Instance |
| | : Identification |
-------------------------------------------:------------------
<-------------To UNI --------- :]]></artwork>
</figure></t>
<t><xref target="uni-traffic-processing"></xref> shows the logical
processing steps involved in a PE both for traffic flowing from
the CE to the MPLS-TP network (left to right), and from the
network to the CE (right to left).</t>
<t>In the first case, when a packet from a client flow is received
by the PE from the CE over the data-link, the following steps
occur:</t>
<t><list style="numbers">
<t>Link-layer specific preprocessing, if any, is performed. An
example of such preprocessing is the PREP function illustrated
in Figure 3 of [RFC3985]. Such preprocessing is outside the
scope of MPLS-TP.</t>
<t>The packet is extracted from the data-link frame if
necessary, and associated with a Transport Service Instance.
At this point, UNI processing has completed.</t>
<t>A transport service encapsulation is associated with the
packet, if necessary, for transport over the MPLS-TP
network.</t>
<t>The packet is mapped to a transport path based on its
associated Transport Service Instance, the transport path
encapsulation is added, if necessary, and the packet is
transmitted over the transport path.</t>
</list>In the second case, when a packet associated with a
Transport Service Instance arrives over a transport path, the
following steps occur:</t>
<t><list style="numbers">
<t>The transport path encapsulation is disposed of.</t>
<t>The transport service encapsulation is disposed of and the
Transport Service Instance and client flow identified.</t>
<t>At this point, UNI processing begins. A data-link
encapsulation is associated with the packet for delivery to
the CE based on the client flow.</t>
<t>Link-layer-specific postprocessing, if any, is performed.
Such postprocessing is outside the scope of MPLS-TP.</t>
</list></t>
</section>
<section anchor="nni-section" title="Network-Network Interface">
<t>The MPLS-TP NNI is illustrated in <xref
target="PE-NNI-FIG"></xref>. The NNI for a particular transport
service instance may or may not involve signaling between the two
PEs, and if signaling is used, it may or may not traverse the same
data-link that supports the service instance.</t>
<t><figure anchor="PE-NNI-FIG"
title="MPLS-TP PE Containing an NNI">
<artwork><![CDATA[ : Network-Network Interface :
:<--------------------------------->:
: :
------------:------------- -------------:------------
| Transport : | | : Transport |
| Path : Transport | | Transport : Path |
| Mux/Demux : Service | | Service : Mux/Demux |
| -- : Control | | Control : -- |
| | | : Plane |Sig- | Plane : | | |
|TP | | : ---------- | naling| ---------- : | | TP|
<--- | | :|Signaling |_|_______|_|Signaling |: | | --->
TSI<-+- | | :|Controller| | | |Controller|: | | |
<--- | | | : ---------- | | ---------- : | | --->
| | | | : :......|.......|......: : | | |
| | | | : |Control| : | | |
|TP | | | : |Channel| : | | TP|
<--- | | | : | | : | | --->
| | | | : | | : | | -+->TSI
<--- | | | : Transport | | Transport : | | | --->
| | | | : Service |Service| Service : | | | |
| | | | : Data Plane |Traffic| Data Plane : | | | |
| | | | ------------- | Flows | ------------- | | | |
|TP -| |-| Service |-|-------|-| Service |-| |- TP|
<--- | | | Traffic | | | | Traffic | | | --->
TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI
<--- | | ------------- | | ------------- | | --->
| | | : |______|_______|______| : | | |
| | | : | Data | : | | |
| -- : | Link | : -- |
| : | | : |
-------------------------- --------------------------
MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
TP = Transport Path
TSI = Transport Service Instance
]]></artwork>
</figure></t>
<t><figure anchor="nni-traffic-processing"
title="MPLS-TP NNI Service Traffic Processing Stages">
<artwork><![CDATA[
:
--------------From NNI-------> :
--------------------------------------------:------------------
| | Service Traffic Unit : |
| Link-Layer-Specific | Link Decapsulation : Service Instance |
| Processing | & : Encapsulation |
| | Service Instance : Normalisation |
| | Identification : |
--------------------------------------------:------------------
:
:
--------------------------------------------:------------------
| | : Service Instance |
| | : Identification |
| Link-Layer-Specific | Service Traffic Unit : & |
| Processing | Link Encapsulation : Service Instance |
| | : Encapsulation |
| | : Normalisation |
--------------------------------------------:------------------
<-------------To NNI --------- :]]></artwork>
</figure></t>
<t><xref target="nni-traffic-processing"></xref> shows the logical
processing steps involved in a PE for traffic flowing both from
the peer PE (left to right) and to the peer PE (right to
left).</t>
<t>In the first case, when a packet from a transport service
instance is received by the PE from the peer PE over the
data-link, the following steps occur:</t>
<t><list style="numbers">
<t>Link-layer specific preprocessing, if any, is performed.
Such preprocessing is outside the scope of MPLS-TP.</t>
<t>The packet is extracted from the data-link frame if
necessary, and associated with a Transport Service Instance.
At this point, NNI processing has completed.</t>
<t>The transport service encapsulation of the packet is
normalised for transport over the MPLS-TP network. This step
allows a different transport service encapsulation to be used
over the NNI than that used in the internal MPLS-TP network.
An example of such normalisation is a swap of a label
identifying the Transport Service Instance.</t>
<t>The packet is mapped to a transport path based on its
associated Transport Service Instance, the transport path
encapsulation is added, if necessary, and the packet is
transmitted over the transport path.</t>
</list>In the second case, when a packet associated with a
Transport Service Instance arrives over a transport path, the
following steps occur:</t>
<t><list style="numbers">
<t>The transport path encapsulation is disposed of.</t>
<t>The Transport Service Instance is identified from the
transport service encapsulation, and this encapsulation is
normalised for delivery over the NNI (see Step 3 above).</t>
<t>At this point, NNI processing begins. A data-link
encapsulation is associated with the packet for delivery to
the peer PE based on the normalised Transport Service
Instance.</t>
<t>Link-layer-specific postprocessing, if any, is performed.
Such postprocessing is outside the scope of MPLS-TP.</t>
</list></t>
</section>
<section title="Example Interfaces">
<t>This section considers some special cases of UNI processing for
particular transport service types. These are illustrative, and do
not preclude other transport service types.</t>
<section title="Layer 2 Transport Service">
<t>In this example the MPLS-TP network is providing a
point-to-point Layer 2 transport service between attached CE
nodes. This service is provided by a Transport Service Instance
consisting of a PW established between the associated PE nodes.
The client flows associated with this Transport Service Instance
are the sets of all Layer 2 frames transmitted and received over
the attachment circuits.</t>
<t>The processing steps in this case for a frame received from
the CE are:</t>
<t><list style="numbers">
<t>Link-layer specific preprocessing, if any, is performed,
corresponding to the PREP function illustrated in Figure 3
of <xref target="RFC3985"></xref>.</t>
<t>The frame is associated with a Transport Service Instance
based on the attachment circuit over which it was
received.</t>
<t>A transport service encapsulation, consisting of the PW
control word and PW label, is associated with the frame.</t>
<t>The resulting packet is mapped to an LSP, the LSP label
is pushed, and the packet is transmitted over the outbound
interface associated with the LSP.</t>
</list>The steps in the reverse direction for PW packets
received over the LSP are analogous.</t>
</section>
<section title="IP Transport Service">
<t>In this example the MPLS-TP network is providing a
point-to-point IP transport service between CE1, CE2, and CE3,
as follows. One point-to-point transport service instance
delivers IPv4 packets between CE1 and CE2, and another instance
delivers IPv6 packets between CE1 and CE3.</t>
<t>The processing steps in this case for an IP packet received
from CE1 are:</t>
<t><list style="numbers">
<t>No link-layer-specific processing is performed.</t>
<t>The IP packet is extracted from the link-layer frame and
associated with a Service LSP based on the source MAC
address (CE1) and the IP protocol version.</t>
<t>A transport service encapsulation, consisting of the
Service LSP label, is associated with the packet.</t>
<t>The resulting packet is mapped to a tunnel LSP, the
tunnel LSP label is pushed, and the packet is transmitted
over the outbound interface associated with the LSP.</t>
</list></t>
<t>The steps in the reverse direction, for packets received over
a tunnel LSP carrying the Service LSP label, are analogous.</t>
</section>
</section>
</section>
<section anchor="PW-sec" title="Pseudowire Adaptation">
<t>MPLS-TP uses pseudowires to provide a Virtual Private Wire
Service (VPWS), a Virtual Private Local Area Network Service (VPLS),
a Virtual Private Multicast Service (VPMS) and an Internet Protocol
Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are
described in <xref target="RFC4664"></xref>. VPMS is described in
<xref target="I-D.ietf-l2vpn-vpms-frmwk-requirements"></xref>.</t>
<t>If the MPLS-TP network provides a layer 2 interface, that can
carry both network layer and non-network layer traffic, as a service
interface, then a PW is required to support the service interface.
The PW is a client of the MPLS-TP LSP server layer. The architecture
for an MPLS-TP network that provides such services is based on the
MPLS <xref target="RFC3031"></xref> and pseudowire <xref
target="RFC3985"></xref> 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 <xref target="RFC5254"></xref>. If MS-PWs are used, then the
MS-PW architecture <xref target="RFC5659"></xref> also applies.</t>
<t><xref target="tp-arch"></xref> shows the architecture for an
MPLS-TP network using single-segment PWs. Note that, in this
document, the client layer is equivalent to the emulated service
described in <xref target="RFC3985"></xref>, while the Transport LSP
is equivalent to the Packet Switched Network (PSN) tunnel of <xref
target="RFC3985"></xref>.</t>
<t><figure anchor="tp-arch"
title="MPLS-TP Architecture (Single Segment PW)">
<artwork><![CDATA[ |<----------------- Client Layer ------------------->|
| |
| |<-------- Pseudowire -------->| |
| | encapsulated, packet | |
| | transport service | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|.......PW1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|.......PW2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
]]></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[ |<--------------------- Client Layer ------------------------>|
| |
| Pseudowire encapsulated, |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
| |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ | |
| TE LSP | TE LSP |
| P-router |
Native Service Native Service
PW1-segment1 and PW1-segment2 are segments of the same MS-PW,
while PW2-segment1 and PW2-segment2 are segments of another MS-PW
]]></artwork>
</figure></t>
<t>The corresponding MPLS-TP protocol stacks including PWs are shown
in <xref target="MPLS-TP-Defn"></xref>. In this figure the Transport
Service Layer <xref target="RFC5654"></xref> is identified by the PW
demultiplexer (Demux) label and the Transport Path Layer <xref
target="RFC5654"></xref> is identified by the LSP Demux Label.</t>
<t><figure anchor="MPLS-TP-Defn"
title="MPLS-TP label stack using pseudowires">
<artwork><![CDATA[
+-------------------+ /===================\ /===================\
| Client Layer | H OAM PDU H H OAM PDU H
/===================\ H-------------------H H-------------------H
H PW Encap H H GACh H H GACh H
H-------------------H H-------------------H H-------------------H
H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack considered
in this document.
]]></artwork>
</figure></t>
<t>PWs and their associated labels may be configured or signaled.
See <xref target="static"></xref> for additional details related to
configured service types. See <xref target="CONTROLPLANE"></xref>
for additional details related to signaled service types.</t>
</section>
<section anchor="NLTS-sec" title="Network Layer Adaptation">
<t>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 <xref target="RFC3031"></xref> and <xref
target="RFC3032"></xref>. The network layer protocols supported by
<xref target="RFC3031"></xref> and <xref target="RFC3032"></xref>
can be transported between service interfaces. Support for network
layer clients follows the MPLS architecture for support of network
layer protocols as specified in <xref target="RFC3031"></xref> and
<xref target="RFC3032"></xref>.</t>
<t>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 <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 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.</t>
<t>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>The following figures illustrate the reference models for network
layer adaptation. The details of these figures are described further
in the following paragraphs.</t>
<t><figure anchor="tp-ip-lsp-arch"
title="MPLS-TP Architecture for Network Layer Clients">
<artwork><![CDATA[
|<------------- Client Network Layer --------------->|
| |
| |<----------- Packet --------->| |
| | Transport Service | |
| | | |
| | | |
| | Transport | |
| | |<------ LSP ------->| | |
| V V V V |
V AC +----+ +-----+ +----+ AC V
+-----+ | | PE1|=======\ /========| PE2| | +-----+
| |----------|..Svc LSP1.| \ / |............|----------| |
| CE1 | | | | | X | | | | | CE2 |
| |----------|..Svc LSP2.| / \ |............|----------| |
+-----+ ^ | | |=======/ \========| | | ^ +-----+
^ | +----+ ^ +-----+ +----+ | | ^
| | Provider | ^ Provider | |
| | Edge 1 | | Edge 2 | |
Customer | | P Router | Customer
Edge 1 | TE LSP | Edge 2
| |
| |
Native service Native service
]]></artwork>
</figure></t>
<t><figure anchor="tp-ip-lsp-arch-sw"
title="MPLS-TP Architecture for Network Layer Adaptation, showing Service LSP Switching">
<artwork><![CDATA[
|<--------------------- Client Layer ------------------------>|
| |
| |
| |<---------- Packet Transport Service ------------->| |
| | | |
| | Transport Transport | |
| AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
| | V V V V V V | |
V | +----+ +-----+ +----+ +----+ | V
+---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+
| |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| |
|CE1| | | | | X | | | | | | |CE2|
| |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| |
+---+ ^ | |===============/ \=====| |==========| | | ^+---+
| +----+ ^ +-----+ +----+ ^ +----+ |
| | ^ ^ | |
| TE LSP | | TE LSP |
| P-router | |
Native Service (LSR for | Native Service
T'port LSP1) |
|
LSR for Service LSPs
LER for Transport LSPs
]]></artwork>
</figure></t>
<t>Client packets are received at the ingress service interface. 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.</t>
<t><figure anchor="MPLS-TP-NL-Stack"
title="MPLS-TP Label Stack for IP and LSP Clients">
<artwork><![CDATA[
/===================\
H OAM PDU H
+-------------------+ H-------------------H /===================\
| Client Layer | H GACh H H OAM PDU H
/===================\ H-------------------H H-------------------H
H Encap Label H H GAL (S=1) H H GACh H
H-------------------H H-------------------H H-------------------H
H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
H-------------------H H-------------------H H-------------------H
H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
\===================/ \===================/ \===================/
| Server Layer | | Server Layer | | Server Layer |
+-------------------+ +-------------------+ +-------------------+
User Traffic Service LSP OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack considered
in this document.
]]></artwork>
</figure></t>
<t>In the figures above, the Transport Service Layer <xref
target="RFC5654"></xref> is identified by the Service LSP (SvcLSP)
demultiplexer (Demux) label and the Transport Path Layer <xref
target="RFC5654"></xref> is identified by the Transport (Trans) LSP
Demux Label. Note that the functions of the Encapsulation label
(Encap Label) and the Service Label (SvcLSP Demux) shown above may
alternatively be represented by a single label stack entry. Note
that the S-bit is always zero when the client layer is
MPLS-labelled. It may be necessary to swap a service LSP label at an
intermediate node. This is shown in <xref
target="tp-ip-lsp-arch-sw"></xref>.</t>
<t>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. <xref
target="MPLS-TP-NL-Stack"></xref> 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.</t>
<t>A label may be used to identify the network layer protocol
payload type. Therefore, when multiple protocol payload types are to
be carried over a single service LSP, a unique label stack entry
needs to be present for each payload type. Such labels are referred
to as "Encapsulation Labels", one of which is shown in <xref
target="MPLS-TP-NL-Stack"></xref>. Encapsulation Label may be either
configured or signaled.</t>
<t>Both an Encapsulation Label and a Service Label should be present
in the label stack when a particular packet transport service is
supporting more than one network layer protocol payload type. For
example, if both IP and MPLS are to be carried, then two
Encapsulation Labels are mapped on to a common Service Label.</t>
<t>Note: The Encapsulation Label may be omitted when the service LSP
is supporting only one network layer protocol payload type. For
example, if only MPLS labeled packets are carried over a service,
then the Service Label (stack entry) provides both the payload type
indication and service identification.</t>
<t>Service labels are typically carried over an MPLS-TP Transport
LSP edge-to-edge (or transport path layer). An MPLS-TP Transport LSP
is represented as an LSP Transport Demux label, as shown in <xref
target="MPLS-TP-NL-Stack"></xref>. Transport LSP is commonly used
when more than one service exists between two PEs.</t>
<t>Note that, if only one service exists between two PEs, the
functions of the Transport LSP label and the Service LSP Label may
be combined into a single label stack entry. For example, if only
one service is carried between two PEs then a single label could be
used to provide both the service indication and the MPLS-TP
transport LSP. Alternatively, if multiple services exist between a
pair of PEs then a per-client Service Label would be mapped on to a
common MPLS-TP transport LSP.</t>
<t>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.</t>
<t>At each service interface, Layer 2 addressing needs to be used to
ensure the proper delivery of a network layer packet to the adjacent
node. This is typically only an issue for LAN media technologies
(e.g., Ethernet) which have Media Access Control (MAC) addresses. In
cases where a MAC address is needed, the sending node sets the
destination MAC address to an address that ensures delivery to the
adjacent node. That is the CE sets the destination MAC address to an
address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not
specified in this document. In some technologies the MAC address
will need to be configured.</t>
<t>Note that when two CEs, which peer with each other, operate over
a network layer transport service and run a routing protocol such as
IS-IS or OSPF, some care should be taken to configure the routing
protocols to use point-to-point adjacencies. The specifics of such
configuration is outside the scope of this document. See <xref
target="RFC5309"></xref> for additional details.</t>
<t>The CE to CE service types and corresponding labels may be
configured or signaled .</t>
</section>
</section>
<section anchor="addr" title="Identifiers">
<t>Identifiers are used to uniquely distinguish entities in an MPLS-TP
network. These include operators, nodes, LSPs, pseudowires, and their
associated maintenance entities. MPLS-TP defined two type of sets of
identifiers: Those that are compatible with IP, and another set that
is compatible with ITU-T transport-based operations. The definition of
these sets of identifiers is outside the scope of this document and is
provided by <xref target="I-D.ietf-mpls-tp-identifiers"></xref>.</t>
</section>
<section anchor="GENERICACH" title="Generic Associated Channel (G-ACh)">
<t>For correct operation of OAM mechanisms it is important that OAM
packets fate-share with the data packets. In addition in MPLS-TP it is
necessary to discriminate between user data payloads and other types
of payload. For example, a packet may be associated with a Signaling
Communication Channel (SCC), or a channel used for a protocol to
coordinate path protection state. This is achieved by carrying such
packets in either:</t>
<t><list style="symbols">
<t>A generic control channel associated to the LSP, PW or section,
with no IP encapsulation. e.g. in a similar manner to
Bidirectional Forwarding Detection for Virtual Circuit
Connectivity Verification (VCCV-BFD) with PW ACH encapsulation
<xref target="I-D.ietf-pwe3-vccv-bfd"></xref>).</t>
<t>An IP encapsulation where IP capabilities are present. e.g. PW
ACH encapsulation with IP headers for VCCV-BFD <xref
target="I-D.ietf-pwe3-vccv-bfd"></xref>, or IP encapsulation for
MPLS BFD <xref target="I-D.ietf-bfd-mpls"></xref>.</t>
</list>MPLS-TP makes use of such a generic associated channel
(G-ACh) to support Fault, Configuration, Accounting, Performance and
Security (FCAPS) functions by carrying packets related to OAM, a
protocol used to coodinate path protection state, SCC, MCC or other
packet types in-band over LSPs, PWs or sections. The G-ACh is defined
in <xref target="RFC5586"></xref> and is similar to the Pseudowire
Associated Channel <xref target="RFC4385"></xref>, which is used to
carry OAM packets over pseudowires. The G-ACh is indicated by an
Associated Channel Header (ACH), similar to the Pseudowire VCCV
control word; this header is present for all sections, LSPs and PWs
making use of FCAPS functions supported by the G-ACh.</t>
<t>As specified in <xref target="RFC5586"></xref>, the G-ACh must only
be used for channels that are an adjunct to the data service. Examples
of these are OAM, a protocol used to coodinate path protection state,
MCC and SCC, but the use is not restricted to these services. The
G-ACh must not to 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>At the server layer, bandwidth and QoS commitments apply to the
gross traffic on the LSP, PW or section. Since the G-ACh traffic is
indistinguishable from the user data traffic, protocols using the
G-ACh need to take into consideration the impact they have on the user
data with which they are sharing resources. Conversely, capacity needs
to be made available for important G-ACh uses such as protection and
OAM. In addition, the security and congestion considerations described
in <xref target="RFC5586"></xref> apply to protocols using the
G-ACh.</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><figure anchor="PWE3-stack"
title="PWE3 Protocol Stack Reference Model showing the G-ACh "
width="72">
<artwork><![CDATA[
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| 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 showing the LSP Associated Control Channel ">
<artwork><![CDATA[
+-------------+ +-------------+
| Payload | < FCAPS > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
]]></artwork>
</figure>
<t></t>
</section>
<section anchor="OAM"
title="Operations, Administration and Maintenance (OAM)">
<t>The MPLS-TP OAM architecture supports a wide range of OAM functions
to check continuity, to verify connectivity, to monitor path
performance, and 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.</t>
<t>The MPLS-TP OAM tool-set is 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. Since MPLS-TP can operate in environments where IP
is not used in the forwarding plane, the default mechanism for OAM
demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated
Channel (<xref target="GENERICACH"></xref>). 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 for IPv4 and that same range embedded as IPv4 mapped
IPv6 addresses for IPv6 <xref target="RFC4379"></xref>. 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, although the mechanisms defined in <xref
target="RFC5586"></xref> can also be used. MPLS-TP is able to operate
in environments where IP forwarding is not supported, and thus the
G-ACh/GAL is the default mechanism to demultiplex OAM packets in
MPLS-TP in these environments.</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 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 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 <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 G-ACh Label (GAL) to create a
control channel associated to an LSP, Section or PW.</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
(ME) can be viewed as the association of two Maintenance Entity Group
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.</t>
<t>A MEG may also include a set of Maintenance Entity Group
Intermediate Points (MIPs). MEPs are capable of sourcing and sinking
OAM flows, while MIPs can both react to OAM flows received from within
a MEG and originate notifications to the MEPs as a result of specific
network conditions.</t>
<t>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 stack
entry for the G-ACh packet, as per the traceroute mode of LSP Ping
<xref target="RFC4379"></xref> and the vccv-trace mode of <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 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.</t>
<t>Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
layer processing is performed on a packet. The MPLS architecture
mandates that MPLS layer processing occurs at least once on an
LSR.</t>
<t>Any node on an LSP can send an OAM packet on that LSP. Likewise,
any node on a PW can send OAM packets on a PW, including S-PEs.</t>
<t>An OAM packet can only be received to be processed at an LSP
endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the LSP
or PW label stack entry.</t>
</section>
<section title="Return Path">
<t>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. Although this section describes the case
of an MPLS-TP LSP, it is also applicable to a PW.</t>
<t>In this description, U and D are LSRs that terminate MPLS-TP LSPs
(i.e. LERs) and Y is an intermediate LSR along the LSP. Note that U is
the upstream LER and D is the downstream LER with respect to a
particular direction of an LSP. This reference model is shown in <xref
target="ret-path-fig"></xref>.</t>
<t><figure anchor="ret-path-fig" title="Return Path reference Model">
<artwork><![CDATA[
LSP LSP
U ========= Y ========= D
LER LSR LER
---------> Direction of user plane traffic flow
]]></artwork>
</figure></t>
<t>The following cases are described for the various types of
LSPs:</t>
<t><list style="hanging">
<t hangText="Case 1">Return path packet transmission from D to
U</t>
<t hangText="Case 2">Return path packet transmission from Y to
U</t>
<t hangText="Case 3">Return path packet transmission from D to
Y</t>
</list>Note that a return path may not always exist (or may exist
but be disabled), 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.</t>
<section title="Return Path Types">
<t>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:</t>
<t><list style="letters">
<t>The LSP between U and D is bidirectional, and therefore D has
a path via the MPLS-TP LSP to return traffic back to U, or</t>
<t>D has some other unspecified means of directing traffic back
to U.</t>
</list></t>
<t>The first option is referred to as an "in-band" return path, the
second as an "out-of-band" return path.</t>
<t>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 distinct Data
Communication Network (DCN) (provided, for example, by the method
specified in <xref target="RFC5718"></xref>); or it may be via one
or more other MPLS-TP LSPs.</t>
</section>
<section title="Point-to-Point Unidirectional LSPs">
<t><list counter="" hangIndent="8" style="hanging">
<t hangText="Case 1">If an in-band return path is required to
deliver traffic from D back to U, it is 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 D to U is
required. Note that the two directions of such an LSP may have
differing bandwidth allocations and QoS characteristics. The
discussion for such LSPs below applies.</t>
<t>As an alternative, an out-of-band return path may be
used.</t>
<t hangText="Case 2">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 D is known to have a
return path to U, then Y can arrange to deliver return traffic
to U by first sending it to D along the original LSP. The
mechanism by which D recognises the need for and performs this
forwarding operation is protocol-specific.</t>
<t hangText="Case 3">In this case only the out-of-band return
path option is available. However, if D has a return path to U,
then in a manner analogous to the previous case D can arrange to
deliver return traffic to Y by first sending it to U along that
return path. The mechanism by which U recognises the need for
and performs this forwarding operation is protocol-specific.</t>
</list></t>
</section>
<section title="Point-to-Point Associated Bidirectional LSPs">
<t>For Case 1, D has a natural in-band return path to U, the use of
which is typically preferred for return traffic, although
out-of-band return paths are also applicable.</t>
<t>For Cases 2 and 3, the considerations are the same as those for
point-to-point unidirectional LSPs.</t>
</section>
<section title="Point-to-Point Co-Routed Bidirectional LSPs">
<t>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 preferred for
return traffic. Out-of-band return paths, however, are also
applicable, primarily as an alternative means of delivery in case
the in-band return path has failed.</t>
</section>
</section>
<section anchor="CONTROLPLANE" title="Control Plane">
<t>A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements
specified in <xref target="RFC5654"></xref> can be met, the MPLS
Transport Profile uses existing standard control plane protocols for
LSPs and PWs.</t>
<t>Note that a dynamic control plane is not required in an MPLS-TP
network. See <xref target="static"></xref> for further details on
statically configured and provisioned MPLS-TP services.</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><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, an LSP or a G-ACh.
]]></artwork>
</figure></t>
<t>The MPLS-TP control plane is based on existing MPLS and PW control
plane protocols, and is consistent with the Automatically Switched
Optical Networks (ASON) architecture <xref target="G.8080"></xref>.
MPLS-TP uses Generalized MPLS (GMPLS) signaling (<xref
target="RFC3945"></xref>, <xref target="RFC3471"></xref>, <xref
target="RFC3473"></xref>) for LSPs and Targeted LDP (T-LDP) <xref
target="RFC4447"></xref> <xref target="I-D.ietf-pwe3-segmented-pw">
</xref><xref target="I-D.ietf-pwe3-dynamic-ms-pw"></xref> for
pseudowires.</t>
<t>MPLS-TP requires that any control plane traffic be capable of being
carried over an out-of-band signaling network or a signaling control
channel such as the one described in <xref target="RFC5718"></xref>.
Note that while T-LDP signaling is traditionally carried in-band in
IP/MPLS networks, this does not preclude its operation over
out-of-band channels. References to T-LDP in this document do not
preclude the definition of alternative PW control protocols for use in
MPLS-TP.</t>
<t>PW control (and maintenance) takes place separately from LSP tunnel
signaling. The main coordination between LSP and PW control will occur
within the nodes that terminate PWs. The control planes for PWs and
LSPs may be used independently, and one may be employed without the
other. This translates into the four possible scenarios: (1) no
control plane is employed; (2) a control plane is used for both LSPs
and PWs; (3) a control plane is used for LSPs, but not PWs; (4) a
control plane is used for PWs, but not LSPs. The PW and LSP control
planes, collectively, need to satisfy the MPLS-TP control plane
requirements reviewed in the MPLS-TP Control Plane Framework <xref
target="I-D.ietf-ccamp-mpls-tp-cp-framework"></xref>. When client
services are provided directly via LSPs, all requirements must be
satisfied by the LSP control plane. When client services are provided
via PWs, the PW and LSP control planes operate in combination and some
functions may be satisfied via the PW control plane while others are
provided to PWs by the LSP control plane.</t>
<t>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 signaled by its own control
protocol.</t>
<t>The distributed MPLS-TP control plane may provide 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-Network Interface (I-NNI), and External Network-Network
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 localisation 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 <xref
target="SURVIVE"></xref>. Examples of the MPLS-TP data plane
connectivity patterns are LSPs utilising 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. In all cases, however, the control plane is logically
decoupled from the data plane such that a control plane failure does
not imply a failure of the existing transport paths.</t>
</section>
<section title="Interdomain Connectivity">
<t>A number of methods exist to support inter-domain operation of
MPLS-TP, including the data plane, OAM and configuration aspects, for
example:</t>
<t><list style="symbols">
<t>Inter-domain TE LSPs <xref target="RFC4726"></xref></t>
<t>Multi-segment Pseudowires <xref target="RFC5659"></xref></t>
<t>LSP stitching <xref target="RFC5150"></xref></t>
<t>back-to-back attachment circuits <xref
target="RFC5659"></xref></t>
</list></t>
<t>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.</t>
</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. 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. Note that the path of an LSP or PW may be
dynamically computed, while the LSP or PW itself is established
through static configuration.</t>
</section>
<section anchor="SURVIVE" title="Survivability">
<t>The survivability architecture for MPLS-TP is 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 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 <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:</t>
<t><list style="symbols">
<t>Two concurrent traffic paths (1+1).</t>
<t>one active and one standby path with guaranteed bandwidth on
both paths (1:1).</t>
<t>one active path and a standby path the resources of which are
shared by one or more other active paths (shared protection).</t>
</list></t>
<t>The applicability of any given scheme to meet specific requirements
is outside the scope of this document.</t>
<t>The characteristics of MPLS-TP resiliency mechanisms are as
follows:<list style="symbols">
<t>Optimised for linear, ring or meshed topologies.</t>
<t>Use OAM mechanisms to detect and localise 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.</t>
<t>MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. 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 behaviour.</t>
</list></t>
</section>
<section anchor="PST" title="Sub-Path Maintenance">
<t>In order to monitor, protect and manage a portion (i.e. segment or
concatenated segment) of an LSP, a hierarchical LSP <xref
target="RFC3031"></xref> can be instantiated. A hierarchical LSP is
instantiated for this purpose is called a Sub-Path Maintenance Element
(SPME). Note that by definition an SPME does not carry user plane
traffic as a direct clident.</t>
<t>An SPME is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. The SPME forms an MPLS-TP
Section <xref target="I-D.ietf-mpls-tp-data-plane"></xref> that
carries the original LSP over this portion of a network as a client.
OAM messages can be initiated at the edge of the SPME and sent to the
peer edge of the SPME or to a MIP along the SPME by setting the TTL
value of the LSE at the corresponding hierarchical LSP level. A P
router only pushes or pops a label if it is at the end of a SPME. In
this mode, it is an LER for the SPME.</t>
<t>For example in <xref target="PST-ic"></xref>, two SPMEs are
configured to allow monitoring, protection and management of the LSP
concatenated segments. One SPME is defined between LER2 and LER3, and
a second SPME is set up between LER4 and LER5. Each of these SPMEs may
be monitored, protected, or managed independently.</t>
<t><figure anchor="PST-ic" title="SPMEs in Inter-Carrier Network">
<artwork><![CDATA[ |<============================= LSP =============================>|
|<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
|LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6|
|====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2)
Note 1: LER2, LER3, LER4 and LER5 are with respect to the SPME
Note 2: The LSP terminates in LERs outside of Carrier 1 and
Carrier 2, for example LER1 and LER6. ]]></artwork>
</figure></t>
<t>The end-to-end traffic of the LSP, including data traffic and
control traffic (OAM, Protection Switching Control, management and
signaling messages) is tunneled within the hierarchical LSP by means
of label stacking as defined in <xref target="RFC3031"></xref>.</t>
<t>The mapping between an LSP and a SPME can be 1:1, in which case it
is similar to the ITU-T Tandem Connection Element <xref
target="G.805"></xref>. The mapping can also be 1:N to allow
aggregated monitoring, protection and management of a set of LSP
segments or concatenated LSP segments. <xref
target="PST-concat"></xref> shows a SPME which is used to aggregate a
set of concatenated LSP segments for the LSP from LERx to LERt and the
LSP from LERa to LERd. 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.</t>
<t>The QoS aspects of a SPME are network specific. <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref> provides further
considerations on the QoS aspects of OAM.</t>
<t><figure anchor="PST-concat"
title="SPME for a Set of Concatenated LSP Segments">
<artwork><![CDATA[|LERx|--|LSRy|-+ +-|LSRz|--|LERt|
| |
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
|LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
]]></artwork>
</figure></t>
<t>SPMEs can be provisioned either statically or using control plane
signaling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a SPME on existing LSPs
in-service without traffic disruption, as described in <xref
target="I-D.ietf-mpls-tp-survive-fwk"></xref>. A SPME can be defined
corresponding to one or more end-to-end LSPs. New end-to-end LSPs
which are tunneled within the SPME can be set up, which may require
coordination across administrative boundaries. Traffic of the existing
LSPs is switched over to the new end-to-end tunneled LSPs. The old
end-to-end LSPs can then be torn down.</t>
<t>Hierarchical label stacking, in a similar manner to that described
above, can be used to implement sub-path maintenance entities on
pseudowires.</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-framework"></xref>
and <xref target="I-D.ietf-mpls-tp-nm-req"></xref>. These derive from
the generic specifications described in ITU-T G.7710/Y.1701 <xref
target="G.7710"></xref> for transport technologies. They also
incorporate 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 expand 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 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 Network Management System (NMS) is used to provision and
manage an end-to-end connection across a network where some segments
are created/managed by, for example, Netconf <xref
target="RFC4741"></xref> or SNMP <xref target="RFC3411"></xref> 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 needs to
support statically provisioning LSPs for an LSR or LER, and PWs for a
PE, as well as any associated MEPs and MIPs, 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 needs to 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 Maintenance Entity Group Endpoint (MEP) ID and
MEG Intermediate Point (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 capable of operating on-demand or
pro-actively.</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. When an MPLS function is included in the MPLS
transport profile, the security considerations pertinent to that
function apply to MPLS-TP. 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.</t>
<t>For pseudowires, the security considerations of <xref
target="RFC3985"></xref> and <xref target="RFC5659"></xref> apply.</t>
<t>MPLS-TP nodes that implement the G-ACh create a Control Channel (CC)
associated with a pseudowire, LSP or section. This control channel can
be signaled or statically configured. Over this control channel, control
channel messages related to network maintenance functions such as OAM,
signaling or network management are sent. Therefore, three different
areas are of concern from a security standpoint.</t>
<t>The first area of concern relates to control plane parameter and
status message attacks, that is, attacks that concern the signaling of
G-ACh capabilities. MPLS-TP Control Plane security is discussed in <xref
target="I-D.ietf-mpls-mpls-and-gmpls-security-framework"></xref>.</t>
<t>A second area of concern centers on data-plane attacks, that is,
attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh
mechanisms are subject to additional data-plane denial-of- service
attacks as follows:</t>
<t><list style="hanging">
<t>An intruder could intercept or inject G-ACh packets effectively
disrupting the protocols carried over the G-ACh.</t>
<t>An intruder could deliberately flood a peer MPLS-TP node with
G-ACh messages to deny services to others.</t>
<t>A misconfigured or misbehaving device could inadvertently flood a
peer MPLS-TP node with G-ACh messages which could result in denial
of services. In particular, if a node has either implicitly or
explicitly indicated that it cannot support one or all of the types
of G-ACh protocol, but is sent those messages in sufficient
quantity, it could result in a denial of service.</t>
</list>To protect against these potential (deliberate or
unintentional) attacks, multiple mitigation techniques can be
employed:</t>
<t><list style="hanging">
<t>G-ACh message throttling mechanisms can be used, especially in
distributed implementations which have a centralized control-plane
processor with various line cards attached by some control-plane
data path. In these architectures, G-ACh messages may be processed
on the central processor after being forwarded there by the
receiving line card. In this case, the path between the line card
and the control processor may become saturated if appropriate G-ACh
traffic throttling is not employed, which could lead to a complete
denial of service to users of the particular line card. Such
filtering is also useful for preventing the processing of unwanted
G-ACh messages, such as those which are sent on unwanted (and
perhaps unadvertised) control channel types.</t>
</list>A third and last area of concern relates to the processing of
the actual contents of G-ACh messages. It is necessary that the
definition of the protocols using these messages carried over a G-ACh
include appropriate security measures.</t>
<t>Additional security considerations apply to each MPLS-TP solution.
These are discussed further in <xref
target="I-D.fang-mpls-tp-security-framework"></xref>.</t>
<t>The security considerations in <xref
target="I-D.ietf-mpls-mpls-and-gmpls-security-framework"></xref>
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>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>Nurit Sprecher</t>
<t>Martin Vigoureux</t>
<t>Yaacov Weingarten</t>
<t>The participants of ITU-T SG15</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?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.4447'?>
<?rfc include='reference.RFC.4872'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.RFC.5586'?>
<?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.RFC.5659'?>
<?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.I-D.ietf-mpls-tp-nm-framework'?>
<?rfc include='reference.I-D.ietf-mpls-tp-data-plane'?>
<?rfc include='reference.I-D.ietf-ccamp-mpls-tp-cp-framework'?>
<?rfc include='reference.RFC.4379'?>
<?rfc include='reference.I-D.ietf-bfd-mpls'?>
<?rfc include='reference.RFC.4364'?>
<?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.RFC.3209'?>
<?rfc include='reference.RFC.5150'?>
<?rfc include='reference.I-D.ietf-l2vpn-vpms-frmwk-requirements'?>
<?rfc include='reference.RFC.4664'?>
<?rfc include='reference.RFC.5254'?>
<?rfc include='reference.RFC.3411'?>
<?rfc include='reference.RFC.4726'?>
<?rfc include='reference.RFC.4741'?>
<?rfc include='reference.I-D.fang-mpls-tp-security-framework'?>
<?rfc include='reference.RFC.5718'?>
<?rfc include='reference.RFC.5309'?>
<?rfc include='reference.RFC.5331'?>
<?rfc include='reference.RFC.3945'?>
<?rfc include='reference.RFC.3443'?>
<?rfc include='reference.I-D.ietf-mpls-tp-identifiers'?>
<?rfc include='reference.I-D.ietf-mpls-mpls-and-gmpls-security-framework'?>
<?rfc include='reference.I-D.ietf-pwe3-vccv-bfd'?>
<?rfc include='reference.RFC.3471'?>
<?rfc include='reference.I-D.ietf-opsawg-mpls-tp-oam-def'?>
<?rfc include='reference.I-D.ietf-mpls-tp-rosetta-stone'?>
<reference anchor="G.8080">
<front>
<title>ITU-T Recommendation G.8080/Y.1304, "Architecture for the
automatically switched optical network (ASON)"</title>
<author>
<organization></organization>
</author>
<date year="2005" />
</front>
</reference>
<reference anchor="X.200">
<front>
<title>ITU-T Recommendation X.200, "Information Technology - Open
Systems Interconnection - Basic reference Model: The Basic
Model"</title>
<author>
<organization></organization>
</author>
<date year="1994" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 04:54:44 |