< draft-martin-isis-local-protect-cap-01.txt   draft-martin-isis-local-protect-cap-02.txt >
Network Working Group C. Martin, Ed. Network Working Group C. Martin, Ed.
Internet-Draft Verizon Internet-Draft iPath Technologies
Expires: April 24, 2005 A. Atlas, Ed. Expires: August 5, 2006 A. Atlas, Ed.
Google, Inc.
R. Torvi R. Torvi
Avici Systems, Inc. Avici Systems, Inc.
D. Fedyk D. Fedyk
Nortel Networks Nortel Networks
October 24, 2004 February 2006
U-turn Alternates for IP/LDP Fast-Reroute ISIS Extensions to support U-turn Alternates for IP/LDP Fast-Reroute
draft-martin-isis-local-protect-cap-01 draft-martin-isis-local-protect-cap-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2005. This Internet-Draft will expire on August 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies additional information that can inserted in This document specifies additional information that can inserted in
IS-IS LSPs to convey link capabilities that may be useful in certain 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 applications. In particular, an IS may convey that zero or more of
its links may be used by an upstream IS as an alternate, SPT-disjoint its links are explicit marked and/or implicit U-turn recipient
path to an arbitrary destination D. Additionally, an IS may convey capable, which may be described as capable of identifying traffic as
that zero or more of its links are explicit marked and/or implicit U-turn traffic and redirecting the traffic to a suitable alternate.
U-turn recipient capable, which may be described as capable of The immediate applicability for these two link capabilities is in
identifying traffic as U-turn traffic and redirecting the traffic to support of local protection, provided by a U-turn alternate, in the
a suitable alternate. The immediate applicability for these three event of a link and/or node failure while the IS-IS area is
link capabilities is in support of local protection, provided by a reconverging onto a new topology.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Signaling Link Capabilities . . . . . . . . . . . . . . . . . 3 2. Signaling Link Capabilities . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 7
1. Introduction 1. Introduction
Recently, an increasing interest in IGP traffic engineering using Recently, an increasing interest in IGP traffic engineering using
intelligent metric assignment has led to the development and intelligent metric assignment has led to the development and
deployment of techniques and methods to manage traffic distribution deployment of techniques and methods to manage traffic distribution
and capacity expansion without explicit source routing [ref]. The and capacity expansion without explicit source routing [ref]. The
fundamental premise to this approach is that it reduces operational fundamental premise to this approach is that it reduces operational
complexity by leveraging existing and well-understood routing methods complexity by leveraging existing and well-understood routing methods
to achieve effectivey the same ends as are possible using explicit to achieve effectivey the same ends as are possible using explicit
skipping to change at page 3, line 29 skipping to change at page 3, line 29
must reconverge. While fast IGP convergence is a topic of great must reconverge. While fast IGP convergence is a topic of great
interest, there is concern that a lower floor exists that, if interest, there is concern that a lower floor exists that, if
crossed, may have a negative impact on the stability of a network. crossed, may have a negative impact on the stability of a network.
As the network diameter and node degree increase, this floor As the network diameter and node degree increase, this floor
invariably raises in some proportionate manner - that is, the bigger invariably raises in some proportionate manner - that is, the bigger
the network, the slower the overall convergence. the network, the slower the overall convergence.
Depending on the application, restoration time-tolerance varies. For Depending on the application, restoration time-tolerance varies. For
real-time applications, it is certainly reasonable to expect real-time applications, it is certainly reasonable to expect
restoration times in the &lt50 msec range. The Fast Reroute method restoration times in the &lt50 msec range. The Fast Reroute method
specified in [RSVP-TE FRR] is one such mechanism to achieve these specified in [RFC4090] is one such mechanism to achieve these
restoration times, as a precomputed alternate path can service the restoration times, as a precomputed alternate path can service the
offered load that was destined for a failed link in a loop-free 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 fashion. However, this requires MPLS TE tunnels, which may not be a
desirable option for reasons mentioned above - namely, the increase desirable option for reasons mentioned above - namely, the increase
in complexity. in complexity.
[IPFRR], [FRAMEWORK], and [U-TURN] have proposed an alternative to [I-D.ietf-rtgwg-ipfrr-spec-base], [I-D.ietf-rtgwg-ipfrr-framework],
tunnel-based restoration in IP networks that is independent of MPLS. and [U-TURN] have proposed an alternative to tunnel-based restoration
Clearly, the ability to traffic engineer for bandwidth efficiency and in IP networks that is independent of MPLS. Clearly, the ability to
fast restoration are attractive to network operators that are opposed traffic engineer for bandwidth efficiency and fast restoration are
to deploying MPLS-based RSVP-TE. Nevertheless, the destination-based attractive to network operators that are opposed to deploying MPLS-
nature of the classical IP routing paradigm does not afford any based RSVP-TE. Nevertheless, the destination-based nature of the
guarantee that an alternate path around a failure is loop-free. classical IP routing paradigm does not afford any guarantee that an
[U-TURN] proposes such a mechanism, however, this mechanism requires alternate path around a failure is loop-free. [U-TURN] proposes such
additional information to be distributed via IS-IS flooding so as to a mechanism, however, this mechanism requires additional information
convey to routers in an area that the capability exists. to be distributed via IS-IS flooding so as to convey to routers in an
area that the capability exists.
2. Signaling Link Capabilities 2. Signaling Link Capabilities
[RFC3784] defines extensions to IS-IS as specified in [IS-IS] and [RFC3784] defines extensions to IS-IS as specified in [IS-IS] and
extended in [RFC1195] to allow for traffic engineering parameters to extended in [RFC1195] to allow for traffic engineering parameters to
be flooded throughout an area. TLV 22, the extended IS-reachability be flooded throughout an area. TLV 22, the extended IS-reachability
TLV is used to add additional information about an IS's connections 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 to other IS's, such as available bandwidth and color, by creating sub
TLVs within TLV 22. [ISIS-Link-Cap] introduces the notion of TLVs within TLV 22. [I-D.ietf-isis-link-attr] introduces the notion
extending TLV 22, sub-TLV 19 to signal an IS's capabilities. The of extending TLV 22, sub-TLV 19 to signal an IS's capabilities. The
initial capabilities proposed in [ISIS-Link-Cap] are orthogonal to initial capabilities proposed in [I-D.ietf-isis-link-attr] are
the two proposed here, as those proposed here do not relate orthogonal to the two proposed here; the "link excluded from local
explicitly to MPLS CSPF or RSVP-TE Fast Reroute. protection path" flag is also used for U-turn alternates [U-TURN].
This draft proposes the creation of three new flags in TLV 22, Sub This draft proposes the creation of two new flags in TLV 22, Sub TLV
TLV 19 for indicating an IS's ability to either break U-turns, act as 19 for indicating an IS's ability to be a U-turn recipient. The
an alternate, or both. The following bits are defined: 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, 0x6: Explicit Marked U-turn Recipient Capable: When this bit is set,
an IS can apply the explicitly marked U-turn packet identification an IS can apply the explicitly marked U-turn packet identification
method [U-TURN] to identify packets as U-turn packets and redirect method [U-TURN] to identify packets as U-turn packets and redirect
those U-turn packets towards an appropriate alternate next-hop, if those U-turn packets towards an appropriate alternate next-hop, if
such is available. A neighbor, which wishes to use this link as a 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 U-turn alternate next-hop, should mark traffic sent on the link
into a U-turn alternate. into a U-turn alternate.
0x7: Implicit U-turn Recipient Capable: When this bit is set, an IS 0x7: Implicit U-turn Recipient Capable: When this bit is set, an IS
can apply the implicit U-turn packet identification method can apply the implicit U-turn packet identification method
[U-TURN] to identify packets as U-turn packets and redirect those [U-TURN] to identify packets as U-turn packets and redirect those
U-turn packets towards an appropriate alternate next-hop, if such U-turn packets towards an appropriate alternate next-hop, if such
is available. A neighbor, which wishes to use this link as a is available. A neighbor, which wishes to use this link as a
U-turn alternate next-hop, should not mark traffic sent on the U-turn alternate next-hop, should not mark traffic sent on the
link into a U-turn alternate. link into a U-turn alternate.
3. Security Considerations 3. Security Considerations
This document does not introduce any new security issues. This document does not introduce any new security issues.
4 References 4. References
[FRAMEWORK] [I-D.ietf-isis-link-attr]
Shand, M., "IP Fast Reroute Framework", Vasseur, J. and S. Previdi, "Definition of an IS-IS Link
draft-ietf-rtgwg-ipfrr-framework-02.txt (work in Attribute sub-TLV", draft-ietf-isis-link-attr-01 (work in
progress), October 2004. progress), May 2005.
[IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute: [I-D.ietf-rtgwg-ipfrr-framework]
Loop-free Alternates", Shand, M. and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-spec-base-01.txt (work in draft-ietf-rtgwg-ipfrr-framework-05 (work in progress),
progress), October 2004. March 2006.
[I-D.ietf-rtgwg-ipfrr-spec-base]
Atlas, A. and A. Zinin, Ed., "Basic Specification for IP
Fast-Reroute: Loop-free Alternates",
draft-ietf-rtgwg-ipfrr-spec-base-05.txt (work in
progress), February 2006.
[IS-IS] "Intermediate System to Intermediate System Intra-Domain [IS-IS] "Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the Routing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Protocol for Providing the Connectionless-mode Network
Service (ISO 8473)", ISO 10589. 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 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
[RSVP-TE FRR] [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Pan, P., Swallow, G., Atlas, A., Gan, D., Vasseur, J., Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
Jork, M. and D. Cooper, "Fast Reroute Extensions to May 2005.
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", [U-TURN] Atlas, A., Ed., "U-turn Alternates for IP/LDP Fast-
draft-atlas-ip-local-protect-uturn-01.txt (work in Reroute", draft-atlas-ip-local-protect-uturn-03.txt (work
progress), October 2004. in progress), February 2006.
Authors' Addresses Authors' Addresses
Christian Martin (editor) Christian Martin (editor)
Verizon iPath Technologies
1880 Campus Commons Drive
Reston, VA 20191
USA
EMail: cmartin@verizon.com Email: chris@ipath.net
Alia K. Atlas (editor) Alia K. Atlas (editor)
Avici Systems, Inc. Google, Inc.
101 Billerica Avenue 1600 Amphitheatre Parkway
N. Billerica, MA 01862 Mountain View, CA 94043
USA USA
Phone: +1 978 964 2070 Email: akatlas@alum.mit.edu
EMail: aatlas@avici.com
Raveendra Torvi Raveendra Torvi
Avici Systems, Inc. Avici Systems, Inc.
101 Billerica Avenue 101 Billerica Avenue
N. Billerica, MA 01862 N. Billerica, MA 01862
USA USA
Phone: +1 978 964 2026 Phone: +1 978 964 2026
EMail: rtorvi@avici.com Email: rtorvi@avici.com
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park 600 Technology Park
Billerica, MA 01821 Billerica, MA 01821
USA USA
Phone: +1 978 288 3041 Phone: +1 978 288 3041
EMail: dwfedyk@nortelnetworks.com Email: dwfedyk@nortelnetworks.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 7, line 41 skipping to change at page 7, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 27 change blocks. 
89 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/