Network Working Group N. Matsuura Internet Draft E. Oki Document: draft-matsuura-reverse-lsp-01.txt (NTT) Expiration Date: May 2003 November 2002 Signaling Reverse-directional LSP in Generalized MPLS draft-matsuura-reverse-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." 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 Generalized MPLS extends the MPLS control plane to encompass bidirectional LSPs. This document defines related extensions to Generalized MPLS signaling to support the establishment of reverse-directional LSPs. This document presents a functional description of the extensions for signaling reverse-directional LSPs. N. Matsuura, E. Oki Expires May 2003 [Page 1]
draft-matsuura-reverse-lsp-01.txt November 2002 1. Introduction Generalized MPLS extends the MPLS control plane to encompass bidirectional LSPs. Support of bidirectional LSPs provides reduction of the setup latency for successful LSP establishment. Signaling of reverse-directional LSPs is derived from the support for bidirectional LSPs 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. 2. Reverse-directional LSPs Generalized MPLS supports the establishment of bidirectional LSPs [GMPLS-SIG, GMPLS-LDP, GMPLS-RSVP]. 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 May 2003 [Page 2]
draft-matsuura-reverse-lsp-01.txt November 2002 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. 3. 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. In considerations of signaling , a reverse-directional LSP is referred to a bidirectional LSP which has an effectively null forward-directional half. An initiator node sends a Path/Request messages including not only an Upstream Label but also a $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. On receipt of the Path/Request message, a terminator node sends a Resv/Mapping message, which has a null Label object/TLV. Thus, a forward-directional LSP is signaled as an effectively empty path. 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 May 2003 [Page 3]
draft-matsuura-reverse-lsp-01.txt November 2002 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. 4. 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 May 2003 [Page 4]
draft-matsuura-reverse-lsp-01.txt November 2002 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 May 2003 [Page 5]
draft-matsuura-reverse-lsp-01.txt November 2002 References [GMPLS-SIG] Ashwood-Smith, P. et al, $B!H(BGeneralized MPLS ? Signaling Functional Description$B!I(B, Internet Draft, draft-ietf-mpls-generalized-signaling-09.txt, August 2002. (work in progress) [GMPLS-LDP] Ashwood-Smith, P. et al, $B!H(BGeneralized MPLS signaling - CR-LDP Extensions$B!I(B, Internet Draft, draft-ietf-mpls-generalized-cr-ldp-07.txt, August 2002. (work in progress) [GMPLS-RSVP] Ashwood-Smith, P. et al, $B!H(BGeneralized MPLS signaling - RSVP-TE Extensions$B!I(B, Internet Draft, draft-ietf-mpls-generalized-rsvp-te-09.txt, September 2002. (work in progress) [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 May 2003 [Page 6]