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]