1 / 8

caowayne@huawei mach@huawei MPLS WG, IETF 70

Head Node Protection Extensions to RSVP-TE for LSP Tunnels draft-cao-mpls-te-p2mp-head-protection-01. caowayne@huawei.com mach@huawei.com MPLS WG, IETF 70. Background and Motivation. Background Multicast applications are being deployed

kosey
Download Presentation

caowayne@huawei mach@huawei MPLS WG, IETF 70

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Head Node Protection Extensions to RSVP-TE for LSP Tunnelsdraft-cao-mpls-te-p2mp-head-protection-01 caowayne@huawei.com mach@huawei.com MPLS WG, IETF 70

  2. Background and Motivation • Background • Multicast applications are being deployed • TE P2MP LSP Protocol is published, FRR mechanism mature but not applicable for head node failure • Why introduce head node protection ? • Head node failure will cause serious (all subscriber) outages • 1+1 backup is inefficient • Edge more vulnerable than core nodes; higher maintenance requirement • Head node protection objectives • Protect against single head node failure • Achieve 50ms protection • Reuse existing FRR mechanism • Minimize the impact to the devices on the P2MP LSP, only a few nodes should be involved

  3. H1 R1 R2 L1 H2 R3 R4 L2 Scenario of TE P2MP Head Protection MHN MP BHN MP MHN: Main Head Node BHN: Back Head Node • Source device is multi-homed to MHN (Major head node) and BHN (Backup Head Node) • BHN builds backup LSP to all MHN’s downstream LSRs • BHN does not forward the traffic but monitors the MHN status • BHN forwards traffic to all MPs in case of MHN node failure

  4. Solution Overview • Backup LSP Construction • BHN is assigned by MHN • Protected LSP information is synchronized between MHN and BHN by PATH messages • Features • Re-use FRR mechanism • In the View of MP, the protection is similar to link failure protection • Downstream devices of MP will not be affected • Backup LSPs start from BHN to all MPs

  5. 0 1 2 3 Length (bytes) Class-Num C-type Protected Head Backup Head Flags Extension to RSVP-TE • Head Node Protection Object ( For IPv4 ) • This object is are carried in PATH and RESV message between MHN and BHN • Protected Head • IPv4 address identifying the RSVP-TE LSP Head node. • Backup Head • IPv4 address identifying the LSR selected as BHN • Flags • 0x01(bit0): Head protection desired • 0x02(bit1): Head protection available

  6. Applicability Consideration • Topology Requirement • Source device has to be multi-homed to MHN and BHN, or • Two source connected to MHN and BHN independently • BHN must have path to all MPs • MHN node failure detection • Multiple, diversely routed, BFD connections between MHN and BHN may be a solution • Node failure detection can be vendor specific

  7. Next Step? • Revertive Operation • How does MHN learn about LSPs after failure recovery ? • Topology maintenance issue if failure isn’t quickly resolved (recovered from) • Pruning and grafting issues • Bandwidth Reservation Adjustment

  8. Q & A Thanks! MPLS WG, IETF 70

More Related