INTERNET DRAFT Expiration Date: May 2003 Vijayanand C HCL Technologies LSP Subobject for RSVP-TE draft-vijay-mpls-rsvpte-lspsubobject-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.'' 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 May 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-TE 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 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] LSR - Label Switch 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 is the start of an LSP Egress - The LSR node which is the finish of an LSP Splicing - Joining two LSPs Nesting - Using an LSP within another LSP Label stacking - Using a stack of labels, one above the other with the outermost label used for switching in the present domain Outer Tunnel - The LSP which is used for tunneling through. Inner Tunnel - The LSP which tunnels through the outer tunnel. ERO - Explicit route object appearing in RSVP-TE messages Vijayanand C December 2002 [page 2 ] INTERNET DRAFT LSP Subobject for RSVP-TE May 2003 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. 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 Vijayanand C December 2002 [page 3 ] INTERNET DRAFT LSP Subobject for RSVP-TE May 2003 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. 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, Vijayanand C December 2002 [page 4 ] INTERNET DRAFT LSP Subobject for RSVP-TE May 2003 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. 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 Vijayanand C December 2002 [page 5 ] INTERNET DRAFT LSP Subobject for RSVP-TE May 2003 _..................... . . 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 . 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, ,R3 ]. The five tuple 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 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 Vijayanand C December 2002 [page 6 ] INTERNET DRAFT LSP Subobject for RSVP-TE May 2003 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 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 184-188,NSK Salai, Vadapalani, Chennai - 600 026, India Phone : +91-44-3728366/367 Ext: 1318 Email : vijayc@ctd.hcltech.com Vijayanand C December 2002 [page 7 ] INTERNET DRAFT LSP Subobject for RSVP-TE May 2003 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. [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. [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 December 2002 [page 8 ]