Internet Draft Alia Atlas (Avici Systems)
Expires: August 2004 Raveendra Torvi (Avici Systems)
Gagan Choudhury (AT&T)
Christian Martin (Verizon)
Brent Imhoff (Wiltel)
Don Fedyk (Nortel)
OSPFv2 Extensions for Link Capabilities and IP/LDP Local Protection
draft-atlas-ospf-local-protect-cap-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
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 IP Local Protection [IP-
LOCAL-PROTECT], this document defines two bits in the proposed link
capabilities extension. Additionally, this document reserves a bit
in the Router Capabilities TLV defined in [OSPF-RTR-CAP].
This document specifies additional information that can inserted in
Atlas et al. [Page 1]
Internet Draft August 2004
OSPF LSAs to convey link capabilities that may be useful in certain
applications. In particular, a router may indicate that zero or more
of its links may be used by an upstream router as an alternate, SPT-
disjoint path to an arbitrary destination D. Additionally, a router
may convey that zero or more of its links are capable of breaking a
U-turn, which may be described as a single-hop forwarding loop
between two router's. This means that a router can detect the
presence of a forwarding loop by recognizing that traffic to a
destination is being received from a neighbor to which it has
forwarding state pointing back to the same neighbor for that
destination. In such a situation, it will switch to a loop-free
node-protecting alternate until new primary forwarding state has been
installed, thus breaking the U-turn. Therefore, the immediate
applicability for these two link capabilities is in support of local
protection in the event of a link and/or node failure while the OSPF
area is reconverging onto a new topology.
Contents
1 Introduction ................................................. 2
2 Link Capabilities sub-TLV .................................... 2
3 IP/LDP Local Protect Router Capability ....................... 3
4 Interpretation for IP/LDP Local Protection ................... 3
5 IANA Considerations .......................................... 4
6 Security Considerations ...................................... 4
7 Full Copyright Statement ..................................... 4
8 References ................................................... 5
9 Authors Information .......................................... 5
1. Introduction
The motivations for an extension to OSPF version 2 to allow
advertising link capabilities is to both allow the signaling required
by [IP-LOCAL-PROTECT] and to provide for future extensibility.
[RFC 3630] 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-
Atlas et al. [Page 2]
Internet Draft August 2004
TLV to the Link TLV.
The Link Capabilities sub-TLV is defined and two bits are identified
to support the signaling required by [IP-LOCAL-PROTECT].
Additionally, this document suggests reserving bit 10 from the Router
Capabilities TLV. The interpretation of these bits as they relate to
[IP-LOCAL-PROTECT] is explained in Section 4.
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 [RFC 3630].
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 Eligible U-Turn Recipient
6-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ca
3. IP/LDP Local Protect Router Capability
This document reserves bit 10, which is currently unassigned [OSPF-
RTR-CAP], to indicate the capability for IP/LDP Local Protection
[IP-LOCAL-PROTECT], with an interpretation as described in Section 4.
4. Interpretation for IP/LDP Local Protection
The OSPFv2 extensions described in this document define three bits
which are relevant for determining the capabilities of a link in
reference to IP/LDP Local Protection. The Link Capabilities
advertised in the TE LSA and the Router Capabilities in "Router
Information" LSA are independent, i.e. a router may send Link
Atlas et al. [Page 3]
Internet Draft August 2004
Capabilities without including Router Capabilities and vice versa.
They are to be interpreted as follows:
+------------------+-----------------+------------+
|IP/LDP Local | Eligible | Usable |
|Protect Router | Alternate | as |
|Capability | Link Capability | Alternate? |
+------------------+-----------------+------------+
| 0 or Not Present | 0 or Not Present| NO |
+------------------+-----------------+------------+
| 0 or Not Present | 1 | YES |
+------------------+-----------------+------------+
| 1 | 0 or Not Present| NO |
+------------------+-----------------+------------+
| 1 | 1 | YES |
+------------------+-----------------+------------+
If a link is usable as an alternate, then the router's neighbors can
assume that the router will have considered that link as an alternate
next-hop.
+------------------+-----------------+------------+
|IP/LDP Local | Eligible U-Turn | Usable |
|Protect Router | Recipient | as U-Turn |
|Capability | Link Capability | Recipient? |
+------------------+-----------------+------------+
| 0 or Not Present | 0 or Not Present| NO |
+------------------+-----------------+------------+
| 0 or Not Present | 1 | YES |
+------------------+-----------------+------------+
| 1 | 0 or Not Present| NO |
+------------------+-----------------+------------+
| 1 | 1 | YES |
+------------------+-----------------+------------+
If a router's link is usable as a U-Turn recipient, then the router
can determine if traffic received on that link is from the router's
primary neighbor for that traffic and, if so, redirect it to the
router's alternate next-hop. If a router's link is usable as a U-
Turn recipient, then the router's neighbor can use select for an
alternate a U-Turn alternate which goes across that link to that
router. The following picture may clarify this. If B indicates that
it can be a U-Turn Recipient on the link from A to B, then if A can
use the link from A to B as an alternate, A can use the link as a U-
Turn alternate, if appropriate.
Atlas et al. [Page 4]
Internet Draft August 2004
Usable as a Usable as an
U-Turn Recipient Alternate
/ /
+----------- +---------
+---+ +---+
| A |-------------------------------------| B |
+---+ +---+
--------+ -----------+
/ /
Usable as an Usable as a
Alternate U-Turn Recipient
5. 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 [RFC 3630].
A new bit in the Capabilities field specified in the OSPF Router
Capabilities TLV will need to be assigned; this is requested to be
bit 10.
The remaining bits in the Link Capabilities sub-TLV will need to be
assigned by IANA.
6. Security Considerations
This document does not introduce any new security issues.
7. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Atlas et al. [Page 5]
Internet Draft August 2004
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
8. References
[IP-LOCAL-PROTECT] A. Atlas, R. Torvi, G. Choudhury, C. Martin, B.
Imhoff, and D. Fedyk, "IP/LDP Local Protection", draft-atlas-ip-
local-protection-00.txt, February 2004, work-in-progress
[RFC 3630] D. Katz, K. Kompella, and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September 2003
[OSPF-RTR-CAP] A. Lindem, N. Shen, R. Aggarwal, S. Shaffer, JP
Vasseur, "Extensions to OSPF for Advertising Optional Router
Capabilities", draft-ietf-ospf-cap-01.txt, April 2004, work-in-
progress
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and
McPherson, D., "OSPF Stub Router Advertisement", RFC 3137, June 2001
9. Authors Information
Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
USA
email: aatlas@avici.com
phone: +1 978 964 2070
Raveendra Torvi
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
USA
email: rtorvi@avici.com
phone: +1 978 964 2026
Gagan Choudhury
AT&T
Room D5-3C21
Atlas et al. [Page 6]
Internet Draft August 2004
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
Brent Imhoff
WilTel Communications
3180 Rider Trail South
Bridgeton, MO 63045
USA
email: brent.imhoff@wcg.com
phone: +1 314 595 6853
Don Fedyk
Nortel Networks
600 Technology Park
Billerica, MA 01450
email: dwfedyk@nortelnetworks.com
phone: +1 978 288 3041
Atlas et al. [Page 7]