Network Working Group C. Martin, Ed. Internet-Draft iPath Technologies Expires: August 5, 2006 A. Atlas, Ed. Google, Inc. R. Torvi Avici Systems, Inc. D. Fedyk Nortel Networks February 2006 ISIS Extensions to support U-turn Alternates for IP/LDP Fast-Reroute draft-martin-isis-local-protect-cap-02 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 August 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 convey that zero or more of Martin, et al. Expires August 5, 2006 [Page 1] Internet-Draft draft-atlas-ip-local-protect-uturn-02 February 2006 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 two 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 . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Martin, et al. Expires August 5, 2006 [Page 2] Internet-Draft draft-atlas-ip-local-protect-uturn-02 February 2006 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 [RFC4090] 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. [I-D.ietf-rtgwg-ipfrr-spec-base], [I-D.ietf-rtgwg-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 Martin, et al. Expires August 5, 2006 [Page 3] Internet-Draft draft-atlas-ip-local-protect-uturn-02 February 2006 be flooded throughout an area. TLV 22, the extended IS-reachability TLV is used to add additional information about an IS's connections to other IS's, such as available bandwidth and color, by creating sub TLVs within TLV 22. [I-D.ietf-isis-link-attr] introduces the notion of extending TLV 22, sub-TLV 19 to signal an IS's capabilities. The initial capabilities proposed in [I-D.ietf-isis-link-attr] are orthogonal to the two proposed here; the "link excluded from local protection path" flag is also used for U-turn alternates [U-TURN]. This draft proposes the creation of two new flags in TLV 22, Sub TLV 19 for indicating an IS's ability to be a U-turn recipient. The following bits are defined: 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 [I-D.ietf-isis-link-attr] Vasseur, J. and S. Previdi, "Definition of an IS-IS Link Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in progress), May 2005. [I-D.ietf-rtgwg-ipfrr-framework] Shand, M. and S. Bryant, "IP Fast Reroute Framework", draft-ietf-rtgwg-ipfrr-framework-05 (work in progress), March 2006. [I-D.ietf-rtgwg-ipfrr-spec-base] Atlas, A. and A. Zinin, Ed., "Basic Specification for IP Fast-Reroute: Loop-free Alternates", Martin, et al. Expires August 5, 2006 [Page 4] Internet-Draft draft-atlas-ip-local-protect-uturn-02 February 2006 draft-ietf-rtgwg-ipfrr-spec-base-05.txt (work in progress), February 2006. [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 Service (ISO 8473)", ISO 10589. [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. [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [U-TURN] Atlas, A., Ed., "U-turn Alternates for IP/LDP Fast- Reroute", draft-atlas-ip-local-protect-uturn-03.txt (work in progress), February 2006. Martin, et al. Expires August 5, 2006 [Page 5] Internet-Draft draft-atlas-ip-local-protect-uturn-02 February 2006 Authors' Addresses Christian Martin (editor) iPath Technologies Email: chris@ipath.net Alia K. Atlas (editor) Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA Email: akatlas@alum.mit.edu 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 August 5, 2006 [Page 6] Internet-Draft draft-atlas-ip-local-protect-uturn-02 February 2006 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 (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Martin, et al. Expires August 5, 2006 [Page 7]