Network Working Group C. Martin, Ed.
Internet-Draft Verizon
Expires: April 24, 2005 A. Atlas, Ed.
R. Torvi
Avici Systems, Inc.
D. Fedyk
Nortel Networks
October 24, 2004
U-turn Alternates for IP/LDP Fast-Reroute
draft-martin-isis-local-protect-cap-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 April 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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
Martin, et al. Expires April 24, 2005 [Page 1]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
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 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 three
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 . . . . . . . . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 7
Martin, et al. Expires April 24, 2005 [Page 2]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
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
desirable option for reasons mentioned above - namely, the increase
in complexity.
[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
be flooded throughout an area. TLV 22, the extended IS-reachability
TLV is used to add additional information about an IS's connections
Martin, et al. Expires April 24, 2005 [Page 3]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
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 RSVP-TE Fast Reroute.
This draft proposes the creation of three 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 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,
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
[FRAMEWORK]
Shand, M., "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-02.txt (work in
progress), October 2004.
[IPFRR] Atlas, A., "Basic Specification for IP Fast-Reroute:
Loop-free Alternates",
draft-ietf-rtgwg-ipfrr-spec-base-01.txt (work in
progress), October 2004.
[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
Martin, et al. Expires April 24, 2005 [Page 4]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
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
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.
[RSVP-TE FRR]
Pan, P., Swallow, G., Atlas, A., Gan, D., Vasseur, J.,
Jork, M. and D. Cooper, "Fast Reroute Extensions to
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",
draft-atlas-ip-local-protect-uturn-01.txt (work in
progress), October 2004.
Authors' Addresses
Christian Martin (editor)
Verizon
1880 Campus Commons Drive
Reston, VA 20191
USA
EMail: cmartin@verizon.com
Alia K. Atlas (editor)
Avici Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: +1 978 964 2070
EMail: aatlas@avici.com
Martin, et al. Expires April 24, 2005 [Page 5]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
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 April 24, 2005 [Page 6]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
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 (2004). 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 April 24, 2005 [Page 7]