Network Working Group Acee Lindem
Internet Draft Naiming Shen
Expiration Date: January 2004 Redback Networks
Extensions to OSPF for Advertising Optional Route Attributes
draft-lindem-ospf-route-attr-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or IPR claims of which I am aware have been disclosed, and
any of which I 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.
Abstract
There are applications which require additional attributes to
be advertised with an OSPF route. The existing OSPF LSA
formats do not allow for backward compatible extension to advertise
these attributes. This draft proposes an extension to OSPF for
advertising additional attributes which will be associated with an
OSPF route.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in
RFC-2119 [BCP-14].
draft-lindem-ospf-route-attr-00.txt [Page 1]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
1. Motivation
There are applications which require the advertisement of
additional attributes associated with an OSPF route. Examples
of such applications include:
o Association of an administrative tag with an intra-area or
inter-area route.
o For Nexthop FRR [NHOPFRR], advertising the next hop of an
inter-area route.
o Indication that the route corresponds to a loopback interface.
draft-lindem-ospf-route-attr-00.txt [Page 2]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
2. OSPF Route Attributes (RA) Opaque LSA
OSPF routers will optionally advertise additional route attributes
(RA) in an area-scoped or AS-scoped opaque-LSA [OPAQUE]. The
advertising OSPF router will originate an area-scoped (type 10)
opaque LSA to associate additional attributes with a route
advertised in a router-LSA (type 1), network-LSA (type 2),
summary-LSAs (type 3 or type 4) or NSSA-LSA (type 7). An
AS-scoped (type 11) Opaque-LSA will be originated to associate
additional attributes with a route advertised in an
AS-external-LSA (type 5).
For certain applications the additional route attributes may only
need to be advertised to a adjacent neighbor, in this case
a link-scoped (type 9) opaque LSA may be originated in place of
an area-scoped (type 10) or AS-scoped (type 11) opaque LSA.
The Route Attributes LSA will have an Opaque type of 5 and a
unique ID.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Unique ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ref LSA Type | Prefix Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ref LSA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLV's -+
| ... |
Figure 1. OSPF Route Attributes LSA
Reference LSA Type
The type for the LSA advertising the IPv4 prefix. The
reference LSA type may be 1-5 or 7.
Prefix Length
The number of significant bits in the IPv4 address. For
router routes, a length of 32 MUST be specified.
draft-lindem-ospf-route-attr-00.txt [Page 3]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
Reference LSA ID
The LSA ID for the LSA advertising the IPv4 prefix. The
advertising router is not required to be respecified since
an OSPF router may not use this LSA to associate additional
attributes with LSAs that it does not originate.
IPv4 Address
The IPv4 address which requires association of additional
attributes. For OSPF router routes advertised in
Summary-ASBR LSAs, this will be the router ID.
The format of the TLV's within the body of a route attributes LSA
is the same as the format used by the Traffic Engineering
Extensions to OSPF [OSPF-TE]. The LSA payload consists of one or
more nested Type/Length/Value (TLV) triplets. The format of
each TLV is:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. TLV Format
The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of zero). The
TLV is padded to four-octet alignment; padding is not included in
the length field (so a three octet value would have a length of
three, but the total size of the TLV would be eight octets). Nested
TLV's are also 32-bit aligned. For example, a one byte value
would have the length field set to 1, and three bytes of padding
would be added to the end of the value portion of the TLV.
Unrecognized types are ignored.
draft-lindem-ospf-route-attr-00.txt [Page 4]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
2.1 OSPF Route Tag TLV
The first defined TLV in the body of an RA opaque LSA is
the Route Tag TLV. It allows one or more tags to be associated with
a given OSPF routes. Its use is optional.
The format of the Route Tag TLV is as follows:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o o
o o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. OSPF Router Capabilities TLV
Type A 16 bit field set to 1.
Length A 16 bit field that indicates the length of the value
portion in bytes. The value will be N * 4 where N is the
number of advertised tags. The maximum number of tags
that can be associated with a route is TBD.
Value The value is comprised of one or more tags. The use of
the tags is beyond the scope of this document but can be
used for applications such as marking a particular route
for a specific action or preference.
draft-lindem-ospf-route-attr-00.txt [Page 5]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
2.2 OSPF Inter-Area Route Attribute TLV
This Inter-Area Route Attribute TLV in RA opaque LSA is to
allow the area border routers (ABRs) to advertise certain
route attributes related to topology information in another
area. For example, the ABR can advertise the nexthop
OSPF node for an inter-area prefix. This can be used for
Nexthop FRR of IP traffic in inter-area node protection case.
Its use is optional.
The format of the Inter-area Route Attribute TLV is as follows:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Flag 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router-ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o o
o o
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attr Flag N | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router-ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A 16 bit field set to 2.
Length A 16 bit field that indicates the length of the value
portion in bytes. The value will be N * 8 where N is the
number of route attributes.
Value The value is comprised of one or more route attributes.
It has an Attribute Flag field, a Reserved field and
a Router-ID field.
Attribute Flag
This is an 16-bits field, currently defined:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|O|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-lindem-ospf-route-attr-00.txt [Page 6]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
Bits Description
N Nexthop Bit. If set, the router advertising this
IP prefix with this TLV uses router specified
in the Router-ID field as the nexthop node.
O Origination Bit. If set, the router advertising this
IP prefix with this TLV had learnt this prefix
from the router specified in the Router-ID field.
B Non-Best Path Bit. The N bit and B bit are mutually
exclusive. If set, the ABR advertising this this TLV
does not consider router specified in the Router-ID
field to be on the IGP best path to reach the
IP prefix.
Router-ID This is a 32-bit number representing the router which
can be used to forward traffic towards the destination
for the prefixes.
The list may contain multiple (Attribute Flag, Router-ID) tuples to
handle ECMP or non-ECMP cases.
If this TLV is being used in support of node protection, the RA
opaque LSA containing the Nexthop attributes need only be flooded
using a link-scoped (type 9) LSA.
3. Operation of OSPF Routers Originating the RA Opaque LSA
OSPF routers originating an RA opaque LSA should directly correlate
the existence with the reference LSA. In other words, the RA opaque
LSA MUST only be originated when the referenced LSA has been
originated and should purge (i.e., MaxAged) the RA opaque LSA when
the referenced LSA is purged. Reoriganation of either the
referenced LSA or the RA opaque LSA do require reorignation of the
other (unless of course, the underlying reason for the reorgination
affects both).
draft-lindem-ospf-route-attr-00.txt [Page 7]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
4. Operation of OSPF Routers
OSPF routers supporting the RA opaque LSA MUST find the
reference LSA and associate the received LSA with the reference
LSA. If the reference LSA is chosen as the best path during the
SPF computation [OSPF] then the additional attributes in the RA
opaque LSA will be associated with the route and handled in an
application specific manner. In essence, the RA opaque LSA and the
LSA it references are concatentated.
In the case of ECMP with more than one of the contributing LSAs
having route attributes, the route will have a superset of optional
route attributes. In the case of conflicting route attributes,
the route will inherit the attributes the LSA with the highest
advertising router ID.
5. Operation of OSPF Area Border Routers
OSPF Area Border Routers (ABRs) supporting RA opaque LSAs will
be required to originate an RA opaque LSA whenever they propagate
routes with additional attributes from one area to another. This
implies that the ABR will:
1. Originate an RA area-scoped opaque LSA when it originates
a summary LSA (type 3 or 4) for an intra-area or inter-area
route with additional attributes.
2. Originate an RA AS-scoped opaque LSA when it originates
an AS external LSA corresponding to a translated NSSA route
with additional attributes.
3. Originate an RA area-scoped opaque LSA when it originates
a summary LSA for an area range and policy dictates that the
ABR should associate additional attributes with the
area range.
4. Originate an RA AS-scoped opaque LSA when it originates
an AS external LSA for an NSSA area range and policy dictates
that the ABR should associate additional attributes with the
NSSA area range.
draft-lindem-ospf-route-attr-00.txt [Page 8]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
6. OSPFv3 Route Attribute LSA
For OSPFv3 [OSPFV3], the OSPFv3 Route Attributes (RA) LSA will be
similiar to the OSPF opaque LSA. It will have it's own OSPFv3
LSA function code assigned by IANA. The U bit will always 1 and
and S1 and S2 bits will be the same as the referenced LSA type.
Optionally, a link-scoped LSA may be orignated when the route
attributes need not be propagated beyond immediate neighbors.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|S|S| TBD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ref LSA Type | Prefix Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ref LSA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+- -+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLV's -+
| ... |
Figure 1. OSPF Route Attributes LSA
Reference LSA Type
The type for the LSA advertising the IPv6 prefix. The
reference LSA type may be 0x2001-0x2005, 0x2007, 0x2009,
of 0x0008.
Prefix Length
The number of significant bits in the IPv6 address. For
router routes, a length of 32 MUST be specified.
draft-lindem-ospf-route-attr-00.txt [Page 9]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
Reference LSA ID
The LSA ID for the LSA advertising the IPv6 prefix. The
advertising router is not required to be respecified since
an OSPFv3 router may not use this LSA to associate additional
attributes with LSAs that it does not originate.
IPv6 Address
The IPv6 address which requires association of additional
attributes. IPv6 Address Prefix is an encoding of the prefix
itself as an even multiple of 32-bit words, padding with zero
bits as necessary; this encoding consumes (Prefix Length
+ 31) / 32) 32-bit words. For OSPFv3 router routes advertised
in Inter-Area-Router-LSAs, this will be the router ID.
6.1 Operation of OSPFv3 Area Border Routers
OSPFv3 Area Border Routers (ABRs) supporting RA LSAs will
be required to originate an RA LSA whenever they propagate
routes with additional attributes from one area to another.
The rules documented in Section 5 apply to Inter-Area-Prefix-LSAs,
Inter-Area-Router-LSAs, and NSSA LSAs.
6.2 Operation of OSPFv3 Designated Routers
Operation of OSPFv3 Routers acting as a DR is similar to OSPFv3
ABRs in that they will propagate route attributes associated with
the prefixes advertised in the intra-area-prefix-LSA referencing
the DR's network LSA.
7. Security Consideration
This memo does not create any new security issues for the OSPF
protocol. Security considerations for the base OSPF protocol are
covered in [OSPF]. Security considerations for OSPFv3 are covered
in [OSPFV3].
8. Acknowledgments
TBD.
draft-lindem-ospf-route-attr-00.txt [Page 10]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
9. IANA Considerations
A new OSPF opaque LSA type and OSPFv3 LSA function code will need
to be assigned by IANA. Additionally, IANA will need to have
registries for the Route attributes LSA TLV's. The TLV assignee
will be responsible for allocation of any sub-TLV's for the IANA
assigned TLV. All TLV's and sub-TLV's will be subject to OSPF
WG review.
10. References
Normative References
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFV3] Colton, R., J. Moy, and D. Ferguson, "OSPF for IPv6",
RFC 2740, December 1999.
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[NHOPFRR] Shen, N., and P. Pan, "Nexthop Fast ReRoute for IP and
MPLS", draft-shen-nhop-fastreroute-00.txt, Work In
Progress.
[BCP-14] Bradner, S., "Keywords for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
Informative References
[OSPF-TE] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003.
11. Author Information
Acee Lindem
Redback Networks
102 Carric Bend Court
Cary, NC 27519
e-mail: acee@redback.com
Naiming Shen
Redback Networks
350 Holger Way
San Jose, CA 95134
e-mail: naiming@redback.com
draft-lindem-ospf-route-attr-00.txt [Page 11]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
12. Full 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.
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.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
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.
draft-lindem-ospf-route-attr-00.txt [Page 12]
Internet Draft draft-lindem-ospf-route-attr-00.txt Jun 2004
13. Intellectual Property
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.
14. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
draft-lindem-ospf-route-attr-00.txt [Page 13]