MPLS-TP Requirements

For many years, SONET/SDH has provided service providers with a high benchmark for reliability and operational simplicity. With the accelerating growth of packet-based services (such as Ethernet, VoIP, L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in need of capabilities to efficiently support packet-based services on their transport networks. The need to increase their revenue while remaining competitive forces operators to look for the lowest network Total Cost of Ownership (TCO). Investment in both Capital Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal. Carriers are considering migrating to packet transport networks in order to reduce their costs and to improve their ability to support services with guaranteed SLAs. Migrating from SONET/SDH to packet transport networks should not involve dramatic changes in network operation, should not necessitate extensive retraining, and should not require major changes to existing work practices. The aim is to preserve the look-and-feel to which carriers have become accustomed in deploying their SONET/SDH networks, while providing common, multi-layer operations, resiliency, control and management for packet, circuit and lambda transport networks. Service providers require control and deterministic usage of network resources. They need end-to-end control to engineer network paths and to efficiently utilize network resources. They require capabilities to support static (OSS based) or dynamic (control plane) provisioning of deterministic, protected and secured services and their associated resources as well as alternative control-plane options. Carriers will still need to cope with legacy networks (which are composed of many layers and technologies), thus the packet transport network should interwork with other packet and transport networks (both horizontally and vertically). Vertical interworking is also known as client/server or network interworking. Horizontal interworking is also known as peer-partition or service interworking. For more details on each type of interworking and some of the issues that may arise (especially with horizontal interworking) see . MPLS is a maturing packet technology and it is already playing an important role in transport networks and services. However, not all of MPLS's capabilities and mechanisms are needed and/or consistent with transport network operations. There is therefore the need to define an MPLS Transport Profile (MPLS-TP) in order to support the capabilities and functionalities needed for packet transport network services and operations through combining the packet experience of MPLS with the operational experience of SONET/SDH. MPLS-TP will enable the migration of SONET/SDH networks to a packet-based network that will easily scale to support packet services in a simple and cost effective way. MPLS-TP needs to combine the necessary existing capabilities of MPLS with additional minimal mechanisms in order that it can be used in a transport role. This document specifies the requirements for a MPLS Transport Profile (MPLS-TP). This document is a product of a joint ITU-IETF effort to include a MPLS Transport Profile within the IETF MPLS architecture to support the capabilities and functionalities of a packet transport network as defined by ITU-T. This work is based on two sources of requirements, MPLS architecture as defined by IETF and packet transport networks as defined by ITU-T. The requirements of MPLS-TP are provided below. Although both static and dynamic configuration of MPLS-TP transport paths (including OAM and protection capabilities) is required by this document, it MUST be possible for operators to be able to completely operate (including OAM) an MPLS-TP network in the absence of any control plane protocols for dynamic configuration.

Section: A section is a network segment between two LSRs that are immediately adjacent at the MPLS-TP layer. Service layer: A network layer in which transport paths are used to carry a customer’s (individual or bundled) service (may be point-to-point, point-to-multipoint or multipoint-to-multipoint services). Tandem Connection: A tandem connection corresponds to a segment of a path. This may be either a segment of an LSP (i.e. a sub-path), or one or more segment(s) of a PW. Transport path: A connection as define in G.805 . Transport path layer: A network layer which provides point-to-point or point-to-multipoint transport paths which are used to carry aggregates of the network service layer. Transmission media layer: A network layer which provides sections (two-port point-to-point connections) to carry the aggregate of network transport path or network service layers on various physical media.

The connectivity service is the basic service provided by a transport network. The purpose of a transport network is to transparently carry its clients (i.e. the stream of client PDUs or client bits) between endpoints in the network (typically over several intermediate nodes). These endpoints may be service switching points or service terminating points. The connectivity services offered to customers are aggregated into large transport paths with long-holding times, which enable the efficient and reliable operation of the transport network. These transport paths are modified infrequently. Aggregation and hierarchy are beneficial for achieving scalability and security since: They reduce the number of provisioning and forwarding states in the network core. They reduce load and the cost of implementing service assurance and fault management. Client signals are completely encapsulated and isolated from each other. This also allows complete isolation of customer traffic from carrier operations. An important attribute of a transport network is its ability to function independently from both its client and server (transmission media) layer networks. It should be capable of transmitting over any media. Another key characteristic of transport networks is the capability to maintain the integrity of the client across the transport network. A transport network must provide the means to commit quality of service objectives to clients. This is achieved by providing a mechanism for client network service demarcation for the network path together with an associated network resiliency mechanism. A transport network must also provide a method of service monitoring in order to verify the delivery of an agreed quality of service. This is enabled by means of carrier-grade OAM tools. Client signals are first transparently encapsulated. These encapsulated client signals are then aggregated for transport through the network in order to optimize network management. Server layer OAM is used to monitor the transport integrity of the client layer aggregate. At any hop, the aggregated signals may be further aggregated in lower layer transport network paths for transport across intermediate shared links. The encapsulated client signals are extracted at the edges of aggregation domains, and are either delivered to the client or forwarded to another domain. In the core of the network, only the server layer aggregated signals are monitored; individual client signals are monitored at the network boundary in the client layer network. Quality-of-service mechanisms are required in the packet transport network to ensure the prioritization of critical services, to guarantee BW and to control jitter and delay.

MPLS-TP MUST offer as much commonality as possible with the MPLS data plane as defined by IETF. When MPLS offers multiple options in this respect, MPLS-TP SHOULD select the minimum sub-set (necessary and sufficient subset) applicable to a transport network application. Any new functionality that is defined to fulfil the requirements for MPLS-TP MUST be agreed within IETF and re-use (as far as practically possible) existing MPLS standards. Mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS and IETF PWE3 control and data planes where appropriate. MPLS-TP MUST support a connection-oriented packet switching paradigm with traffic engineering capabilities that allow deterministic control of the use of network resources. MPLS-TP MUST support the logical separation of the control and management planes from the data plane. MPLS-TP MUST allow the physical separation of the control and management planes from the data plane. MPLS-TP MUST support point to point (P2P) or point to multipoint (P2MP) transport paths. MPLS-TP MUST support static provisioning of transport paths via an NMS/OSS (i.e. via the management plane). Static provisioning MUST NOT depend on routing or signaling protocols (e.g. GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.). MPLS-TP MUST support the capability for network operation (including OAM) via an NMS/OSS (without the use of any control plane protocols). MPLS-TP MUST support dynamic provisioning of transport paths via a control plane. The MPLS-TP data plane MUST be capable of functioning independently of the control or management plane used to operate the MPLS-TP layer network. That is the MPLS-TP data plane operation MUST continue to operate normally if the management plane or control plane that configured the transport paths fails. MPLS-TP MUST support any network topology and be able to support increasing bandwidth demands, topology, number of customers or number of services incrementally. MPLS-TP SHOULD support mechanisms to safeguard against the provisioning of transport paths which contain forwarding loops.

An MPLS-TP network MUST operate in a multiple layer network environment consisting of independent service, transport path and transmission media layers. MPLS-TP may be used as the service layer (for P2P and P2MP services) and/or as the transport path layer within a packet transport network. An MPLS-TP layer network MUST support the transparent transport of MPLS-TP and non MPLS-TP client layer networks. An MPLS-TP layer network MUST be able to be transparently carried over MPLS-TP and non MPLS-TP server layer networks (such as Ethernet, OTN, etc.) It MUST be possible to operate the MPLS-TP layer network independently of other layer networks (either MPLS-TP or non MPLS-TP). The above are not only technology requirements, but also operational. Different administrative groups may be responsible for the same layer network or different layer networks, and require the capability for autonomous network operations. It MUST be possible to hide MPLS-TP layer network addressing and other information (e.g. topology) from client layers.

The identification of each transport path within its aggregate MUST be supported. A label in a particular section MUST uniquely identify the transport path. A transport path's source MUST be identifiable at its destination. Transport paths can be aggregated into trunks by pushing and de-aggregated by popping labels. MPLS-TP labels are swapped within a transport path in a layer network instance when the traffic is forwarded from one MPLS-TP link to another MPLS-TP link. Labeling MUST make use of the MPLS label and label stack entry as defined in RFC3032. It MUST be possible to operate and configure the MPLS-TP data (transport) plane without any IP functionality. MPLS-TP MUST support both unidirectional and bi-directional point-to-point transport paths. The forward and backward directions of a bi-directional transport path MUST be capable of following the same path within the MPLS-TP network. The intermediate nodes MUST be aware about the pairing relationship of the forward and the backward directions belonging to the same bi-directional transport path. MPLS-TP MUST support unidirectional point-to-multipoint transport paths. MPLS-TP transport paths MUST NOT perform merging in a way that prevents the unique identification of the source at the destination (e.g. no use of LDP mp2p signaling in order to avoid losing LSP head-end information, no use of PHP, etc). MPLS-TP MUST support transport paths through a single domain. MPLS-TP MUST support transport paths through multiple domains. MPLS-TP MUST be able to accommodate new traffic types. MPLS-TP SHOULD support mechanisms to minimize traffic impact during network reconfiguration. MPLS-TP SHOULD support mechanisms which ensure the integrity of the transported customer's service traffic. MPLS-TP MUST support an unambiguous and reliable means of distinguishing users' (client) packets from MPLS-TP control packets (e.g. control plane, management plane, OAM and protection switching packets).

A distributed control plane MAY be supported to enable fast, dynamic and reliable service provisioning in multi-vendor and multi-domain environments using standardized protocols that guarantee interoperability. If a control plane is used for configuration of MPLS-TP transport paths then: Failure of the control plane MUST NOT impact the MPLS-TP data plane. Recovery of the control plane MUST NOT impact the MPLS-TP data plane any more than is necessary to re-establish the control plane. It MUST support the setup, modification, and release of MPLS-TP transport paths and protection paths. It MUST support mechanisms to provide traffic engineering, constraint-based routing and explicit path control. It MUST provide mechanisms to address QoS and performance requirements (such as throughput, delay, packet loss, etc.) while utilizing network resources efficiently and reliably. MPLS-TP SHOULD support off-path (out-of-band) control and management planes. The MPLS-TP control plane MUST be able to be operated independent of any particular client or server layer control plane. The control plane SHOULD facilitate the implementation of the service by providing end-to-end seamless connectivity and service assurance. The MPLS-TP control plane MUST support establishing all the connectivity patterns defined for the MPLS-TP data plane (e.g., uni-directional and bidirectional P2P, uni-directional P2MP, etc.) including configuration of protection functions and any associated maintenance functions. The MPLS-TP control pane MUST support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path is established or modified. An MPLS-TP control plane MUST support topology hiding and address independence between domains. At the boundary of a domain an MPLS-TP control plane MUST support unique control plane identifiers or addresses identifying boundary points to be interconnected. At the boundary of a domain an MPLS-TP control plane MUST support group control plane identifiers or addresses identifying sets of boundary points to be interconnected. MPLS-TP data plane layer network access points (or connection points that proxy for access points) SHOULD be able to be assigned control plane identifiers which are available to clients to identify endpoints in call or connection requests. An MPLS-TP control plane MUST support translation between externally visible endpoint control plane identifiers and internal network addresses. An MPLS-TP control plane MUST support constraint-based route calculation. An MPLS-TP control plane MUST support provisioning and application of routing constraint policies. An MPLS-TP control plane MUST support pre-provisioned path protection. In some situations it is impractical to expect acceptable recovery performance to be achieved using dynamic recalculation of transport path routes. For this reason, it is necessary to allow for pre-planning of protection routes for selected transport paths. The MPLS-TP control plane MUST support fast restoration. An MPLS-TP control plane MUST scale gracefully to support a large number of transport paths. An MPLS-TP control plane MUST clearly distinguish resources belonging to the MPLS-TP layer network from those in other layer networks that may also be under control plane control. An MPLS-TP control plane MUST support the independent unique identification of control plane elements as needed to support interoperability. It MUST be possible to identify and provision these elements independently, in order to reorganize the control plane components without impacting the data plane services and vice-versa. Architecturally distinct elements in a control plane include: nodes and links, control plane functional components, protocol controllers, etc. An MPLS-TP control plane SHOULD provide a common control mechanism for architecturally similar operations. An MPLS-TP control plane MUST support mechanisms for partitioning the network under control into separate peer or hierarchical control domains. To enable the deployment of a unified control plane aimed at controlling the set of transport technologies used in a transport network, the MPLS-TP control plane MUST also be applicable to other transport layer networks and provide common operations across multiple layers. In order to maintain independence between MPLS-TP and its respective client and server layer networks, the capability to support separate control plane instances SHOULD be possible for control of transport multilayer networks. MPLS-TP SHOULD detect and recover from control plane failures and degradations using graceful operations.

MPLS-TP MUST operate under a common operation, control and management paradigm with respect to other transport technologies (e.g. SDH, OTN or WDM). An MPLS-TP network MUST be able to be operated with a centralized NMS system. An MPLS-TP network SHOULD be able to be operated by a centralized NMS system with the support of a distributed control plane. The MPLS-TP management plane MUST be able to operate independently of any particular client or server layer management plane. The MPLS-TP management plane MUST support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path is established or modified. For the complete set of requirements related to NM functionality for MPLS-TP, see the MPLS-TP NM requirements document [REF].

MPLS-TP SHOULD provide a comprehensive set of capabilities (that are independent of and agnostic to the transmitted client services) to support fault management (e.g. fault detection and localization), performance monitoring (e.g. signal quality measurement) of the MPLS-TP network and the services) and protection switching. OAM mechanisms SHOULD detect and trigger recovery actions in case of facility and equipment failures and performance degradations according to the requirements of the service. MPLS-TP OAM and data MUST share the same fate. MPLS-TP OAM MUST be able to operate without IP functionality and without relying on control and/or management planes. When MPLS-TP is run with IP functionality, all existing IP-MPLS OAM functionality, e.g. LSP-Ping, BFD and VCCV, MUST be able to operate seamlessly. For the complete set of requirements related to OAM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [REF].

For the complete set of requirements related to PM functionality for MPLS-TP, see the MPLS-TP OAM requirements document [REF].

Network survivability plays a critical factor in the delivery of reliable services. Network availability is a significant contributor to revenue and profit. Service guarantees in the form of SLAs require a resilient network that rapidly detects facility or node failures and restores network operation in accordance with the terms of the SLA. The requirements in this section use the recovery terminology defined in RFC 4427 . MPLS-TP MUST support transport network style protection switching mechanisms (tandem network connection protection, LSP protection and PW protection) to provide the appropriate recovery time required to maintain customer SLAs when potentially thousands of services are simultaneously affected by a single failure. MPLS-TP recovery mechanisms SHOULD be applicable at various levels throughout the network including support for span, tandem connection and end-to-end recovery. MPLS-TP MUST support network restoration mechanisms controlled by a distributed control plane and MUST support network restoration mechanisms controlled by a management plane. The restoration resources MAY be pre-planned and selected a priori, or computed after failure occurrence. MPLS-TP MAY support shared-mesh restoration. MPLS-TP SHOULD support soft LSP restoration. MPLS-TP MAY support hard LSP restoration. The restoration mechanism MUST be applicable to any topology. Restoration priority MAY be implemented to determine the order in which transport paths should be restored (to minimize service restoration time as well as to gain access to available spare capacity on the best paths). Preemption priority MAY be used in the event that not all transport paths can be restored, in which case transport paths with lower preemption priority should be released. When preemption is supported, its use MUST be operator configurable. The restoration mechanism SHOULD operate in synergy with other transport network technologies (SDH, OTN, WDM). MPLS-TP MUST support data plane driven protection mechanisms (without any dependency on a control plane or IP protocols) to enable fast recovery from failure. If protection is supported then: MPLS-TP protection mechanisms SHOULD be applied to LSPs and PWs. MPLS-TP MUST support mechanisms that rapidly detect, locate, notify and remedy network faults. MPLS-TP MAY support 1:1 bidirectional protection switching. If bi-directional 1:1 protection switching is activated then the protection state of both ends of the protected entity MUST be synchronized. MPLS-TP MAY support 1+1 unidirectional protection switching. MPLS-TP protection mechanisms MUST be applicable to point-to-point and SHOULD be applicable to point-to-multipoint transport paths. Protection ratio MUST be of 100%, i.e. 100% of impaired working traffic MUST be protected for a failure on the working path. Additionally: The QoS objectives defined by the operator MUST also be met along the protection path. In the case of 1:1 protection mechanisms, the bandwidth reserved for the protection path MAY be available for other traffic when the working path is operational. Operator requests for manual control of protection switching such as clear, lockout of protection, forced-switch and manual-switch commands MUST be supported. Prioritized protection between Signal Fail (SF), Signal Degradation (SD) and operator switch requests MUST be supported. MPLS-TP protection mechanisms MUST support revertive and non-revertive behaviour. MPLS-TP protection switching mechanisms MUST prevent frequent operation of the protection switch due to an intermittent defect. MPLS-TP protection mechanisms MUST ensure co-ordination of timing of protection switches at multiple layers to avoid races and to allow the protection switching mechanism of the server layer to fix the problem before switching at the MPLS-TP layer. MPLS-TP MAY support mechanisms that are optimized for specific network topologies (Ring, Mesh) in order to handle protection switching in an efficient manner.

Service providers require advanced traffic management capabilities to enforce and guarantee the QoS parameters of customers’ SLAs. Quality of service mechanisms are required to ensure: Support for differentiated services and different traffic types with traffic class separation associated with different traffic. Prioritization of critical services. Enabling the provisioning and the guarantee of Service Level Specifications (SLS), with support for hard and relative end-to-end BW guaranteed. Controlled jitter and delay. Guarantee of fair access to shared resources in an MPLS-TP network. Resources for control and management plane packets so that data plane traffic, regardless of the amount, will not cause control and management functions to become inoperative. MPLS-TP: MUST be able to deliver the same degree of QoS that has been delivered by SDH/SONET systems. MUST support a method to offer packet loss objectives comparable to those in TDM transport networks (only due to bit errors). SHOULD support transport and QoS mechanisms that can deliver statistical multiplexing gain. Packets exceeding the agreed traffic profile may be marked or discarded by the traffic conditioning at the ingress of the MPLS-TP network. MUST support transport bandwidth allocation to any granularity without any restrictions based on a circuit-switched multiplexing hierarchy. This will provide service providers with the capability to efficiently support service demands over the MPLS-TP network. [Should we refer here to the requirements specified in RFC 2702?]

MPLS-TP MUST ensure that the network and services are secured. Traffic flows from different users MUST NOT be intermingled, but if this does occur then this MUST be detectable and the appropriate consequent actions taken. MPLS-TP MUST ensure the separation of customer (client) and provider (server and peer network) addressing and other information. MPLS-TP MUST ensure that the control and management planes as well as OAM traffic are secure from external attack. MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network remains secure and stable under situations of extreme stress. Examples of attacks and situations of extreme stress include (but are not limited to) classical security attacks (e.g., hijacking, privacy, non-repudiation, etc.) and attacks on network availability (e.g., denial of service (DoS) attacks).