Network Working Group Cui Ying Internet Draft Jiang Weilian Feng Jun Expiration Date: Jan. 2008 Teng Zhimeng Zhang Chaofeng ZTE, Inc. Jul. 2007 Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) Locally draft-cui-ccamp-te-loose-reopt-local-01 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 Jan , 2008. 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: Jan. 2008 [Page 1] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.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...............................9 4.2.3. Process PATH TEAR message...........................9 4.3. Process ERROR message ..................................10 5. Security Considerations .....................................11 6. IANA Considerations .........................................11 7. Acknowledgements.............................................11 8. References...................................................11 8.1. Normative References...................................11 8.2. Informative References.................................11 Author's Addresses..............................................11 Intellectual Property Statement.................................13 Full Copyright Statement........................................13 Intellectual Property...........................................13 cui Expires: Jan. 2008 [Page 2] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2008 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 finds 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: Jan. 2008 [Page 3] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 with [LOOSE-REOPT], and in order to preserve integrity, the document cites 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 compareing with [LOOSE-REOPT]. When a more optimal path appears 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 more extra work. The ingress node may using RROs to record the new path which the tunnel is passing, and show it to the user. 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 works 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: Jan. 2008 [Page 4] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.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 because local reoptimization is not mandatory function, so the value of 0x01 should not appear in the cui Expires: Jan. 2008 [Page 5] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 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. Local reoptimization delete 0x04 This value indicates that the message with this value, is the local reoptimization message, and the node which supporting local reoptimization must should end the local reptimization process, for example, delete the PSB or the RSB save in local node. The value should appear in the PATH TEAR or RESV TEAR messages of the local reoptimization. 3.2. RRO IPv4/IPv6 Sub-object Flags Extend RRO IPv4/IPv6 sub-objectFlags, new add Local reoptimization support 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 indicates that this tunnel permit reoptimization locally, by user config. If the tunnel need local reoptimization, the ingress must set "Local reoptimization desire" value in the PATH message. This value of "Local reoptimization desire" 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 cui Expires: Jan. 2008 [Page 6] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2008 should decide that if the tunnel is permited 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 the value of "Local reoptimization vesire" may appper in the Attributes Flags TLV of LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTES, so the process of the PATH message must abide by RFC4420. 4.1.2. process RESV message When receiving RESV message from the downstream node,the transit nodes should set the value of "Local reoptimization surpport" in the RRO. Then the ingress can know the information about where can support local reoptimization, that means which nodes have the ability to reoptimize the tunnel locally. 4.2. Processing after reoptimization triggers When a new TE link appears or bandwidth of TE link increases, this indicates that maybe a shorter 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 by 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 or reoptimize the tunnel by using the methord in the [LOOSE-REOPT]. The transit nodes in the loose area will maintain the regular refresh for the old path when processint the local reoptimization message. 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 cui Expires: Jan. 2008 [Page 7] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 new object of LSP_REQUIRED_ATTRIBUTES. LSP_REQUIRED_ATTRIBUTES must be include in the PATH message. If PSB has saved LSP_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. The loose node computes the new explicit routes between the loose area, that means that the destination is not the egress node but loose node in the path. These new strict routes which computed by CSPF are added into the new ERO, that means that the new ERO only include the strict routes between the loose area and the last ERO subobjects MUST be the destination loose node which should be set loose node. The old explicit routes will be save the the loose node and not be deleted until the reoptimation of the tunnel success. The loose node may be modify the HOP object. If the new path has new interface compare the old one, HOP object should be modified. And the loose node should save the new objects for using local reoptimation templately. 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 does 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 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 it will find that the last ERO subojects in the ERO subobjects in the new coming message is same with itself adress . Then the destination loose node will not send the PATH message to downstream nodes. The destination loose node will send RESV message along the path of new PATH message , and the RESV message MUST set the "Local reoptimization in use" value in the LSP_REQUIRED_ATTRIBUTES. If the transit nodes don't not support the vale of "Local reoptimization in use", the PATH ERROR message MUST be sent 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 cui Expires: Jan. 2008 [Page 8] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 reoptimization any more, it can make choice to send information to the tunnel ingress or just keep silence or use the methord of reoptimation in the [LOOSE-REOPT]. 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 in the loose area 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 TEAR message The ingress node of local reoptimization will send new PATH TEAR message to downstream nodes when it receives the RESV message from the new path. It can find the value of "the Local reoptimization in use" in the Attributes Flags TLV of LSP_REQUIRED_ATTRIBUTES from the new come RESV message. Then it will send new PATH TEAR message to delete the old path. When the new PATH TEAR message is created successfully, send along the old path, ingress node of local reoptimization send this message with the "the Local reoptimization in use" value in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES which depend on the old PSB save which one. If the ingress node receives the RESV TEAR message with the value of "the Local reoptimization in use", it will send the PATH TEAR messassage along the new path of reoptimization, MUST set the value "the Local reoptimization delete " in the Attributes Flags TLV of LSP_REQUIRED_ATTRIBUTES. After receiving the PATH TEAR message, the transit node should decide which path the new coming PATH TEAR message want to delete, that is the old one or the new reoptimizate one. If the PSB dest not exist, the transit node should drop the message as RFC3209 requires. If cui Expires: Jan. 2008 [Page 9] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 the PSB exists, then the transit node other information according to the PATH TEAR message. If the PSB has reoptimization information, and the same time, the transit nodes find the value of "the Local reoptimization in use", then it will send the PATH TEAR message of local reoptimization along the old path ; else if it find the value of "the Local reoptimization delete", it will send the PATH TEAR message along the new path. Then the transit node must replace the ERO and HOP of local reoptimzation with old one, HOP object may be to that also. If PSB has not reoptimization information, and the same time, the transit node find the value of "the Local reoptimization delete", it should drop the message. The transit node with no reoptimization information should process the PATH TEAR message as RFC3209 defines. The destination node of local reoptimization receive the PATH TEAR message with "the Local reoptimization in use" value or "the Local reoptimization delete", it MUST not send the PATH TEAR message to downsteam nodes. If receiving the PATH TEAR message with no value of "local reoptimization in use" or "the Local reoptimization delete" value, the nodes must process the incoming message normally. At the same time, the node which is has the information of local reoptimization MUST send PATH TEAR message out along reoptimization path, which with the the "Local reoptimization delete" value in the LSP_REQUIRED_ATTRIBUTES. If receiving the RESV TEAR message with reoptimation, the destionation of the local reoptiomization should send PATH ERROR message with "local reoptimization in use " along the new path to the ingress of the local reoptimization. the ingress of the local reoptimization. 4.3 Process ERROR message The ingress node of local reoptimization, which signaling reoptimization message, receives the PATH ERROR message with "local reoptimization in use ", and should knows that the reoptimzation fail, then should send PATH TEAR message to delete the path created by local reoptimization along the new path with the value of "local reoptimization delete". 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 with "local reoptimization in use ". cui Expires: Jan. 2008 [Page 10] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 5. Security Considerations This doucment does not add abnormal security question. 6. IANA Considerations This document defines new flag in the Attributes Flags TLV and RRO IPv4/IPv6 Sub-object Flags in the Signaling extensions.These new flags needs to be registered by the IANA . 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC2119. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC2434. [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)", RFC4736, November 2006. 8.2. Informative References Authors' Addresses Cui Ying ZTE Inc. CHINA Email: cui.ying@zte.com.cn Jiang Weilian cui Expires: Jan. 2008 [Page 11] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 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: Jan. 2008 [Page 12] Internet-Draft draft-cui-ccamp-te-loose-reopt-local-01 Jul.2007 Full Copyright Statement Copyright (C) The IETF Trust (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. 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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). cui Expires: Jan. 2008 [Page 13]