wdiff draft-atlas-ospf-local-protect-cap-01.txt draft-atlas-ospf-local-protect-cap-02.txt

Network Working Group A. Atlas, Ed.
Internet-Draft Google Inc.
Expires: August 5, 2006 R. Torvi
Avici Systems, Inc.
Expires: April 24, 2005 October 24, 2004
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-01.txt
draft-atlas-ospf-local-protect-cap-02

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 becomes
aware will be disclosed, in accordance with
RFC 3668. 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.

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. August 5, 2006.

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.

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 . . . . . . . . . . . .
Authors' Addresses . . . . . . . . . . . 5
Contributing Authors' Addresses . . . . . . . . . . . . . . . 5 6
Intellectual Property and Copyright Statements . . . . . . . . 7 . . 8

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 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
0-1 Reserved
2 Link excluded from local protection path
3-4 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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", as "link excluded from local protection
path", then the router's neighbors are informed that the router
considers whether that link can 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 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.

[RFC3630] Katz, D., Kompella, K. K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.

[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-01.txt Fast-
Reroute", draft-atlas-ip-local-protect-uturn-03.txt (work
in progress), October 2004.

Editor's Address February 2006.

Authors' Addresses

Alia K. Atlas (editor)
Avici Systems,
Google Inc.
101 Billerica Avenue
N. Billerica, MA 01862
1600 Amphitheatre Parkway
Mountain View, CA 94043
USA

Phone: +1 978 964 2070
EMail: aatlas@avici.com

Contributing Authors' Addresses

Email: akatlas@alum.mit.edu

Raveendra Torvi
Avici Systems Systems, Inc.
101 Billerica Avenue
N. Billerica, MA 01862
USA

Phone: +1 978 964 2026
EMail:
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
EMail: cmartin@verizon.com 420 3721
Email: gchoudhury@att.com

Brent Imhoff
LightCore
14567
Juniper Networks
1194 North Outer Forty Rd.
Chesterfield, MO 63017 Mathilda
Sunnyvale, CA 94089
USA

EMail: brent@lightcore.net

Phone: +1 314 880 1851 378 2571
Email: bimhoff@planetspork.com
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, MA 01821

EMail: dwfedyk@nortelnetworks.com
USA

Phone: +1 978 288 3041
Email: dwfedyk@nortelnetworks.com

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 (C) The Internet Society (2004). (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.