Network Working Group Sina Mirtorabi Internet Draft Force10 Networks Expiration Date: September 2007 Abhay Roy File name: draft-ietf-ospf-mt-ospfv3-02.txt Cisco Systems March 2007 Multi-topology routing in OSPFv3 (MT-OSPFv3) draft-ietf-ospf-mt-ospfv3-02.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 September 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an extensible mechanism to support multiple topologies (MT) in OSPFv3. These topologies can be used within the same address family in order to compute different paths for different classes of service, or belong to different address families allowing an integrated definition of address family with OSPFv3. The extension described in this document can further facilitate any future extensions of OSPFv3. Mirtorabi, Roy [Page 1] Internet Draft OSPFv3 MTR March 2007 1. Introduction Multi-topology routing as described in this document is similar in concept to M-ISIS [M-ISIS]. It is used to introduce an integrated definition of other address families in OSPFv3. Each address-family may also need to support multiple topologies, to compute different paths for different classes of service or in-band management network. 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 2119 [RFC-KEYWORDS]. 2. Potential Solutions In order to support multiple topologies at least two different solutions are possible. We discuss them briefly below, and describe issues with each of them. 2.1 Using Different Instance IDs [INSTANCES] defines a range of Instance IDs for each address family. It is therefore possible to define multiple topologies by using different Instance IDs. However this approach is inefficient due to the overhead involved in having to manage multiple adjacencies, multiple link-state databases etc. 2.2 Using an integrated approach with existing LSAs Another solution would be to define multiple topologies as an integrated approach within each instance. This can be done by redefining an unused field in the link description of Router LSA and define it as a multi-topology identifier (MT-ID). We will have to generate N link descriptions for a link with N topologies configured on it. This seems wasteful as the link description is replicated N times, further we have some backward compatibility issues. Also, there is a need to identify prefixes carried for each topology, i.e. prefix-LSAs need to carry MT-IDs and there is no possibility to reuse the existing prefix-LSAs. Mirtorabi, Roy [Page 2] Internet Draft OSPFv3 MTR March 2007 3. Proposed Solution We propose to define new LSAs in order to achieve this. Not only does this allow an optimum definition of topologies within OSPFv3, it also does not have any backward compatibility issues as new LSAs will be ignored by old routers. The flexible encoding proposed for the new LSAs can also facilitate any future extension in OSPFv3. 4. MT Capability We define a Multi-topology capability bit in Options filed. 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 -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+ | | | | | | | | | | | | | |MT|AF|* |* |DC| R| N|MC| E|V6| -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+ The Options field MT-bit This bit is set when a router supports MT-OSPFv3 as specified in this memo. 5. T-bit in LS type We define a new T-bit (TLV based) in LS type field in order to extend the existing LSAs. This will define new LSA types homogeneously compared to the existing LSA types. The U-bit and the T-bit are set. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |U |S2|S1|T | LSA Function Code | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Mirtorabi, Roy [Page 3] Internet Draft OSPFv3 MTR March 2007 For the function codes defined in [OSPFv3] the LS types become: LSA function code LS Type Description ---------------------------------------------------- 1 0xB001 E-Router-LSA 2 0xB002 E-Network-LSA 3 0xB003 E-Inter-Area-Prefix-LSA 4 0xB004 E-Inter-Area-Router-LSA 5 0xD005 E-AS-External-LSA 6 0xB006 E-Group-membership-LSA 7 0xB007 E-Type-7-LSA 8 0x9008 E-Link-LSA 9 0xB009 E-Intra-Area-Prefix-LSA 6. OSPFv3 TLVs and sub-TLVs All the Extended LSAs have a flexible TLV format encoding. OSPFv3 TLVs have a 16 bit Type and a 16 bit Length field followed by the TLV value. TLV Length is set to the length of Value field in bytes. Any unknown TLV/sub-TLV should 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLV Value . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPFv3 TLV Format sub-TLVs are similar to TLVs with an additional 16 bit Total sub-TLV length (in bytes) and a 16 bit reserved field. If the TLV has multiple Values, total sub-TLV length allows to locate the next Value, when there are variable number of sub-TLVs present. Mirtorabi, Roy [Page 4] Internet Draft OSPFv3 MTR March 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total sub-TLV length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPFv3 sub-TLV Format The presence of sub-TLVs is indicated by a S-bit in the value field of TLVs. If the S-bit is set, the format of sub-TLVs is as specified above. If the S-bit is clear, no sub-TLVs are added. For LSAs which carry a prefix, we define S-bit in PrefixOptions. Note that S-bit in PrefixOptions is only defined in Extended LSAs. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |S | | | | P|MC|LA|NU| +--+--+--+--+--+--+--+--+ The Prefix Options field 7. Default Topology In order to interact with non-MT capable routers we define default topology as the topology that is built by using the existing LSAs as specified in OSPFv3 [OSPFv3]. We define MT topologies as topologies which are other than the Default Topology. A MT topology will be defined by using the new LSAs as specified in this memo. When all routers are MT capable, there is no need to generate existing LSAs as defined in [OSPFv3]. The new LSAs can be used even for Default Topology. A global configurable parameter RFC2740Compatibility (see Appendix A) is used to control the generation of existing or new LSAs. Mirtorabi, Roy [Page 5] Internet Draft OSPFv3 MTR March 2007 8. MT-ID Fields We define a 8 bit MT-ID field which is present in various LSA types. Each MT-ID is also accompanied with a MT-ID Metric field which carries a metric specific to one MT. When a MT capable router participates in Default Topology, depending on RFC2740Compatibility (see Appendix A) it will generate existing LSAs or extended LSAs for the Default Topology. MT-ID value 0 is reserved for carrying information about Default Topology in the new LSAs. 9. MT Control packet and IPv6 link local address IPv6 link local address is MT independent and is used for MT-OSPFv3 control packets. 10. Forming adjacency in MT Each interface can be configured to belong to a set of topologies. A single adjacency will be formed even if the interface is configured to participate in multiple topologies. 11. Advertising MT topology When a router is configured with multiple topologies on a link, it advertises the list of MT-IDs and their corresponding metrics in E-router-LSA. When a MT-capable router participates in default topology, based on RFC2740Compatibility it may generate existing or Extended Router-LSAs. Network LSAs are common to all MT. The DR will announce an adjacency to all attached routers independently of their MT-ID value. When RFC2740Compatibility is disabled on DR (and all routers should be MT capable) E-network-LSA will be used instead of network-LSA. This allow a smooth migration to extended LSAs. 12. Advertising MT prefix When a MT-capable router participate in non-Default Topology, it generates extended prefix LSAs with MT-ID in which it participates. When a MT-capable router participates in default topology, based on RFC2740Compatibility it may generate existing or Extended prefix LSAs. Mirtorabi, Roy [Page 6] Internet Draft OSPFv3 MTR March 2007 13. Advertising intra-area-prefix-LSA on multi-access link On multi-access links, the DR is responsible to generate prefix-LSA on behalf of the LAN, this is done by considering the prefix advertised in link-LSAs. If RFC2740Compatibility is disabled the DR will generate Extended prefix-LSAs. If RFC2740Compatibility is enabled we select a Multi-Topology DR (MT-DR) which generates the E-intra-area-prefix-LSA on behalf of the LAN. MT-DR is elected by considering the highest Router ID among MT-capable routers (done by examining MT-bit of neighbors). The E-intra-area-prefix-LSA generated by the MT-DR will have the Referenced LS type set to 2, Referenced Link State ID set to DR's Router ID and Referenced Advertising Router set to DR's Router ID. Note that MT-DR's role is to just generate the E-intra-area-prefix-LSA whereas DR is responsible for network LSA generation and helping in flooding on the multi-access link. 14. MT Area Boundary Area boundaries for all topologies are the same but an interface can be configured to not participate in all topologies. This will make a router's B-bit setting topology independent whereas reachability to the ABR will be topology dependent. 15. MT SPF Computation When a link participates in a topology, it's MT-ID value is carried in extended Router-LSA. A separate SPF is computed for each topology by considering only the link/metric for the corresponding topology. Network LSAs are used by all topologies during the SPF computation. Nexthops computed during the MT SPF MUST belong to the same topology. Similarly when processing prefix-LSAs or external-LSAs, only prefixes which contain a valid MT Metric for that MT SPF are considered reachable in that topology. During SPF computation for the Default Topology, independently of RFC2740Compatibility value, extended LSA are used when present otherwise existing LSA are used. This allows a smooth transition across RFC2740Compatibility changes. Mirtorabi, Roy [Page 7] Internet Draft OSPFv3 MTR March 2007 16. Forwarding in MT Forwarding must make sure that only routes belonging to the single topology are used to forward the packet along its way from source to destination. Therefore user configuration MUST be consistently applied throughout the network so that an incoming packet be associated with the corresponding topology. It is outside of the scope of this document to consider different methods of associating an incoming packet to the corresponding topology routes. 17. MT-ID reserved value The following MT-ID values are defined: 0 - Reserved for IPv6 unicast topology 1 - Reserved for IPv4 in-band management purposes 2 - Reserved for IPv4 unicast topology 3 - Reserved for IPv6 multicast topology 4 - Reserved for IPv4 multicast topology 5-31 - Reserved for IETF consensus. 32-255 - Reserved for development, experimental and proprietary features [RFC3692]. 18. IPv4 address family considerations OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses for OSPFv3 control packets and next hop calculations. Although IPV6 link local addresses could be used as next hops for IPv4 address families, it is desirable to have IPv4 next hop addresses. For example, in IPv4 multicast having the nexthop address the same as the PIM neighbor address (IPv4 address) makes it easier to know to which upstream neighbor to send a PIM join when doing a RPF lookup for a source. It is also easier for troubleshooting purposes to have a next hop with the same semantics as the AF. In order to achieve this, the link's IPv4 address will be advertised in the E-link-LSA, see section 20.6. We call direct interface address (DIA) the address that is reachable directly via the link provided that a layer 3 to layer 2 mapping is available. Note that there is no explicit need for the IPv4 link addresses to be on the same subnet. An implementation should resolve layer 3 to layer 2 mappings via ARP or ND for a DIA even if the IPv4 address is not on the same subnet as the router's interface IP address. Mirtorabi, Roy [Page 8] Internet Draft OSPFv3 MTR March 2006 19. Backward compatibility and interaction with non-MT routers An MT capable router will interact (in Default Topology) with non-MT capable routers by using the existing LSAs. MT information is carried in new LSAs which are ignored by non-MT routers therefore this document does not introduce any backward compatibility issues. When all routers are MT capable, RFC2740Compatibility can be set to disable and only extended LSAs are used for Default Topology. 20. Extended LSA Formats 20.1 Extended Router-LSA We define a new E-router-LSA with LS type equal to 0xB001. This LSA, extends router LSA by defining TLVs within the LSA payload. The LSA has a fixed portion followed by TLVs. Each TLV could further contains sub-TLVs. The processing and generation of this LSA is the same as for router-LSA defined in [OSPFv3]. 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 |0|0|1|1| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |W|V|E|B| Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are defined as in [OSPFv3]. Mirtorabi, Roy [Page 9] Internet Draft OSPFv3 MTR March 2007 We define a Link-description TLV (LD-TLV). This TLV extends the router-LSA payload by defining sub-TLVs within each link description. 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 (LD-TLV) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Type | Reserved | Link-Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Type | Reserved | Link-Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Link-Block Length : Define the length of link block including Link-Type, Reserved, Link-Block Length, fixed ID fields and sub-TLVs. All other fields are defined as in [OSPFv3]. LD-TLV is the only top level TLV defined in this document. This TLV should not be repeated within an E-router-LSA fragment, instead multiple link descriptions are included within the LD-TLV (Total sub-TLV length indicates the next link description). Mirtorabi, Roy [Page 10] Internet Draft OSPFv3 MTR March 2007 We define a Router Multi-Topology sub-TLV (RMT-sTLV) below. This sub-TLV could further contain sub-TLVs. E-router-LSA must contain the LD-TLV and each link description must contain the RMT-sTLV. 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 (RMT-sTLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | 0 |S| MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | 0 |S| MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | When a link participates in different topologies, it will include the RMT-sTLV with MT-IDs and MT-ID metrics for corresponding topologies. 20.2 Extended Network-LSA The network LSA does not contain any MT information as the DR is shared by all topologies therefore the existing network LSA can be used independently of the router participation in a MT. However we define an E-network-LSA in order to allow for any future extensions. The LS type is equal to 0xB002. This LSA extends network-LSA by defining TLVs within the LSA payload. The processing and generation of this LSA is the same as for network-LSA defined in [OSPFv3]. Mirtorabi, Roy [Page 11] Internet Draft OSPFv3 MTR March 2006 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 |0|0|1|1| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are defined as in [OSPFv3]. We define a Attached-Router TLV (AR-TLV). This TLV has similar contents as the network-LSA payload. E-network-LSA must contain AR-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (AR-TLV) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attached Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attached Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | All fields are defined as in [OSPFv3]. 20.3 Extended Inter-Area-Prefix-LSA We define a new E-inter-area-prefix-LSA with LS type of 0xB003. It is originated by area border routers to describe routes to prefixes associated with a MT-ID that belong to other areas. Mirtorabi, Roy [Page 12] Internet Draft OSPFv3 MTR March 2007 An implementation could decide to advertise one or more prefixes within one E-inter-area-prefix-LSA. The processing and generation of this LSA is the same as for as inter-area-prefix-LSA as defined in [OSPFv3]. 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 |0|0|1|1| 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Prefix-Block Length : Define the length of prefix block including Prefix-Block Length, PrefixLength, Reserved field, Address Prefix and TLVs. All other fields are defined as in [OSPFv3]. Mirtorabi, Roy [Page 13] Internet Draft OSPFv3 MTR March 2007 We define an Inter Prefix Multi-Topology TLV (IPMT-TLV) below. This TLV could further contain sub-TLVs. E-inter-area-prefix-LSA must contain one or more prefix blocks and each prefix block must contain the IPMT-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (IPMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 20.4 Extended Inter-Area-Router-LSA We define a new E-inter-area-router-LSA with LS type of 0xB004. This LSA is originated by area border routers and describes routes to routers in other areas. An implementation could decide to advertise information about one or more routers within one E-inter-area-router-LSA. The processing and generation of this LSA is the same as for as inter-area-router-LSA as defined in [OSPFv3]. Mirtorabi, Roy [Page 14] Internet Draft OSPFv3 MTR March 2007 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 |0|0|1|1| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are defined as in [OSPFv3]. We define a Dest-Router TLV (DR-TLV) below. This TLV extends the Inter-area-router-LSA payload by defining sub-TLVs within each Destination Router. E-inter-area-router-LSA must contain the DR-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (DR-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Mirtorabi, Roy [Page 15] Internet Draft OSPFv3 MTR March 2007 Destination Router ID: It is defined in [OSPFv3]. DR-TLV is the only top level TLV defined by this document. This TLV should not be repeated within an E-Inter-area-router-LSA, instead multiple destination router values are included within the DR-TLV (Total sub-TLV length indicates the next destination router value). We define an Inter Router Multi-Topology sub-TLV (IRMT-sTLV) below. DR-TLV must contain the IRMT-sTLV. 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 (IRMT-sTLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 20.5 Extended AS-external-LSA We define a new E-AS-external-LSA with LS type of 0xD005. This LSA is originated by AS boundary routers, and describes destinations external to the AS associated to a MT-ID. An implementation could decide to advertise one or more prefixes within one E-AS-external-LSA. The processing and generation of this LSA is the same as for an AS-external-LSA as defined in [OSPFv3]. Mirtorabi, Roy [Page 16] Internet Draft OSPFv3 MTR March 2007 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 |0|1|0|1| 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Prefix-Block Length : Define the length of prefix block including Prefix-Block Length, PrefixLength, Reserved field, Address Prefix and TLVs. All other fields are defined as in [OSPFv3] We define an External Prefix Multi-Topology TLV (EMT-TLV) below. This EMT-TLV could further contain sub-TLVs. E-AS-external-LSA must contain one or more prefix blocks and each prefix block must contain the EMT-TLV. Mirtorabi, Roy [Page 17] Internet Draft OSPFv3 MTR March 2007 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 (EMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|F|T| PrefixOptions| Referenced LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Forwarding Address (Optional) -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|F|T| PrefixOptions| Referenced LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Forwarding Address (Optional) -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Note that when the sub-TLV is present (S-bit set in the PrefixOptions) the sub-TLV is placed after Forwarding address and external route Tag if they are present. Mirtorabi, Roy [Page 18] Internet Draft OSPFv3 MTR March 2007 20.6 Extended Link-LSA We define a new E-link-LSA with LS type of 0x9008. This LSA is generated for each link and carries each link's prefix in the corresponding topology. It also carries next hop IP information for the supported address families. The processing and generation of this LSA is the same as for link-lsa as defined in [OSPFv3]. This LSA has a fixed portion followed by 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 |0|0|0|1| 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Pri | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We define the following three TLVs o IPv6 Next hop TLV (NH6-TLV) o IPv4 Next hop TLV (NH4-TLV) o Prefix Multi-topology TLV (PMT-TLV) Next hop TLVs carry IPv6/IPv4 information for next hop calculation. IPv6 next hop information MUST be a link local IPv6 address. Prefix-TLV carries router link's prefix on multi-access link. This information is used by DR in order to include those prefix in its E-intra-area prefix LSA. Mirtorabi, Roy [Page 19] Internet Draft OSPFv3 MTR March 2007 NH6-TLV has the following format: 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 (NH6-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Link-local Interface Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV MUST be present if the link participate in a MT belonging to IPv6 address family. NH4-TLV has the following format: 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 (NH4-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +---------------------------------------------------------------+ This TLV MUST be present if the link participate in a MT belonging to IPv4 address family. PMT-TLV extends link-LSA by defining TLV under each address prefix. This TLV should only be present on multi-access links. Mirtorabi, Roy [Page 20] Internet Draft OSPFv3 MTR March 2007 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 (PMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # prefixes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Prefix-Block Length : Define the length of prefix block including Prefix-Block Length, PrefixLength, Reserved field, Address Prefix and TLVs. All other fields are defined as in [OSPFv3]. We define a Link Multi-Topology sub-TLV (LMT-sTLV) below. This sub-TLV could further contain sub-TLVs. Each prefix block must contain the LMT-sTLV. Mirtorabi, Roy [Page 21] Internet Draft OSPFv3 MTR March 2007 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 (LMT-sTLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 20.7 Extended Intra-Area-Prefix-LSA We define a new E-intra-area-prefix-LSA with LS type of 0xB009. A router generates E-Intra-Area-Prefix-LSAs to advertise one or more prefixes associated with a topology. The processing and generation of this LSA is the same as for intra-area-prefix-LSA defined in [OSPFv3]. Mirtorabi, Roy [Page 22] Internet Draft OSPFv3 MTR March 2007 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 |0|0|1|1| 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # prefixes | Referenced LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Block Length | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Prefix-Block Length : Define the length of prefix block including Prefix-Block Length, PrefixLength, Reserved field, Address Prefix and TLVs. All other fields are defined as in [OSPFv3]. We define a Prefix Multi-Topology TLV (PMT-TLV) below. This TLV could further contain sub-TLVs. Mirtorabi, Roy [Page 23] Internet Draft OSPFv3 MTR March 2007 E-intra-area-prefix-LSA must contain one or more prefix blocks and each prefix block must contain the PMT-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (PMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 21. Security Considerations The technique described in this document does not introduce any new security issues to the OSPFv3 protocol. 22. Acknowledgements The authors would like to thank Alex Zinin, Acee Lindem, Tom Henderson, Jeff Ahrenholz and Paul Wells for their comments on the document. 23. IANA Considerations IANA is requested to create a new registry, "OSPFv3 multi-topology ID values" with the assignment listed in Section 17 of this document and registration policies for future assignments. 24. References Normative References [OSPFv3] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. [RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997. Mirtorabi, Roy [Page 24] Internet Draft OSPFv3 MTR March 2007 Informative Reference [INSTANCES] Mirtorabi, S. et al, "Support of address families in OSPFv3", Internet Draft, work in progress [M-ISIS] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology (MT) Routing in IS-IS", Internet Draft, work in progress Appendix A. Global Parameter RFC2740Compatibility This parameter controls which LSAs are used for Default Topology. When set to "enabled", the Default Topology is described using existing LSAs [OSPFv3]. When set to "disabled" the Default Topology is described using Extended LSAs as specified in this memo. This parameter is set to "enabled" by default. Authors' Addresses Sina Mirtorabi Abhay Roy Force10 Networks Cisco Systems 350 Holger Way 170 W. Tasman Dr. San Jose, CA 95134, USA San Jose, CA 95134, USA E-mail: sina@force10netwroks.com E-mail: akr@cisco.com Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 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, THE IETF TRUST 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. Mirtorabi, Roy [Page 25] Internet Draft OSPFv3 MTR March 2007 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Mirtorabi, Roy [Page 26]