INTERNET DRAFT                       
Expiration Date: November 2003            
                                                           Vijayanand C 
                                                       HCL Technologies 

 

 

                     LSP Subobject for RSVP-TE  
              draft-vijay-mpls-rsvpte-lspsubobject-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.'' 
   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 
    
   This document describes the use of RSVP-TE to establish hierarchical 
   tunnels using a LSP sub-object in the ERO. 
    
   This document proposes extensions to existing RSVP-TE for 
   establishing hierarchical tunnels in RSVP-TE using a LSP subobject 
   in the Explicit route object of RSVP-TE path message. LSP subobject 
   can be used to uniquely identify the outer tunnel to be used for 
   tunneling. This is useful in situations where the outer tunnel is 
   not an FA-LSP and the knowledge of outer tunnel is available to the 
   administrator.  
    
   1. Introduction 
    
       MPLS serves as a high speed switching mechanism which leverages 
   existing layer 2 protocols with popular layer 3 routing protocols 
   and serves to establish a common control and management plane.  
   RSVP-TE[RSVP-TE] is an extension of RSVP[RSVP] for establishing 
   traffic engineered LSPs across the network to meet the needs of 
   real-time applications and QoS conscious applications. Tunneling of 


Vijayanand C                                                  [Page 1] 
 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 

 
   LSPs using pre-established LSPs is done to transparently transport 
   data across by using the label stack in the tunnel. 
    
       This document describes the use of RSVP-TE to establish nested 
   LSPs without the need for advertising the outer tunnel LSP as FA-
   LSPs as described in MPLS-FA-LSP[FA-LSP]. The LSP ingress, after 
   computing the path for the LSP can use an existing LSP as a hop 
   along the path by mentioning it as a hop in the ERO of RSVP-TEs path 
   message to establish the LSP. This is very useful when the LSP to be 
   established is not an FA-LSP and the knowledge of the LSP is 
   available to the administrator. The administrator  needs to be aware 
   of the LSP parameters and bandwidth remaining in the LSP that it is 
   used for tunneling.  
    
    
   2. Terminology 

       
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC2119 [RFC-WORDS]. 
    
   The reader is assumed to be familiar with the terminology in [RSVP-
   TE] and [MPLS-ARCH] 
    
        LSR - Label Switching Router 
    
        LSP - An MPLS Label Switched Path 
    
         FA-LSP - A Forwarding Adjacency LSP. An LSP which is  
         advertised as a link into the Layer 3 routing protocol 
    
        Ingress - The LSR node which originates an LSP 
    
        Egress - The LSR node which terminates an LSP 
         
        Splicing - Joining two LSPs 
    

        Merging - the replacement of multiple incoming labels for            
        particular FEC with a single outgoing label 

        Nesting - method of carrying LSP within other LSP by means 
        of a label stack     
          
         Label stacking - Using a stack of labels, one above the other 
         with the outermost label used for switching 
          
         Tunnel -  An LSP might be used to tunnel IP packets or labeled 



Vijayanand C                 June 2003                    [page 2 ] 
 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 

         packets, the topmost label in the label stack represents the 
         tunnel 
          
          
         Outer Tunnel - The LSP which is used for tunneling through 
         another tunnel. The label of the outer tunnel appears at the 
         top of the label stack and is used for switching.  
          
         Inner Tunnel - The LSP which tunnels through the outer tunnel. 
         The label of the inner tunnel appears below the label of the 
         inner tunnel. 
 
         ERO - Explicit route object appearing in RSVP-TE messages 
    
    
   3. RSVP-TE Extensions 
    
    
       A new subobject - LSP subobject is proposed to be used as a 
   subobject of ERO. This subobject will be used in the ERO of the path 
   message used for establishing nested tunnels or splicing. The 
   description of the subobject is stated below. 
    
   3.1 LSP Subobject 
    
    
       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |L|      Type   |     Length    |         Reserved              | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                IPv4 tunnel sender address                     |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       IPv4 tunnel end point address           | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Tunnel ID           |         LSPID                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                             Extended Tunnel ID                | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
    
    
   L 
    
         The L bit is an attribute of the subobject.  The L bit is set 
   if the subobject represents a loose hop in the explicit route. If 
   the bit is not set, the subobject represents a strict hop in         
   the explicit route. 


Vijayanand C                 June 2003                    [page 3 ] 

 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 
 
   Type 
    
         TBD    
    
   Length  
        
       The Length contains the total length of the subobject in bytes, 
       including the Type and Length fields.  The Length is always 16. 
    
    
   Reserved 
    
       Zero on transmission.  Ignored on receipt. This is used for 
   padding 
    
    
   IPv4 tunnel sender address 
    
       IPv4 address for a sender node. This is the address of the outer 
   tunnel ingress. 
    
    
   IPv4 tunnel end point address 
 
       IPv4 address of the egress node for the tunnel. 
 
    
   Tunnel ID 
    
       A 16-bit identifier used in the SESSION object of the tunnel 
   that remains constant over the life of the tunnel. 
    
    
   LSPID 
    
       A 16-bit identifier used in the SENDER_TEMPLATE and the 
   FILTER_SPEC of the tunnel 
    
 
   Extended Tunnel ID 
    
       A 32-bit identifier used in the SESSION object that remains 
   constant over the life of the tunnel.  
 
 
 
   The IPv4 tunnel sender address, IPv4 tunnel end point address, 
   Tunnel ID, LSPID and Extended Tunnel ID are the parameters of the 
   outer tunnel to be used as a Hop by the inner tunnel.   


Vijayanand C                 June 2003                    [page 4 ] 

 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 
    
    
   4. Operational overview 
    
    
       When an LSP needs to be established with bandwidth reservation 
   the path is computed and an ERO is formed consisting of the hops 
   through which the LSP should pass so that the bandwidth constraints 
   can be satisfied. The path may contain an LSP with adequate 
   bandwidth to accommodate the bandwidth requirements of this LSP. In 
   this case, the new LSP can use the existing LSP as a single hop and 
   tunnel though it, provided the above LSP supports this. In the 
   forwarding plane, a label stack will exist inside the pre-
   established LSP with the outer label being the label of the outer 
   tunnel LSP and the inner label being that of the inner tunnel LSP. 
   If the outer tunnel LSP is the last hop in the path of the new LSP, 
   then the new LSP can be spliced onto the same provided the bandwidth 
   and policy considerations permit.  
    
       In order to signal this usage of an established LSP as a hop of 
   an LSP as described in this document, the ERO must carry the LSP 
   subobject described previously. This denotes that the LSP with the 
   parameters described in the LSP subobject will be used as a single 
   hop for tunneling or splicing. The LSP subobject containing 
   information about the outer tunnel to be used can be formed in the 
   ingress of the inner tunnel or in the node which is the penultimate 
   hop to the head of the outer tunnel. Usually it is the administrator 
   who has knowledge of the outer tunnel to be used and hence the 
   subobject would be inserted in the ERO at the ingress itself. 
    
    
       The use of LSP subobject with the mechanism described in this 
   document is useful when the outer tunnel LSP is not an FA-LSP. This 
   approach therefore removes the necessity to use only FA-LSPs for 
   tunneling. In a network where only a few tunnels exist and knowledge 
   and bandwidth accounting of these tunnels is a simple 
   management/administrative task, the approach suggested is very 
   useful. 
    
        Also, it could so happen that the outer tunnel LSP is part of 
   another signaling domain. In this case the above LSP may not be 
   advertised as an FA-LSP into other domains. Apart from this, policy 
   considerations of certain operators may prohibit them from 
   advertising the LSP as a link into the domain of another 
   operator/customer. In this case, when the outer tunnel is in another 
   signaling domain, apriori knowledge of the outer tunnel to be used 
   and its bandwidth should be known to the initiator of the inner 
   tunnel. This would be known by agreement with the service provider 
   in the domain. 


    
Vijayanand C                 June 2003                    [page 5 ] 

 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 
    
       If the outer tunnel is part of the same domain but different or 
   same routing area as inner tunnel then this approach does not treat 
   the outer tunnel LSP as a single hop in the path computation for 
   inner tunnel. The hop list after path computation, may match with 
   that of the outer tunnel and hence the outer tunnel can be chosen as 
   a hop and tunneled through. Even if the outer tunnel information is 
   not present in the Traffic engineering database, the administrator 
   may have knowledge of the outer tunnel and use it, once he infers 
   that the outer tunnel hops match with those obtained and the 
   required bandwidth is supported in the outer tunnel. 
    
   The operation is described below with an example 
    
    
    
                       _.....................   
                       .                     .     
        R1------R2------r1=======r2========r3--------R3 
                       .                     . 
                        ..................... 
    
    
    
    
       Consider that, an LSP(to be used as outer tunnel) is already 
   established across the nodes r1,r2 and r3. Let the < IPv4 tunnel 
   sender address, IPv4 tunnel end point address, Tunnel ID, LSPID and 
   Extended Tunnel ID> parameters of this LSP be  <r1,r3,t1,L1,E1> . If 
   another LSP( inner tunnel) needs to be established across 
   R1,R2,r1,r2,r3,R3, which   uses the above tunnel, then ER Hop for 
   the Path message would be [ R2, <r1,r3,t1,L1,E1>,R3 ]. The five 
   tuple <r1,r3,t1,L1,E1> would be carried in the LSP subobject 
   proposed in this document. The node R2, when processing this ERO 
   would recognize that the address r1 in the LSP subobject as its next 
   hop and propagate the LSP subobject to it. The node r1 would process 
   the LSP subobject and identify the tunnel to be used from the five 
   tuple described above. The LSP subobject would be removed from the 
   ERO by r1 and the Path message would be then sent to r3 provided the 
   bandwidth constraints of the LSP L1 are not violated by admitting 
   the new LSP. The path message is sent from r1 to r3 in one of the 
   two following ways. It could be sent over the LSP L1 itself. In this 
   case, the LSP L1 must have sufficient bandwidth set aside for the 
   path/reserve messages and the refreshes. Otherwise, it could be sent 
   over the normal IP interfaces by setting the PHOP object in the path 
   message to r1, setting the IP destination address to r3 and not 
   setting the IP Router alert option.  Hence this path message would 
   travel transparently to r3 without creating any path state in the 
   intermediate nodes. At r3, the node would recognize that R3 is 
   adjacent to it and propagate the path message to it. Once the path 


Vijayanand C                 June 2003                    [page 6 ] 

 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 
   message reaches R3 and the path state is established, the reserve 
   message which traverses the same path back to the ingress, would 
   establish the reservation state and the LSP would be ready for data 
   traffic. Let the new LSP be called L2. The bandwidth remaining in 
   the tunnel between r1 to r3 must be updated with the bandwidth taken 
   by establishing L2. When data is sent over this new LSP - L2 a label 
   stack would be carried between r1 and r3.  
    
        If the new LSP-L2 needs to be established across 
   R1,R2,r1,r2,r3 then the new LSP can be spliced/joined with the 
   existing LSP at r1. The path message would not be propagated beyond 
   r1 and there would be no label stack across r1,r2 and r3. 
    
        
    
   5. Considerations for Path Computation 
     
    
       For the purpose of path computation the outer tunnel LSP is 
   transparent since it is not an FA-LSP. The administrator of the 
   inner tunnel shall use his knowledge of the outer tunnel to use it 
   as a hop in the ERO. Another scenario may arise when the outer LSP 
   is in a different domain. In this situation the topology of the 
   outer LSP domain may not be known outside the domain and hence the 
   path through that domain cannot be computed and matched against that 
   of the outer tunnel. In this situation, the owner of that domain( 
   the provider) shall provide the LSP parameters to the user( 
   customer) to tunnel across the domain.  
    
    
   6. Interoperability Considerations 
    
        
       The nodes which do not recognize the LSP subobject should drop 
   the path message and send a path error with 'the Bad EXPLICIT_ROUTE 
   object' described in RSVP-TE. In order to use the feature described 
   in this document the nodes which construct the subobject and process 
   it, namely the ingress of inner tunnel, ingress of outer tunnel and 
   penultimate hop must support the feature described in this document.  
    
    
   7. Open Issues 
    
       The knowledge of the outer tunnel LSP parameters must be known 
   the node which constructs the LSP subobject, namely the ingress of 
   inner tunnel LSP or penultimate hop of outer tunnel LSP. 
    
   8. Acknowledgements 
    



Vijayanand C                 June 2003                    [page 7 ] 

 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 
       The mechanism described in this document has been inspired by 
   literature about MPLS traffic engineering mechanisms. Specifically 
   the drafts authored by Kireeti Kompella, Yakov Rekhter, D. Awduche, 
   Chetan Kumar S have provided motivation to come up with this 
   contribution. The support given by other well-wishers and friends 
   during this work is recalled with gratitude. 
    
   9. Authors Address 
    
     Vijayanand C 
     HCL Technologies Limited 
     Technologies Division 
     No.184,NSK Road, 
     Vadapalani, 
     Chennai - 600 026, India 
     Phone : +91-44-23728366 Ext: 1321 
     Email : vijayc@ctd.hcltech.com 
    
    
   10. References 
    
    
    [RSVP] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin 
   ,"Resource ReSerVation Protocol (RSVP)",RFC2205 , September 1997 
    
    [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan , G. 
   Swallow ," RSVP-TE: Extensions to RSVP for LSP Tunnels ",RFC 
   3209,December 2001.  
    

    [MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon,              
   "Multiprotocol Label Switching Architecture", RFC 3031, January 2001 

    
    [FA-LSP] Kireeti Kompella, Yakov Rekhter,"LSP Hierarchy with 
   Generalized MPLS TE", 
    
    [INTER-AREA-TE] Kireeti Kompella, Yakov Rekhter, Jean Philippe 
   Vasseur, Ting Wo Chung, "draft-kompella-mpls-multiarea-te-
   03.txt",December 2002 
    
    
    [LSP-OSPF] Chetan Kumar S, Sunil Kumar," Signalling LSPID's in OSPF 
   TE ",draft-chetan-lspid-ospf-00.txt, March 2002. 
    
    [RFC-WORDS]  Bradner, S., "Key words for use in RFCs to Indicate 
   Requirement Levels", RFC 2119, March 1997. 
    
    [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, 
   draft-katz-yeung-ospf-traffic-05.txt,June 2001. 
    

Vijayanand C                 June 2003                    [page 8 ] 

 

   INTERNET DRAFT    LSP Subobject for RSVP-TE  November 2003 
 
 
   [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
   ietf-isis-traffic-03.txt, June 2001. 
    
   [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an 
   IANA Considerations Section in RFCs", RFC 2434. 
    
   [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an 
   IANA Considerations Section in RFCs", RFC 2434. 












































Vijayanand C                 June 2003                    [page 9 ]