60 likes | 160 Views
Bi-directional LSPs For Classical MPLS draft-dube-bidirectional-lsp-00/01.txt Rohit Dube, Michele Costa (Previously presented at MEF and MPLS WG). Bi-directional Symmetric LSP. Definition
E N D
Bi-directional LSPs For Classical MPLSdraft-dube-bidirectional-lsp-00/01.txtRohit Dube, Michele Costa (Previously presented at MEF and MPLS WG)
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
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
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
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
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.