Network Working Group C. Martin, Ed. Internet-Draft Verizon Expires: April 24, 2005 A. Atlas, Ed. R. Torvi Avici Systems, Inc. D. Fedyk Nortel Networks October 24, 2004 U-turn Alternates for IP/LDP Fast-Reroute draft-martin-isis-local-protect-cap-01 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document specifies additional information that can inserted in IS-IS LSPs to convey link capabilities that may be useful in certain applications. In particular, an IS may indicate that zero or more of Martin, et al. Expires April 24, 2005 [Page 1] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 its links may be used by an upstream IS as an alternate, SPT-disjoint path to an arbitrary destination D. Additionally, an IS may convey that zero or more of its links are explicit marked and/or implicit U-turn recipient capable, which may be described as capable of identifying traffic as U-turn traffic and redirecting the traffic to a suitable alternate. The immediate applicability for these three link capabilities is in support of local protection, provided by a U-turn alternate, in the event of a link and/or node failure while the IS-IS area is reconverging onto a new topology. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling Link Capabilities . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 7 Martin, et al. Expires April 24, 2005 [Page 2] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 1. Introduction Recently, an increasing interest in IGP traffic engineering using intelligent metric assignment has led to the development and deployment of techniques and methods to manage traffic distribution and capacity expansion without explicit source routing [ref]. The fundamental premise to this approach is that it reduces operational complexity by leveraging existing and well-understood routing methods to achieve effectivey the same ends as are possible using explicit source routing, without adding any new technology to the routing system. Many carriers have adopted this approach as a means to better manage bandwidth utilization and overall network efficiency. However, in many environments and under certain failure scenarios, the IGP TE approach does not allow for fast restoration, as the IGP must reconverge. While fast IGP convergence is a topic of great interest, there is concern that a lower floor exists that, if crossed, may have a negative impact on the stability of a network. As the network diameter and node degree increase, this floor invariably raises in some proportionate manner - that is, the bigger the network, the slower the overall convergence. Depending on the application, restoration time-tolerance varies. For real-time applications, it is certainly reasonable to expect restoration times in the <50 msec range. The Fast Reroute method specified in [RSVP-TE FRR] is one such mechanism to achieve these restoration times, as a precomputed alternate path can service the offered load that was destined for a failed link in a loop-free fashion. However, this requires MPLS TE tunnels, which may not be a desirable option for reasons mentioned above - namely, the increase in complexity. [IPFRR], [FRAMEWORK], and [U-TURN] have proposed an alternative to tunnel-based restoration in IP networks that is independent of MPLS. Clearly, the ability to traffic engineer for bandwidth efficiency and fast restoration are attractive to network operators that are opposed to deploying MPLS-based RSVP-TE. Nevertheless, the destination-based nature of the classical IP routing paradigm does not afford any guarantee that an alternate path around a failure is loop-free. [U-TURN] proposes such a mechanism, however, this mechanism requires additional information to be distributed via IS-IS flooding so as to convey to routers in an area that the capability exists. 2. Signaling Link Capabilities [RFC3784] defines extensions to IS-IS as specified in [IS-IS] and extended in [RFC1195] to allow for traffic engineering parameters to be flooded throughout an area. TLV 22, the extended IS-reachability TLV is used to add additional information about an IS's connections Martin, et al. Expires April 24, 2005 [Page 3] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 to other IS's, such as available bandwidth and color, by creating sub TLVs within TLV 22. [ISIS-Link-Cap] introduces the notion of extending TLV 22, sub-TLV 19 to signal an IS's capabilities. The initial capabilities proposed in [ISIS-Link-Cap] are orthogonal to the two proposed here, as those proposed here do not relate explicitly to MPLS CSPF or RSVP-TE Fast Reroute. This draft proposes the creation of three new flags in TLV 22, Sub TLV 19 for indicating an IS's ability to either break U-turns, act as an alternate, or both. The following bits are defined: 0x5: Eligible Alternate: When this bit is set, an IS is indicating to its neighbors that it considers whether the link can be used as an alternate next-hop. 0x6: Explicit Marked U-turn Recipient Capable: When this bit is set, an IS can apply the explicitly marked U-turn packet identification method [U-TURN] to identify packets as U-turn packets and redirect those U-turn packets towards an appropriate alternate next-hop, if such is available. A neighbor, which wishes to use this link as a U-turn alternate next-hop, should mark traffic sent on the link into a U-turn alternate. 0x7: Implicit U-turn Recipient Capable: When this bit is set, an IS can apply the implicit U-turn packet identification method [U-TURN] to identify packets as U-turn packets and redirect those U-turn packets towards an appropriate alternate next-hop, if such is available. A neighbor, which wishes to use this link as a U-turn alternate next-hop, should not mark traffic sent on the link into a U-turn alternate. 3. Security Considerations This document does not introduce any new security issues. 4 References [FRAMEWORK] Shand, M., "IP Fast Reroute Framework", draft-ietf-rtgwg-ipfrr-framework-02.txt (work in progress), October 2004. [IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute: Loop-free Alternates", draft-ietf-rtgwg-ipfrr-spec-base-01.txt (work in progress), October 2004. [IS-IS] "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Martin, et al. Expires April 24, 2005 [Page 4] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 Service (ISO 8473)", ISO 10589. [ISIS-Link-Cap] Vasseur, J. and S. Previdi, "Definition of an IS-IS Link Attribute sub-TLV", draft-vasseur-isis-link-attr-01.txt (work in progress), July 2004. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RSVP-TE FRR] Pan, P., Swallow, G., Atlas, A., Gan, D., Vasseur, J., Jork, M. and D. Cooper, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt (work in progress). [U-TURN] Atlas, A., "U-turn Alternates for IP/LDP Fast-Reroute", draft-atlas-ip-local-protect-uturn-01.txt (work in progress), October 2004. Authors' Addresses Christian Martin (editor) Verizon 1880 Campus Commons Drive Reston, VA 20191 USA EMail: cmartin@verizon.com Alia K. Atlas (editor) Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: +1 978 964 2070 EMail: aatlas@avici.com Martin, et al. Expires April 24, 2005 [Page 5] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 Raveendra Torvi Avici Systems, Inc. 101 Billerica Avenue N. Billerica, MA 01862 USA Phone: +1 978 964 2026 EMail: rtorvi@avici.com Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 USA Phone: +1 978 288 3041 EMail: dwfedyk@nortelnetworks.com Martin, et al. Expires April 24, 2005 [Page 6] Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004 Intellectual Property Statement 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. 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Martin, et al. Expires April 24, 2005 [Page 7]