Network Working Group Sina Mirtorabi Internet Draft Abhay Roy Expiration Date: December 2004 Cisco Systems File name: draft-mirtorabi-mt-ospfv3-00.txt June 2004 Multi-topology routing in OSPFv3 (MT-OSPFv3) draft-mirtorabi-mt-ospfv3-00.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. Abstract This document describes an extensible mechanism to support multiple topologies (MT) in OSPFv3. These topologies will be defined within each address family and can be used to compute different paths for different classes of service. The extension described in this document can further facilitate any future extensions of OSPFv3. Mirtorabi, Roy [Page 1] Internet Draft MT in OSPFv3 June 2004 1. Motivation Multi-topology routing as described in this document is similar in concept to M-ISIS [Ref3]. We have already defined support for multiple address families [Ref2]. Each address-family may need to support multiple topologies, to compute different paths for different classes of service or in-band management network. 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 [Ref2] 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. 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. Mirtorabi, Roy [Page 2] Internet Draft MT in OSPFv3 June 2004 4. MT Capability We define a Multi-topology capability bit in Options filed. 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. Note that in order to define MT-OSPFv3 in other address families (other than IPv6), MT-OSPFv3 must be defined in the corresponding AF range as defined in [Ref2]. 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. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |U |S2|S1|T | LSA Function Code | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ For the function codes defined in [Ref1] the LS types become: LSA function code LS Type Description ---------------------------------------------------- 1 0x3001 Router-LSA 2 0x3002 Network-LSA 3 0x3003 Inter-Area-Prefix-LSA 4 0x3004 Inter-Area-Router-LSA 5 0x5005 AS-External-LSA 6 0x3006 Group-membership-LSA 7 0x3007 Type-7-LSA 8 0x1008 Link-LSA 9 0x3009 Intra-Area-Prefix-LSA Mirtorabi, Roy [Page 3] Internet Draft MT in OSPFv3 June 2004 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. 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. Mirtorabi, Roy [Page 4] Internet Draft MT in OSPFv3 June 2004 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 [Ref1]. 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 [Ref1]. 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. 8. MT-ID Fields We define a 16 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. For IPv4 address family, OSPFv3 may be running on top of IPv4 as described in [Ref2]. In that case MT control packet must be sent over Default Topology and connected route should still exist for a Default Topology which will allow the OSPF control packets to be received. Mirtorabi, Roy [Page 5] Internet Draft MT in OSPFv3 June 2004 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. 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. Mirtorabi, Roy [Page 6] Internet Draft MT in OSPFv3 June 2004 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. 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. 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. Mirtorabi, Roy [Page 7] Internet Draft MT in OSPFv3 June 2004 18. Extended LSA Formats 18.1 Extended Router-LSA We define a new E-router-LSA with LS type equal to 0x3001. 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 [Ref1]. 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 [Ref1]. We define a Link-description TLV (LD-TLV). This TLV extends the router-LSA payload by defining sub-TLVs within each link description. Mirtorabi, Roy [Page 8] Internet Draft MT in OSPFv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (LD-TLV) | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Type | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-Type | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . sub-TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | All fields are defined as in [Ref1]. 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). 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. Mirtorabi, Roy [Page 9] Internet Draft MT in OSPFv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 18.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 0x3002. 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 [Ref1]. 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 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mirtorabi, Roy [Page 10] Internet Draft MT in OSPFv3 June 2004 All fields are defined as in [Ref1]. 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 [Ref1]. 18.3 Extended Inter-Area-Prefix-LSA We define a new E-inter-area-prefix-LSA with LS type of 0x3003. It is originated by area border routers to describe routes to prefixes associated with a MT-ID that belong to other areas. 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 [Ref1]. Mirtorabi, Roy [Page 11] Internet Draft MT in OSPFv3 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 |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 [Ref1]. 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. Mirtorabi, Roy [Page 12] Internet Draft MT in OSPFv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (IPMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 18.4 Extended Inter-Area-Router-LSA We define a new E-inter-area-router-LSA with LS type of 0x3004. 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 [Ref1]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . TLVs . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are defined as in [Ref1]. Mirtorabi, Roy [Page 13] Internet Draft MT in OSPFv3 June 2004 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 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Destination Router ID: It is defined in [Ref1]. 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. Mirtorabi, Roy [Page 14] Internet Draft MT in OSPFv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (IRMT-sTLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 18.5 Extended AS-external-LSA We define a new E-AS-external-LSA with LS type of 0x5005. 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 [Ref1]. Mirtorabi, Roy [Page 15] Internet Draft MT in OSPFv3 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 |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 [Ref1] 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 16] Internet Draft MT in OSPFv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 17] Internet Draft MT in OSPFv3 June 2004 18.6 Extended Link-LSA We define a new E-link-LSA with LS type of 0x1008. This LSA is generated for each link and carries each link's prefix in the corresponding topology. The processing and generation of this LSA is the same as for link-lsa as defined in [Ref1]. Mirtorabi, Roy [Page 18] Internet Draft MT in OSPFv3 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 |0|0|0|1| 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Pri | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Link-local Interface Address -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # 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. Mirtorabi, Roy [Page 19] Internet Draft MT in OSPFv3 June 2004 All other fields are defined as in [Ref1]. We define a Link Multi-Topology TLV (LMT-TLV) below. This TLV could further contain sub-TLVs. Each prefix block must contain the LMT-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 (LMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 18.7 Extended Intra-Area-Prefix-LSA We define a new E-intra-area-prefix-LSA with LS type of 0x3009. 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 [Ref1]. Mirtorabi, Roy [Page 20] Internet Draft MT in OSPFv3 June 2004 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 [Ref1]. We define a Prefix Multi-Topology TLV (PMT-TLV) below. This TLV could further contain sub-TLVs. E-intra-area-prefix-LSA must contain one or more prefix blocks and each prefix block must contain the PMT-TLV. Mirtorabi, Roy [Page 21] Internet Draft MT in OSPFv3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 (PMT-TLV) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | PrefixOptions | MT-ID metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 19. Security Considerations The technique described in this document does not introduce any new security issues to the OSPFv3 protocol. 20. Acknowledgements The authors would like to thank Alex Zinin, Acee Lindem, Tom Henderson, Jeff Ahrenholz and Paul Wells for their comments on the document. 21. References Normative References [Ref1] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. Informative Reference [Ref2] Mirtorabi, S. et al, "Support of address families in OSPFv3", Internet Draft, work in progress [Ref3] 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 [Ref1]. 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. Mirtorabi, Roy [Page 22] Internet Draft MT in OSPFv3 June 2004 Authors' Addresses Sina Mirtorabi Abhay Roy Cisco Systems Cisco Systems 170 W. Tasman Dr. 170 W. Tasman Dr. San Jose, CA 95134, USA San Jose, CA 95134, USA E-mail: sina@cisco.com E-mail: akr@cisco.com Mirtorabi, Roy [Page 23]