One document matched: draft-ietf-mpls-tp-framework-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="3"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-ietf-mpls-tp-framework-01"
ipr="trust200902">
<front>
<title abbrev="MPLS TP Framework">A Framework for MPLS in Transport
Networks</title>
<author fullname="Matthew Bocci" initials="M" role="editor"
surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Voyager Place, Shoppenhangers Road</street>
<city>Maidenhead</city>
<region>Berks</region>
<code>SL6 2PJ</code>
<country>United Kingdom</country>
</postal>
<phone>+44-207-254-5874</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>+44-208-824-8828</phone>
<email>stbryant@cisco.com</email>
</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>+33-6-33-86-1916</phone>
<email>lieven.levrau@alcatel-lucent.com</email>
</address>
</author>
<date day="29" month="June" year="2009" />
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<keyword>mpls-tp</keyword>
<keyword>MPLS</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document specifies an archiectectural framework for the
application of MPLS in transport networks. It describes a profile of
MPLS that enables operational models typical in transport networks
networks, while providing additional OAM, survivability and other
maintenance functions not currently supported by MPLS.</t>
</abstract>
<note title="Requirements Language">
<!--Borrowed the following from the tp requirements, as this gives us a nice get-out for being more prescriptive than a normal informative draft-->
<t>Although this document is not a protocol specification, the key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in <xref target="RFC2119">RFC2119</xref> and
are to be interpreted as instructions to the protocol designers
producing solutions that satisfy the architectural concepts set out in
this document..</t>
</note>
</front>
<middle>
<section title="Introduction">
<section title="Motivation and Background">
<!--Updated in line with the requirements draft intro-->
<t>This document describes a framework for a Multiprotocol Label
Switching Transport Profile (MPLS-TP). It presents the architectural
framework for MPLS-TP, definining those elements of MPLS applicable to
supporting the requirements in <xref
target="I-D.ietf-mpls-tp-requirements" /> and what new protocol
elements are required.</t>
<t>Bandwidth demand continues to grow worldwide, stimulated by the
accelerating growth and penetration of new packet based services and
multimedia applications:</t>
<t>
<list style="symbols">
<t>Packet-based services such as Ethernet, Voice over IP (VoIP),
Layer 2 (L2)/Layer 3 (L3) Virtual Private Networks (VPNs), IP
Television (IPTV), Radio Access Network (RAN) backhauling,
etc.,</t>
<t>Applications with various bandwidth and Quality of Service
(QoS) requirements.</t>
</list>
</t>
<t>This growth in demand has resulted in dramatic increases in access
rates that are, in turn, driving dramatic increases in metro and core
network bandwidth requirements.</t>
<t>Over the past two decades, the evolving optical transport
infrastructure (Synchronous Optical Networking (SONET)/Synchronous
Digital Hierarchy (SDH), Optical Transport Network (OTN)) has provided
carriers with a high benchmark for reliability and operational
simplicity. To achieve this, these existing transport technologies
have been designed with specific characteristics :</t>
<t><list style="symbols">
<t>Strictly connection-oriented connectivity, which may be
long-lived and may be provisioned manually or by network
management.</t>
<t>A high level of protection and availability.</t>
<t>Quality of service.</t>
<t>Extended OAM capabilities.</t>
</list>Carriers are looking to evolve such transport networks to
support packet based services and networks, and to take advantage of
the flexibility and cost benefits of packet switching technology.
While MPLS is a maturing packet technology that is already playing an
important role in transport networks and services, not all of MPLS's
capabilities and mechanisms are needed and/or consistent with
transport network operations. There are also transport technology
characteristics that are not currently reflected in MPLS.</t>
<t>The types of packet transport services delivered by transport
networks are very similar to Layer 2 Virtual Private Networks defined
by the IETF.</t>
<t>There are thus two objectives for MPLS-TP:</t>
<t>
<list style="numbers">
<t>To enable MPLS to be deployed in a transport network and
operated in a similar manner to existing transport
technologies.</t>
<t>To enable MPLS to support packet transport services with a
similar degree of predictability to that found in existing
transport networks.</t>
</list>
</t>
<t>In order to achieve these objectives, there is a need to create a
common set of new functions that are applicable to both MPLS networks
in general, and those blonging to the MPLS-TP profile.</t>
<t>MPLS-TP therefore defines a profile of MPLS targeted at transport
applications and networks. This profile specifies the specific MPLS
characteristics and extensions required to meet transport
requirements. An equipment conforming to MPLS-TP MUST support this
profile. An MPLS-TP conformant equipment MAY support additional MPLS
features. A carrier may deploy some of those additional features in
the transport layer of their network if they find them to be
beneficial.</t>
<t>
<!--moved the following be in an 'applicability' section-->
</t>
</section>
<section title="Applicability">
<t><xref target="tp-spectrum" /> illustrates the range of services
that MPLS-TP is intended to address. MPLS-TP is intended to support a
range of layer 1, layer 2 and layer 3 services, and is not limited to
layer 3 services only. Networks implementing MPLS-TP may choose to
only support a subset of these services.</t>
<t>
<figure anchor="tp-spectrum" title="MPLS-TP Applicability">
<artwork><![CDATA[ MPLS-TP Solution exists
over this spectrum
|<-------------------------------->|
cl-ps Multi-Service co-cs & co-ps
(cl-ps & co-ps) (Label is
| | service context)
| | |
|<------------------------------|--------------------------------->|
| | |
L3 Only L1, L2, L3 Services L1, L2 Services
Pt-Pt, Pt-MP, MP-MP Pt-Pt and Pt-MP
]]></artwork>
</figure>
</t>
<t>The diagram above shows the spectrum of services that can be
supported by MPLS. MPLS-TP solutions are primarily intended for packet
transport applications. These can be deployed using a profile of MPLS
that is strictly connection oriented and does not rely on IP
forwarding or routing (shown on the right hand side of the figure), or
in conjunction with an MPLS network that does use IP forwarding and
that supports a broader range of IP services. This is the
multi-service solution in the centre of the figure.<!--move this section after terminology--></t>
</section>
<section title="Scope">
<t>This document describes a framework for a Tranport Profile of
Multiprotocol Label Switching (MPLS-TP). It presents the architectural
framework for MPLS-TP, definining those elements of MPLS applicable to
supporting the requirements in <xref
target="I-D.ietf-mpls-tp-requirements" /> and what new protocol
elements are required.</t>
<t>This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried over
a PW, is outside the scope of this document. This does not preclude
the use of LSPs conforming to the MPLS transport profile from being
used to carry IP or other MPLS LSPs by general purpose MPLS
networks.</t>
</section>
<section title="Terminology">
<texttable align="left" style="headers">
<ttcol>Term</ttcol>
<ttcol>Definition</ttcol>
<c>LSP</c>
<c>Label Switched Path</c>
<c>MPLS-TP</c>
<c>MPLS Transport profile</c>
<c>SDH</c>
<c>Synchronous Digital Hierarchy</c>
<c>ATM</c>
<c>Asynchronous Transfer Mode</c>
<c>OTN</c>
<c>Optical Transport Network</c>
<c>cl-ps</c>
<c>Connectionless - Packet Switched</c>
<c>co-cs</c>
<c>Connection Oriented - Circuit Switched</c>
<c>co-ps</c>
<c>Connection Oriented - Packet Switched</c>
<c>OAM</c>
<c>Operations, Adminitration and Maintenance</c>
<c>G-ACh</c>
<c>Generic Associated Channel</c>
<c>GAL</c>
<c>Generic Alert Label</c>
<c>MEP</c>
<c>Maintenance End Point</c>
<c>MIP</c>
<c>Maintenance Intermediate Point</c>
<c>APS</c>
<c>Automatic Protection Switching</c>
<c>SCC</c>
<c>Signaling Communication Channel</c>
<c>MCC</c>
<c>Management Communication Channel</c>
<c>EMF</c>
<c>Equipment Management Function</c>
<c>FM</c>
<c>Fault Management</c>
<c>CM</c>
<c>Configuration Management</c>
<c>PM</c>
<c>Performance Management</c>
</texttable>
</section>
<t />
<t>Detailed definitions and additional terminology may be found in <xref
target="I-D.ietf-mpls-tp-requirements" />.</t>
</section>
<section title="Introduction to Requirements">
<t>The requirements for MPLS-TP are specified in <xref
target="I-D.ietf-mpls-tp-requirements"></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 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. Any new mechanisms and
capabilities added to support transport networks and packet transport
services must be able to interoperate with existing MPLS and pseudowire
control and forwarding planes.</t>
<t>Point to point LSPs MAY be unidirectional or bi-directional, and it
MUST be possible to construct congruent Bi-directional LSPs. Point to
multipoint LSPs are unidirectional.</t>
<t>MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
MUST be possible to detect if a merged LSP has been created.</t>
<t>It MUST be possible to forward packets solely based on switching the
MPLS or PW label. It MUST also be possible to establish and maintain
LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there MUST be no
dependency on dynamic routing or signaling.</t>
<t>OAM, protection and forwarding of data packets MUST be able to
operate without IP forwarding support.</t>
<t>It MUST be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate path
recovery actions at either the PW or LSP layers.</t>
</section>
<section title="Transport Profile Overview ">
<t></t>
<section title="Packet Transport Services">
<t>The types of packet transport services provided by existing
transport networks are similar to MPLS Layer 2 VPNs. A key
characteristic of packet transport services is that the network used
to provide the service does not participate in the any IP routing
protocols present in the client, or use the IP addresses in client
packets to forward those packets. The network is therefore transparent
to IP in the client service.</t>
<t>MPLS-TP MUST use one of the Layer 2 VPN services defined in [PPVPN
architecture] to provide a packet transport service.</t>
<t>MPLS-TP LSPs MAY also be used to transport traffic for which the
immediate client of the MPLS-TP LSP is not a Layer 2 VPN. However, for
the purposes of this document, we do not refer to these traffic types
as belonging to a packet transport service. Such clients include IP
and MPLS LSPs.</t>
</section>
<section anchor="arch" title="Architecture">
<t>The architecture for a transport profile of MPLS (MPLS-TP) is based
on the MPLS <xref target="RFC3031"></xref>, pseudowire <xref
target="RFC3985"></xref>, and multi-segment pseudowire <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref> architectures, as
illustrated in <xref target="tp-arch"></xref>.</t>
<figure anchor="tp-arch"
title="MPLS-TP Architecture (Single Segment PW)">
<artwork><![CDATA[ |<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudo Wire ------>| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
]]></artwork>
</figure>
<figure title="MPLS-TP Architecture (Multi-Segment PW)">
<artwork><![CDATA[ Native |<------------Pseudowire-------------->| Native
Service | PSN PSN | Service
(AC) | |<--cloud->| |<-cloud-->| | (AC)
| V V V V V V |
| +----+ +-----+ +----+ |
+----+ | |TPE1|===========|SPE1 |==========|TPE2| | +----+
| |------|..... PW.Seg't1.........PW.Seg't3.....|-------| |
| CE1| | | | | | | | | |CE2 |
| |------|..... PW.Seg't2.........PW.Seg't4.....|-------| |
+----+ | | |===========| |==========| | | +----+
^ +----+ ^ +-----+ ^ +----+ ^
| | | |
| TE LSP TE LSP |
| |
| |
|<---------------- Emulated Service ----------------->|
]]></artwork>
</figure>
<t></t>
<t>The above figures illustrates the MPLS-TP architecture used to
provide a point-to-point packet transport service, or VPWS. In this
case, the MPLS-TP forwarding plane is a profile of the MPLS LSP and
SS-PW or MS-PW forwarding architecture as detailed in section <xref
target="FWD"></xref>.</t>
<t>This document describes the architecture for MPLS-TP when the LSP
client is a PW. The transport of IP and MPLS, other than carried over
a PW, is outside the scope of this document. This does not preclude
the use of LSPs conforming to the MPLS transport profile from being
used to carry IP or other MPLS LSPs by general purpose MPLS networks.
LSP hierarchy MAY be used within the MPLS-TP network, so that more
than one LSP label MAY appear in the label stack.</t>
<t><figure anchor="MPLS-TP-Defn"
title="Domain of MPLS-TP Layer Network using Pseudowires">
<artwork><![CDATA[ +---------------------------+
| PW Native service |
/===========================\
H PW Encapsulation H \ <---- PW Control word
H---------------------------H \ <---- Normalised client
H PW OAM H MPLS-TP channel
H---------------------------H /
H PW Demux (S=1) H /
H---------------------------H \
H LSP OAM H \
H---------------------------H / MPLS-TP Path(s)
H LSP Demultiplexer(s) H /
\===========================/
| Server |
+---------------------------+
]]></artwork>
</figure><xref target="MPLS-TP-Defn">Figure</xref> illustrates the
protocol stack to be used when pseudowires are carried over MPLS-TP
LSPs.</t>
<t>When providing a VPWS, VPLS, VPMS or IPLS, pseudowires MUST be used
to carry a client service. For compatibility with transport
nomenclature, the PW may be referred to as the MPLS-TP Channel and the
LSP may be referred to as the MPLS-TP Path.</t>
<t>Note that in MPLS-TP environments where IP is used for control or
OAM purposes, IP MAY be carried over the LSP demultiplexers as per
RFC3031 <xref target="RFC3031"></xref>, or directly over the
server.</t>
<t>PW OAM, PSN OAM and PW client data are mutually exclusive and never
exist in the same packet.</t>
<t>The MPLS-TP definition applies to the following two domains:</t>
<t><list style="symbols">
<t>MPLS-TP Forwarding Domain</t>
<t>MPLS-TP Transport Domain</t>
</list></t>
</section>
<section anchor="FWD" title="MPLS-TP Forwarding Domain" toc="default">
<t>A set of client-to-MPLS-TP adaptation functions interface the
client to MPLS-TP. For pseudowires, this adaptation function is the PW
forwarder shown in Figure 4a of <xref target="RFC3985"></xref>. The PW
label is used for forwarding in this case and is always at the bottom
of the label stack. The operation of the MPLS-TP network is
independent of the payload carried by the MPLS-TP PW packet.</t>
<t>MPLS-TP is itself a client of an underlying server layer. MPLS-TP
is thus bounded by a set of adaptation functions to this server layer
network. These adaptation functions provide encapsulation of the
MPLS-TP frames and for the transparent transport of those frames over
the server layer network. The MPLS-TP client inherits its QoS from the
MPLS-TP network, which in turn inherits its QoS from the server layer.
The server layer must therefore provide the neccesary Quality of
Service (QoS) to ensure that the MPLS-TP client QoS commitments are
satisfied.</t>
<t>MPLS-TP LSPs use the MPLS label switching operations defined in
<xref target="RFC3031"></xref>. These operations are highly optimized
for performance and are not modified by the MPLS-TP profile.</t>
<t>During forwarding a label is pushed to associate a forwarding
equivalence class (FEC) with the LSP or PW. This specifies the
processing operaton 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, in which case the packet may be inspected and either discarded
or subjected to further processing within the LSR. TTL expiry causes
an exception which forces a packet to be further inspected and
processed. While this occurs, the forwarding of succeeding packets
continues without interruption. Therefore, the only way to cause a P
(intermediate) LSR to inspect a packet (for example for OAM purposes)
is to set the TTL to expire at that LSR.</t>
<t>MPLS-TP PWs support the PW and MS-PW forwarding operations defined
in<xref target="RFC3985"></xref> and <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref>.</t>
<t>The Traffic Class field (formerly the MPLS EXP field) follows the
definition and processing rules of <xref target="RFC5462"></xref> and
<xref target="RFC3270"></xref>. Only the pipe and short-pipe models
are supported in MPLS-TP.</t>
<t>The MPLS encapsulation format is as defined in RFC 3032<xref
target="RFC3032"></xref>. Per-platform label space is used for PWs.
Either per-platform or per-interface label space may be used for
LSPs.</t>
<t>Point to point MPLS-TP LSPs can be either unidirectional or
bidirectional. Point-to-multipoint MPLS-TP LSPs are unidirectional.
Point-to-multipont PWs are currently being defined in the IETF and may
be incorporated in MPLS-TP if required.</t>
<t>It MUST be possible to configure an MPLS-TP LSP such that the
forward and backward directions of a bidirectional MPLS-TP LSP are
co-routed i.e. they follow the same path. The pairing relationship
between the forward and the backward directions must be known at each
LSR or LER on a bidirectional LSP.</t>
<t>Per-packet equal cost multi-path (ECMP) load balancing is not
applicable to MPLS-TP LSPs.</t>
<t>Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by
default.</t>
<t>Both E-LSP and L-LSP are supported in MPLS-TP, as defined in RFC
3270 <xref target="RFC3270"></xref></t>
</section>
<section title="MPLS-TP Transport Domain">
<t>This document specifies the architecture when the client of the
MPLS-TP LSP is a PW. Note, however, that in MPLS-TP environments where
IP is used for control or OAM purposes, IP MAY be carried over the the
LSPs or directly over the server, as described in <xref
target="arch"></xref>. In this case, the MPLS-TP transport domain
consists of the PW encapsulation mechanisms, including the PW control
word.</t>
</section>
<section anchor="addr" title="Addressing">
<t>Editor's note: This section will be updated after publication of
the MPLS-TP Addressing Architecture draft.</t>
<t>MPLS-TP distinguishes between adressing used to identify nodes in
the network, and identifiers used for demultiplexing and forwarding.
This distinction is illustrated in <xref
target="tp-addresses"></xref>.<figure anchor="tp-addresses"
title="Addressing in MPLS-TP">
<artwork><![CDATA[ NMS Control/Signalling
..... .....
[Address]| | [Address]
| |
+-----+---------+------+
Address = Node | | | |
ID in forwarding plane | V V |
| |
| MEP or MIP |
| dmux |
| svcid |
| src |
+--^-------------------+
|
OAM: OAM |
dmux= [GAL/GACH]...........
or ________________________________________
IP (________________________________________)
svc context=ID/FEC PWE=ID1
SRC=IP .
.
IDx]]></artwork>
</figure></t>
<t>Editor's note: The figure above arose from discussions in the
MPLS-TP design team. It will be clarified in a future verson of this
draft.</t>
<t>IPv4 or IPv6 addresses are used to identify MPLS-TP nodes by
default for network management and signaling purposes.</t>
<t>In the forwarding plane, identfiers are required for the service
context (provided by the FEC), and for OAM. OAM requires both a
demultiplexer and an address for the source of the OAM packet.</t>
<t>For MPLS in general where IP addressing is used, IPv4 or IPv6 is
used by default. However, MPLS-TP must be able to operate in
environments where IP is not used in the forwarding plane. Therefore,
the default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs
is the generic associated channel. Forwarding based on IP addresses
for user or OAM packets is NOT REQUIRED for MPLS-TP.</t>
<t>RFC 4379 <xref target="RFC4379"></xref>and BFD for MPLS LSPs <xref
target="I-D.ietf-bfd-mpls"></xref> have defined alert mechanisms that
enable a MPLS LSR to identify and process MPLS OAM packets when the
OAM packets are encapsulated in an IP header. These alert mechanisms
are based on TTL expiration and/or use an IP destination address in
the range 127/8. These mechanisms are the default mechanisms for MPLS
networks in general for identifying MPLS OAM packets when the OAM
packets are encapsulated in an IP header. MPLS-TP must not rely on
these mechanisms, and thus relies on the GACH/GAL to demultiplex OAM
packets.</t>
</section>
<section anchor="OAM"
title="Operations, Administration and Maintenance (OAM)">
<t>MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those provided
in SONET/SDH.</t>
<t>MPLS-TP defines mechanisms to differentiate specific packets (e.g.
OAM, APS, MCC or SCC) from those carrying user data packets on the
same LSP. These mechanisms are described in RFC5586 <xref
target="RFC5586"></xref>.</t>
<t>MPLS-TP requires <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref> that a set of OAM
capabilities is available to perform fault management (e.g. fault
detection and localization) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>.</t>
<t>OAM and monitoring in MPLS-TP is based on the concept of
maintenance entities, as described in <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>. A Maintenance Entity
can be viewed as the association of two (or more) Maintenance End
Points (MEPs) (see example in <xref target="tp-oam-ex"></xref> ). The
MEPs that form an ME should be configured and managed to limit the OAM
responsibilities of an OAM flow within a network or sub- network, or a
transport path or segment, in the specific layer network that is being
monitored and managed.</t>
<!--The above sentence does not parse. Need to check with Italo.-->
<t>Each OAM flow is associated with a single ME. Each MEP within an ME
resides at the boundaries of that ME. An ME may also include a set of
zero or more Maintenance Intermediate Points (MIPs), which reside
within the Maintenance Entity. Maintenance end points (MEPs) are
capable of sourcing and sinking OAM flows, while maintenance
intermediate points (MIPs) can only sink or respond to OAM flows.</t>
<t><figure anchor="tp-oam-ex" title="Example of MPLS-TP OAM "
width="72">
<artwork><![CDATA[
========================== End to End LSP OAM ============================
..... ..... ..... .....
-----|MIP|---------------------|MIP|---------|MIP|------------|MIP|-----
''''' ''''' ''''' '''''
|<-------- Carrier 1 --------->| |<--- Carrier 2 ----->|
---- --- --- ---- ---- --- ----
NNI | | | | | | | | NNI | | | | | | NNI
-----| PE |---| P |---| P |----| PE |--------| PE |---| P |---| PE |-----
| | | | | | | | | | | | | |
---- --- --- ---- ---- --- ----
==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM ===
(Carrier 1) LSP OAM (Carrier 2)
(inter-carrier)
..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
''''' ''''' ''''' '''''''''' '''''''''' ''''' '''''
<------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope of this figure.
]]></artwork>
</figure></t>
<t><xref target="oam-arch"></xref> illustrates how the concept of
Maintenance Entities can be mapped to sections, LSPs and PWs in an
MPLS-TP network that uses MS-PWs.</t>
<t><figure anchor="oam-arch" title="MPLS-TP OAM archtecture">
<artwork><![CDATA[ Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | |
|CE1|--------|........PW1........|...PW3...|........PW5........|-----|CE2|
| | | |=========| |=========| |=========| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+
|<- Subnetwork 123->| |<- Subnetwork XYZ->|
.------------------- PW15 PME -------------------.
.---- PW1 PTCME ----. .---- PW5 PTCME ---.
.---------. .---------.
PSN13 LME PSNXZ LME
.--. .--. .--------. .--. .--.
Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity
LME: LSP Maintenance Entity
PME: PW Maintenance Entity
]]></artwork>
</figure></t>
<t>The following MPLS-TP MEs are specified in <xref
target="I-D.ietf-mpls-tp-oam-framework"></xref>:</t>
<t><list style="symbols">
<t>A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs).</t>
<t>A LSP Maintenance Entity (LME), allowing monitoring and
management of an end-to-end LSP (between LERs).</t>
<t>A PW Maintenance Entity (PME), allowing monitoring and
management of an end-to-end SS/MS-PWs (between T-PEs).</t>
<t>An LSP Tandem Connection Maintenance Entity (LTCME), allowing
monitoring and management of an LSP Tandem Connection (or LSP
Segment) between any LER/LSR along the LSP. o A MS-PW Tandem
Connection Maintenance Entity (PTCME), allows monitoring and
management of a SS/MS-PW Tandem Connection (or PW Segment) between
any T-PE/S-PE along the (MS-)PW. Note that the term Tandem
Connection Monitoring has historical significance dating back to
the early days of the telephone network, but is equally applicable
to the two-level hierarchal architectures commonly employed in
todays packet networks.</t>
</list></t>
<t>Individual MIPs along the path of an LSP or PW are addressed by
setting the appropriate TTL in the label for the OAM packet, as per
<xref target="I-D.ietf-pwe3-segmented-pw"></xref>. Note that this
works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be cases where this is not the case in general MPLS
networks e.g. following restoration using a facility bypass LSP.</t>
<t>MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel
mechanism <xref target="RFC5586"></xref>. This uses a combination of
an Associated Channel Header (ACH) and a Generic Alert Label (GAL) to
create a control channel associated to an LSP, Section or PW.</t>
<t>The MPLS-TP OAM architecture support a wide range of OAM functions,
including the following <list style="symbols">
<t>Continuity Check</t>
<t>Connectivity Verification</t>
<t>Performance monitoring (e.g. loss and delay)</t>
<t>Alarm suppression</t>
<t>Remote Integrity</t>
</list></t>
<t>These are applicable to any layer defined within MPLS- TP, i.e.
MPLS Section, LSP and PW.</t>
<t>The MPLS-TP OAM toolset needs to be able to operate without relying
on a dynamic control plane or IP functionality in the datapath. In the
case of MPLS-TP deployment with IP functionality, all existing IP-MPLS
OAM functions, e.g. LSP-Ping, BFD and VCCV, may be used. This does not
preculde the use of other OAM tools in an IP addressable network.</t>
<t>One use of OAM mechanisms is to detect link failures, node failures
and performance outside the required specification which then may be
used to trigger recovery actions, according to the requirements of the
service.</t>
</section>
<section anchor="GENERICACH" title="Generic Associated Channel (G-ACh)">
<t>For correct operation of the OAM it is important that the OAM
packets fate share with the data packets. In addition in MPSL-TP it is
necessary to discriminate between user data payloads and other types
of payload. For example the packet may contain a Signaling
Communication Channel (SCC), or a channel used for Automatic Protecton
Switching (APS) data. Such packetets are carried on a control channel
associated to the LSP, Section or PW. This is achieved by carrying
such packets on a generic control channel associated to the LSP, PW or
section.</t>
<t>MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC or
other packet types in band over LSPs or PWs. The G-ACH is defined in
<xref target="RFC5586"></xref>and it is similar to the Pseudowire
Associated Channel <xref target="RFC4385"></xref>, which is used to
carry OAM packets across pseudowires. The G-ACH is indicated by a
generic associated channel header (ACH), similar to the Pseudowire
VCCV control word, and this is present for all Sections, LSPs and PWs
making use of FCAPS functions supported by the G-ACH.</t>
<t>For pseudowires, the G-ACh use the first nibble of the pseudowire
control word to provide the initial discrimination between data
packets a packets belonging to the associated channel, as described
in<xref target="RFC4385"></xref>. When the first nibble of a packet,
immediately following the label at the bottom of stack, has a value of
one, then this packet belongs to a G-ACh. The first 32 bits following
the bottom of stack label then have a defined format called an
associated channel header (ACH), which further defines the content of
the packet. The ACH is therefore both a demultiplexer for G-ACh
traffic on the PW, and a discriminator for the type of G-ACh
traffic.</t>
<t>When the OAM, or a similar message is carried over an LSP, rather
than over a pseudowire, it is necessary to provide an indication in
the packet that the payload is something other than a user data
packet. This is acheived by including a reserved label with a value of
13 in the label stack. This reserved label is referred to as the
'Generic Alert Label (GAL)', and is defined in <xref
target="RFC5586"></xref>. When a GAL is found anywhere within the
label stack it indicates that the payload begins with an ACH. The GAL
is thus a demultiplexer for G-ACh traffic on the LSP, and the ACH is a
discriminator for the type of traffic carried on the G-ACh. Note
however that MPLS-TP forwarding follows the normal MPLS model, and
that a GAL is invisible to an LSR unless it is the top label iin the
label stack. The only other circumstance under which the label stack
may be inspected for a GAL is when the TTL has expired. Any MPLS-TP
component that intentionally performs this inspection must assume that
it is asynchronous with respect to the forwarding of other packets.
All operations on the label stack arein accordance with <xref
target="RFC3031"></xref> and <xref target="RFC3032"></xref>.</t>
<t>In MPLS-TP, the 'Generic Alert Label (GAL)' always appears at the
bottom of the label stack (i.e. S bit set to 1), however this does not
preclude its use elsewhere in the label stack in other
applications.</t>
<t>The G-ACH MUST only be used for channels that are an adjunct to the
data service. Examples of these are OAM, APS, MCC and SCC, but the use
is not resticted to those names services. The G-ACH MUST NOT be used
to carry additional data for use in the forwarding path, i.e. it MUST
NOT be used as an alternative to a PW control word, or to define a PW
type.</t>
<t>Since the G-ACh traffic is indistinguishable from the user data
traffic at the server layer, bandwidth and QoS commitments apply to
the gross traffic on the LSP, PW or section. Protocols using the G-ACh
must therefore take into consideration the impact they have on the
user data that they are sharing resources with. In addition, protocols
using the G-ACh MUST conform to the security and congestion
considerations described in <xref target="RFC5586"></xref>. .</t>
<t><xref target="PWE3-stack"></xref> shows the reference model
depicting how the control channel is associated with the pseudowire
protocol stack. This is based on the reference model for VCCV shown in
Figure 2 of <xref target="RFC5085"></xref>.</t>
<t><figure anchor="PWE3-stack"
title="PWE3 Protocol Stack Reference Model including the G-ACh "
width="72">
<artwork><![CDATA[
+-------------+ +-------------+
| Payload | < Service / FCAPS > | Payload |
+-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / |
|Discriminator| |Discriminator|
+-------------+ +-------------+
| PW | < PW > | PW |
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
]]></artwork>
</figure></t>
<t>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>
<figure anchor="MPLS-PS-inc-LSP-ACH"
title="MPLS Protocol Stack Reference Model including the LSP Associated Control Channel ">
<artwork><![CDATA[
+-------------+ +-------------+
| Payload | < Service > | Payload |
+-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+
| PSN | < LSP > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS/MPLS-TP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
</section>
<section anchor="CONTROLPLANE" title="Control Plane">
<t>MPLS-TP should be capable of being operated with centralized
Network Management Systems (NMS). The NMS may be supported by a
distributed control plane, but MPLS-TP can operated in the absense of
such a control plane. A distributed control plane may be used to
enable dynamic service provisioning in multi-vendor and multi-domain
environments using standardized protocols that guarantee
interoperability. Where the requirements specified in <xref
target="I-D.ietf-mpls-tp-requirements"></xref> can be met, the MPLS
transport profile uses existing control plane protocols for LSPs and
PWs.</t>
<t><xref target="cp-arch"></xref> illustrates the relationshop 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|<->|Forwarding|<---->|Forwarding|<----->|Forwarding|<->|Edge|-+--
/: +----+ | | : : | | : : | | +----+ :\
: +----------+ : : +----------+ : : +----------+ :
''''''''''''''''''''''''' ''''''''''''''''' ''''''''''''''''''''''''
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.
]]></artwork>
</figure></t>
<t>The MPLS-TP control plane is based on a combination of the
LDP-based control plane for pseudowires <xref target="RFC4447"></xref>
and the RSVP-TE based control plane for MPLS-TP LSPs <xref
target="RFC3471"></xref>. Some of the RSVP-TE functions that are
required for LSP signaling for MPLS-TP are based on GMPLS.</t>
<t>The distributed MPLS-TP control plane provides the following
functions:</t>
<t><list style="symbols">
<t>Signaling</t>
<t>Routing</t>
<t>Traffic engineering and constraint-based path computation</t>
</list></t>
<t>In a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the
domains. These include the User-Network Interface (UNI), Internal
Network Node Interface (I-NNI), and External Network Node Interface
(E-NNI). Note that different policies may be defined that control the
information exchanged across these interface types.</t>
<t>The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document <xref
target="OAM"></xref> e.g. for fault detection and localization in the
event of a failure in order to efficiently restore failed transport
paths.</t>
<t>The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport paths
including protected paths as described in the survivability section
<xref target="SURVIVE"></xref> of this document. Examples of the
MPLS-TP data plane connectivity patterns are LSPs utilizing the fast
reroute backup methods as defined in <xref target="RFC4090"></xref>
and ingress-to-egress 1+1 or 1:1 protected LSPs.</t>
<t>The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures and
degredations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data plane
may be achieved.</t>
<section title="PW Control Plane">
<t>An MPLS-TP network provides many of its transport services using
single-segment or multi-segment pseudowires, in compliance with the
PWE3 architecture (<xref target="RFC3985"></xref> and <xref
target="I-D.ietf-pwe3-ms-pw-arch"></xref> ). The setup and
maintenance of single-segment or multi- segment pseudowires uses the
Label Distribution Protocol (LDP) as per <xref
target="RFC4447"></xref> and extensions for MS-PWs <xref
target="I-D.ietf-pwe3-segmented-pw"></xref> and <xref
target="I-D.ietf-pwe3-dynamic-ms-pw"></xref>.</t>
</section>
<section title=" LSP Control Plane">
<t>MPLS-TP provider edge nodes aggregate multiple pseudowires and
carry them across the MPLS-TP network through MPLS-TP tunnels
(MPLS-TP LSPs). Applicable functions from the Generalized MPLS
(GMPLS) protocol suite supporting packet-switched capable (PSC)
technologies are used as the control plane for MPLS-TP transport
paths (LSPs).</t>
<t>The LSP control plane includes:<list style="symbols">
<t>RSVP-TE for signalling</t>
<t>OSPF-TE or ISIS-TE for routing</t>
</list>RSVP-TE signaling in support of GMPLS, as defined in <xref
target="RFC4872"></xref>, is used for the setup, modification, and
release of MPLS-TP transport paths and protection paths. It supports
unidirectional, bi-directional and multicast types of LSPs. The
route of a transport path is typically calculated in the ingress
node of a domain and the RSVP explicit route object (ERO) is
utilized for the setup of the transport path exactly following the
given route. GMPLS based MPLS-TP LSPs must be able to interoperate
with RSVP-TE based MPLS-TE LSPs, as per <xref
target="RFC5146"></xref></t>
<t>OSPF-TE routing in support of GMPLS as defined in <xref
target="RFC4203"></xref> is used for carrying link state information
in a MPLS-TP network. ISIS-TE routing in support of GMPLS as defined
in <xref target="RFC5307"></xref> is used for carrying link state
information in a MPLS-TP network.</t>
</section>
</section>
<section anchor="static" title="Static Operation of LSPs and PWs ">
<t>A PW or LSP may be statically configured without the support of a
dynamic control plane. This may be either by direct configuration of
the PEs/LSRs, or via a network management system. The colateral damage
that loops can cause during the time taken to detect the failure may
be severe. When static configuration mechanisms are used, care must be
taken to ensure that loops to not form.</t>
</section>
<section anchor="SURVIVE" title="Survivability">
<t>Survivability requirements for MPLS-TP are specified in <xref
target="I-D.ietf-mpls-tp-survive-fwk"></xref>.</t>
<t>A wide variety of resiliency schemes have been developed to meet
the various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels (<xref target="RFC4090"></xref>),
while pseudowire redundancy <xref
target="I-D.ietf-pwe3-redundancy"></xref> supports scenarios where the
protection for the PW can not be fully provided by the PSN layer (i.e.
where the backup PW terminates on a different target PE node than the
working PW). Additionally, GMPLS provides a well known set of control
plane driven protection and restoration mechanisms <xref
target="RFC4872"></xref>. MPLS-TP provides additional protection
mechansisms that are optimised for both linear topologies and ring
topologies, and that operate in the absense of a dynamic control
plane. These are specified in <xref
target="I-D.ietf-mpls-tp-survive-fwk"></xref>.</t>
<t>Different protection schemes apply to different deployment
topologies and operational considerations. Such protection schemes may
provide different levels of resiliency. For example, two concurrent
traffic paths (1+1), one active and one standby path with guaranteed
bandwidth on both paths (1:1) or one active path and a standby path
that is shared by one or more other active paths (shared protection).
The applicability of any given scheme to meet specific requirements is
outside the current scope of this document.</t>
<t>The characteristics of MPLS-TP resiliency mechanisms are listed
below.<list style="symbols">
<t>Optimised for linear, ring or meshed topologies.</t>
<t>Use OAM mechanisms to detect and localize network faults or
service degenerations.</t>
<t>Include protection mechanisms to coordinate and trigger
protection switching actions in the absense of a dynamic control
plane. This is known as an Automatic Protection Switching (APS)
mechanism.</t>
<t>MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e. MPLS section, LSP and PW), providing segment
and end-to- end recovery.</t>
<t>MPLS-TP recovery mechanisms support the coordination of
protection switching at multiple levels to prevent race conditions
occuring between a client and its server layer.</t>
<t>MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based.</t>
<t>MPLS-TP supports revertive and non-revertive behavior.</t>
</list></t>
</section>
<section anchor="NETMGT" title="Network Management">
<t>The network management architecture and requirements for MPLS-TP
are specified in <xref target="I-D.ietf-mpls-tp-nm-req"></xref>. It
derives from the generic specifications described in ITU-T
G.7710/Y.1701 <xref target="G.7710"></xref> for transport
technologies. It also incorporates the OAM requirements for MPLS
Networks <xref target="RFC4377"></xref> and MPLS-TP Networks <xref
target="I-D.ietf-mpls-tp-oam-requirements"></xref> and expands on
those requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.</t>
<t>The Equipment Management Function (EMF) of a MPLS-TP Network
Element (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means
through which a management system manages the NE. The Management
Communication Channel (MCC), realized by the G-ACh, provides a logical
operations channel between NEs for transferring Management
information. For the management interface from a management system to
a MPLS-TP NE, there is no restriction on which management protocol
should be used. It is used to provision and manage an end-to-end
connection across a network where some segments are create/managed,
for examples by Netconf or SNMP and other segments by XML or CORBA
interfaces. Maintenance operations are run on a connection (LSP or PW)
in a manner that is independent of the provisioning mechanism. An
MPLS-TP NE is not required to offer more than one standard management
interface. In MPLS-TP, the EMF must be capable of statically
provisioning LSPs for an LSR or LER, and PWs for a PE, as per <xref
target="static"></xref>.</t>
<t>Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission
(such as continuity, connectivity, etc.), software processing,
hardware, and environment. Alarm handling includes alarm severity
assignment, alarm suppression/aggregation/correlation, alarm reporting
control, and alarm reporting.</t>
<t>Configuration Management (CM) provides functions to control,
identify, collect data from, and provide data to MPLS-TP NEs. In
addition to general configuration for hardware, software protection
switching, alarm reporting control, and date/time setting, the EMF of
the MPLS-TP NE also supports the configuration of maintenance entity
identifiers (such as MEP ID and MIP ID). The EMF also supports the
configuration of OAM parameters as a part of connectivity management
to meet specific operational requirements. These may specify whether
the operational mode is one-time on-demand or is periodic at a
specified frequency.</t>
<t>The Performance Management (PM) functions within the EMF of an
MPLS- TP NE support the evaluation and reporting of the behaviour of
the NEs and the network. One particular requirement for PM is to
provide coherent and consistent interpretation of the network
behaviour in a hybrid network that uses multiple transport
technologies. Packet loss measurement and delay measurements may be
collected and used to detect performance degradation. This is reported
via fault management to enable corrective actions to be taken (e.g.
protection switching), and via performance monitoring for Service
Level Agreement (SLA) verification and billing. Collection mechanisms
for performance data should be should be capable of operating
on-demand or proactively.</t>
</section>
</section>
<section title="Security Considerations">
<t>The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS and PWE3 apply to those
transport networks. Furthermore, when general MPLS networks that utilise
functionality outside of the strict MPLS-TP profile are used to support
packet transport services, the security considerations of that
additional functionality also apply.</t>
<t>The security considerations of <xref target="RFC3985"></xref> and
<xref target="I-D.ietf-pwe3-ms-pw-arch"></xref> apply.</t>
<t>Each MPLS-TP solution must specify the addtional security
considerations that apply.</t>
</section>
<section title="IANA Considerations">
<t>IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that
functionality.</t>
<t>This document introduces no additional IANA considerations in
itself.</t>
</section>
<section title="Acknowledgements">
<t>The editors wish to thank the following for their contribution to
this document: <list style="symbols">
<t>Dieter Beller</t>
<t>Italo Busi</t>
<t>Hing-Kam Lam</t>
<t>Marc Lasserre</t>
<t>Vincenzo Sestito</t>
<t>Martin Vigoureux</t>
<t>Malcolm Betts</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3031'?>
<?rfc include='reference.RFC.3032'?>
<?rfc include='reference.RFC.3270'?>
<?rfc include='reference.RFC.3985'?>
<?rfc include='reference.RFC.4385'?>
<?rfc include='reference.RFC.4090'?>
<?rfc include='reference.RFC.4201'?>
<?rfc include='reference.RFC.4203'?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.RFC.4872'?>
<?rfc include='reference.I-D.ietf-pwe3-redundancy'?>
<?rfc include='reference.RFC.5085'?>
<?rfc include='reference.I-D.ietf-pwe3-ms-pw-arch'?>
<?rfc include='reference.RFC.5586'?>
<?rfc include='reference.RFC.5462'?>
<?rfc include='reference.RFC.3471'?>
<?rfc include='reference.RFC.5307'?>
<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>
<?rfc include='reference.I-D.ietf-mpls-cosfield-def'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.4377'?>
<?rfc include='reference.I-D.ietf-mpls-tp-requirements'?>
<?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.bryant-filsfils-fat-pw'?>
<?rfc include='reference.RFC.4379'?>
<?rfc include='reference.I-D.ietf-bfd-mpls'?>
<?rfc include='reference.RFC.5146'?>
<?rfc include='reference.I-D.ietf-mpls-tp-survive-fwk'?>
<?rfc include='reference.I-D.ietf-mpls-tp-oam-framework'?>
<?rfc include='reference.I-D.ietf-pwe3-dynamic-ms-pw'?>
<?rfc include='reference.I-D.ietf-pwe3-segmented-pw'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 13:57:56 |