Protection Mechanisms for LDP P2MP/MP2MP LSP

draft-zhao-mpls-mldp-protections-02.txt

Quintin Zhao, Emily Chen, Tao ChouHuawei Technology

Daniel KingOldDog Consulting

83rd IETF @ Paris

Updates for Version 02

• Since IETF82, We have received a number of comments and suggestions both from the Taipei meeting and after the meeting. Notable thanks to Ijsbrand Wijnands and Alia Atlas for their comments.

• Using the aforementioned feedback. The major updates in the new version include:

 1. Protocol extension and procedure details have been added for:

- The backup p2p LSP’s cleanup for p2p based mLDP node protection.- P2MP based mLDP node protection.

2. Two switchover modes for backup path forwarding have been added:- One mode is for the case when node failure detection from the PLR node

is not available - Second mode is for the case when the node failure detection from the PLR

node is available;3. Further Examples for p2p based mLDP node protection and p2mp based

mLDP node, providing emphasis on procedures.

83rd IETF @ Paris

3

Solution 1: Node protection using P2P backup LSP

Two Options Exist for Cleanup of Backup Path:

Method 1, timer based cleanup of the backup path:① A label reserve timer on both Merge Point (MP) and Point of Local Repair (PLR) is

synched during the LSP setup through the node being protected;② MPT will set up this timer after network convergence, and delete the old forwarding

entry after MBB finished or reserve timer timeout. Note that MPT MUST keep the old label resource until reserve timer expire, this is a local behavior.

③ After the failure is detected, PLR: removes the backup path after a reserve timer timeout.

Method 2, T-LDP cleanup of the backup path:① A T-LDP session between MP and PLR is setup during the LSP setup; ② MPT will delete the old label if: session down, network convergence, or MBB has

finished. The MP will send the notification message, with withdraw flag, to the PLR MPT using T-LDP.

③ The PLR will cleanup the backup path after it receives this notification message from MPT via the T-LDP session.

83rd IETF @ Paris

4

Example for Timer Based Node Protection using P2P LDP Backup LSP

1. R2 send notification message to R3 including its downstream LSR’s information: R1 and R4 node addresses & label reserve time(5s) & forwarding labels(L1 and L4) & other

optional parameters respectively.2. When R3 detects the R2 failing, it will send traffic over the two P2P LDP backup tunnels to R1

and R4 :a) Tunnel Red : R3->R6->R5->R4 using inner label L1;b) Tunnel Blue: R3->R6->R5->R4->R1 using Inner label L4;

3. R1 and R4 will process the packets just as they receive from the R2 after they pop the tunnel label;

4. The backup traffic will be stopped when PLR’s reserve timer timeout.

R2

R6

R3

R4 R5

R1 12.0.0.1 RootReceiver

Receiver

Label L1 5s

Label L4 5s

Label L2 Label L3

L4

L1

Tunnel

L1

Tunnel

L1

Tunnel

L1Label L1’ 5s

Label L4’ 5s Label L5

Labe

l L6

P2P based protection Capability

Config timer

5s

Config timer

5s

Reserve timeout

83rd IETF @ Paris

Notification:R1 node address&L1&5sR4 node address&L4&5s

5

T-LDP Based Node Protection by P2P LDP Backup LSP with T-LDP

There still has another choice to cleanup the backup path information. Following is the differences between the previous solution:1. PLR need trigger the T-LDP between PLR and MPs, T-LDPs of ‘R3-R1’ and ‘R3-R4’ in the example.2. MP will send notification message to PLR when it finish the procedure of MBB or convergence. PLR will delete its backup path when receives this notification message.

R2

R6

R3

R4 R5

R1 12.0.0.1 RootReceiver

Receiver

Label L1

Label L4

Label L2 Label L3

L4

L1

Tunnel

L1

Tunnel

L1

Tunnel

L1Label L1’

Label L4’ Label L5

Labe

l L6

P2P based protection Capability

T-LDP Session

Notification:

L1 delete

Notific

ation

:L4

del

ete

T-LDP Session

Note: Ice and Alia will present another alternative to this next using the T-LDP to setting up and cleanup of the backup LSP.

83rd IETF @ Paris

Notification:R1 node address&L1R4 node address&L4

83rd IETF @ Paris

Protocol Extensions for P2P Based Solution (1)

A new type of LDP MP Status Value Element is introduced for notifying downstream LSRs and respective labels. The encoding is as follows:

83rd IETF @ Paris

Protocol Extensions for P2P Based Solution (2)

The Downstream Element encoding is:

Backup Label: The label assigned by MP for PLRDownstream Node Address: Downstream node’s LSR-ID address

D Bit: Delete Flag, The type of deleting backup label: 1 = ’explicit-delete’, delete by MP’s notification message through T-LDP 0 = ’implicit-delete’, delete by reserve-timer expireN Bit: Node Failure Required Flag, the occasion of switching traffic’s on PLR 1 = ’Y’, switch traffic to backup path only when PLR detects the node failure 0 = ’N’, switch traffic to backup path when PLR detects failure

Res-time: The time of MP’s reserve-timer, synchronizing to PLR.It is effective when D bit set as ’implicit-delete’ and MUST be ignored when D bit set as ’explicit-delete’.

8

Solution2: Node Protection Using P2MP LDP Backup LSP

1. N sends its up-stream’s(PLR) information in notification message to its downstream LSRs(MPs) .This message triggers MP setting up a backup P2MP LSP toward PLR. PLR’s address, P2MP FEC key, N’s address is the key of this backup path. This backup path will avoid N if possible.

2. When PLR detects N failure, it switches the traffic to backup P2MP LSP path.

3. This backup P2MP LSP will be destroyed by label mapping withdraw message, after MP convergence.

83rd IETF @ Paris

label L64label L64 label L74label L74

label L21label L21

label L42label L42

R1(ROOT)

NotificationPLR

NotificationPLR

Notification PLRNotification PLR

Backup label L65

Backup label L65

Backup label L53Backup

label L53

Backup label L32Backup

label L32

Label L65’Label L65’

Label L75’Label L75’

Label L53’Label L53’

Label 32’Label 32’

Withdraw L65

Withdraw L65

Withdraw L75

Withdraw L75

Withdraw L53

Withdraw L53

Withdraw L32

Withdraw L32

R2(PLR) R3(Pn1)

R5(Pn2)

R7(MP2)

R6(MP1)

R4(N)

83rd IETF @ Paris

Protocol Extensions for P2MP Based Solution (1)

A new type of LDP MP Status Value Element is introduced, fornotifying upstream LSR information. It is encoded as:

mLDP FRR Type: Type 3 (to be assigned by IANA)Length: If the Address Family is IPv4, the Length MUST be 5;

If the Address Family is IPv6, the Length MUST be 17.PLR Node Address: The host address of the PLR Node.

83rd IETF @ Paris

Protocol Extensions for P2MP Based Solution (2)

A new type of LDP MP Status Value Element is introduced, for setting up secondary mLDP LSP. It is encoded as:

mLDP FRR Type: Type 4 (to be assigned by IANA)Length: If the Address Family is IPv4, the Address Length MUST be 9; if the Address Family is IPv6, the Address Length MUST be 33.Status code: 1 = Primary path for traffic forwarding 2 = Secondary path for traffic forwardingPLR Node Address: The host address of the PLR Node.Protected Node Address: The host address of the Protected Node.N Bit: Node Failure Required Flag, which indicates the switchover timing on PLR. 1 = ’Y’, switch traffic to backup path only when PLR detects the node failure. 0 = ’N’, switch traffic to backup path when PLR detects failure.

Scenario: The Protection of Node N with 100 Merge Point (MP) and each Merge Point with 10 leaves.

Backup path Bandwidth Cost on Path Per PLR

( LSP Bandwidth is M)

T-LDPSessions(for the

whole tree)

P2P Based SolutionCleanup by timer 1 00M 0

Cleanup by T-LDP 100M >100*10

P2MP Based Solution 1 M(assuming that MPs

Share the same alternate N)0

Analysis for An Example Scenario

83rd IETF @ Paris

L1 L1 L1L10L10

MP1 MP2 MP100

PLR

N N’

L100

Summary & Next Steps

• The authors will update the draft to include the following points raised during IETF83 discussions:

– No additional effort required for MP2MP since the solution is defined based on the PLR and N and MP; Any node, including root, leaf, transit or branch in the MP2MP or P2MP, will function as either PLR, N or MP;

– Backward compatibility: all other features such as GR, MBB and Wildcard features should work “as is” now; we will explain this more in the next version of the draft.

• A need for further evaluation of Timer and T-LDP mechanisms, via more topology, scalability analysis and continued prototyping. Use Cases and input from users would also be welcome;

• We will continue to work with Ice and Alia (draft-wijnands-mpls-mldp-node-protection), merging drafts is a potential option.

83rd IETF @ Paris

Thanks!Questions & Comments?

83rd IETF @ Paris