Network Working Group                                        N. Matsuura
Internet Draft                                                    E. Oki
Document: draft-matsuura-reverse-lsp-02.txt                          NTT
Expiration Date: August 2003
                                                           February 2003


            Signaling Reverse-directional LSP in Generalized MPLS


                      draft-matsuura-reverse-lsp-02.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."

   To view the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
   Directory, see http://www.ietf.org/shadow.html.


Abstract

   This document defines an extension to Generalized MPLS signaling
   procedure to support the establishment of reverse-directional LSPs.
   Reverse-directional LSPs can be signaled by "one-way" signaling.




















N. Matsuura, E. Oki         Expires August 2003                  [Page 1]

 
draft-matsuura-reverse-lsp-02.txt                          February 2003


. Introduction

   Generalized MPLS extends the MPLS control plane to encompass
   bidirectional LSPs. Support of Upstream Label provides reduction
   of the setup latency for successful establishment of bidirectional
   LSPs. Signaling of reverse-directional LSPs is derived from the
   support of Upstream Label and it can be considered as a reasonable
   generalization of the MPLS functionalities. This memo presents a
   functional description of the extensions for signaling reverse-
   directional LSPs.


. Reverse-directional LSPs

   Generalized MPLS supports the establishment of bidirectional
   LSPs [RFC3471, RFC3472, RFC3472]. For the support of bidirectional
   LSPs, the concept of Upstream Label is introduced. As per these
   Internet Drafts, in the remainder of this document, the term
   "initiator" is used to refer to a node that starts the establishment
   of an LSP and the term "terminator" is used to refer to the node
   that is the target of the LSP.

   An initiator node sends a Path/Request message, which includes
   an Upstream Label object/TLV indicating a request for the
   establishment of a bidirectional LSP. When a message containing
   an Upstream Label is received, an intermediate node allocates a
   label on the outgoing interface and establishes internal data
   paths before filling in an outgoing Upstream Label and
   propagating the Path/Request message. Terminator nodes process
   Path/Request messages as usual, with the exception that the
   upstream label can immediately be used to transport data
   traffic associated with the LSP towards the initiator. Note
   that a resource reservation correlating with the upstream
   direction must be done during the Path/Request processing on
   each node.

   The procedure referred above implies possible functionality for
   the signaling of reverse-directional LSPs. In this document,
   the term "reverse-directional LSP" is used to refer to a
   unidirectional LSP that transports data traffic from the
   terminator to the initiator. The term "forward-directional LSP"
   is used to refer a unidirectional LSP that transports data
   traffic from the initiator to the terminator. This document
   presents a functional description of the extensions for
   signaling these unidirectional LSPs.

   A label allocation between two nodes should be executed on a
   responsibility of the node which receives datagram bound to the
   label. Therefore it is rather rational that a receiver of data
   traffic initiates an establishment of an LSP.



N. Matsuura, E. Oki         Expires August 2003                  [Page 2]

 
draft-matsuura-reverse-lsp-02.txt                          February 2003


   The most remarkable advantage of reverse-directional signaling
   is fast setup of LSPs. The time between the beginning of a
   signaling and the establishment of a data path is reduced by
   half compared with forward-directional signaling. It is also
   helpful to reduce the occupation of network resources by LSPs,
   especially for $B!H(Bshort-hold$B!I(B LSPs.

   In addition, in a case of failure of LSPs, it is usually
   detected earlier$B!!(Bby nodes in receiver side with respect to data
   traffic. Thus, receiver-oriented initiation of LSPs is easy to
   work in cooperation with a failure handling.


. Signaling procedures

   In Generalized MPLS signaling, the presence of Upstream Label
   indicates the LSP to be set up is bidirectional. Similarly,
   Upstream Label object/TLV is used for the establishment of
   reverse-directional LSPs.

   An initiator node sends a Path/Request messages including not
   only an Upstream Label but also one $B!H(Bnull$B!I(B Label Set object/TLV,
   i.e., a Label Set object/TLV which has only one null label as
   an inclusive list. When the Path/Request message reaches the
   terminator node, a reverse-directional LSP has been already
   usable. For this LSP, the terminator node does not need to send
   Resv/Mapping messages any longer.

   When an initiator uses ERO label subobjects/TLVs, two label
   subobjects/TLVs, i.e., one label with the U-bit set and one
   null label without the U-bit set, following the first address
   subobject/TLV are sufficient. Because these label
   subobjects/TLVs are copied to the Upstream Label and Label Set
   respectively, in consequent Path/Request messages.

   The node originating an Upstream Label must ensure that the
   Upstream Label is consistent with the Generalized Label Request
   object/TLV in the Path/Request message. When an LSR receives a
   Path/Request message containing an Upstream Label and a null
   Label Set, it should confirm the existence of an appropriate
   link, on which it transports data traffic using received
   Upstream Label, before propagating the Path/Request message.










N. Matsuura, E. Oki         Expires August 2003                  [Page 3]

 
draft-matsuura-reverse-lsp-02.txt                          February 2003


   Such a consideration can be also applied to the signaling of
   hierarchical LSP [LSP-HIERARCHY]. When an LSR receives a
   Path/Request message, and decides it is at the edge of a region
   with respect to the ERO carried in the message, it must
   determine the other edge of the region. If a new FA-LSP is
   required to be set up between the LSR and the other edge of the
   region, the LSR can initiates the setup of a new reserve-
   directional FA-LSP $B!H(Bconcurrently$B!I(B. That is, the LSR may send
   the Path/Request messages simultaneously, one for the original
   reverse-directional LSP to the other edge of the region, and
   the other for new reserve-directional FA-LSPs to next hops
   along the FA-LSP$B!G(Bs path. On the other edge of the region, when
   the LSR receives these two Path/Request messages, it can
   forward the Path/Request message for the original LSP to its
   next hop. Because the receipt of the Path/Request message for
   the new FA-LSP implies that the new FA-LSP is already usable.

   In deletion of reverse-directional LSPs, there are two cases,
   described here for RSVP specifications. When an initiator node
   inserts an Admin Status Object in a Path message and sets the
   R-bit and D-bit, the terminator node responds with a PathErr
   message with the Path_State_Removed flag set. When a terminator
   node inserts an Admin Status Object in a Resv message and sets
   the R-bit and D-bit, the initiator node sends a PathTear
   message downstream to remove the LSP.


. Applications

   There are three possible application of the signaling reverse-
   directional LSPs. In the first, it is used to establish a
   single reverse-directional LSP. In the second, it can be used
   as parts of establishment of asymmetrical bidirectional LSPs.
   The final application is an alternative method for
   establishment of forward-directional LSPs, and it is an RSVP
   specific mechanism.

4.1 Reverse-directional LSP

   For general purposes of use of networks, a receiver of data
   traffic may want to be an initiator of the signaling. In such a
   case, a node issues a Path/Request message which includes both
   of an Upstream Label and a null Label Set. At the point in time
   when the Path/Request message is processed by the terminator
   node, a reverse-directional LSP setup is completed.








N. Matsuura, E. Oki         Expires August 2003                  [Page 4]

 
draft-matsuura-reverse-lsp-02.txt                          February 2003


4.2 Asymmetric bidirectional LSP

   When a node, which is signaling an establishment of bi-
   directional LSP, can not find an appropriate pair of labels on
   an identical link, it may intend the LSP to diverge into
   different routes. Instead of issuing Error messages, the node
   sends two Path/Request messages, one for a forward-directional
   LSP and the other for a reverse-directional LSP, on different
   outgoing interfaces. Since this approach may bring some
   complexity to the signaling, it should be applied to only some
   limited conditions, for instance, when there is no
   subobject/TLV last in ERO/ER-Hop besides the terminator node.

4.3 Pseudo forward-directional LSP

   The procedure described below is RSVP-TE specific. It is based
   on the Notification message extension [GMPLS-RSVP].

   For some reasons, it is useful that a sender of data traffic
   leaves a receiver an initiation of a signaling. For example,
   when a sender node does not have sufficient perspective of
   label (resource) availabilities along the route on which the
   LSP is set up, it may be an immediate and probable way to
   establish a forward-directional LSP from the sender$B!G(Bs point of
   view.

   A sender node of data traffic pretends a terminator of
   signaling of a reverse-directional LSP. The sender sends an
   unsolicited Notify message to the receiver node, requesting the
   receiver to initiate signaling a reverse-directional LSP from
   the receiver$B!G(Bs point of view. The Notify message is targeted
   the receiver directly e.g., by means of an IP encapsulation.
   The Notify message must include a MESSAGE_ID object and an
   ADMIN_STATUS object with R bit set to 0. Information required
   for the consequent Path message, except for an UPSTREAM_LABEL
   object, is enveloped in a POLICY_DATA object. The IP address of
   the sender is included in an ERROR_SPEC object. An error code
   for indication of "Unsolicited Notify message" is TBA, and
   error values for this application are TBD. When the Notify
   message is received, the receiver returns an Ack message to the
   sender, and initiates a signaling for a reverse-directional LSP
   immediately.


Security Considerations

   This document raises no new security concerns.






N. Matsuura, E. Oki         Expires August 2003                  [Page 5]

 
draft-matsuura-reverse-lsp-02.txt                          February 2003


References

   [RFC3471]  L.Berger (Editor) et al., "Generalized MPLS -
   Signaling Functional Description", RFC 3471, IETF Proposed
   Standard, January 2003.

   [RFC3472]  L.Berger (Editor) et al., "Generalized MPLS Signaling -
   CR-LDP Extensions", RFC 3472, IETF Proposed Standard, January 2003.

   [RFC3473]  L.Berger (Editor) et al., "Generalized MPLS Signaling -
   RSVP-TE Extensions", RFC 3473, IETF Proposed Standard, January 2003.

   [MPLS-HIERARCHY]  Kompella, K. et al, $B!H(BLSP Hierarchy with
   Generalized MPLS TE$B!I(B, Internet Draft, draft-ietf-mpls-lsp-
   hierarchy-08.txt, September 2002. (work in progress)


Author's Addresses

   Nobuaki Matsuura
   NTT Corporation
   3-9-11 Midori, Musashino
   Tokyo, Japan 180-8585
   Phone: +81 422 59 3758
   Email: matsuura.nobuaki@lab.ntt.co.jp

   Eiji Oki
   NTT Corporation
   3-9-11 Midori, Musashino
   Tokyo, Japan 180-8585
   Phone: +81 422 59 3441
   Email: oki.eiji@lab.ntt.co.jp


















N. Matsuura, E. Oki         Expires August 2003                  [Page 6]