1 / 6

Bi-directional Symmetric LSP

This draft proposes extending RSVP-TE to enable bi-directional symmetric LSPs in Classical MPLS, offering benefits like better manageability, scalability, and fault isolation. It introduces the UPSTREAM_LABEL object in PATH message for reverse direction path labeling. The CSPF extension allows for bidirectional path calculations without requiring further routing standards extensions. The proposal enhances LSP setup mechanisms, fitting well with MPLS WG. Future versions aim to support asymmetric bandwidth reservations.

mignon
Télécharger la présentation

Bi-directional Symmetric LSP

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. Bi-directional LSPs For Classical MPLSdraft-dube-bidirectional-lsp-00/01.txtRohit Dube, Michele Costa (Previously presented at MEF and MPLS WG)

  2. Bi-directional Symmetric LSP • Definition A symmetric bi-directional LSP has the same traffic engineering requirements for both directions including fate sharing, protection and restoration, LSRs, and resource requirements (e.g. latency and jitter). [GMPLS-Architecture] A symmetric bi-directional LSP also uses the same path through the network for both directions • Current Status • GMPLS supports Bi-directional LSP • Classical MPLS does not • Two unidirectional “Classical” LSPs required for bi-directional communication • Proposal • Extend RSVP-TE to enable Bi-directional LSPs for Classical MPLS

  3. Benefits of Bi-directional Symmetric LSP • Best fit for applications that require connectivity in both directions • Pseudo-wire emulation • MEF EVPL • Better Manageability • Less configuration • Simplify adding new sites to a VPN • Easier fault isolation • Better Scalability • Less LSP state • Less LSP setup and maintenance messages • Lower LSP setup latency

  4. RSVP-TE extension • Add Support of UPSTREAM_LABEL object in PATH message for the label to be used in the reverse direction: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (26) | C-Type (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Class-Num 26: UPSTREAM_LABEL C-Type 1: Regular Label

  5. CSPF Extension • Constrained-based Shortest Path First (CSPF) usually calculates a path to meet the traffic engineering constraints in the forwarding direction. • Adequate for IP traffic-engineering [TE] for uni-directional LSP, due to the asymmetrical nature of the underlying IP traffic. • CSPF Implementation Extension • Be able to calculate a strict explicit path which meets the traffic engineering constraints in both forwarding and reverse directions for bi-directional symmetric LSP. • No extensions required to routing standards • OSPF-TE already conveys the necessary information for a bi-directional CSPF calculation

  6. Closing Remarks • Proposal extends LSP setup mechanism • thus fits in MPLS WG • presented to PWE3 for information • Proposal being extended to support asymmetric bandwidth reservation • 01 version will be submitted soon. • An UPSTREAM_FLOWSPEC object is defined which carries the reverse path reservation information in the PATH message.

More Related