1 / 6

Inter-domain P2MP LSP Signaling for Path Protection

This draft proposes solutions for inter-domain Point-to-Multipoint (P2MP) Label Switched Paths (LSPs) in an environment that requires path merging and protection. It addresses the limitations of existing RFCs and introduces mechanisms for loose hop expansion and crankback signaling. The document seeks to be adopted as a working group document.

holston
Télécharger la présentation

Inter-domain P2MP LSP Signaling for Path Protection

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. Signaling RSVP-TE P2MP LSPs in an Inter-domain Environmentdraft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-03.txt Zafar Ali, Cisco SystemsN. Neate, Data Connection Ltd

  2. Requirements for inter-domain P2MP tree computation 77th IETF, CCAMP WG, Anaheim, CA, USAMarch 2010 End-to-end Path has to be remerged free (may also need to be cross-over free). P2MP LSPs may need to be stitched at the border nodes, or hierarchical P2MP LSPs. Loose hop expansion at the border node such that overall P2MP LSP is remerge free. RFC4875 (RSVP-TE extensions for P2MP TE) does not address inter-domain requirements. RFC5151 (inter-domain RSVP-TE extensions) does not address P2MP LSP setup. RFC4920 does not address crankbacks for P2MP LSP.

  3. ERO-L (D2) ERO-L (D1) Issues with Loose ERO expansion for P2MP LSPs Remerge happens at (C) in domain 3 Domain 2 B18 D2 G B16 B19 B24 C B23 J D1 D B17 B20 B26 B15 H B22 B21 Domain 4 B1 Domain 3 S B2 Domain 1 • RSVP-TE signaling based solutions to address these requirements are not defined in RFC4875. • The above mentioned situation can even lead to infinite signaling loop! 77th IETF, CCAMP WG, Anaheim, CA, USAMarch 2010

  4. Solution • Ingress selects the same domain border node for ERO expansion for all siblings transiting a given domain. Domain border nodes expands EROs for all siblings S2L such that the overall path taken by these siblings in the domain is remerge free. • Crankback Signaling: • Does not require selection of same domain border node for all siblings transiting a given domain. • For siblings that have failed the LSP setup, on receipt of a PathErr a domain border node may hold the PathErr. • The domain border node may try to signal an alternate path through the domain, for siblings that have failed the LSP setup. • If a subsequent attempt is successful, the domain border node discards the held PathErr message. • If all subsequent attempts are unsuccessful, the domain border node send a PathErr with a new cause to the Ingress node. • Ingress node tries to find an alternate domain for the siblings failed the setup. 77th IETF, CCAMP WG, Anaheim, CA, USAMarch 2010

  5. Next Steps • We would like to request chairs of CCAMP and MPLS WG to decide where this work will belong. • We would like to make this document a WG Document. 77th IETF, CCAMP WG, Anaheim, CA, USAMarch 2010

  6. Thank You. 77th IETF, CCAMP WG, Anaheim, CA, USAMarch 2010

More Related