1 / 6

RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-02

Yimin Shen (Juniper Networks) Yuji Kamite (NTTC) IETF 86, Orlando. RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-02. The idea. 1. Path ( dest = P3, ERO = i1, i2, i3). 3. Path ( dest = P3, ERO = i3). An LSP is signaled with an ERO of strict hops.

tannar
Download Presentation

RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-02

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. Yimin Shen (Juniper Networks) Yuji Kamite (NTTC) IETF 86, Orlando RSVP Setup Protectiondraft-shen-mpls-rsvp-setup-protection-02

  2. The idea 1. Path (dest = P3, ERO = i1, i2, i3) 3. Path (dest = P3, ERO = i3) • An LSP is signaled with an ERO of strict hops. • If a link/node is in failure state, the router upstream adjacent to the failure (i.e. PLR) can reroute the LSP by signaling a backup LSP through a existing bypass LSP. • Detects failure based on the strict ERO. • Finds an existing bypass LSP that is protecting the failed link/node. • Egress of the bypass LSP (i.e. MP) terminates the backup LSP, re-creates the original LSP, and signals it towards destination. • LSP is protected during setup time, i.e. initial Path message signaling. i1 i3 i2 P1 PLR P2 MP 4. Resv 6. Resv P3 P0 5. Resv 2. Path bypass LSP P4

  3. The established LSP LSP • LSP appears as if it was originally set up along the desired path and then failed over to the bypass LSP. • PLR’s notification to ingress: • PLR sets “local protection in use” flag in Resv. • PLR sends PathErr of “tunnel locally repaired”. • Benefits: • The LSP is established with a minimal delay. • Path re-computation and re-signaling may follow up at a slower pace, if applicable. i1 i3 i2 P 1 PLR P 2 MP backup LSP P 3 P 0 bypass LSP P 4

  4. Use Cases • LSPs with pre-defined strict EROs that cannot be modified or recomputed by ingress on the fly. • Statically configured. • Computed offline, based a topology that assumes no network failure. • LSPs with a strict requirement for setup time. • Cannot tolerate the delay introduced by PathErr propagation, TE info update, path re-computation, re-signaling, etc. • Solution: First bring up LSP; Then re-compute and re-signal path, and resolve network failure. • Traffic sharing between sibling sub-LSPs of P2MP LSP. • If a sibling sub-LSP is already been protected by a bypass LSP, the new sub-LSP being signal shall also use the bypass LSP.

  5. Extension to RSVP • A "setup protection desired" flag for Attribute Flags TLV of LSP_ATTRIBUTES object. • Two new LSP Attribute TLVs for conveying the original source IP address of protected LSP from PLR to MP. • Protected LSP Sender IPv4 Address TLV. • Protected LSP Sender IPv6 Address TLV. • Carried by the LSP_REQUIRED_ATTRIBUTES of Path message of the backup LSP. • Used by MP for recreating the protected LSP.

  6. Next Steps • Comments? • WG adoption?

More Related