One document matched: draft-dube-bidirectional-lsp-00.txt

Network Working Group               Rohit Dube (Xebeo Communications)
Internet Draft                   Michele Costa (Xebeo Communications)
Expiration Date: January 2003                               July 2002
                                      
                                
                               



             Bi-directional LSPs for classical MPLS

               draft-dube-bidirectional-lsp-00.txt

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

    This memo proposes extensions to support bi-directional LSPs for
    classical MPLS. Specifically RSVP-TE is extended with objects 
    similar to those in GMPLS to allow establishment of bi-directional 
    LSPs for MPLS networks.

1.  Introduction

    Bi-directional LSPs are well known in a GMPLS context. However, no 
    mechanism exists to establish bi-directional LSPs with with 
    classical (non-generalized) MPLS labels. Allowing bi-directional 
    LSPs in MPLS networks is useful for operators from a maintenance 
    point of view because bi-directional LSPs traverse the same path 
    through the network in both directions. They are especially useful 
    when MPLS is used to provide a service which requires connectivity 
    in both directions between two LERs. Applications include 
    pseudo-wire emulation [PWE3] of Ethernet, Frame Relay and ATM. 

    In this memo, we use the term MPLS to mean "classical" MPLS and
    GMPLS to mean Generalized MPLS. Further, when describing 
    bi-directional LSPs, we will use the term "initiator" to represent 
    the LER that initiates LSP setup and "terminator" to represent the 
    LER at the other end of the LSP. 

Expires January 2003

2.  Details

    In order to support bi-directional LSPs, traffic engineered paths 
    in both the forward and reverse directions need to be calculated 
    and the signaling protocol needs to carry additional labels for 
    the reverse path. For RSVP-TE, extensions are needed to carry MPLS 
    labels in PATH messages, such that the reverse path is setup at the
    same time as the forward path.

2.1 CSPF extensions

    Constrained Shortest-Path-First (CSPF) calculations in MPLS networks
    are usually in the forward direction from an ingress LER. This is 
    adequate for IP traffic-engineering [TE] due to the asymmetrical 
    nature of the underlying IP traffic. For applications like 
    pseudo-wire transport over MPLS, a symmetric path is often desired.

    To support this functionality, the CSPF implementation at an LER 
    needs to be able to calculate a strict and explicit path which 
    meets the TE constraints in both in the forward and reverse 
    directions.

2.2 RSVP-TE extensions

    [GMPLS-RSVP-TE] describes for bi-directional LSP setup in a GMPLS 
    environment. The primary mechanism used for this support is the 
    UPSTREAM_LABEL object which is sent out as part of the PATH message
    and contains the label to be used in the reverse direction.

    [GMPLS-RSVP-TE] defines the use of UPSTREAM_LABEL objects only with
    generalized labels (c-type=2). This object needs to be implemented
    for MPLS with regular labels (c-type=1).

3.  Operation

    On receiving an operators input, the initiator LER kicks off a 
    a path computation which satisfies the TE constraints in both the
    forward and reverse directions. The resulting strict and explicit
    hop list is handed to RSVP-TE for a bi-directional LSP setup.

    The initiator populates a label in the UPSTREAM_LABEL object which
    it sends as part of the PATH message to the downstream node. The
    downstream node uses the label in the UPSTREAM_LABEL object for the
    reverse direction. When sending the UPSTREAM_LABEL object to the 
    next node further downstream, it similarly populates the 
    UPSTREAM_LABEL object with an MPLS label for use in the reverse 
    direction. This process stops when the terminator receives the 
    PATH message.

    The terminator then sends back a RESV message (which is no different
    from that in [RSVP-TE],[RSVP]) to setup the LSP in the forward 
    direction from the terminator.

Expires January 2003

    At the end of this transaction, a bi-directional LSP is setup 
    requiring no more messages than that needed for a regular 
    uni-directional LSP.

5.  Conclusion

    Bi-directional LSPs are a useful construct which simplify operations
    wherever connectivity in both directions is required. They are 
    efficient as they require the same number of messages as regular 
    uni-directional LSPs for path maintenance. Extending their 
    applicability from GMPLS to MPLS is straight-forward and the 
    implementation overhead is low.

    Since CR-LDP [CR-LDP] supports bi-directional LSPs for GMPLS as well
    [GMPLS-CR-LDP], enhancements similar to those in section 2.2 can be 
    made to support bi-directional LSPs via CR-LDP for MPLS.

6.  Security Considerations

    The procedures and extensions proposed in this document do not raise 
    any new security concerns.

7.  IANA Considerations

    There are no additional IANA issues besides those already present in 
    [GMPLS-RSVP-TE]. The class-num value assigned to the UPSTREAM_LABEL
    object will work as is for any value assigned by IANA [IANA].
   
8.  Acknowledgments

    TBD.


Expires January 2003

9.  References

    [CR-LDP] B. Jamoussi, Ed. et al, "Constraint-Based LSP Setup using 
    LDP", RFC 3212.

    [IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
    IANA Considerations Section in RFCs", RFC 2434.
 
    [GMPLS-CR-LDP] P. Ashwood-Smith, Ed., et al, "Generalized MPLS 
    Signaling - CR-LDP Extensions", Internet Draft,
    draft-ietf-mpls-generalized-cr-ldp-06.txt.

    [GMPLS-RSVP-TE] L. Berger, Ed., et al, "Generalized MPLS Signaling - 
    RSVP-TE Extensions", Internet Draft,
    draft-ietf-mpls-generalized-rsvp-te-07.txt.

    [PWE3] X. Xiao, et al, "Requirements for Pseudo-Wire Emulation
    Edge-to-Edge", Internet Draft, draft-ietf-pwe3-requirements-01.txt

    [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
    -- version 1 functional specification", RFC2205.
 
    [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
    tunnels", RFC 3209.

    [TE] D. Awduche, et al, "Requirements for Traffic Engineering Over 
    MPLS", RFC 2702.

10. Author Information

Rohit Dube
Xebeo Communications Inc.
1 Cragwood Road, Suite 100
South Plainfield, NJ 07080
e-mail: rohit@xebeo.com

Michele Costa
Xebeo Communications Inc.
1 Cragwood Road, Suite 100
South Plainfield, NJ 07080
e-mail: mcosta@xebeo.com