Network Working Group Cui Ying Internet Draft Jiang Weilian Feng Jun Expiration Date: Jul. 2007 Teng Zhimeng Zhang Chaofeng ZTE, Inc. Jan. 2007 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) Locally draft-cui-ccamp-te-loose-reopt-local-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. This Internet-Draft will expire on Jul , 2007. Copyright Notice Copyright (C) The Internet Society (2007). Abstract This document defines a mechanism for the local reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering (TE) LSPs signaled with RSVP-TE.This behavior of reoptimization is happened at loose node ,but not the ingress node . cui Expires: Jul. 2007 [Page 1] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 Table of Contents 1. Terminology...................................................3 1.1 Acronyms and Abbreviations................................3 2. Introduction..................................................3 3. Signaling extensions..........................................4 3.1. Extension Attributes Flags TLV...........................5 3.2. RRO IPv4/IPv6 Sub-object Flags...........................6 4. Mode of operation.............................................6 4.1. Head-end reoptimization control..........................6 4.1.1. process PATH message................................6 4.1.2. process RESV message................................7 4.2. Process after reoptimization triggers....................7 4.2.1. Process PATH message................................7 4.2.2. Process RESV message...............................8 4.2.3. Process PATH TEAR message...........................9 4.3. Process ERROR message ...................................9 5. Multicast local reoptimiaiton.................................9 6. Intellectual Property Statement...............................9 7. Disclaimer of Validity.......................................10 8. Full Copyright Statement.....................................10 9. References...................................................10 10.Author Information...........................................11 cui Expires: Jul. 2007 [Page 2] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 1. Terminology This document follows the nomenclature of the MPLS Architecture defined in [RFC3031] and [LOOSE-REOPT]. 1.1 Acronyms and Abbreviations This document follows the nomenclature defined in [LOOSE-REOPT] New add : local reoptimization: optimize a tunnel by loose node, not the ingress nodes. loose area: the traffic engineering area between loose nodes. 2. Introduction This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching) Traffic Engineering LSPs signaled with RSVP-TE (see [RFC3209] and [RFC3473]). A loosely routed LSP , defined in [LOOSE-REOPT], that does not contain a full explicit route identifying each LSR along the path of the LSP at the time it is signaled by the ingress LSR. Such an LSP is signaled with no ERO, with an ERO that contains at least one loose hop, or with an ERO that contains an abstract node that is not a simple abstract node (that is, an abstract node that identifies more than one LSR). Although, IETF provides a method to solve the reoptimization of loosely routed TE LSP, [LOOSE-REOPT], which is when the loose node find the more optimal path , it will use notify message to inform the TE LSP head-end, then TE LSP head-end use the method of ¡°make before break¡± to create a new tunnel. when the new tunnel is created successfully,then TE LSP head-end will delete the old path. But this method has some problems. Firstly, if loose node is far away form TE LSP head-end , there are some middle nodes between TE LSP head-end and the loose node, and the signal of reoptimization will spend long time, at the same time, the middle nodes which do not have more optimal path have to compute path also, and this will increase the signaling load of the whole network. Secondly, the loose node needs to inform the ingress LSR that the tunnel needs to be re-optimized, but the notify message may be lost. Although using reliable message is a good idea, but all of the nodes on the tunnel must support reliable message. So, based on these problems, this document suggests loose node re-optimization method locally, which can resolve these problems properly. This document supposes that the readers of the document are familiar cui Expires: Jul. 2007 [Page 3] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 whth [LOOSE-REOPT], and in order to preserve integrity , the document cite narration from [LOOSE-REOPT]. An example of an explicit loosely routed TE LSP signaling. <---area 1--><-area 0--><-area 2-> R1---R2----R3---R6 R8---R10 | | | / | \ | | | | / | \ | | | | / | \| R4---------R5---R7----R9---R11 Assumptions - R3, R5, R8 and R9 are ABRs - The path of an inter-area TE LSP T1 from R1 (head-end LSR) to R11 (tail-end LSR) is defined on R1 as the following loosely routed path: R1-R3(loose)-R8(loose)-R11(loose). R3, R8 and R11 are defined as loose hops. - the loose area : from R3 to R8 This document provides a method of local reoptimization of loose nodes will affect few nodes. When a more optimal path appear at loose area (between R3 and R8), messages of reoptimization will only signal between loose nodes, for example R3 and R8, that is, upstream node(R3)will signal messages of reoptimization to the downstream loose node(R8), and the downsteam loose node will not send message to other nodes,and the ingress node (R1) does not need to do extra work. This document provides a method of using methord of PATH refresh to implement roptimization, not using the method of ¡°make-before break".This method will also decrease the work of the head-end. The mechanism which provided by this document is not give a denial to the methord of [LOOSE-REOPT], it can be supplement of [LOOSE-REOPT]. The loose node can choice the local reoptimization, and also can use the mothord in [LOOSE-REOPT]. 3. Signaling extensions A new flag in the RECORD_ROUTE object and new value sub-codes in the attributes flags TLV are proposed in this document.(to be assigned by IANA). 3.1. Extension Attributes Flags TLV cui Expires: Jul. 2007 [Page 4] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type indicates the Attributes Flags TLV Attributes Flags TLV Length The length of the Value field in bytes. Thus, if no Value field is present the Length field contains the value zero. Each Value field must be zero padded at the end to take it up to a four byte boundary -- the padding is not included in the length so that a one byte value would be encoded in an eight byte TLV with Length field set to one. Value Local reoptimization Desire 0x01 This value permits transit routers to use a local reoptimization mechanism .When a more optimal path is detected , loose node may optimize tunnel between the loose node locally. The transit routers which are loose node will process this value. If the loose node which not supporting local reoptimization, must ignore this value, else must express in the RERORD_REROUTE object. This value must appear only in the PATH message, and only loose transit nodes have to process this value. Local reoptimization in use 0x02 This value indicates that the message with this value,is the local reoptimization message, and the node which supporting local reoptimization must process the message correctly. This value can appear in the messages by RFC2205 defined. This TLV may appear in the LSP_ATTRIBUTES,and may appear in the LSP_REQUIRED_ATTRIBUTES,but it is not suggested to appear in both at the same time.This document suggests that cui Expires: Jul. 2007 [Page 5] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 because local reoptimization is not mandatory function, so the value of 0x01 should not appear in the LSP_REQUIRED_ATTRIBUTES. In the local reoptimization , the tunnel ingress indicates that the tunnel need local reoptimization using the value 0x01 of LSP_REQUIRED_ATTRIBUTES in PATH message, the transit nodes record information of local reoptimization, then response to the ingress node that it support this function. 3.2. RRO IPv4/IPv6 Sub-object Flags Extend RRO IPv4/IPv6 sub-objectFlags,new add Local reoptimization in use 0x80 This new flag indicates that the node which has the IP address Supports local reoptimization function. When the node discovers more optimal path ,it will reoptimize the tunnel which with Local reoptimization Desire value in the loose area. 4. Mode of operation 4.1. Head-end reoptimization control The tunnel ingress may indicate that this tunnel permit reoptimization locally , by user config.If the tunnel need local reoptimization, the ingress must set Local reoptimization Desire value in PATH message. This value may appear in the Attributes Flags TLV of LSP_ATTRIBUTES, or in the LSP_REQUIRED_ATTRIBUTES . This document suggests that the value should be included in the LSP_ATTRIBUTES. If one of the two objects has the value in the sub TLV,it indicates that the tunnel need to be reoptimized locally , when receiving PATH message. 4.1.1. process PATH message When receiving the PATH message from upstream node,The transit nodes should decide that if the tunnel permit to local reoptimization. If the tunnel has Local reoptimization Desire value in the PATH message, and at the same time , if the transit node is loose route node of this tunnel, that means the transit node can reoptimize this tunnel locally but not reoptimize this tunnel by the ingress node. Because Local reoptimization Desire may appper in the LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES,so the process of the PATH message must abide by RFC4420. cui Expires: Jul. 2007 [Page 6] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 4.1.2. process RESV message When receiving RESV message from the downstream node,the transit nodes should set Local reoptimization in use value in the RRO. Then the ingress can know the information about where can support local reoptimization. 4.2. Process after reoptimization triggers When a new TE link appears or bandwidth of TE link increases, this indicates that maybe a better path appears in the loose area. This information may be flooded in the traffic engineering area by IGP protocols. The traffic engineering area may be a area in the OSPF or a level in the ISIS. The loose node gets that information from IGP, if the loose node supports the method of local reoptimizaiton, it will re-compute tunnel through it using CSPF .The loose node computes the path which the destination may be egress of the tunnel or may be another loose node. If CSPF compute successfully , loose node compares the new path with the old path which is using by the tunnel. If the new path is more optimal than the old one ,the loose node will signal the tunnel and complete reoptimization. If the loose node does not support the local reoptimizaiton, this document suggests that the loose node should send information to the tunnel ingress. 4.2.1. Process PATH message Loose node sends the new PATH message,and some objects in the PATH message must be modified , the objects are ERO,HOP object and add new object of LSP_REQUIRED_ATTRIBUTES. LSP_REQUIRED_ATTRIBUTES must be include in the PATH message. If PSB has saved SP_REQUIRED_ATTRIBUTES of the old path,then the new path must not add this object again. The LSP_REQUIRED_ATTRIBUTES must include Attributes Flags TLV, and set value of ¡°Local reoptimization in use¡± in this sub-TLV. These new strict routes which computed by CSPF are added into the new ERO, and the old explicit route will be copied in the end of the new ERO. The old explicit route is the rest ERO subobjects which delete the explicit subobjects before the destination loose node , which saving in loose node ¡®s RSB who initiates the local reoptimization. When receiving the new PATH message , the transit nodes in the loose area must decide if there have PSB corresponding to the new PATH message. If there do not have corresponding PSB, then the transit nodes must create a new PSB for the new coming PATH message, save PATH message information, and express that the new coming message is cui Expires: Jul. 2007 [Page 7] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 the message of optimization, and send PATH message to downstream node according to ERO; if there have PSB, then transit nodes MUST save the HOP and new ERO of the new coming PATH message, at the same time, mark reoptimizition flag to the these objects, but don¡¯t delete the old objects, and send PATH message to downstream nodtes according to the new ERO. The destination of the local reoptimizaiton receives the new PATH message, it knows that this PATH message is the reoptimization message by ¡°the Local reoptimization in use¡± value and compare ERO subjects which get away from it with the old ERO, it will find that the ERO in the new coming message is the same with local old ERO, and then does not send the PATH message to downstream nodes. The destination will send RESV message along the path of new PATH message ,and the RESV message will be with the ¡° the Local reoptimization in use¡± value in the LSP_REQUIRED_ATTRIBUTES. This does not affect the regular refresh process of old path. If the transit nodes don not support the vale of ¡°Local reoptimization in use¡±, the PATH ERROR message must be send to the local reoptimization ingress, and drop the new coming PATH message. The reoptimization ingress, which is signal the reoptimization message, receives the PATH ERROR message, should not process local reoptimization any more, it can make choice to send information to the tunnel ingress or just keep silence. 4.2.2. Process RESV message When receiving RESV message with ¡°the Local reoptimization in use¡± value in the LSP_REQUIRED_ATTRIBUTES, the transit node knows that the RESV message is the local reoptimization message but not regular RESV refresh message. When processing the RESV message, because the message is the local reoptimization message, the transit node should send RESV message along the path of local reoptimization . In this document , if the RESV message of local reoptimization has the same outgoing interface with old RESV message of the tunnel, and the style of tunnel is SE style, the reservation must to be do once. When ingress node of local reoptimization receives the first coming RESV message, it switches the traffic on the new path ,and then sends PATH TEAR message with the ¡°the Local reoptimization in use¡± value in the LSP_ATTRIBUTES. If errors are to be found when processing the RESV message, the node MUST send RESV ERROR message, and drop the RESV message. 4.2.3 Process PATH TEAR message cui Expires: Jul. 2007 [Page 8] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 When the new PATH TEAR is created successfully, along the old path, loose node send this message with the ¡°the Local reoptimization in use¡± value in the LSP_ATTRIBUTES. After receiving the PATH TEAR message, the transit node should finds PSB or other information according to the PATH TEAR message. If PSB exists and the PSB does not have reoptimizaiton information, the transit node MUST deletes the PSB as RFC3209 requires; if PSB exists and the PSB has reoptimization information, the node must replace the ERO and HOP of local reoptimzation with old one, HOP object need to that also. If receiving the PATH TEAR message with no local reoptimization value, the node must process the incoming message normally and at the same time it must send PATH TEAR message out along reoptimization path, which with the ¡°the Local reoptimization in use¡± value in the LSP_ATTRIBUTES. 4.3 Process ERROR message The ingress node of local reoptimization, which signaling reoptimization message, receives the PATH error with local reotpimization flag, and should knows that the reoptimzation fail, then should send PATH TEAR message to delete the path created by local reoptimization. For the RESV ERROR message with local reotpimization flag, the destination of local reoptimization should send PATH ERROR message to the ingress of local reoptimizaiton. 5. Multicast local reoptimiaiton Now , there is not think about it clearly ,will be study in the future . 6. 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. cui Expires: Jul. 2007 [Page 9] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 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. 7. Disclaimer of Validity This document and the information contained herein are provided on an "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. 8. Full Copyright Statement Copyright (C) The Internet Society (2007). 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. 9. 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. [LOOSE-REOPT] JP. Vasseur, Ed.,"Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP)",draft-ietf-ccamp-loose-path-reopt. 10.Author Information Cui Ying ZTE Inc. cui Expires: Jul. 2007 [Page 10] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-00 Jan.2007 CHINA Email: cui.ying@zte.com.cn Jiang Weilian ZTE Inc. CHINA Email: jiang.weilian@zte.com.cn Feng Jun ZTE Inc. CHINA Email: Feng.jun99@zte.com.cn Teng Zhimeng ZTE Inc. CHINA Email: Teng.zhimeng@zte.com.cn Zhang Chaofeng ZTE Inc. CHINA Email: Zhang.chaofeng@zte.com.cn cui Expires: Jul. 2007 [Page 11]