Network Working Group W. Dec Request for Comments: P. Psenak Category: S. Sturgess Expiration Date: December 2004 Cisco Systems File Name: draft-dec-ospf-tags-01.txt June 2004 A Proposal for a Tag Value field in OSPF draft-dec-ospf-tags-01.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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document proposes a method for encoding in Open Shortest Path First (OSPF) Internal and External Link State Advertisements (LSA) a Tag Value field containing user tag information associated with each link or prefix described within an LSA. Dec, Psenak, Sturgess [Page 1] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 1. Introduction Currently OSPF, as defined in [rfc2328], within LSA Type-1 to LSA Type-4 does not have a mechanism for assigning user tags to individual link or prefixes described in these internal LSAs. OSPF LSA Type-5 and Type-7 allow such a mechanism for external prefixes and this proposal does not alter it, however it does propose a uniform format for both internal and external prefix user tags. The proposal defines in a backward compatible manner, avoiding replication of link information or definition of new LSA Types, a method of inserting user tag information into OSPF LSA Types 1-5 via a Tag Value field. The purpose of the Tag Value field is to allow user tags to be assigned to links or prefixes described within a given LSA. The method of inserting into LSAs the proposed field is dependent upon the LSA Type and is described within this draft. 2. The OSPF Tag Value Field Tag Value Field will be used to propagate additional per link or prefix related user tag information carried in LSAs and is defined as a 24 bit value. The encoding of the Tag Value MUST follow the structure defined in Section X.X. The Tag Value is an attribute of a single link or prefix described within the LSA entry, just as a metric is an attribute of a link. A Tag Value applies to one and only one link. If any other links within an LSA are meant to have the same tag, then the LSA entry for those links MUST have a separate Tag Value field inserted. An OSPF Router generating an LSA will typically only insert the Tag Value attribute for links where such a value is specified in the configuration or system settings. The insertion of the Tag Value should be omitted in LSA entries for links for which the Tag Value is not specified. For internal LSAs (Type 1 and 3) the Tag Value is inserted into the corresponding link`s as TOS 129 metric. If a per TOS Tag Value Field is required, then the TOS 129 metric Tag Value Field, MUST immediately follow the corresponding TOS' metric field. All Tag Value Fields in Type-1 LSAs, must be counted in the '# TOS' field associated with the link as per Section A.4.2 of [rfc2328]. The TOS 129 metric was chosen because it cannot be used to represent any TOS metric due to the ambiguity arising out of the external LSA Dec, Psenak, Sturgess [Page 2] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 encoding. The TOS field is not proposed for carrying tags in external (Type 5 and 7) LSAs. Instead the scheme already defined in rfc2328 is used and a new proposal for encoding the tag, to allow a 24-bit Tag Value Field, is put forward. This is detailed in Section X.X. Additionally, Section X.X specifies a way to achieve a per TOS Tag Value field in external LSAs if required. 2.1. Tag Value Encoding The 24-bit Tag Value field is structured as shown and explained below. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsrv | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rsrv Reserved field for future definition and SHOULD be set to 0x00. No significance should currently be derived from this field. Tag A field that carries a 16-bit administratively user or system assigned tag for the corresponding link/prefix. The above fields, unless addressed by name, are referred to as "tag fields" in the remainder of this document. The term Tag Value will be used to represent the combined 24-bit field. 2.2. The Tag Value in Router-LSAs (LSA Type 1) In order to encode the Tag Value information in the Router-LSA [rfc2328] the 16-bit TOS metric field together with the preceding unused 8 bit all-0 space is used. This achieves the 24-bit space required. Additional per-TOS Tag Value fields MUST immediately follow the corresponding TOS entry and be inserted as the TOS 129 metric. Given the above, a OSPF Router-LSA (Type 1) carrying the Tag Value field appears as: Dec, Psenak, Sturgess [Page 3] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 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 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 | Rsrv | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 2.3. Tag Value Field in Network LSAs (LSA Type 2) Network LSAs (Type 2) [rfc2328] have no capability to carry the Tag Value field. However, since the Network LSA is used to derive the active tree topology for multi-access network segments, in order to have the ability to assign user tags to such segments the following method is used: A Designated Router (DR) originating a Network LSA (Type 2) MUST insert the Tag Value for the multi-access network into the Router-LSA (Type 1) description of the link it uses to connect to the DR itself. Dec, Psenak, Sturgess [Page 4] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 2.4. The Tag Value in Summary-LSAs (LSA Types 3 and 4) The OSPF Summary-LSA (Type 3 and 4) [rfc2328] defines a 24-bit TOS Metric. The overall format of a LSA Type 3 or 4 is the same, hence a Summary-LSA (Type 3 or 4) carrying the Tag Value field appears 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 3 or 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 | Rsrv | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 2.5. The Tag Value in External and NSSA External-LSAs (Type 5 and 7) The encoding of the Tag Value field in OSPF External-LSA (Type 5 and 7) [rfc 2328 and 1587] uses the existing External Route Tag field. However, since the external tag is defined as a 32 bit field, the 24 bit Tag Value MUST be mapped by pre-pending a value of 0b01111111 to it. This allows a method for recognizing classical 32 bit tags as containing the mapped Tag Value field. Implementations supporting TOS routing should allow independent setting of the Tag Value field per TOS instance, and appropriate insertion into the LSA in the respective TOS` External Route Tag. Thus, External LSAs (Type 5 or 7) carrying the Tag Value field appear as: Dec, Psenak, Sturgess [Page 5] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 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 | 5 or 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1|1|1|1|1|1|1| Rsrv | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1|1|1|1|1|1|1| Rsrv | Tag Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 3. Operation The LSA propagation rules and path selection as defined in [rfc2328] remain unchanged by this proposal. The user or system triggered creation or modification of a Tag Value field for a specific link MUST trigger the re-flooding of the LSA in the same manner as a change of a link metric does. An implementation SHOULD allow the user configuration option of enabling or disabling the copying or modification of any of the individual tag fields at OSPF Area Border Routers (ABRs) when generating a Summary-LSA from Router-LSAs carrying Tag Values. By default the implementation should not copy any Tag Values into Summary-LSA or translated External-LSAs Dec, Psenak, Sturgess [Page 6] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 4. Interoperability The use TOS value 129 does not present a conflict or interoperability issue with any well know TOS value (see Appendix A for a list of defined TOS values). Deployed systems not aware of the Tag Value field will in the case of an internal LSA see the Tag Value field as a TOS 129 metric, whilst in the external LSA case simply as a classical tag. 5. Deployment Considerations The proposed method of pre-pending the 24-bit Tag Value with the 0 to the 0b01111111 value when mapping it to the 32-bit External Route Tag field is compatible with the "Manually Configured Tags" scheme defined in the historic [rfc1403]. In network deployments where administratively defined tag values with their first 8-bits being 0b01111111 are already being used, network administrators are advised to modify such tagging schemes before deploying the described Tag Value enhancements. 6. IANA Considerations The internal LSA OSPF TOS(id) 129 will need to be assigned as a well known value where the TOS metric carries the defined Tag Value field. The process should aim at gathering consensus from the OSPF community, or designated experts, on the allocation of this unassigned TOS value. The assignment of a value other than 129 but preferably greater than 128 is also acceptable. Through the Rsvd field, the draft is open for further IANA assignments which could, but do not have to, designate other formats of the User Tags. Dec, Psenak, Sturgess [Page 7] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 7. Security Considerations The technique described in this document does not introduce any new security issues into the OSPF protocol. Routing policies or applications that use information carried in the tags are not directly associated to the OSPF protocol or this proposal and hence outside of the scope. 8. Acknowledgements The authors would like to thank John Evans, Sina Mirtorabi, Russ White, Alvaro Retana, and Roy Brooks. 9. Normative References [RFC2328] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet Engineering Task Force, 1998. 10. Informative References [RFC2178] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet Engineering Task Force, 1998. [RFC1583] J. Moy. OSPF version 2. Technical Report RFC 1583, Internet Engineering Task Force, 1994. [RFC2434] T. Narten, H. Alvestrand. Guidelines for Writing an IANA Considera- tions Section in RFCs. Internet Engineering Task Force, 1998. [RFC1403] K. Varadhan. BGP OSPF Interaction. Technical Report RFC 1403, Internet Engineering Task Force, 1993. Dec, Psenak, Sturgess [Page 8] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 11. Authors' Addresses Wojciech Dec Cisco Systems, Inc. Haarlerbergweg 13-19, Amsterdam 1101 CH, The Netherlands. E-mail: wdec@cisco.com Peter Psenak Cisco Systems, Inc. De Kleetlaan 6a, Brussels 1831, Belgium. E-mail: ppsenak@cisco.com Scott Sturgess Cisco Systems, Inc. De Kleetlaan 6a, Brussels 1831, Belgium. E-mail: scsturge@cisco.com 12. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to per- tain 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Dec, Psenak, Sturgess [Page 9] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 13. Full Copyright Notice 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 derivativeworks. However, this docu- ment 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 develop- ing 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 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 MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 14. Appendix A Currently the following TOS codes are defined/reserved [rfc2328] for backward compatibility OSPF encoding RFC 1349 TOS values ___________________________________________ 0 0000 normal service 2 0001 minimize monetary cost 4 0010 maximize reliability 6 0011 8 0100 maximize throughput 10 0101 12 0110 14 0111 16 1000 minimize delay 18 1001 20 1010 22 1011 24 1100 Dec, Psenak, Sturgess [Page 10] INTERNET DRAFT A Proposal for a Tag Value field in OSPF June 2004 26 1101 28 1110 30 1111 Dec, Psenak, Sturgess [Page 11]