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]