Network Working Group A. Lindem Internet-Draft Ericsson Intended status: Standards Track S. Mirtorabi Expires: March 14, 2014 A. Roy F. Baker Cisco Systems September 10, 2013 OSPFv3 LSA Extendibility draft-acee-ospfv3-lsa-extend-02.txt Abstract OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSA. This document extends the LSA format by allowing the optional inclusion of Type-Length- Value (TLV) tuples in the LSAs. Backward compatibility mechanisms are also described. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 14, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Lindem, et al. Expires March 14, 2014 [Page 1] Internet-Draft OSPFv3 LSA Extendibility September 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Lindem, et al. Expires March 14, 2014 [Page 2] Internet-Draft OSPFv3 LSA Extendibility September 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 2. OSPFv3 Extended LSA Types . . . . . . . . . . . . . . . . . . 6 3. OSPFv3 Extended LSA TLV . . . . . . . . . . . . . . . . . . . 7 4. OSPFv3 E-Router-LSA . . . . . . . . . . . . . . . . . . . . . 8 5. OSPFv3 E-Network-LSA . . . . . . . . . . . . . . . . . . . . . 10 6. OSPFv3 E-Inter-Area-Prefix-LSA . . . . . . . . . . . . . . . . 12 7. OSPFv3 E-Inter-Area-Router-LSA . . . . . . . . . . . . . . . . 14 8. OSPFv3 E-AS-External-LSA . . . . . . . . . . . . . . . . . . . 16 9. OSPFv3 E-NSSA-LSA . . . . . . . . . . . . . . . . . . . . . . 18 10. OSPFv3 E-Link-LSA . . . . . . . . . . . . . . . . . . . . . . 19 11. OSPFv3 E-Intra-Area-Prefix-LSA . . . . . . . . . . . . . . . . 22 12. LSA Extension Backward Compatibility . . . . . . . . . . . . . 23 12.1. Extended LSA Mixed-Mode Backward Compatibility . . . . . . 24 12.2. LSA TLV Processing Backward Compatibility . . . . . . . . 24 13. Security Considerations . . . . . . . . . . . . . . . . . . . 25 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 15.1. Normative References . . . . . . . . . . . . . . . . . . . 27 15.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Configurable Constants . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Lindem, et al. Expires March 14, 2014 [Page 3] Internet-Draft OSPFv3 LSA Extendibility September 2013 1. Introduction OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340 [OSPFV3]. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSA. This document extends the LSA format by allowing the optional inclusion of Type- Length-Value (TLV) tuples in the LSAs. Backward compatibility mechanisms are also described. A similar extension was previously proposed in support of multi- topology routing. Additional requirements for OSPFv3 LSA extension include source/destination routing, route tagging, and others. A final requirement is to limit the changes to OSPFv3 to those necessary for TLV-based LSAs. For the most part, the semantics of existing OSPFv3 LSA are retained for their TLV-based successor LSAs described herein. Additionally, encoding details, e.g., the representation of IPv6 prefixes as described in section A.4.1 in RFC 5340 [OSPFV3], have been retained. This requirement was included to increase the expedience of IETF adoption and deployment. The following aspects of OSPFv3 LSA extension are described: 1. Extended LSA Types 2. Extended LSA Formats 3. Backward Compatibility 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 [RFC-KEYWORDS]. 1.2. Acknowledgments OSPFv3 TLV-based LSAs were first proposed in "Multi-topology routing in OSPFv3 (MT-OSPFv3)" [MT-OSPFV3]. Thanks for Peter Psenak for significant contributions to the backward compatibility mechanisms. Thanks go to Michael Barnes, Mike Dubrovsky, and Anton Smirnov for review of the draft versions and discussions of backward compatibility. Lindem, et al. Expires March 14, 2014 [Page 4] Internet-Draft OSPFv3 LSA Extendibility September 2013 The RFC text was produced using Marshall Rose's xml2rfc tool. Lindem, et al. Expires March 14, 2014 [Page 5] Internet-Draft OSPFv3 LSA Extendibility September 2013 2. OSPFv3 Extended LSA Types In order to provide backward compatibility, new LSA codes must be allocated. There are eight fixed-format LSAs defined in RFC 5340 [OSPFV3]. For ease of implementation and debugging, the LSA function codes are the same as the fixed-format LSAs only with 32, i.e., 0x20, added. The alternative was to allocate a bit in the LSA Type indicating the new LSA format. However, this would have used one half the LSA function code space for the migration of the eight original fixed-format LSAs. For backward compatibility, the U-bit will be set in LS Type so that the LSAs will be flooded by OSPFv3 routers that do not understand them. LSA function code LS Type Description ---------------------------------------------------- 33 0xA021 E-Router-LSA 34 0xA022 E-Network-LSA 35 0xA023 E-Inter-Area-Prefix-LSA 36 0xA024 E-Inter-Area-Router-LSA 37 0xC025 E-AS-External-LSA 38 N/A Unused (Not to be allocated) 39 0xA027 E-Type-7-LSA 40 0x8028 E-Link-LSA 41 0xA029 E-Intra-Area-Prefix-LSA OSPFv3 Extended LSA Types Lindem, et al. Expires March 14, 2014 [Page 6] Internet-Draft OSPFv3 LSA Extendibility September 2013 3. OSPFv3 Extended LSA TLV The format of the TLVs within the body of the extended LSAs is the same as the format used by the Traffic Engineering Extensions to OSPF [TE]. The variable TLV section consists of one or more nested Type/ Length/Value (TLV) tuples. 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 0). The TLV is padded to 4-octet alignment; padding is not included in the length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-byte value would have the length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored. Lindem, et al. Expires March 14, 2014 [Page 7] Internet-Draft OSPFv3 LSA Extendibility September 2013 4. OSPFv3 E-Router-LSA The E-Router-LSA has an LS Type of 0xA021 and has the same base information content as the Router-LSA, section 4.4.3.2 in [OSPFV3]. However, unlike the existing Router-LSA, it is fully extendable and represented as 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 |1|0|1| 0x21 | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |Nt|x|V|E|B| Options | +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extended Router-LSA All LSA Header fields are the same as defined for the Router-LSA. The following top-level TLVs are defined: o 0 - Reserved o 1 - Router-Link TLV Lindem, et al. Expires March 14, 2014 [Page 8] Internet-Draft OSPFv3 LSA Extendibility September 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (Router-Link) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router-Link TLV Like the existing Router-LSA, the LSA length is used to determine the end of the LSA including TLVs. The Router-Link TLV is only applicable to the E-Router-LSA. Inclusion in other Extended LSAs MUST be ignored. Lindem, et al. Expires March 14, 2014 [Page 9] Internet-Draft OSPFv3 LSA Extendibility September 2013 5. OSPFv3 E-Network-LSA The E-Network-LSA has an LS Type of 0xA022 and has the same base information content as the Network-LSA, section 4.4.3.3 in [OSPFV3]. However, unlike the existing Network-LSA, it is fully extendable and represented as 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 |1|0|1| 0x22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Network-LSA All LSA Header fields are the same as defined for the Network-LSA. The following top-level TLVs are defined: o 2 - Attached-Routers 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 (Attached-Routers) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjacent Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Additional Adjacent Neighbors . . . Lindem, et al. Expires March 14, 2014 [Page 10] Internet-Draft OSPFv3 LSA Extendibility September 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attached-Routers TLV There are two reasons for not having a separate TLV or sub-TLV for each adjacent neighbor. The first is to discourage using the E-Network-LSA for more than its current role of solely advertising the routers attached to a multi-access network. The router's metric as well as her attributes of individual attached routers should be advertised in their respective E-Router-LSAs. The second reason is that there is only a single E-Network-LSA per multi-access link with the Link State ID set to the Designated Router's Interface ID and, consequently, compact encoding has been chosen to decrease the likelihood of the size of the E-Network-LSA requiring IPv6 fragmentation when advertised in an OSPFv3 Link State Update packet. Like the existing Network-LSA, the LSA length is used to determine the end of the LSA including TLVs. The Attached-Routers TLV is only applicable to the E-Network-LSA. Inclusion in other Extended LSAs MUST be ignored. Lindem, et al. Expires March 14, 2014 [Page 11] Internet-Draft OSPFv3 LSA Extendibility September 2013 6. OSPFv3 E-Inter-Area-Prefix-LSA The E-Inter-Area-Prefix-LSA has an LS Type of 0xA023 and has the same base information content as the Inter-Area-Prefix-LSA, section 4.4.3.4 in [OSPFV3]. However, unlike the existing Inter-Area-Prefix- LSA, it is fully extendable and represented as 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 |1|0|1| 0x23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Inter-Area-Prefix-LSA All LSA Header fields are the same as defined for the Network-LSA. The following top-level TLVs are defined: o 3 - Inter-Area Prefix TLV Lindem, et al. Expires March 14, 2014 [Page 12] Internet-Draft OSPFv3 LSA Extendibility September 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Inter-Area Prefix) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inter-Area Prefix TLV In order to retain compatibility and semantics with the current OSPFv3 specification, each LSA MUST contain a single Inter-Area Prefix TLV. This will facilitate migration and avoid changes to functions such as incremental SPF computation. Like the existing Inter-Area-Prefix-LSA, the LSA length is used to determine the end of the LSA including TLV. The Inter-Area-Prefix TLV is only applicable to the E-Inter-Area-Prefix-LSA. Inclusion in other Extended LSAs MUST be ignored. Lindem, et al. Expires March 14, 2014 [Page 13] Internet-Draft OSPFv3 LSA Extendibility September 2013 7. OSPFv3 E-Inter-Area-Router-LSA The E-Inter-Area-Router-LSA has an LS Type of 0xA024 and has the same base information content as the Inter-Area-Router-LSA, section 4.4.3.5 in [OSPFV3]. However, unlike the Inter-Area-Router-LSA, it is fully extendable and represented as 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 |1|0|1| 0x24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Inter-Area-Router-LSA All LSA Header fields are the same as defined for the Inter-Area- Router-LSA. The following top-level TLVs are defined: o 4 - Inter-Area Router TLV Lindem, et al. Expires March 14, 2014 [Page 14] Internet-Draft OSPFv3 LSA Extendibility September 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (Inter-Area Router) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inter-Area Router TLV In order to retain compatibility and semantics with the current OSPFv3 specification, each LSA MUST contain a single Inter-Area Router TLV. This will facilitate migration and avoid changes to functions such as incremental SPF computation. Like the existing Inter-Area-Router-LSA, the LSA length is used to determine the end of the LSA including sub-TLVs. The Inter-Area- Router TLV is only applicable to the E-Inter-Area-Router-LSA. Inclusion in other Extended LSAs MUST be ignored. Lindem, et al. Expires March 14, 2014 [Page 15] Internet-Draft OSPFv3 LSA Extendibility September 2013 8. OSPFv3 E-AS-External-LSA The E-AS-External-LSA has an LS Type of 0xC025 and has the same base information content as the AS-External-LSA, section 4.4.3.6 in [OSPFV3]. However, unlike the existing AS-External-LSA, it is fully extendable and represented as 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 |1|1|0| 0x25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-AS-External-LSA All LSA Header fields are the same as defined for the AS-External- LSA. The following top-level TLVs are defined: o 5 - External Prefix TLV Lindem, et al. Expires March 14, 2014 [Page 16] Internet-Draft OSPFv3 LSA Extendibility September 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 (External Prefix) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|F|T| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Forwarding Address (Optional) -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ External Prefix TLV In order to retain compatibility and semantics with the current OSPFv3 specification, each LSA MUST contain a single External Prefix TLV. This will facilitate migration and avoid changes to functions such as incremental SPF computation. Given the Referenced LS type and Referenced Link State ID from the AS-External-LSA have never been used or even specified, they have been omitted from the External Prefix TLV. If there were ever a requirement for a referenced LSA, it could be satisfied with a sub-TLV. Like the existing AS-External-LSA, the LSA length is used to determine the end of the LSA including sub-TLVs. The External-Prefix TLV is only applicable to the E-AS-External-LSA and the E-NSSA-LSA. Inclusion in other Extended LSAs MUST be ignored. Lindem, et al. Expires March 14, 2014 [Page 17] Internet-Draft OSPFv3 LSA Extendibility September 2013 9. OSPFv3 E-NSSA-LSA The E-NSSA-LSA will have the same format and TLVs as the Extended AS- External-LSA Section 8. This is the same relationship as exists between the NSSA-LSA, section 4.4.3.7 in [OSPFV3], and the AS- External-LSA. The NSSA-LSA will have type 0xA027 which implies area flooding scope. Future requirements may dictate that supported TLVs differ between the E-AS-External-LSA and the E-NSSA-LSA. However, future requirements are beyond the scope of this document. Lindem, et al. Expires March 14, 2014 [Page 18] Internet-Draft OSPFv3 LSA Extendibility September 2013 10. OSPFv3 E-Link-LSA The E-Link-LSA has an LS Type of 0x8028 and will have the same base information content as the Link-LSA, section 4.4.3.8 in [OSPFV3]. However, unlike the existing Link-LFA, it is extendable and represented as 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 |1|0|0| 0x28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Priority | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Link-LSA The following top-level TLVs are defined: o 6 - Intra-Area Prefix TLV o 7 - IPv6 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV Lindem, et al. Expires March 14, 2014 [Page 19] Internet-Draft OSPFv3 LSA Extendibility September 2013 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 (Intra-Area Prefix) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Intra-Area Prefix TLV Like the Link-LSA, the E-Link-LSA affords advertisement of multiple intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be specified and the LSA length defines the end of the LSA including all TLVs. The Intra-Area-Prefix TLV is only applicable to the E-Link-LSA and the E-Intra-Area-Prefix-LSA. Inclusion in other Extended LSAs MUST be ignored. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 (IPv6 Local-Local Address) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- IPv6 Link-Local Interface Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Link-Local Address TLV The IPv6 Link-Local Address TLV is to be used with IPv6 address Lindem, et al. Expires March 14, 2014 [Page 20] Internet-Draft OSPFv3 LSA Extendibility September 2013 families as defined in [OSPFV3-AF]. The IPv6 Link-Local Address TLV is only applicable to the E-Link-LSA. Inclusion in other Extended LSAs MUST be ignored. Only a single instance of the IPv6 Link-Local Address family SHOULD be included in the E-Link-LSA. Instances preceding the first MUST be ignored. For IPv4 address families as defined in [OSPFV3-AF], this TLV SHOULD be ignored. Future specifications may support advertisement of routing and topology information for multiple address families. However, this is beyond the scope of this document. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 8 (IPv4 Local-Local Address) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Link-Local Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Link-Local Address TLV The IPv4 Link-Local Address TLV is to be used with IPv4 address families as defined in [OSPFV3-AF]. The IPv4 Link-Local Address TLV is only applicable to the E-Link-LSA. Inclusion in other Extended LSAs MUST be ignored. Only a single instance of the IPv4 Link-Local Address family SHOULD be included in the E-Link-LSA. Instances preceding the first MUST be ignored. For IPv6 address families as defined in [OSPFV3-AF]. Future specifications may support advertisement of routing and topology information for multiple address families. However, this is beyond the scope of this document. Lindem, et al. Expires March 14, 2014 [Page 21] Internet-Draft OSPFv3 LSA Extendibility September 2013 11. OSPFv3 E-Intra-Area-Prefix-LSA The E-Intra-Area-Prefix-LSA has an LS Type of 0xA029 and has the same base information content as the Intra-Area-Prefix-LSA, section 4.4.3.9 in [OSPFV3]. However, unlike the Intra-Area-Prefix-LSA, it is fully extendable and represented as 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 |1|0|1| 0x29 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Referenced LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E-Intra-Area-Prefix-LSA All LSA Header fields are the same as defined for the Intra-Area- Prefix-LSA. The following top-level TLVs are defined: o 6 - Intra-Area-Prefix TLV (defined in Section 10) Like the Intra-Area-Prefix-LSA, the E-Intra-Area-Link-LSA affords advertisement of multiple intra-area prefixes. Hence, multiple Intra-Area Prefix TLVs may be specified and the LSA length defines the end of the LSA including all TLVs. Lindem, et al. Expires March 14, 2014 [Page 22] Internet-Draft OSPFv3 LSA Extendibility September 2013 12. LSA Extension Backward Compatibility In the context of this document, backward compatibility is solely related to the capability of an OSPFv3 router to receive, process, and originate the TLV-based LSAs defined herein. Backward compatibility for future OSPFv3 extensions utilizing the TLV-based LSAs is out of scope and must be covered in the documents describing those extensions. Both full and, if applicable, partial deployment should be covered for future OSPFv3 LSA extensions. For simplicity and to avoid the scaling impact of maintaining both TLV and non-TLV based versions of the same LSA within a routing domain, the basic backward compatibility mode will not allow mixing of LSA formats. Different formats could still be supported with multiple OSPFv3 instances and separate OSPFv3 routing domains. Additionally, a more complex mode is provided in Section 12.1, where both formats of LSA coexist. An OSPFv3 instance will be configured to use either the Non-TLV-based LSAs, TLV-based LSAs, or support both (Appendix A). In order to facilitate backward compatibility, the OSPFv3 options field (as described in Appendix A.2 of RFC 5340 [OSPFV3]), will contain an additional options bits. The EL-bit will be used to indicate that the advertising OSPFv3 Router can receive, process, and originate TLV-based LSAs. An OSPFv3 router configured to support TLV-based LSAs WILL set its option field EL-bit in OSPFv3 Hello and Database Description packets. If "Normal" is specified for ExtendedLSASupport, the OSPFv3 router MUST NOT form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database Description packets with the options field EL-bit clear. In this manner, OSPFv3 routing domains utilizing the new encoding will be completely isolated from those using the RFC 5340 encodings. 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 +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ | | | | | | | | | | | | |EL|AT|L|AF|*|*|DC|R|N|x| E|V6| +-+-+-+-+-+-+-+-+-+-+-+-+--+--+-+--+-+-+--+-+-+-+--+--+ The Options field EL-bit This bit is indicates whether or not the OSPFv3 router supports the Extended LSA format with the bit set condition indicating support. Options Field EL-bit Lindem, et al. Expires March 14, 2014 [Page 23] Internet-Draft OSPFv3 LSA Extendibility September 2013 12.1. Extended LSA Mixed-Mode Backward Compatibility An implementation MAY support configuration allowing a mixture of OSPFv3 routers supporting and not supporting TLV-based LSAs in the same OSPFv3 routing domain. In these deployments, the OSPFv3 routers configured with a value of MixedMode or MixedModeDegraded for ExtendedLSASupport, (Appendix A), MUST originate both the TLV-based and non-TLV-based versions of the OSPFv3 LSAs described herein. For the purposes of Shortest Path First (SPF) computation, if the configured value is MixedMode, the TLV-based LSAs MUST be used by OSPFv3 routers supporting this specification. If MixedModeDegraded is configured, the non-TLV-based versions of the OSPFv3 LSAs are used for SPF computation. OSPFv3 routers configured for mixed mode operation also MUST form adjacencies with OSPFv3 Routers sending OSPFv3 Hello and Database Description packets with the options field EL-bit clear. In this manner, OSPFv3 routing domains utilizing the new encodings can be gradually migrated with a worst-case cost of approximately doubling the number of LSAs in the routing domain. 12.2. LSA TLV Processing Backward Compatibility This section defines the general rules for processing LSA TLVs. To ensure compatibility of future TLV-based LSA extensions, all implementations MUST adhere to these rules: 1. Unrecognized TLVs and sub-TLVs are ignored when parsing or processing Extended-LSAs. 2. Whether or not partial deployment of a given TLV is supported MUST be specified. 3. If partial deployment is not supported, mechanisms to ensure the corresponding feature are not deployed MUST be specified in the document defining the new TLV or sub-TLV. 4. If partial deployment is supported, backward compatibility and partial deployment MUST be specified in the document defining the new TLV or sub-TLV. Lindem, et al. Expires March 14, 2014 [Page 24] Internet-Draft OSPFv3 LSA Extendibility September 2013 13. Security Considerations In general, extendible OSPFv3 LSAs are subject to the same security concerns as those described in RFC 5340 [OSPFV3]. Additionally, implementations must assure that malformed TLV and Sub-TLV permutations do not result in errors which cause hard OSPFv3 failures. If there were ever a requirement to digitally sign OSPFv3 LSAs as described for OSPFv2 LSAs in RFC 2154 [OSPF-DIGITAL-SIGNATURE], the mechanisms described herein would greatly simplify the extension. Lindem, et al. Expires March 14, 2014 [Page 25] Internet-Draft OSPFv3 LSA Extendibility September 2013 14. IANA Considerations This specification defines nine OSPFv3 Extended LSA types as described in Section 2. This specification also creates two registries OSPFv3 Extended-LSAs TLVs and sub-TLVs. The TLV and Sub-TLV code-points in these registries are common to all Extended-LSAs and their respective definitions must define where they are applicable. The OSPFv3 Extend-LSA TLV registry will define top-level TLVs for Extended-LSAs and should be placed in the existing OSPFv3 IANA registry. New values can be allocated via IETF Consensus or IESG Approval. Nine initial values are allocated: o 0 - Reserved o 1 - Router-Link TLV o 2 - Attached-Routers TLV o 3 - Inter-Area Prefix TLV o 4 - Inter-Area Router TLV o 5 - External Prefix TLV o 6 - Intra-Area Prefix TLV o 7 - IPv6 Link-Local Address TLV o 8 - IPv4 Link-Local Address TLV The OSPFv3 Extend-LSA sub-TLV registry will define sub-TLVs at any level of nesting for Extended-LSAs and should be placed in the existing OSPFv3 IANA registry. New values can be allocated via IETF Consensus or IESG Approval. One initial value is allocated: o 0 - Reserved Lindem, et al. Expires March 14, 2014 [Page 26] Internet-Draft OSPFv3 LSA Extendibility September 2013 15. References 15.1. Normative References [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [OSPFV3-AF] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010. [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003. 15.2. Informative References [MT-OSPFV3] Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3 (MT-OSPFV3)", draft-ietf-ospf-mt-ospfv3-04.txt (work in progress). [OSPF-DIGITAL-SIGNATURE] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. Lindem, et al. Expires March 14, 2014 [Page 27] Internet-Draft OSPFv3 LSA Extendibility September 2013 Appendix A. Configurable Constants An additional global configurable constant will be added to the OSPFv3 protocol. ExtendedLSASupport This is an enumeration type indicating the extent to which the OSPFv3 instance supports the TLV format described herein for Extended LSAs. The valid value for the enumeration are: * None - Non-extended LSAs will not be originated or used in the SPF calculation. * Normal - Extended LSAs will be originated and adjacencies will not be formed with OSPFv3 routers not supporting this specification. * MixedMode - Both extended and non-extended LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The extended LSAs are used for the SPF computation. * MixedModeDegraded - Both extended and non-extended LSAs will be originated. OSPFv3 adjacencies will be formed with OSPFv3 routers not supporting this specification. The non-extended LSAs are used for the SPF computation. Lindem, et al. Expires March 14, 2014 [Page 28] Internet-Draft OSPFv3 LSA Extendibility September 2013 Authors' Addresses Acee Lindem Ericsson 301 Midenhall Way Cary, NC 27513 USA Email: acee.lindem@ericsson.com Sina Mirtorabi Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: sina@cisco.com Abhay Roy Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: akr@cisco.com Fred Baker Cisco Systems Santa Barbara, CA 93117 USA Email: fred@cisco.com Lindem, et al. Expires March 14, 2014 [Page 29]