Internet Draft Alia Atlas (Avici Systems) Expires: August 2004 Raveendra Torvi (Avici Systems) Christian Martin (Verizon) Don Fedyk (Nortel) ISIS Extensions for Signaling Local Protection Capabilities draft-martin-isis-local-protect-cap-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 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 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 capable of breaking a U-turn, which may be described as a single-hop forwarding loop between two IS's. This means that a router can detect the presence of a forwarding loop by recognizing that traffic to a destination is being received from a neighbor to which it has forwarding state pointing back to the same neighbor for that destination. In such a situation, it will switch to a loop-free node-protecting alternate until new primary forwarding state has been installed, thus breaking the U- Atlas et al. [Page 1] Internet Draft August 2004 turn. Therefore, the immediate applicability for these two link capabilities is in support of local protection in the event of a link and/or node failure while the IS-IS area is reconverging onto a new topology. Contents 1 Introduction ................................................. 2 2 Signaling Link Capabilities .................................. 3 3 Interpretation for IP/LDP Local Protection ................... 3 4 Security Considerations ...................................... 4 5 Full Copyright Statement ..................................... 4 6 References ................................................... 5 7 Authors Information .......................................... 5 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 Atlas et al. [Page 2] Internet Draft August 2004 desirable option for reasons mentioned above - namely, the increase in complexity. [IP-LOCAL-PROTECT] has 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. [IP-LOCAL-PROTECT] 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 [ISIS-TE] defines extensions to IS-IS as specified in [10589] and extended in [1195] 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 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 Fast Reroute. This draft proposes the creation of two 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 that it can provide a loop-free, node-protecting alternate path, as defined in [IP-LOCAL-PROTECT]. 0x6: "Eligible U-Turn Recipient". When this bit is set, an IS is indicating that it can break a U-Turn by redirecting looping traffic to an alternate, as defined in [IP-LOCAL-PROTECT]. 3. Interpretation for IP/LDP Local Protection The IS-IS extensions described in this document define two bits which are relevant for determining the capabilities of a link in reference to IP/LDP Local Protection. If a link is usable as an alternate, then the IS's neighbors can assume that the router will have considered that link as an alternate next-hop. Atlas et al. [Page 3] Internet Draft August 2004 They are to be interpreted as follows: +-----------+-----------+------------+------------+ | | | Usable | Can | | Flag 0x5 | Flag 0x6 | As | Break | | | | Alternate? | U-Turns? | +-----------+-----------+------------+------------+ | 0 or unset|0 or unset | No | No | +-----------+-----------+------------+------------+ | 0 or unset| 1 | No | Yes | +-----------+-----------+------------+------------+ | 1 |0 or unset | Yes | No | +-----------+-----------+------------+------------+ | 1 | 1 | Yes | Yes | +-----------+-----------+------------+------------+ If a IS's link is usable as a U-Turn recipient, then the IS can determine if traffic received on that link is from the router's primary neighbor for that traffic and, if so, redirect it to the IS's alternate next-hop. If a IS's link is usable as a U- Turn recipient, then the IS's neighbor can use select for an alternate a U-Turn alternate which goes across that link to that IS. 4. Security Considerations This document does not introduce any new security issues. 5. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Atlas et al. [Page 4] Internet Draft August 2004 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 6. References [IS-IS] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589. [IS-IS-IP] Callon, R., RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [IS-IS-TE] H. Smit, T. Li, "Is-IS extensions for traffic engineering", draft-ietf-isis-traffic, work in progress. [ISIS-Link-Cap] JP Vasseur, S. Previdi, "IS-IS Link Attributes", draft-vasseur-isis-link-attr-00.txt, work in progress. [IP-LOCAL-PROTECT] A. Atlas, R. Torvi, G. Choudhury, C. Martin, B. Imhoff, and D. Fedyk, "IP/LDP Local Protection", draft-atlas-ip- local-protection-00.txt, February 2004, work-in-progress [RSVP-TE FRR] P. Pan, D. Gan, G. Swallow, JP Vasseur, D. Cooper, A. Atlas, and M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", work-in-progress draft-ietf-mpls-rsvp-lsp-fastreroute- 04.txt, February 2004 7. Authors Information Alia Atlas Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA email: aatlas@avici.com phone: +1 978 964 2070 Raveendra Torvi Avici Systems 101 Billerica Avenue N. Billerica, MA 01862 USA Atlas et al. [Page 5] Internet Draft August 2004 email: rtorvi@avici.com phone: +1 978 964 2026 Christian Martin Verizon Laboratories 1880 Campus Commons Dr. Reston, VA 20191 USA email: cmartin@verizon.com Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01450 email: dwfedyk@nortelnetworks.com phone: +1 978 288 3041 Atlas et al. [Page 6]