Network Working Group A. Atlas, Ed.
Internet-Draft Google Inc.
Expires: August 5, 2006 R. Torvi
Avici Systems, Inc.
G. Choudhury
AT&T
Juniper Networks
D. Fedyk
Nortel Networks
February 2006
OSPFv2 Extensions for Link Capabilities to support U-turn Alternates for
IP/LDP Fast-Reroute
draft-atlas-ospf-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 proposes an extension to OSPF Version 2 for advertising
Atlas, et al. Expires August 5, 2006 [Page 1]
Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006
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.
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Atlas, et al. Expires August 5, 2006 [Page 2]
Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006
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-1 Reserved
2 Link excluded from local protection path
3-4 Reserved
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, et al. Expires August 5, 2006 [Page 3]
Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006
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 as "link excluded from local protection
path", then the router's neighbors are informed that the router
considers whether that link cannot be used as an alternate next-hop.
For other applications, such as RSVP-TE FRR [RFC4090], this means the
link SHOULD not be included in any computation of a repair path by
any other router in the routing area.
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
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
Atlas, et al. Expires August 5, 2006 [Page 4]
Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006
[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.
Atlas, et al. Expires August 5, 2006 [Page 5]
Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006
Authors' Addresses
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
Gagan Choudhury
AT&T
Room D5-3C21
200 Laurel Avenue
Middletown, NJ 07748
USA
Phone: +1 732 420 3721
Email: gchoudhury@att.com
Brent Imhoff
Juniper Networks
1194 North Mathilda
Sunnyvale, CA 94089
USA
Phone: +1 314 378 2571
Email: bimhoff@planetspork.com
Atlas, et al. Expires August 5, 2006 [Page 6]
Internet-Draft draft-atlas-ospf-local-protect-cap-02 February 2006
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, MA 01821
USA
Phone: +1 978 288 3041
Email: dwfedyk@nortelnetworks.com
Atlas, et al. Expires August 5, 2006 [Page 7]
Internet-Draft draft-atlas-ospf-local-protect-cap-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.
Atlas, et al. Expires August 5, 2006 [Page 8]