Network Working Group A. Atlas, Ed.
Internet-Draft Avici Systems, Inc.
Expires: April 24, 2005 October 24, 2004
U-turn Alternates for IP/LDP Fast-Reroute
draft-atlas-ospf-local-protect-cap-01.txt
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 proposes an extension to OSPF Version 2 for advertising
link capabilities using the extensions defined for traffic
engineering. The link capabilities are defined there for future
extensibility. To support the signaling requirements of U-turn
alternates for IP Fast-Reroute, this document defines three bits in
the proposed link capabilities extension.
Atlas Expires April 24, 2005 [Page 1]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Link Capabilities sub-TLV . . . . . . . . . . . . . . . . . . 3
3. Interpretation for U-turn Alternates for IP Fast-Reroute . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 5
Contributing Authors' Addresses . . . . . . . . . . . . . . . 5
Intellectual Property and Copyright Statements . . . . . . . . 7
Atlas Expires April 24, 2005 [Page 2]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
1. Introduction
The motivations for an extension to OSPF version 2 to allow
advertising link capabilities is to both allow the signaling required
by [U-TURN] and to provide for future extensibility.
[RFC3630] specifies OSPFv2 Traffic Engineering extensions for
carrying link attributes, via a new Link TLV which is carried in the
TE LSA. The Link TLV comprises of several sub-TLVs characterizing
the links. Among those sub-TLVs are the Link ID and Link Type sub-
TLVs, which are the only mandatory sub-TLVs. This is the set of
information that is necessary to associated advertised link
capabilities to the specific link. To avoid potentially unnecessary
redundant advertisement of the Link ID and Link Type, in the event
that a router needs to support signaling for both TE and link
capabilities, this document proposes adding a Link Capabilities
sub-TLV to the Link TLV.
The Link Capabilities sub-TLV is defined and three bits are
identified to support the signaling required by [U-TURN].
2. Link Capabilities sub-TLV
A new "Link Capabilities" sub-TLV is defined here to be carried in
the "Link" TLV which uses the TE LSA [RFC3630]. The Link
Capabilities field contains 32 flags, each indicating a different
link capability. The following flags are defined:
Bit Capability
0-3 Reserved
4 Eligible Alternate
5 Explicit Marked U-Turn Recipient Capable
6 Implicit U-Turn Recipient Capable
7-31 Future assignments
Following is the format for Link-ID sub TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Atlas Expires April 24, 2005 [Page 3]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
3. Interpretation for U-turn Alternates for IP Fast-Reroute
The OSPFv2 extensions described in this document define three bits
which are relevant for determining the capabilities of a link in
reference to U-turn Alternates for IP/LDP Fast-Reroute.
If a link is advertised with a capability of "Eligible Alternate",
then the router's neighbors are informed that the router considers
whether that link can be used as an alternate next-hop.
If a router's link is advertised as Implicit U-turn Recipient
capable, then the advertising router 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.
If a router's link is advertised as Explicit Marked U-turn Recipient
capable, then the advertising router 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.
4. IANA Considerations
A new sub-TLV in the Link TLV will need to be assigned by IANA; this
is requested to be type 10, which is to be assigned via Standards
Action [RFC3630]. The remaining bits in the Link Capabilities
sub-TLV will need to be assigned by IANA.
5. Security Considerations
This document does not introduce any new security issues.
6 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.
Atlas Expires April 24, 2005 [Page 4]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
[RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[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.
Editor's Address
Alia K. Atlas (editor)
Avici Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: +1 978 964 2070
EMail: aatlas@avici.com
Contributing Authors' Addresses
Raveendra Torvi
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
USA
Phone: +1 978 964 2026
EMail: rtorvi@avici.com
Gagan Choudhury
AT&T
Room D5-3C21
200 Laurel Avenue
Middletown, NJ 07748
USA
EMail: gchoudhury@att.com
Phone: +1 732 420-3721
Christian Martin
Verizon
1880 Campus Commons Drive
Reston, VA 20191
Atlas Expires April 24, 2005 [Page 5]
Internet-Draft draft-atlas-ip-local-protect-uturn-01 October 2004
EMail: cmartin@verizon.com
Brent Imhoff
LightCore
14567 North Outer Forty Rd.
Chesterfield, MO 63017
USA
EMail: brent@lightcore.net
Phone: +1 314 880 1851
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, MA 01821
EMail: dwfedyk@nortelnetworks.com
Phone: +1 978 288 3041
Atlas 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.
Atlas Expires April 24, 2005 [Page 7]