MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching

1. MPLT-TP MRPS OverviewPresentation for the IETF 76draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

2. Introduction • MPLS-TP Ring Protection Switching (MRPS) is a mechanism addressing the requirements for protection of the MPLS-TP LSPs in a ring topology. • Specifically this mechanism is designed to satisfy the optimization criteria considered in ring topologies (see “MPLS-TP Requirements”). • The MRPS mechanism is designed to support point-to-point as well as point-to-multipoint LSPs. • The MPLS-TP section layer OAM is used to monitor the connectivity between each two adjacent nodes. • The Automatic Protection Switching (APS) protocol is used for coordination of protection switching actions between the ring nodes.

3. Protection ring • The protection ring consists of two counter-rotating rings, transmitting in opposite directions relative to each other. Both rings carry working and protection traffic. • The bandwidth on each ring is divided so that a part of ring capacity is dedicated for the working traffic and another part is dedicated to the protection traffic. The protection bandwidth on one ring is used to transport the working traffic from the other ring in case of failure. • Part of ring bandwidth can also be dedicated to carry unprotected non-preemptable traffic (NUT).

4. Architecture types – Wrapping • Wrapping: • The Wrapping technique implies that the node detecting a failure sends out an APS request to the (opposite to the failure) node adjacent to the failure. The APS request is transmitted over the APS communication protocol. • When a node detects a failure or receives an APS request through APS protocol addressed to this node, the traffic of all working LSPs/tunnels transmitted towards the failed span is switched to the protection LSPs/tunnels in the opposite direction (away from the failure). This traffic travels around the ring to the other node (adjacent to the failure) where it is switched back onto the working LSPs/tunnels. • The nodes that performed the protection switching revert back to the normal traffic flow when the failure or APS request is cleared.

5. Wrapping example – point-to-point

6. Node A Node B Node C Node F Node E Node D LSP Q a) Normal state Node B Node A Node C Node F Node E Node D b) Failed state Bandwidth dedicated for working traffic Bandwidth dedicated for protection traffic Wrapping example – point-to-multipoint

7. Architecture types – Steering • The Steering technique implies that the node detecting a failure sends an APS request to the node adjacent to the failure (away from the failure). • The APS request is processed by all intermediate nodes in the ring. For each affected LSP the source node (that adds traffic onto the ring) and the sink node (that drops the traffic from the ring) switches the traffic from working LSPs/tunnels to the protection LSPs/tunnels and restore normal traffic flow when the failure or APS request is cleared. • Te example of the steering technique is shown on the next slide.

8. Steering example

9. APS protocol operation basics • The MPLS-TP MRPS protection operation is controlled with the help of the MPLS-TP Section OAM APS protocol. • The APS protocol carries the APS requests, both automatic and externally generated commands, between the ring nodes. • The protocol type is a 1-phase protocol with support of acknowledgement mechanism by means of Reverse Request code.

10. APS protocol operation basics (cont.) • Each node on the ring is identified uniquely by assigning it a node ID used for detection of the messages addressed to it. • When no protection switches are active on the ring, each node dispatches periodically APS PDUs to the two adjacent nodes, indicating no switch request. • When a node determines that a protection switching is required, it sends the appropriate bridge requests in both directions. • ‘Destination node’ is a node that is adjacent to a node that identified a failed span. • When a node that is not the destination node receives a bridge request and it has no higher priority local request it transfers the APS information as received. In this way, the switching nodes can maintain direct APS protocol communication on the ring.

11. Externally initiated commands Incoming protocol messages Detected failures APS controller Protection switching operation Updated protocol messages Protection switching triggers • Protection switching actions (bridge requests) are conducted when: • they are initiated by operator control (e.g., manual switch, forced switch, and lockout of protection) without a higher priority switch request being in effect on addressed span or entire ring • an MPLS-TP Section SF is declared on the associated span and without a higher priority switch request (e.g., lockout of protection, forced switch) being in effect on addressed span or entire ring and the hold-off timer has expired • the wait to restore timer expires

12. Manual control • The following commands are not transferred by the APS PDU: • Clear • Lockout of working • The following commands (bridge requests) are transferred by the APS PDU: • Lockout of Protection • Forced Switch to protection • Manual Switch to protection • Exercise

13. Automatically initiated commands • The node initiates the following bridge requests automatically: • Signal Fail • Wait-To-Restore • Reverse Request

14. APS payload fields • Destination Node ID: The destination node ID is set to the value of the node ID for which the APS request is destined. The destination node ID is always that of an adjacent node. • Source node ID: The source node ID is set to the value of the node ID of the node generating the APS request. • Bridge Request code: A code consisting of four bits carrying the bridge request message from a tail-end node to the head-end node requesting the head-end to perform a bridge of the normal traffic signals.

15. Next steps • Finalise descriptions. • Request to become WG draft.