1 / 8

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

Yimin Shen (Juniper) Yuji Kamite (NTTC) Eric Osborn (Cisco) IETF 87, Berlin. RSVP Setup Protection draft-shen-mpls-rsvp-setup-protection-03. The idea. 1. Path ( dest = P3, ERO = i1, i2, i3). 3. Path ( dest = P3, ERO = i3).

aadi
Télécharger la présentation

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

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) Yuji Kamite (NTTC) Eric Osborn (Cisco) IETF 87, Berlin RSVP Setup Protectiondraft-shen-mpls-rsvp-setup-protection-03

  2. The idea 1. Path (dest = P3, ERO = i1, i2, i3) 3. Path (dest = P3, ERO = i3) • An LSP is signaled with ERO of strict hops, while a link/node happens to be in failure state. • The router upstream adjacent to the failure (i.e. PLR) can reroute the LSP by signaling a backup LSP through an existing bypass LSP. • Egress router of the bypass LSP (i.e. MP) terminates the backup LSP, re-creates the original LSP, and signals it to destination. • Ingress router of the LSP receives Resv → LSP up. • Ingress router of the LSP receives PathErr of “tunnel locally repaired” → re-compute path and resignal LSP, if applicable. i1 i3 i2 P1 PLR P2 MP 4. Resv 6. Resv 7. PathErr P3 P0 5. Resv 2. Path bypass LSP P4

  3. The established LSP LSP • The LSP comes up as if it were originally set up along the desired ERO and then failed over to the bypass LSP. • PLR’s notification to ingress router: • Resv with “Local protection in use” flag. • PathErr of “tunnel locally repaired”. i1 i3 i2 P 1 PLR P 2 MP backup LSP P 3 P 0 bypass LSP P 4

  4. The benefit • Improvement of reliability in RSVP signaling. • LSPs are protected during setup time, i.e. initial Path message signaling. • Higher chance of establishment. • Minimal setup delay + no crankback. • Ingress router can still re-compute path and re-signal an LSP. • Based on PathErr of “tunnel locally repaired” from PLR.

  5. Use Cases • LSPs with strict EROs which are configured or planned based a topology assuming no network failure. • ERO cannot be modified on the fly by ingress routers. • An ERO change must require involvement of operators. • Setup protection → higher chance of establishment. • LSPs with a strict requirement for setup latency. • Example: On-demand transport LSPs for TV broadcast. • Cannot tolerate the delay of PathErr propagation, path re-computation, LSP re-signaling, etc. • Solution: First, use setup protection to bring up LSP; Second, re-compute and resignal LSP, if applicable. • Setup protection → lower setup latency.

  6. Use Cases (cont.) • Avoiding traffic duplication for P2MP LSPs. • If a sub-LSP is being protected by a bypass LSP, new sibling sub-LSPs can use the same bypass LSP to minimize traffic duplication. • Setup protection → less traffic duplication.

  7. RSVP extensions • A "setup protection desired" flag for Attribute Flags TLV of LSP_ATTRIBUTES object. • New LSP Attribute TLVs for backup LSP to carry the original source address of protected LSP 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 to recreate the protected LSP.

  8. Next Steps • Comments? • WG adoption?

More Related