Network Working Group S. Mirtorabi Internet-Draft A. Roy Expires: January 12, 2006 N. Shen A. Lindem Cisco Systems July 11, 2005 Extensions to OSPFv2 for Advertising Optional Route/Link Attributes draft-mirtorabi-ospf-tag-00.txt 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract There are applications which require additional attributes to be advertised with an OSPF link or 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 a link or route. It also introduces the support of administrative tags for any link Mirtorabi, et al. Expires January 12, 2006 [Page 1] Internet-Draft OSPFv2 Route/Link Attributes July 2005 type in the router-LSA and any route in summary-LSAs, NSSA-LSAs, or AS-external-LSAs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 3 2. OSPF Router Attributes (RA) Opaque LSA . . . . . . . . . . . . 4 3. Link Attribute TLV (LA-TLV) . . . . . . . . . . . . . . . . . 6 4. Inter-Area/External Route Attribute TLV (RA-TLV) . . . . . . . 7 5. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1 Tag sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 8 5.2 Extended Tag sub-TLV . . . . . . . . . . . . . . . . . . . 8 5.3 MT-ID sub-TLV . . . . . . . . . . . . . . . . . . . . . . 9 6. Generation of RA-LSAs . . . . . . . . . . . . . . . . . . . . 10 7. Generation of RA-LSA across Area Boundaries . . . . . . . . . 11 8. Multi-access Link Considerations . . . . . . . . . . . . . . . 12 9. Backward Compatibility/Deployment Considerations . . . . . . . 13 10. Security Considerations . . . . . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 12. Normative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Mirtorabi, et al. Expires January 12, 2006 [Page 2] Internet-Draft OSPFv2 Route/Link Attributes July 2005 1. Introduction There are applications which require the advertisement of additional attributes associated with an OSPF link or route. This document introduces the support for administrative tags for intra-area or inter-area routes. Future applications could introduce new link or route attributes. 1.1 Requirements notation 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 RFC2119 [RFC2119]. Mirtorabi, et al. Expires January 12, 2006 [Page 3] Internet-Draft OSPFv2 Route/Link Attributes July 2005 2. OSPF Router Attributes (RA) Opaque LSA OSPF routers will optionally advertise additional link/route attributes 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 for an area scoped LSA. An AS-scoped (type 11) Opaque-LSA will be originated to associate additional attributes with an AS scopeed LSA. The attribute LSA type is specifically coded in opaque ID (see below) allowing direct mapping of an RA LSA to a given LSA type. For certain applications the additional route attributes may only need to be advertised to an adjacent neighbor. In this case, a link- scoped (type 9) opaque LSA may originated instead of an area-scoped (type 10) or AS-scoped (type 11) opaque LSA. The Router Attributes LSA will have an LSDB Opaque type of 5. The remainder of LSID or Opaque ID is divided into one byte Attribute LS type and two bytes of unique ID. The body of this LSA is made up of one or more TLVs. 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 | Attr LS type | Unique ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | TLV's | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the TLV's within the body of a router 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/sub-TLV is: Mirtorabi, et al. Expires January 12, 2006 [Page 4] Internet-Draft OSPFv2 Route/Link Attributes July 2005 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. The following TLV-type are defined: TLV-type Definition ----------------------------------------------- 1 Link attribute TLV 2 Inter-area route attribute 3 External route attribute 4 NSSA External route attribute Note that a type 3 link in a Router-LSA carries intra-area route. Therefore, TLV-type 1 can contain both link attributes and intra-area route attributes. Mirtorabi, et al. Expires January 12, 2006 [Page 5] Internet-Draft OSPFv2 Route/Link Attributes July 2005 3. Link Attribute TLV (LA-TLV) This TLV appears in RA LSA with Attr LS type set to 1 and allows one of more attributes to be associated with a link or an intra-area route. The format of this TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | link-type | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link-type This field is as defined in Router-LSA in [OSPFv2]. Unknown link- types MUST be ignored. Link ID This field is as defined in Router-LSA in [OSPFv2]. Link Data This field is as defined in Router-LSA in [OSPFv2]. Reserved Reserved field. It should be set to 0 and ignored upon reception. sub-TLVs This field is the same as TLV and could further contain sub-TLVs. See section 5 for sub-TLVs. At least one sub-TLV must be present. The combination of [Link-type, Link ID, Link Data] uniquely identifies a link description in the corresponding Router-LSA. Mirtorabi, et al. Expires January 12, 2006 [Page 6] Internet-Draft OSPFv2 Route/Link Attributes July 2005 4. Inter-Area/External Route Attribute TLV (RA-TLV) This TLV appears in RA LSA with "Attr LS type" set to 3/5/7 allowing one or more attributes to be associated with an inter-area, NSSA, or external routes. The format of this TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2/3/4 | TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|R| P-length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link State ID This field is as defined in summary-LSA, NSSA-LSA, or AS-external- LSA as defined in [OSPFv2]. R Bits Reserved, they are set 0 and ignored in reception. P-length This fields indicates the length of prefix carried in Link state ID field. The valid value range are 0-32. sub-TLVs This field is the same as TLV and could further contain sub-TLVs. See section 5 for sub-TLV. At least one sub-TLV must be present. One or more RA-TLV of same type MUST appear in the corresponding RA LSA. For example, RA-TLV type 2 (Inter-area route attribute) MUST appear in an RA LSA with Attr LS type set to 3. Mirtorabi, et al. Expires January 12, 2006 [Page 7] Internet-Draft OSPFv2 Route/Link Attributes July 2005 5. Sub-TLVs The following sub-TLV area defined for inclusion in the LA-TLV and RA-TLV. sub-TLV-type Definition ----------------------------------------------- 1 Tag 2 Extended tag 3 MT-ID 5.1 Tag sub-TLV This sub-TLV allows one or more tags to be advertised for a route. Note that for intra-area routes this, sub-TLV is used for transit and stub links (link-types 2 and 3). Also, note that the Tag sub-TLV (type 1) is not required for the first tag for NSSA and external routes since AS-external-LSAs and NSSA-LSAs already contain a tag field. However, it may be used to advertise any additional tags needed for those LSA types. The format of this sub-TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tag A 32-bit configurable value set by the user. 5.2 Extended Tag sub-TLV This sub-TLV allows one or more extended tags to be advertised for a route. Note that for intra-area routes this sub-TLV is used for transit and stub links (Link-types 2 and 3). The format of this sub- TLV is as follows: Mirtorabi, et al. Expires January 12, 2006 [Page 8] Internet-Draft OSPFv2 Route/Link Attributes July 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended tag | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended tag | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Tag A 64-bit configurable value set by the user. 5.3 MT-ID sub-TLV This sub-TLV advertises attributes corresponding to multiple topologies as defined in [MTOSPF]. The MT-ID identifies the topology as defined in [MTOSPF]. This sub-TLV can contain sub-TLVs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | sub-TLV length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sub-TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MT-ID Multi-topology identifier as defined in [MTOSPF]. The valid MT-ID range is [0-127]. Mirtorabi, et al. Expires January 12, 2006 [Page 9] Internet-Draft OSPFv2 Route/Link Attributes July 2005 6. Generation of RA-LSAs A router configured to advertise route attributes, generates Router Attribute LSAs corresponding to links or prefixes advertised in its LSAs. The attribute LS type in RA-LSA header corresponds to the LS type advertised by the router. All attributes of a link or prefix MUST be advertised in a single Router Attribute LSA. RA-LSAs should be regenerated only when there is a change in an attribute value. On a multi-access link, the DR should is responsible for advertised attributes for the route corresponding to the transit link. If attributes are to be advertised all routers eligible to become DR MUST be configured to advertise them. If an LSA is used for a best path during the SPF computation the additional attributes in the RA opaque LSA will be associated with the route and handled in an application specific manner. In the case of ECMP with more than one of the contributing LSAs having route attributes, the route will have the union of optional route attributes. In the case of conflicting route attributes, the route will inherit the attributes from the LSA with the highest advertising router ID. Mirtorabi, et al. Expires January 12, 2006 [Page 10] Internet-Draft OSPFv2 Route/Link Attributes July 2005 7. Generation of RA-LSA across Area Boundaries OSPF Area Border Routers (ABRs) supporting RA opaque LSAs will be required (unless prevented by local policy) to originate an RA opaque LSA whenever they propagate routes with additional attributes from one area to another. This implies that the ABR will: o 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. o Originate an RA AS-scoped opaque LSA when it originates an AS- external-LSA corresponding to a translated NSSA route with additional attributes. o 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. o 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. Mirtorabi, et al. Expires January 12, 2006 [Page 11] Internet-Draft OSPFv2 Route/Link Attributes July 2005 8. Multi-access Link Considerations In order to tag prefixes on the multi-access links the Designated Router (DR) SHOULD be capable of the RA extension. This is accomplished by advertising a link type of 2 in the Link Attribute TLV. Mirtorabi, et al. Expires January 12, 2006 [Page 12] Internet-Draft OSPFv2 Route/Link Attributes July 2005 9. Backward Compatibility/Deployment Considerations This document does not introduce any backward compatibility issues. The new LSA is simply ignored by non-capable routers. Attribute capable routers could be introduced gradually without any interoperability problem. It should be noted that in order to convey the attributes across an area boundary, the ABRs MUST be RA capable so that attributes can be propagated to multiple areas. Mirtorabi, et al. Expires January 12, 2006 [Page 13] Internet-Draft OSPFv2 Route/Link Attributes July 2005 10. Security Considerations This document does not raise any security issues that are not already covered in [OSPFv2]. Mirtorabi, et al. Expires January 12, 2006 [Page 14] Internet-Draft OSPFv2 Route/Link Attributes July 2005 11. IANA Considerations The following IANA assignments are to be made from existing registries: 1. The OSPFv2 opaque LSA type 5 will need to be reserved for the OSPFv2 RA opaque LSA. New registries are defined for the following purposes: 1. Registry for OSPF RA TLVs - The values of 1-4 are defined herein. All TLV additions are subject to OSPF WG review. 2. Registry for OSPF RA SubTLVs - The values of 1-2 are defined herein. All SubTLV additions are subject to OSPF WG review. 12. Normative References [MT-OSPF] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", draft-ietf-ospf-mt-04.txt (work in progress). [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [OSPFv2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. Authors' Addresses Sina Mirtorabi Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: sina@cisco.com Mirtorabi, et al. Expires January 12, 2006 [Page 15] Internet-Draft OSPFv2 Route/Link Attributes July 2005 Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: akr@cisco.com Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA Email: naiming@cisco.com Acee Lindem Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA Email: acee@cisco.com Mirtorabi, et al. Expires January 12, 2006 [Page 16] Internet-Draft OSPFv2 Route/Link Attributes July 2005 Appendix A. Acknowledgments The RFC text was produced using Marshall Rose's xml2rfc tool. Mirtorabi, et al. Expires January 12, 2006 [Page 17] Internet-Draft OSPFv2 Route/Link Attributes July 2005 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 (2005). 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. Mirtorabi, et al. Expires January 12, 2006 [Page 18]