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]