Requirements of an MPLS Transport Profile
Extracted elements (31)
MPLS-TP is defined to combine the packet experience of MPLS with the operational experience and practices of existing transport networks (SONET/SDH, OTN). The goal is to deliver carrier-grade reliability, deterministic resource control, and operational simplicity for packet-based transport services while minimizing CAPEX and OPEX.
Ring topology recovery optimization criteria (minimizing OAM entities, protection labels, and control transactions) were analyzed and found to yield no requirements that are specifically unique to ring topologies beyond the generic recovery requirements in Section 2.5 through 2.5.6.
MPLS-TP MUST support transport paths through multiple homogeneous domains and SHOULD support paths through non-homogeneous domains. Any new MPLS-TP functionality must be agreed within IETF through the IETF consensus process per RFC 4929.
Recovery mechanisms optimized for specific topologies (e.g., rings) MUST be interoperable with mechanisms defined for arbitrary mesh networks to enable protection of end-to-end transport paths. Ring recovery techniques MUST NOT prevent connection to a general MPLS-TP network.
A transport path on a link MUST be uniquely identifiable by a single label on that link, and a transport path's source MUST be identifiable at its destination within its layer network.
Following a control-plane failure, the control plane MUST be capable of restarting and relearning its previous state without impacting forwarding. The control plane MUST also provide a mechanism for dynamic ownership transfer between management plane and control plane, minimizing data-plane reconfiguration.
It MUST be possible to hide MPLS-TP layer network addressing and topology from client layer networks, though operators SHOULD be able to optionally leak limited summarized information (such as SRLGs or reachability) between layers.
It MUST be possible to operate and configure the MPLS-TP data plane without any IP forwarding capability; the data plane only operates on the MPLS label. This applies equally to protection mechanisms.
It MUST be possible to test and validate any protection/restoration mechanisms including the integrity of the recovery transport path, without triggering the actual protection/restoration, both while the working path is in and out of service.
Mechanisms and capabilities MUST be able to interoperate with existing IETF MPLS (RFC 3031) and IETF PWE3 (RFC 3985) control and data planes where appropriate. Data-plane interoperability MUST NOT require a gateway function.
MPLS-TP 1+1 and 1:1 ring protection MUST support switching time within 50ms from fault detection in a 16-node ring with less than 1200 km of fiber. The switching time MUST be independent of the number of LSPs crossing the ring.
MPLS-TP MUST be a connection-oriented packet-switching technology with traffic-engineering capabilities that allow deterministic control of the use of network resources. It MUST support traffic-engineered P2P and P2MP transport paths.
MPLS-TP MUST provide mechanisms to guarantee 50ms recovery times from the moment of fault detection in networks with spans less than 1200 km. Recovery MUST meet SLA requirements over multiple domains, and recovery objectives SHOULD be configurable per transport path.
MPLS-TP MUST support 1+1 protection (bidirectional and unidirectional for P2P, unidirectional for P2MP) and 1:n protection (including 1:1). Protection-switching MUST NOT cause user data to enter an uncontrolled loop.
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).
MPLS-TP MUST support both the logical and physical separation of the control and management planes from the data plane. When planes run out-of-band, no assumptions SHOULD be made about data-plane channel state from control/management-plane channel state.
MPLS-TP MUST support fault indication triggers from lower layers, OAM-based triggers, and management-plane triggers (e.g., forced switch). There MUST be a mechanism to distinguish administrative recovery actions from recovery actions initiated by other triggers.
MPLS-TP MUST support rings of at least 16 nodes (to support upgrade of existing TDM rings) and MUST be possible to deploy in arbitrarily interconnected rings with one or two points of interconnection.
MPLS-TP MUST support static provisioning of transport paths via the management plane, and static provisioning MUST NOT depend on the presence of any element of a control plane.
MPLS-TP MUST support unidirectional, co-routed bidirectional, and associated bidirectional point-to-point transport paths, as well as unidirectional point-to-multipoint transport paths.
MPLS-TP recovery mechanisms MUST be applicable at various levels: link, transport path, segment, concatenated segment, and end-to-end. Recovery MUST also operate in synergy with recovery mechanisms in client or server transport networks to avoid inter-layer race conditions.
Operation of the MPLS-TP layer network MUST be possible without any dependencies on the server or client layer network. The server layer MUST guarantee that traffic loading from other clients does not degrade the transport service to the MPLS-TP layer below the agreed level.
QoS mechanisms are REQUIRED in MPLS-TP to support differentiated services, guarantee SLS parameters (including hard and relative end-to-end bandwidth), support jitter/delay-sensitive services, ensure fair access within a class to shared resources, and guarantee resources for in-band control/management traffic.
The default ring recovery scheme MUST be bidirectional recovery, and revertive switching MUST be the default behavior. Ring recovery MUST scale better than linearly with number of transport paths, and at least linearly with number of nodes and ring interconnects.
The MPLS-TP control plane MUST support control-plane topology and data-plane topology independence; a failure of the control plane does not imply a failure of the data plane. The control plane MUST also fit within the ASON architecture (ITU-T G.8080).
The MPLS-TP data plane MUST be a subset of the MPLS data plane as defined by IETF. When MPLS offers multiple options, MPLS-TP SHOULD select the minimum (necessary and sufficient) subset applicable to a transport network application.
The MPLS-TP data plane MUST be capable of forwarding data and taking recovery actions independent of the control or management plane, and forwarding, OAM, and protection MUST continue to operate if the management or control plane that configured the transport paths fails.
An MPLS-TP ring topology is a set of LSRs where each is connected to exactly two others via single point-to-point bidirectional MPLS-TP links. Physical rings use physical links; logical rings use logical data links such as MPLS-TP LSP tunnels or pseudowires.
MPLS-TP defines two bidirectional path types: co-routed (forward and backward follow the same route and are monitored/protected as a single entity) and associated (constructed from independent unidirectional paths that may follow different routes and are monitored/protected independently).
MPLS-TP transport paths correspond to LSPs or pseudowires (PWs), as defined by network connections in G.805. Transport paths may be P2P or P2MP; the transport-path layer provides only P2P or P2MP connectivity to carry aggregates of transport service layer traffic.
Security requirements for MPLS-TP are delegated to two companion documents: 'Security Framework for MPLS and GMPLS Networks' covers general MPLS/GMPLS threats and defenses, and 'Security Framework for MPLS-TP' covers additional threats specific to the MPLS-TP context.