RFC 5921
A Framework for MPLS in Transport Networks
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 environments. 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 Points (MIPs). 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 Figure 15. LSP LSP 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 provisioning.
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 U. The first option is referred to as an "in-band" return path, the second as an "out-of-band" return path. There are various possibilities for "out-of-band" return paths. Such a path may, for example, be based on ordinary IP routing. In this case, packets would be forwarded as usual to a destination IP address associated with U. In an MPLS-TP network that is also an IP/MPLS network, such a forwarding path may traverse the same physical links or logical transport paths used by MPLS-TP. An out-of-band return path may also be indirect, via a 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
specific.
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| | : : +---+ | : : +---+ | : : +---+ | : : | | : : | | : : | | : \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/ --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+-- /: +----+ |ing | : : |ing | : : |ing | +----+ :\ : +--------+ : : +--------+ : : +--------+ : ''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' Note: 1) NMS may be centralized or distributed. Control plane is distributed. 2) 'Edge' functions refers to those functions present at the edge of a PSN domain, e.g., native service processing or classification. 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 plane. 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. The distributed MPLS-TP control plane may provide the following functions: o Signaling o Routing 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, for example: 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 document.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.
3.12. Survivability
The survivability architecture for MPLS-TP is specified in [SURVIVE-FWK]. 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 [SURVIVE-FWK]. 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 paths (1:1). 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 service degenerations. 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 end-to-end recovery.
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
management-plane based.
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 ---->|
|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,
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. |LERx|--|LSRy|-+ +-|LSRz|--|LERt| | | | |<---------- 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 specified frequency. 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 [RFC5659] apply. 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 in [RFC5920]. 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
functionality.
This document introduces no additional IANA considerations in itself.
6. Acknowledgements
The editors wish to thank the following for their contributions to this document: 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 SG157. References
7.1. Normative References
[G.7710] ITU-T, "Common equipment management function requirements", ITU-T Recommendation G.7710/Y.1701, July 2007. [G.805] ITU-T, "Generic Functional Architecture of Transport Networks", ITU-T Recommendation G.805, November 1995. [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 2002. [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, May 2005. [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, February 2006. [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, April 2006. [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, July 2010. [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 G.8080/Y.1304, 2005. [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 2009. [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, April 2010. [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 2004. [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, September 2006. [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006. [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, October 2008.
[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 2010. [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [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, June 2010.
[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.
Authors' Addresses
Matthew Bocci (editor) Alcatel-Lucent Voyager Place, Shoppenhangers Road Maidenhead, Berks SL6 2PJ United Kingdom EMail: matthew.bocci@alcatel-lucent.com Stewart Bryant (editor) Cisco Systems 250 Longwater Ave Reading RG2 6GB United Kingdom EMail: stbryant@cisco.com Dan Frost (editor) Cisco Systems EMail: danfrost@cisco.com Lieven Levrau Alcatel-Lucent 7-9, Avenue Morane Sulnier Velizy 78141 France EMail: lieven.levrau@alcatel-lucent.com Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net