3.7. Operations, Administration, and Maintenance (OAM)
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.
The MPLS-TP OAM tool-set is able to operate without relying on a
dynamic control plane or IP functionality in the data path. 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 (Section 3.6). Forwarding based on IP
addresses for OAM or user data packets is not required for MPLS-TP.
[RFC4379] and BFD for MPLS LSPs [RFC5884] 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 [RFC4379]. 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 [RFC5586] 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
MPLS-TP supports a comprehensive set of OAM capabilities for packet
transport applications, with equivalent capabilities to those
provided in SONET/SDH.
MPLS-TP requires [RFC5860] 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 [OAM-FRAMEWORK].
MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel
mechanism [RFC5586]. 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.
OAM and monitoring in MPLS-TP is based on the concept of maintenance
entities, as described in [OAM-FRAMEWORK]. 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.
A MEG may also include a set of Maintenance Entity Group Intermediate
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
[RFC4379] and the vccv-trace mode of [SEGMENTED-PW]. Note that this
works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be circumstances where this is not the case,
e.g., following restoration using a facility bypass LSP. In these
cases, tools to trace the path of the LSP may be used to determine
the appropriate setting for the TTL to reach a specific MIP.
Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
layer processing is performed on a packet. The MPLS architecture
mandates that MPLS layer processing occurs at least once on an LSR.
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.
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.
3.8. Return Path
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.
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
U ========= Y ========= D
LER LSR LER
---------> Direction of user traffic flow
Figure 15: Return Path Reference Model
The following cases are described for the various types of LSPs:
Case 1 Return path packet transmission from D to U
Case 2 Return path packet transmission from Y to U
Case 3 Return path packet transmission from D to Y
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
3.8.1. Return Path Types
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:
a. 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
b. D has some other unspecified means of directing traffic back to
The first option is referred to as an "in-band" return path, the
second as an "out-of-band" return path.
There are various possibilities for "out-of-band" return paths. Such
a path may, for example, be based on ordinary IP routing. In this
case, packets would be forwarded as usual to a destination IP address
associated with U. In an MPLS-TP network that is also an IP/MPLS
network, such a forwarding path may traverse the same physical links
or logical transport paths used by MPLS-TP. An out-of-band return
path may also be indirect, via a distinct Data Communication Network
(DCN) (provided, for example, by the method specified in [RFC5718]);
or it may be via one or more other MPLS-TP LSPs.
3.8.2. Point-to-Point Unidirectional LSPs
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 below for such LSPs applies.
As an alternative, an out-of-band return path may be used.
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 recognizes the need for and performs this forwarding
operation is protocol specific.
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 recognizes the
need for and performs this forwarding operation is protocol
3.8.3. Point-to-Point Associated Bidirectional LSPs
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.
For Cases 2 and 3, the considerations are the same as those for
point-to-point unidirectional LSPs.
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs
For all of Cases 1, 2, and 3, a natural in-band return path exists in
the form of the LSP itself, and its use is 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.
3.9. Control Plane
A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements
specified in [RFC5654] can be met, the MPLS Transport Profile uses
existing standard control-plane protocols for LSPs and PWs.
Note that a dynamic control plane is not required in an MPLS-TP
network. See Section 3.11 for further details on statically
configured and provisioned MPLS-TP services.
Figure 16 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.
| Network Management System and/or |
| Control Plane for Point-to-Point Connections |
| | | | | |
.............|.....|... ....|.....|.... ....|.....|............
: +---+ | : : +---+ | : : +---+ | :
: |OAM| | : : |OAM| | : : |OAM| | :
: +---+ | : : +---+ | : : +---+ | :
: | | : : | | : : | | :
\: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
/: +----+ |ing | : : |ing | : : |ing | +----+ :\
: +--------+ : : +--------+ : : +--------+ :
''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
1) NMS may be centralized or distributed. Control plane is
2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g., native service processing or
3) The control plane may be transported over the server
layer, an LSP, or a G-ACh.
Figure 16: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on existing MPLS and PW control
plane protocols, and is consistent with the Automatically Switched
Optical Network (ASON) architecture [G.8080]. MPLS-TP uses:
o Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471],
[RFC3473]) for LSPs, and
o Targeted LDP (T-LDP) signaling ([RFC4447], [SEGMENTED-PW],
[DYN-MS-PW]) for pseudowires.
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 [RFC5718]. 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.
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
[CP-FRAMEWORK]. 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
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
The distributed MPLS-TP control plane may provide the following
o Traffic engineering and constraint-based path computation
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.
The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document
Section 3.7, e.g., for fault detection and localization in the event
of a failure in order to efficiently restore failed transport paths.
The MPLS-TP control plane supports all MPLS-TP data-plane
connectivity patterns that are needed for establishing transport
paths, including protected paths as described in Section 3.12.
Examples of the MPLS-TP data-plane connectivity patterns are LSPs
utilizing the fast reroute backup methods as defined in [RFC4090] and
ingress-to-egress 1+1 or 1:1 protected LSPs.
The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures
and degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data
plane may be achieved. 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.
3.10. Inter-Domain Connectivity
A number of methods exist to support inter-domain operation of
MPLS-TP, including the data-plane, OAM, and configuration aspects,
o Inter-domain TE LSPs [RFC4726]
o Multi-segment Pseudowires [RFC5659]
o LSP stitching [RFC5150]
o Back-to-back attachment circuits [RFC5659]
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
3.11. Static Operation of LSPs and PWs
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.
The survivability architecture for MPLS-TP is specified in
A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([RFC4090]), while pseudowire
redundancy [PW-REDUNDANCY] supports scenarios where the protection
for the PW cannot be fully provided by the underlying LSP (i.e.,
where the backup PW terminates on a different target PE node than the
working PW in dual-homing scenarios, or where protection of the S-PE
is required). Additionally, GMPLS provides a well-known set of
control-plane-driven protection and restoration mechanisms [RFC4872].
MPLS-TP provides additional protection mechanisms that are optimized
for both linear topologies and ring topologies and that operate in
the absence of a dynamic control plane. These are specified in
Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide
different levels of resiliency, for example:
o two concurrent traffic paths (1+1).
o one active and one standby path with guaranteed bandwidth on both
o one active path and a standby path the resources of which are
shared by one or more other active paths (shared protection).
The applicability of any given scheme to meet specific requirements
is outside the scope of this document.
The characteristics of MPLS-TP resiliency mechanisms are as follows:
o Optimized for linear, ring, or meshed topologies.
o Use OAM mechanisms to detect and localize network faults or
o Include protection mechanisms to coordinate and trigger protection
switching actions in the absence of a dynamic control plane.
o MPLS-TP recovery schemes are applicable to all levels in the
MPLS-TP domain (i.e., section, LSP, and PW) providing segment and
o 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.
o MPLS-TP recovery mechanisms can be data-plane, control-plane, or
o MPLS-TP supports revertive and non-revertive behavior.
3.13. Sub-Path Maintenance
In order to monitor, protect, and manage a portion (i.e., segment or
concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
instantiated. A hierarchical LSP instantiated for this purpose is
called a Sub-Path Maintenance Element (SPME). Note that by
definition an SPME does not carry user traffic as a direct client.
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 [DATA-PLANE] that carries the original LSP over this
portion of the 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.
For example, in Figure 17, 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.
|<============================= LSP =============================>|
|<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
|====== SPME =========| |====== SPME =========|
(Carrier 1) (Carrier 2)
Note 1: LER2, LER3, LER4, and LER5 are with respect to the SPME,
but LSRs with respect to the LSP.
Note 2: The LSP terminates in LERs outside of Carrier 1 and
Carrier 2, for example, LER1 and LER6.
Figure 17: SPMEs in Inter-Carrier Network
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 [RFC3031].
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 [G.805]. The mapping
can also be 1:N to allow aggregated monitoring, protection, and
management of a set of LSP segments or concatenated LSP segments.
Figure 18 shows a SPME that 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.
The QoS aspects of a SPME are network specific. [OAM-FRAMEWORK]
provides further considerations on the QoS aspects of OAM.
| |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+
|LER1 | |LSR| |LSR| |LER2 |
+--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ |
| |============ SPME ==============| |
|LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
Figure 18: SPME for a Set of Concatenated LSP Segments
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 [SURVIVE-FWK]. A
SPME can be defined corresponding to one or more end-to-end LSPs.
New end-to-end LSPs that 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.
Hierarchical label stacking, in a similar manner to that described
above, can be used to implement Sub-Path Maintenance Elements on
pseudowires, as described in [OAM-FRAMEWORK].
3.14. Network Management
The network management architecture and requirements for MPLS-TP are
specified in [NM-FRAMEWORK] and [NM-REQ]. These derive from the
generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for
transport technologies. They also incorporate the OAM requirements
for MPLS Networks [RFC4377] and MPLS-TP Networks [RFC5860] and expand
on those requirements to cover the modifications necessary for fault,
configuration, performance, and security in a transport network.
The Equipment Management Function (EMF) of an MPLS-TP Network Element
(NE) (i.e., LSR, LER, PE, S-PE, or T-PE) provides the means through
which a management system manages the NE. The Management
Communication Channel (MCC), realized by the G-ACh, provides a
logical operations channel between NEs for transferring management
information. The Network Management System (NMS) can be used to
provision and manage an end-to-end connection across a network.
Maintenance operations are run on a connection (LSP or PW) in a
manner that is independent of the provisioning mechanism. Segments
may be created or managed by, for example, Netconf [RFC4741], SNMP
[RFC3411], or CORBA (Common Object Request Broker Architecture)
interfaces, but not all segments need to be created or managed using
the same type of interface. Where an MPLS-TP NE is managed by an
NMS, at least one of these standard management mechanisms is required
for interoperability, but this document imposes no restriction on
which of these standard management protocols is used. 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 Section 3.11.
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.
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
The Performance Management (PM) functions within the EMF of an
MPLS-TP NE support the evaluation and reporting of the behavior of
the NEs and the network. One particular requirement for PM is to
provide coherent and consistent interpretation of the network
behavior 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 proactively.
4. Security Considerations
The introduction of MPLS-TP into transport networks means that the
security considerations applicable to both MPLS [RFC3031] and PWE3
[RFC3985] 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 utilize functionality
outside of the strict MPLS Transport Profile are used to support
packet transport services, the security considerations of that
additional functionality also apply.
For pseudowires, the security considerations of [RFC3985] and
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.
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
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:
An intruder could intercept or inject G-ACh packets effectively
disrupting the protocols carried over the G-ACh.
An intruder could deliberately flood a peer MPLS-TP node with
G-ACh messages to deny services to others.
A misconfigured or misbehaving device could inadvertently flood a
peer MPLS-TP node with G-ACh messages that 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.
To protect against these potential (deliberate or unintentional)
attacks, multiple mitigation techniques can be employed:
G-ACh message throttling mechanisms can be used, especially in
distributed implementations that 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.
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.
Additional security considerations apply to each MPLS-TP solution.
These are discussed further in [SEC-FRAMEWORK].
The security considerations in [RFC5920] apply.
5. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that
This document introduces no additional IANA considerations in itself.
The editors wish to thank the following for their contributions to
o Rahul Aggarwal
o Dieter Beller
o Malcolm Betts
o Italo Busi
o John E Drake
o Hing-Kam Lam
o Marc Lasserre
o Vincenzo Sestito
o Nurit Sprecher
o Martin Vigoureux
o Yaacov Weingarten
o The participants of ITU-T SG15
7.1. Normative References
[G.7710] ITU-T, "Common equipment management function
requirements", ITU-T Recommendation G.7710/Y.1701,
[G.805] ITU-T, "Generic Functional Architecture of Transport
Networks", ITU-T Recommendation G.805, November
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D.
McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN", RFC 4385,
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using
the Label Distribution Protocol (LDP)", RFC 4447,
[RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou,
"RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual
Circuit Connectivity Verification (VCCV): A Control
Channel for Pseudowires", RFC 5085, December 2007.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS
Generic Associated Channel", RFC 5586, June 2009.
7.2. Informative References
[CP-FRAMEWORK] Andersson, L., Berger, L., Fang, L., Bitar, N.,
Takacs, A., Vigoureux, M., Bellagamba, E., and E.
Gray, "MPLS-TP Control Plane Framework", Work in
Progress, March 2010.
[DATA-PLANE] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Profile Data Plane Architecture", Work in Progress,
[DYN-MS-PW] Martini, L., Bocci, M., Balus, F., Bitar, N., Shah,
H., Aissaoui, M., Rusmisel, J., Serbest, Y., Malis,
A., Metz, C., McDysan, D., Sugimoto, J., Duckett,
M., Loomis, M., Doolan, P., Pan, P., Pate, P.,
Radoaca, V., Wada, Y., and Y. Seo, "Dynamic
Placement of Multi Segment Pseudo Wires", Work in
Progress, October 2009.
[G.8080] ITU-T, "Architecture for the automatically switched
optical network (ASON)", ITU-T Recommendation
[IDENTIFIERS] Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
Work in Progress, March 2010.
[NM-FRAMEWORK] Mansfield, S., Ed., Gray, E., Ed., and H. Lam, Ed.,
"MPLS-TP Network Management Framework", Work in
Progress, February 2010.
[NM-REQ] Mansfield, S. and K. Lam, "MPLS TP Network
Management Requirements", Work in Progress, October
[OAM-DEF] Andersson, L., Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "The OAM Acronym Soup", Work
in Progress, June 2010.
[OAM-FRAMEWORK] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan,
Ed., "MPLS-TP OAM Framework", Work in Progress,
[PW-REDUNDANCY] Muley, P., "Pseudowire (PW) Redundancy", Work in
Progress, May 2010.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL)
Processing in Multi-Protocol Label Switching (MPLS)
Networks", RFC 3443, January 2003.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and
S. Matsushima, "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched
(MPLS) Networks", RFC 4377, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
Protocol Label Switched (MPLS) Data Plane Failures",
RFC 4379, February 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2
Virtual Private Networks (L2VPNs)", RFC 4664,
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC
4741, December 2006.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A.
Farrel, "Label Switched Path Stitching with
Generalized Multiprotocol Label Switching Traffic
Engineering (GMPLS TE)", RFC 5150, February 2008.
[RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements
for Multi-Segment Pseudowire Emulation Edge-to-Edge
(PWE3)", RFC 5254, October 2008.
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation
over LAN in Link State Routing Protocols", RFC 5309,
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS
Upstream Label Assignment and Context-Specific Label
Space", RFC 5331, August 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC
5659, October 2009.
[RFC5718] Beller, D. and A. Farrel, "An In-Band Data
Communication Network For the MPLS Transport
Profile", RFC 5718, January 2010.
[RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements
for Operations, Administration, and Maintenance
(OAM) in MPLS Transport Networks", RFC 5860, May
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G.
Swallow, "Bidirectional Forwarding Detection (BFD)
for MPLS Label Switched Paths (LSPs)", RFC 5884,
[RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional
Forwarding Detection (BFD) for the Pseudowire
Virtual Circuit Connectivity Verification (VCCV)",
RFC 5885, June 2010.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and
GMPLS Networks", RFC 5920, July 2010.
[ROSETTA-STONE] Sprecher, N., "A Thesaurus for the Terminology used
in Multiprotocol Label Switching Transport Profile
(MPLS-TP) drafts/RFCs and ITU-T's Transport Network
Recommendations.", Work in Progress, May 2010.
[SEC-FRAMEWORK] Fang, L. and B. Niven-Jenkins, "Security Framework
for MPLS-TP", Work in Progress, March 2010.
[SEGMENTED-PW] Martini, L., Nadeau, T., Metz, C., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", Work in Progress,
[SURVIVE-FWK] Sprecher, N. and A. Farrel, "Multiprotocol Label
Switching Transport Profile Survivability
Framework", Work in Progress, June 2010.
[VPMS-REQS] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard,
D., and L. Jin, "Framework and Requirements for
Virtual Private Multicast Service (VPMS)", Work in
Progress, October 2009.
[X.200] ITU-T, "Information Technology - Open Systems
Interconnection - Basic reference Model: The Basic
Model", ITU-T Recommendation X.200, 1994.