Network Working Group Nobuaki Matsuura Internet Draft Eiji Oki Document: draft-matsuura-reverse-lsp-00.txt NTT Expires: December 2002 June 2002 Signaling Reverse-directional LSP in Generalized MPLS draft-matsuura-reverse-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 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. 1. Introduction 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. 2. Signaling Reverse-directional LSPs 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. However, a signaling for reverse- directional LSPs must be distinguished from ones for bidirectional LSPs. Therefore, an initiator node sends a Path/Request messages including not only an Upstream Label but also a "null" Label Set object/TLV, i.e., a Label Set object/TLV which has label type of 0 and no subchannel. 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 not signaled in this case. 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. 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 an "LSP 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 initiates the setup of a new reserve- directional FA-LSP. At the same time, the LSR may send the Path/Request message for the original reverse-directional LSP to the other edge of the region. The signaling reverse-directional LSPs is used in three ways. 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. 2.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. 2.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 last in ERO/ER-Hop besides the terminator node. 2.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・s 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・s 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. References [GMPLS-SIG] Ashwood-Smith, P. et al, ・Generalized MPLS Signaling Functinal Description・, Internet Draft, draft-ietf-mpls-generalized-signaling-08.txt, April 2002. (work in progress) [GMPLS-LDP] Ashwood-Smith, P. et al, ・Generalized MPLS signaling - CR-LDP Extensions・, Internet Draft, draft-ietf-mpls-generalized-cr-ldp-06.txt, April 2002. (work in progress) [GMPLS-RSVP] Ashwood-Smith, P. et al, ・Generalized MPLS signaling - RSVP-TE Extensions・, Internet Draft, draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002. (work in progress) [MPLS-HIERARCHY] Kompella, K. et al, ・LSP Hierarchy with Generalized MPLS TE・, Internet Draft, draft-ietf-mpls-isp- hierarchy-05.txt, May 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 Internet Draft draft-matsuura-reverse-lsp-00.txt June 2002