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