Network Working Group Yang Hui Internet Draft Jiang Weilian Shen Xiaofeng Expiration Date: Apr. 2007 Feng Jun Teng Zhimeng ZTE, Inc. Oct. 2006 Resource-sharing Method for MBB CSPF by RSVP-TE draft-yang-mpls-resouce-sharing-mbb-cspf-00 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document is based upon RSVP MBB£¨make-before-break£©defined in RFC3209, providing a method to realize resource-sharing between old path and new path while RSVP-TE calculating a new path using CSPF in MBB manner. ¡¡¡¡ 1. Specification of Requirements 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 [RFC-2119]. yang Expires: Apr. 2007 [Page 1] Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006 2. Terminology This document follows the nomenclature of the MPLS Architecture defined in [RFC3031]. 2.1 Acronyms and Abbreviations CSPF Constraint-based Shortest Path First. LSR Label Switching Router LSP Label Switched Path[y1] MPLS MultiProtocol Label Switching RSVP Resource ReSerVation Protocol TE Traffic Engineering TE LSP Traffic Engineering Label Switched Path 3. Introduction As to the current applications of RSVP-TE, MBB mechanism is always to be adopted while finding optimum route, or detecting faults in original lsp, or restoring the lsp to the recovered path which was invalid before, or expanding the bandwidth of tunnel etc. MBB, Make Before Break, is a technique used to non-intrusively alter the path of a TE LSP. The ingress LER first signals the new path, sharing the bandwidth with the primary TE LSP (to avoid double booking), then switches forwarding over to a new path. Finally the old path state is torn down. As defined in RFC3209, in MBB mechanism, the new lsp need share bandwidth with the old lsp when routing and reserving. RSVP-TE may use SE mode defined in RFC2205 to guarantee MBB sharing the reserved resources of old path on the overlapping links when reserving. However, CSPF is only aimed to calculate the optimum path by current link info and tunnel request. Because the current link info does not save the resource reservation info of the old path, in some cases, the new path calculation might fail or provides the path which is not the optimum one. In the following two situations, CSPF will exit the problems mentioned above. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡R1---10M----R2 R1---4M----R2 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡£¨Fig. 1-1£© £¨Fig. 1-2£© In the network depicted above in figure 1-1, it establishes a tunnel 1 from R1 to R2 with its bandwidth as 6M. After the tunnel is established, its bandwidth is changed into 9M. The info of link from R1 to R2 in CSPF is shown in Fig.1-2(the available bandwidth of link R1->R2 is 4M, not meet the requirement of 9M), and therefore CSPF path-calculating fails. So by traditional RSVP-TE, this mbb will fail in CSPF.Obviously, the bandwidth is able to meet the bandwidth requirement for MBB to reestablish tunnel. If we improve the CSPF calculation of MBB, such error will be avoided. R1--20M---R2---15M----R4 LSP1: \ / R1---R2-->R4 ¡¡¡¡¡¡¡¡¡¡15M 15M \ / ¡¡¡¡¡¡¡¡¡¡¡¡¡¡ R3 £¨Fig. 2-1£© yang Expires: Apr. 2007 [Page 2] Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006 R1--15M---R2---10M----R4 LSP1: LSP2: \ / R1---R2-->R4 R1---R2 R4 15M 15M \ / \ / R3 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡ R3 £¨Fig. 2-2£© In the network depicted above in figure 2-1, the bandwidth of R1 interface is 20M, and TE bandwidths of R2, R3 and R4 are 15M respectively. Establish a Tunnel 2 from R1 to R4 with its bandwidth as 5M and R2 as the loose node. CSPF gived the path as LSP1 in Fig. 2-1. Now the bandwidths is shown in Fig. 2-2. Then change the bandwidth of tunnel 2 into 15M, by traditional RSVP-TE, CSPF will give the new path as LSP2 in Fig 2-2. Obviously, this path is not the optimumest path that meets the constraint condition. If being re-optimized after MBB, the tunnel 2 will switch to the path as LSP1 in Fig. 2-1. As CSPF exists the above problems in MBB, this draft provides a method for RSVP-TE in order to guarantee CSPF share the bandwidth with the old path when calculating the new path in MBB, at the same time, the bandwidth will not be available to the calculation for other tunnels. 4. The Resource-sharing Method for MBB CSPF by RSVP-TE 4.1. Solution When adopting CSPF to calculate new path in MBB, RSVP-TE not only provides the requirement of establishing a new path but also introduces the info of strict route and bandwidth of old path etc. CSPF will make use of these resource info to share the resources the old path has occupied when calculating the new path, and thus MBB mechanism is able to establish the optimum path successfully. As to how CSPF makes use of the resource info of old path RSVP-TE provided to calculate the new path, it is not the key point of this document. Here we assume to adopt the following method: CSPF adds the resource info of the old path into a temporary link library of TE link and the info is just used for the calculation this time but not be notified outside, which will be restored after the path calculation immediately. The key point is: it is necessary to introduce the strict bandwidth info of the old path, that is to say,the info of all the nodes that the old path has passed must be included according to the saved ERO. If ERO of the old path contains loose nodes, it is necessary to encapsulate the resource info in the following way: at the head node,encapsulate the info between the head node and the first loose node; at each loose node, encapsulate the info between itself and the next loose node or the end node. In the following, we¡¯ll explain the details about the method advanced in this draft. 4.2. Processing at the Head Node In the network depicted above in figure 1-2, the bandwidth of tunnel 1 is changed into 9 M. RSVP-TE adopting MBB mechanism to reestablish tunnel encapsulate the requirement info of bandwidth£¨9 M£© to CSPF as well as the yang Expires: Apr. 2007 [Page 3] Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006 strict path bandwidth info of the old path£¨, Interface 1 of R2£©;Thus, CSPF formed a temporary TE info database and the temporary bandwidth of Interface 1 of R1 is 10M. The temporary bandwidth is only used for MBB reestablishment of Tunnel 1,and the interface bandwidth will recover to 4M after this path calculation. Then the optimum path£¨Interface 1 of R1->R2) that satisfies the condition of constraint-based bandwidth will be obtained. RSVP-TE will implement resource reservation along this path in SE mode till new tunnel establishes, and then break the old path. Thus, MBB mechanism Tunnel reestablishment successfully completes. 4.3. Processing at the Loose Node In the network depicted above in figure 2-2, the bandwidth of tunnel 2 is changed into 15M. RSVP-TE adopts MBB mechanism to reestablish tunnel. The head node R1 encapsulates the requirement info of tunnel 2 £¨15M,loose route R2£© to CSPF as well as the strict path bandwidth info of the old path£¨,Interface 1 of R2, R2, R4£©; as tunnel 2 designates R2 as Loose node, and the old path info in ERO contains Loose node R2, in order to obtain strict bandwidth info of the old path, The old path info£¨,Interface 1 of R4£© should be re-encapsulated to CSPF on R2. Thus, at Node R1 and R2,before CSPF calculating path, it distributes two temporary bandwidth 20M and 15M to corresponding interfaces(the interface 1 of R1 and interface 2 of R2). Then the optimum path that satisfies the condition of constraint-based bandwidth will be obtained.£¨See the path LSP2 showed in Fig. 2-2£©, RSVP-TE will implement resource reservation along this path till new tunnel establishes, and then tear down the old path. Thus, MBB mechanism Tunnel reestablishment successfully completes and the new path is constraint-based optimum one. 5. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Disclaimer of Validity This document and the information contained herein are provided on an yang Expires: Apr. 2007 [Page 4] Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 7. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [MPLS-ARCH] Rosen, Viswanathan, Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001. [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) - version 1 functional specification," RFC2205, September 1997. [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC3209, December 2001. 9.Author Information Yang Hui ZTE Inc. CHINA Email: yang.hui6@zte.com.cn Jiang Weilian ZTE Inc. CHINA Email: jiang.weilian@zte.com.cn Shen Xiaofeng ZTE Inc. CHINA Email: shen.xiaofeng@zte.com.cn Feng Jun ZTE Inc. CHINA Email: Feng.jun99@zte.com.cn yang Expires: Apr. 2007 [Page 5] Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006 Teng Zhimeng ZTE Inc. CHINA Email: teng.zhimeng@zte.com.cn yang Expires: Apr. 2007 [Page 6] Internet-Draft draft-yang-mpls-resouce-sharing-mbb-cspf-00 Oct. 2006