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






             Bi-directional LSPs for classical MPLS

               draft-dube-bidirectional-lsp-01.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.

.  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. This simplifies the
    operators view of the network as well as path failure modes -
    since the forward and reverse paths are identical. Further,
    bi-directional LSPs require less state when compared to two
    uni-directional LSPs [GMPLS-SIG].

    Bi-directional LSPs are especially relevant 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 2004

.  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.1.1 CSPF extensions for asymmetric bandwidth reservation

    An application may desire asymmetric bandwidth reservation in
    the forward and reverse directions. To accommodate this the CSPF
    implementation should be capable of accepting separate sets of
    constraints for the forward and reverse directions.

2.2 RSVP-TE extensions

    [GMPLS-RSVP-TE] describes 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).

2.2.1 RSVP-TE extensions for asymmetric bandwidth reservation

    An Asymmetric bandwidth reservation request is indicated by the
    presence of an UPSTREAM_FLOWSPEC object. The initiator includes an
    UPSTREAM_FLOWSPEC object describing the QoS properties for the
    reverse direction in the PATH message. The format of this object
    is the same as the RSVP FLOWSPEC object [RSVP-INTSERV].

    An implementation supporting the UPSTREAM_FLOWSPEC object should
    allocate any necessary resources before sending a PATH message to
    a node downstream.


Expires January 2004

.  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.
    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.

.  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. Implementation experience
    shows that the memory requirement for a bi-directional lsp when
    compared to two uni-directional LSPs is lower as less state needs
    to be maintained for one bi-directional LSP when compared to two
    uni-directional LSPs 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.

.  Security Considerations

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

.  IANA Considerations

    For label allocation in the reverse direction, 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].

    For asymmetric bandwidth reservation on the revere path a new RSVP
    Class-Num is needed for the UPSTREAM_FLOWSPEC object. A value of 38
    is suggested.


Expires January 2004

.  Acknowledgments

    We would like to thank Giles Heron, Pascal Menezes, Lior Shabtay,
    Yaron Raz, Vasanthi Thirumalai, Dawn Xie and Kerry Fendick for
    their comments on this memo.

.  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-SIG] L. Berger, Ed., et al, "Generalized MPLS - Signaling
    Functional Description", Internet Draft,
    draft-ietf-mpls-generalized-signaling-09.txt

    [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-09.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-INTSERV] R. Braden, Ed., et al, "The Use of RSVP with IETF
    Integrated Services", RFC2210.

    [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.

.  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