15
MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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

  • Upload
    mia-roy

  • View
    214

  • Download
    2

Embed Size (px)

Citation preview

Page 1: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

MPLT-TP MRPS Overview

Presentation for the IETF 76

draft-umansky-mpls-tp-ring-protection-switching

Igor Umansky

Huub van Helvoort

Page 2: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-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.

Page 3: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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).

Page 4: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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.

Page 5: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

5

Wrapping example – point-to-point

Bandwidth guaranteed for working traffic

Node A Node B Node C

Node D Node E Node F

a) Normal state

b) Failed state

Node A Node B Node C

Node D Node E Node F

Bandwidth available for protection traffic

Note: Bandwidth for unprotected traffic is not presented here

Page 6: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

6

Wrapping example – point-to-multipoint

Bandwidth dedicated for working traffic

Node A Node B Node C

Node DNode ENode F

a) Normal state

b) Failed state

LSP Q

Node A Node B Node C

Node DNode ENode F

Bandwidth dedicated for protection traffic

Page 7: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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.

Page 8: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

8

Steering example

Node F

Bandwidth guaranteed for working traffic

Node A Node B Node C

Node D Node E

a) Normal state

b) Failed state

Node A Node B Node C

Node D Node E Node F

Bandwidth available for protection traffic

Note: Bandwidth for unprotected traffic is not presented here

Page 9: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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.

Page 10: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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.

Page 11: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

11

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

APS controller

Detected

failures

Externally

initiated comman

ds

Incoming

protocol message

s

Updated protocol message

s

Protection

switching

operation

Page 12: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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

Page 13: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

13

Automatically initiated commands

The node initiates the following bridge requests automatically: Signal Fail Wait-To-Restore Reverse Request

Page 14: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

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.

Page 15: MPLT-TP MRPS Overview Presentation for the IETF 76 draft-umansky-mpls-tp-ring-protection-switching Igor Umansky Huub van Helvoort

15

Next steps

Finalise descriptions.

Request to become WG draft.