Internet Draft
 

Network Working Group                      Jonathan P. Lang (Chromisys) 
Internet Draft                                Krishna Mitra (Chromisys) 
Expiration Date: September 2000                  John Drake (Chromisys) 
 
 
    
               Extensions to RSVP for optical networking 
    
                    draft-lang-mpls-rsvp-oxc-00.txt 
 
    
 
1. Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1]. 
    
   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. 
    
2. Abstract 
    
   Dynamically provisionable optical crossconnects (OXCs) will play an 
   active role in future optical networks and the MPL(ambda)S control 
   plane will be used to establish, teardown, and reroute optical 
   trails through the network.  This document specifies extensions to 
   RSVP to address some of the unique requirements of such optical 
   trails.  Specifically, we propose extensions to RSVP that allow an 
   upstream node to make a Label suggestion to a downstream node when 
   establishing an optical trail and allow both directions of a bi-
   directional optical trail to be established simultaneously.  A new 
   message type is also defined so that an RSVP node can notify 
   (possibly non-adjacent) RSVP nodes when network failures occur, 
   without affecting the RSVP states of intermediate RSVP nodes.  
   Finally, we propose a modification to allow bundle messages to be 
   sent to non-adjacent RSVP nodes. 





 
Lang/Mitra/Drake                                              [Page 1] 

Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000 

3. Conventions used in this document 
    
   In this document, we follow the naming convention of [2] and use OXC 
   to refer to all categories of optical crossconnects, irrespective of 
   the internal switching fabric.  We use the term source node to refer 
   to an RSVP node that initiates the optical trail establishment and 
   the term destination node to refer to the RSVP node that terminates 
   the trail at the other end of the network.  Furthermore, we call the 
   message path from the source node to the destination node the 
   downstream direction and the reverse path from the destination node 
   back to the source node the upstream direction.  Note that for bi-
   directional connections our terminology is such that there is only 
   one source node and one destination node. 
    
4. Introduction 
    
   Future optical networks will consist of label switched routers 
   (LSRs) and optical crossconnects (OXCs) that internetwork using the 
   MPL(ambda)S control plane.  Support for provisioning and restoration 
   of end-to-end optical trails within this type of network imposes new 
   requirements on the signaling protocols.  Specifically, optical 
   trails will require small setup latency, support for bi-directional 
   trails, and rapid restoration of trails in case of network failures.  
   This document builds on work already done for traffic engineering in 
   MPLS and proposes solutions for these requirements. 
    
   The modifications proposed in this document enhance the extensions 
   of RSVP-TE [3] to support the following functions: 
     1.   Reduction of trail establishment latency by allowing 
          resources to be configured in the downstream direction. 
     2.   Establishment of bi-directional trails as a single process 
          instead of establishing two uni-directional trails, one in 
          each direction, each being a separate process.  Normally, 
          both directions of a bi-directional trail have the same 
          traffic engineering requirements and need to be routed over 
          the same physical route.  As a result, they cannot be treated 
          as two separate trail requests. 
     3.   Fast failure notification to a node responsible for trail 
          restoration can be achieved so that restoration techniques 
          can be quickly initiated.  For example, for end-to-end path 
          restoration, the source is responsible for rerouting failed 
          trails, and must be notified when the trail's resources are 
          involved in a failure. 
      
   The organization of the remainder of this document is as follows.  
   In Section 5, we propose a Label suggestion to reduce the trail 
   establishment latency.  In Section 6, we present modifications to 
   RSVP so that both directions of a bi-directional trails can be 
   provisioned simultaneously.  In Section 7, we introduce a new Notify 
   message that is to notify nodes when failures occur in the network.  
   Finally, in Section 8, we discuss a modification to the bundle 
   message [3] to allow transmission between non-adjacent nodes. 


 
Lang/Mitra/Drake                                              [Page 2] 

Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000 

   5. Label suggestion 
    
   Currently in RSVP, the Label object for an optical trail is returned 
   in the Resv message.  A unique feature of OXCs is that selecting a 
   (fiber, lambda) Label (see [4]) for a trail requires configuring the 
   OXC so that an input is switched to an output, and all data that 
   arrives over the input must go to the same output.  This is 
   different from traditional LSRs where multiple flows from the same 
   input maybe be assigned different Labels and subsequently switched 
   to different outputs.  A consequence of this is that when an OXC is 
   initially configured, Labels can be assigned to each input and 
   output and protocols (such as LMP [5]) can be used to exchange Label 
   mappings between adjacent nodes. 
    
   A consequence of the inherent receiver-oriented nature of RSVP is 
   that the internal configuration of an OXC in the downstream 
   direction cannot be initiated until it receives the Resv message 
   from the downstream node.  The ability to begin configuring an OXC  
   before receiving a Label object in the Resv message can provide a 
   significant reduction in the setup latency, especially in OXCs with 
   non-negligible configuration time. 
    
   To accomplish this, we propose that an upstream OXC suggest a 
   (fiber, lambda) Label for the downstream node to use by including 
   the suggested Label object in the Label Request object [3] of the 
   Path message.  The Label object will contain the downstream nodeÆs 
   Label for the bearer channel, which can be obtained through the Link 
   Management Protocol (LMP) [5].  This will allow the upstream OXC to 
   begin its internal configuration before receiving the Resv message 
   from the downstream node.  If, however, the downstream node ignores 
   the suggested Label and passes a different Label upstream, the 
   upstream OXC must reconfigure itself so that it uses the label 
   specified by the downstream node. 
    
 
5.1. Label Request 
    
   The LABEL_REQUEST object format is shown below, where we have 
   defined a new C_Type for a suggested Label. 
   

   Class = 19, C_Type = 5 (suggested label) 
    
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       Link Media Type         |            L3PID              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Label Object                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
 

   Link Media Type: 
   The Link Media Type is the two-octet media type values in IS-IS/OSPF 
   Link Media Type TLV defined in [4]. 
    

 
Lang/Mitra/Drake                                              [Page 3] 

Internet Draft     draft-lang-mpls-rsvp-oxc-00.txt         March 2000 

   L3PID: 
   The L3PID is an identifier of the layer 3 protocol using this path.  
   Standard Ethertype values are used. 
    
   Label Object: 
   The Label object is the suggested Label for the downstream node. 
    
 
    
6. Bidirectional Optical Paths 
    
   In future optical networks, it may be desirable to establish bi-
   directional optical paths across the network.  Using RSVP-TE [3], 
   this requires establishing two unidirectional paths: an initial path 
   from the source to the destination and a subsequent path from the 
   destination back to the source.  This approach has two 
   disadvantages: the latency to establish the bi-directional path 
   requires three source/destination transit times, and the time window 
   between reserving the resources in the downstream direction and 
   reserving them in the upstream direction may be large (as much as 
   two times the source/destination transit time), decreasing the 
   probability of successfully establishing the overall bi-directional 
   path. 
    
   To address the disadvantages of establishing bi-directional paths 
   using current techniques in RSVP, we propose that a Label object is 
   added to the Path message in the downstream direction.  In this way, 
   the upstream direction of the bi-directional path is established on 
   the first pass from the source to the destination, reducing the 
   latency of the reservation process.  Furthermore, if suggested 
   Labels are used for the downstream direction of the bi-directional 
   path (see Section 5), then the time between reserving resources in 
   the upstream and downstream directions can be eliminated, increasing 
   the overall probability of success for the bi-directional path. 
    
   The format of the Path message is as follows (where we assume the 
   extensions of [3] are also implemented): 
    
    ::=  [ ]  
                        [] 
                      [