Protection Mechanisms for LDP P2MP/MP2MP LSP draft-zhao-mpls-mldp-protections-02.txt Quintin Zhao,...
-
Upload
megan-legrande -
Category
Documents
-
view
219 -
download
0
Transcript of Protection Mechanisms for LDP P2MP/MP2MP LSP draft-zhao-mpls-mldp-protections-02.txt Quintin Zhao,...
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