idnits 2.17.1 draft-ietf-ospf-mt-ospfv3-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1081. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6251 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2740 (ref. 'OSPFv3') (Obsoleted by RFC 5340) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sina Mirtorabi 3 Internet Draft Force10 Networks 4 Expiration Date: September 2007 Abhay Roy 5 File name: draft-ietf-ospf-mt-ospfv3-02.txt Cisco Systems 6 March 2007 8 Multi-topology routing in OSPFv3 (MT-OSPFv3) 9 draft-ietf-ospf-mt-ospfv3-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 29, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes an extensible mechanism to support multiple 43 topologies (MT) in OSPFv3. These topologies can be used within the 44 same address family in order to compute different paths for different 45 classes of service, or belong to different address families allowing 46 an integrated definition of address family with OSPFv3. The extension 47 described in this document can further facilitate any future 48 extensions of OSPFv3. 50 1. Introduction 52 Multi-topology routing as described in this document is similar in 53 concept to M-ISIS [M-ISIS]. It is used to introduce an integrated 54 definition of other address families in OSPFv3. Each address-family 55 may also need to support multiple topologies, to compute different 56 paths for different classes of service or in-band management network. 58 1.1. Requirements notation 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 63 [RFC-KEYWORDS]. 65 2. Potential Solutions 67 In order to support multiple topologies at least two different 68 solutions are possible. We discuss them briefly below, and describe 69 issues with each of them. 71 2.1 Using Different Instance IDs 73 [INSTANCES] defines a range of Instance IDs for each address family. 74 It is therefore possible to define multiple topologies by using 75 different Instance IDs. However this approach is inefficient due to 76 the overhead involved in having to manage multiple adjacencies, 77 multiple link-state databases etc. 79 2.2 Using an integrated approach with existing LSAs 81 Another solution would be to define multiple topologies as an 82 integrated approach within each instance. This can be done by 83 redefining an unused field in the link description of Router LSA and 84 define it as a multi-topology identifier (MT-ID). We will have to 85 generate N link descriptions for a link with N topologies configured 86 on it. This seems wasteful as the link description is replicated 87 N times, further we have some backward compatibility issues. 89 Also, there is a need to identify prefixes carried for each topology, 90 i.e. prefix-LSAs need to carry MT-IDs and there is no possibility to 91 reuse the existing prefix-LSAs. 93 3. Proposed Solution 95 We propose to define new LSAs in order to achieve this. Not only does 96 this allow an optimum definition of topologies within OSPFv3, it 97 also does not have any backward compatibility issues as new LSAs will 98 be ignored by old routers. 100 The flexible encoding proposed for the new LSAs can also facilitate 101 any future extension in OSPFv3. 103 4. MT Capability 105 We define a Multi-topology capability bit in Options filed. 107 0 1 2 108 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 109 -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+ 110 | | | | | | | | | | | | | |MT|AF|* |* |DC| R| N|MC| E|V6| 111 -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+ 113 The Options field 115 MT-bit 116 This bit is set when a router supports MT-OSPFv3 as specified 117 in this memo. 119 5. T-bit in LS type 121 We define a new T-bit (TLV based) in LS type field in order to extend 122 the existing LSAs. This will define new LSA types homogeneously 123 compared to the existing LSA types. The U-bit and the T-bit are set. 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 126 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 127 |U |S2|S1|T | LSA Function Code | 128 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 130 For the function codes defined in [OSPFv3] the LS types become: 132 LSA function code LS Type Description 133 ---------------------------------------------------- 134 1 0xB001 E-Router-LSA 135 2 0xB002 E-Network-LSA 136 3 0xB003 E-Inter-Area-Prefix-LSA 137 4 0xB004 E-Inter-Area-Router-LSA 138 5 0xD005 E-AS-External-LSA 139 6 0xB006 E-Group-membership-LSA 140 7 0xB007 E-Type-7-LSA 141 8 0x9008 E-Link-LSA 142 9 0xB009 E-Intra-Area-Prefix-LSA 144 6. OSPFv3 TLVs and sub-TLVs 146 All the Extended LSAs have a flexible TLV format encoding. OSPFv3 147 TLVs have a 16 bit Type and a 16 bit Length field followed by the 148 TLV value. TLV Length is set to the length of Value field in bytes. 149 Any unknown TLV/sub-TLV should be ignored. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | TLV Type | TLV Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 . . 157 . TLV Value . 158 . . 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 OSPFv3 TLV Format 163 sub-TLVs are similar to TLVs with an additional 16 bit Total sub-TLV 164 length (in bytes) and a 16 bit reserved field. If the TLV has 165 multiple Values, total sub-TLV length allows to locate the next 166 Value, when there are variable number of sub-TLVs present. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Total sub-TLV length | 0 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 . . 174 . TLVs . 175 . . 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 OSPFv3 sub-TLV Format 180 The presence of sub-TLVs is indicated by a S-bit in the value field 181 of TLVs. If the S-bit is set, the format of sub-TLVs is as specified 182 above. If the S-bit is clear, no sub-TLVs are added. 184 For LSAs which carry a prefix, we define S-bit in PrefixOptions. Note 185 that S-bit in PrefixOptions is only defined in Extended LSAs. 187 0 1 2 3 4 5 6 7 188 +--+--+--+--+--+--+--+--+ 189 |S | | | | P|MC|LA|NU| 190 +--+--+--+--+--+--+--+--+ 192 The Prefix Options field 194 7. Default Topology 196 In order to interact with non-MT capable routers we define default 197 topology as the topology that is built by using the existing LSAs as 198 specified in OSPFv3 [OSPFv3]. 200 We define MT topologies as topologies which are other than the 201 Default Topology. A MT topology will be defined by using the new LSAs 202 as specified in this memo. 204 When all routers are MT capable, there is no need to generate 205 existing LSAs as defined in [OSPFv3]. The new LSAs can be used even 206 for Default Topology. A global configurable parameter 207 RFC2740Compatibility (see Appendix A) is used to control the 208 generation of existing or new LSAs. 210 8. MT-ID Fields 212 We define a 8 bit MT-ID field which is present in various LSA types. 213 Each MT-ID is also accompanied with a MT-ID Metric field which 214 carries a metric specific to one MT. 216 When a MT capable router participates in Default Topology, depending 217 on RFC2740Compatibility (see Appendix A) it will generate existing 218 LSAs or extended LSAs for the Default Topology. 220 MT-ID value 0 is reserved for carrying information about Default 221 Topology in the new LSAs. 223 9. MT Control packet and IPv6 link local address 225 IPv6 link local address is MT independent and is used for MT-OSPFv3 226 control packets. 228 10. Forming adjacency in MT 230 Each interface can be configured to belong to a set of topologies. 231 A single adjacency will be formed even if the interface is configured 232 to participate in multiple topologies. 234 11. Advertising MT topology 236 When a router is configured with multiple topologies on a link, it 237 advertises the list of MT-IDs and their corresponding metrics in 238 E-router-LSA. When a MT-capable router participates in default 239 topology, based on RFC2740Compatibility it may generate existing or 240 Extended Router-LSAs. 242 Network LSAs are common to all MT. The DR will announce an adjacency 243 to all attached routers independently of their MT-ID value. When 244 RFC2740Compatibility is disabled on DR (and all routers should be MT 245 capable) E-network-LSA will be used instead of network-LSA. This 246 allow a smooth migration to extended LSAs. 248 12. Advertising MT prefix 250 When a MT-capable router participate in non-Default Topology, it 251 generates extended prefix LSAs with MT-ID in which it participates. 252 When a MT-capable router participates in default topology, based 253 on RFC2740Compatibility it may generate existing or Extended 254 prefix LSAs. 256 13. Advertising intra-area-prefix-LSA on multi-access link 258 On multi-access links, the DR is responsible to generate prefix-LSA 259 on behalf of the LAN, this is done by considering the prefix 260 advertised in link-LSAs. 262 If RFC2740Compatibility is disabled the DR will generate Extended 263 prefix-LSAs. If RFC2740Compatibility is enabled we select a 264 Multi-Topology DR (MT-DR) which generates the E-intra-area-prefix-LSA 265 on behalf of the LAN. 267 MT-DR is elected by considering the highest Router ID among 268 MT-capable routers (done by examining MT-bit of neighbors). 270 The E-intra-area-prefix-LSA generated by the MT-DR will have the 271 Referenced LS type set to 2, Referenced Link State ID set to DR's 272 Router ID and Referenced Advertising Router set to DR's Router ID. 273 Note that MT-DR's role is to just generate the 274 E-intra-area-prefix-LSA whereas DR is responsible for network LSA 275 generation and helping in flooding on the multi-access link. 277 14. MT Area Boundary 279 Area boundaries for all topologies are the same but an interface can 280 be configured to not participate in all topologies. This will make a 281 router's B-bit setting topology independent whereas reachability to 282 the ABR will be topology dependent. 284 15. MT SPF Computation 286 When a link participates in a topology, it's MT-ID value is carried 287 in extended Router-LSA. A separate SPF is computed for each topology 288 by considering only the link/metric for the corresponding topology. 290 Network LSAs are used by all topologies during the SPF computation. 291 Nexthops computed during the MT SPF MUST belong to the same topology. 293 Similarly when processing prefix-LSAs or external-LSAs, only prefixes 294 which contain a valid MT Metric for that MT SPF are considered 295 reachable in that topology. 297 During SPF computation for the Default Topology, independently of 298 RFC2740Compatibility value, extended LSA are used when present 299 otherwise existing LSA are used. This allows a smooth transition 300 across RFC2740Compatibility changes. 302 16. Forwarding in MT 304 Forwarding must make sure that only routes belonging to the single 305 topology are used to forward the packet along its way from source to 306 destination. Therefore user configuration MUST be consistently 307 applied throughout the network so that an incoming packet be 308 associated with the corresponding topology. It is outside of the 309 scope of this document to consider different methods of associating 310 an incoming packet to the corresponding topology routes. 312 17. MT-ID reserved value 314 The following MT-ID values are defined: 316 0 - Reserved for IPv6 unicast topology 317 1 - Reserved for IPv4 in-band management purposes 318 2 - Reserved for IPv4 unicast topology 319 3 - Reserved for IPv6 multicast topology 320 4 - Reserved for IPv4 multicast topology 321 5-31 - Reserved for IETF consensus. 322 32-255 - Reserved for development, experimental and 323 proprietary features [RFC3692]. 325 18. IPv4 address family considerations 327 OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses 328 for OSPFv3 control packets and next hop calculations. Although IPV6 329 link local addresses could be used as next hops for IPv4 address 330 families, it is desirable to have IPv4 next hop addresses. For 331 example, in IPv4 multicast having the nexthop address the same as 332 the PIM neighbor address (IPv4 address) makes it easier to know to 333 which upstream neighbor to send a PIM join when doing a RPF lookup 334 for a source. It is also easier for troubleshooting purposes to have 335 a next hop with the same semantics as the AF. 337 In order to achieve this, the link's IPv4 address will be advertised 338 in the E-link-LSA, see section 20.6. 340 We call direct interface address (DIA) the address that is reachable 341 directly via the link provided that a layer 3 to layer 2 mapping is 342 available. Note that there is no explicit need for the IPv4 link 343 addresses to be on the same subnet. An implementation should resolve 344 layer 3 to layer 2 mappings via ARP or ND for a DIA even if the IPv4 345 address is not on the same subnet as the router's interface IP 346 address. 348 19. Backward compatibility and interaction with non-MT routers 350 An MT capable router will interact (in Default Topology) with non-MT 351 capable routers by using the existing LSAs. MT information is carried 352 in new LSAs which are ignored by non-MT routers therefore this 353 document does not introduce any backward compatibility issues. 355 When all routers are MT capable, RFC2740Compatibility can be set to 356 disable and only extended LSAs are used for Default Topology. 358 20. Extended LSA Formats 360 20.1 Extended Router-LSA 362 We define a new E-router-LSA with LS type equal to 0xB001. This LSA, 363 extends router LSA by defining TLVs within the LSA payload. The LSA 364 has a fixed portion followed by TLVs. Each TLV could further contains 365 sub-TLVs. 367 The processing and generation of this LSA is the same as for 368 router-LSA defined in [OSPFv3]. 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | LS age |0|0|1|1| 1 | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Link State ID | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Advertising Router | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | LS sequence number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | LS checksum | length | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | 0 |W|V|E|B| Options | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 . . 386 . TLVs . 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 All fields are defined as in [OSPFv3]. 392 We define a Link-description TLV (LD-TLV). This TLV extends the 393 router-LSA payload by defining sub-TLVs within each link description. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | 1 (LD-TLV) | TLV Length | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Link-Type | Reserved | Link-Block Length | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Interface ID | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Neighbor Interface ID | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Neighbor Router ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 . . 409 . sub-TLVs . 410 . . 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | ... | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Link-Type | Reserved | Link-Block Length | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Interface ID | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Neighbor Interface ID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Neighbor Router ID | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 . . 423 . sub-TLVs . 424 . . 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | ... | 428 Link-Block Length : Define the length of link block including 429 Link-Type, Reserved, Link-Block Length, fixed ID 430 fields and sub-TLVs. 432 All other fields are defined as in [OSPFv3]. 434 LD-TLV is the only top level TLV defined in this document. This TLV 435 should not be repeated within an E-router-LSA fragment, instead 436 multiple link descriptions are included within the LD-TLV (Total 437 sub-TLV length indicates the next link description). 439 We define a Router Multi-Topology sub-TLV (RMT-sTLV) below. This 440 sub-TLV could further contain sub-TLVs. 442 E-router-LSA must contain the LD-TLV and each link description must 443 contain the RMT-sTLV. 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | 1 (RMT-sTLV) | Length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | MT-ID | 0 |S| MT-ID metric | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | ... | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | MT-ID | 0 |S| MT-ID metric | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | ... | 458 When a link participates in different topologies, it will include the 459 RMT-sTLV with MT-IDs and MT-ID metrics for corresponding topologies. 461 20.2 Extended Network-LSA 463 The network LSA does not contain any MT information as the DR is 464 shared by all topologies therefore the existing network LSA can be 465 used independently of the router participation in a MT. 467 However we define an E-network-LSA in order to allow for any future 468 extensions. The LS type is equal to 0xB002. This LSA extends 469 network-LSA by defining TLVs within the LSA payload. 471 The processing and generation of this LSA is the same as for 472 network-LSA defined in [OSPFv3]. 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | LS age |0|0|1|1| 2 | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Link State ID | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Advertising Router | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | LS sequence number | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | LS checksum | length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 . . 488 . TLVs . 489 . . 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 All fields are defined as in [OSPFv3]. 494 We define a Attached-Router TLV (AR-TLV). This TLV has similar 495 contents as the network-LSA payload. 497 E-network-LSA must contain AR-TLV. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | 1 (AR-TLV) | TLV Length | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | 0 | Options | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Attached Router | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | ... | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Attached Router | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | ... | 514 All fields are defined as in [OSPFv3]. 516 20.3 Extended Inter-Area-Prefix-LSA 518 We define a new E-inter-area-prefix-LSA with LS type of 0xB003. It is 519 originated by area border routers to describe routes to prefixes 520 associated with a MT-ID that belong to other areas. 522 An implementation could decide to advertise one or more prefixes 523 within one E-inter-area-prefix-LSA. 525 The processing and generation of this LSA is the same as for as 526 inter-area-prefix-LSA as defined in [OSPFv3]. 528 0 1 2 3 529 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 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | LS age |0|0|1|1| 3 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Link State ID | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Advertising Router | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | LS sequence number | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | LS checksum | length | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Prefix-Block Length | PrefixLength | Reserved | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Address Prefix | 544 | ... | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 . . 547 . TLVs . 548 . . 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | ... | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Prefix-Block Length | PrefixLength | Reserved | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Address Prefix | 555 | ... | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 . . 558 . TLVs . 559 . . 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | ... | 563 Prefix-Block Length : Define the length of prefix block including 564 Prefix-Block Length, PrefixLength, Reserved 565 field, Address Prefix and TLVs. 567 All other fields are defined as in [OSPFv3]. 569 We define an Inter Prefix Multi-Topology TLV (IPMT-TLV) below. This 570 TLV could further contain sub-TLVs. 572 E-inter-area-prefix-LSA must contain one or more prefix blocks and 573 each prefix block must contain the IPMT-TLV. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | 1 (IPMT-TLV) | Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | MT-ID | MT-ID metric | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | PrefixOptions | 0 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | ... | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | MT-ID | MT-ID metric | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | PrefixOptions | 0 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | ... | 592 20.4 Extended Inter-Area-Router-LSA 594 We define a new E-inter-area-router-LSA with LS type of 0xB004. This 595 LSA is originated by area border routers and describes routes to 596 routers in other areas. 598 An implementation could decide to advertise information about one or 599 more routers within one E-inter-area-router-LSA. 601 The processing and generation of this LSA is the same as for as 602 inter-area-router-LSA as defined in [OSPFv3]. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | LS age |0|0|1|1| 4 | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Link State ID | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Advertising Router | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | LS sequence number | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | LS checksum | length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | 0 | Options | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 . . 621 . TLVs . 622 . . 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 All fields are defined as in [OSPFv3]. 627 We define a Dest-Router TLV (DR-TLV) below. This TLV extends the 628 Inter-area-router-LSA payload by defining sub-TLVs within each 629 Destination Router. 631 E-inter-area-router-LSA must contain the DR-TLV. 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | 1 (DR-TLV) | Length | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Destination Router ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 . . 641 . sub-TLVs . 642 . . 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | ... | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Destination Router ID | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 . . 649 . sub-TLVs . 650 . . 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | ... | 653 Destination Router ID: It is defined in [OSPFv3]. 655 DR-TLV is the only top level TLV defined by this document. This TLV 656 should not be repeated within an E-Inter-area-router-LSA, instead 657 multiple destination router values are included within the DR-TLV 658 (Total sub-TLV length indicates the next destination router value). 660 We define an Inter Router Multi-Topology sub-TLV (IRMT-sTLV) below. 662 DR-TLV must contain the IRMT-sTLV. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | 1 (IRMT-sTLV) | Length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | MT-ID | MT-ID metric | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | ... | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | MT-ID | MT-ID metric | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | ... | 677 20.5 Extended AS-external-LSA 679 We define a new E-AS-external-LSA with LS type of 0xD005. This LSA is 680 originated by AS boundary routers, and describes destinations 681 external to the AS associated to a MT-ID. An implementation could 682 decide to advertise one or more prefixes within one 683 E-AS-external-LSA. 685 The processing and generation of this LSA is the same as for an 686 AS-external-LSA as defined in [OSPFv3]. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | LS age |0|1|0|1| 5 | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Link State ID | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Advertising Router | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | LS sequence number | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | LS checksum | length | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Prefix-Block Length | PrefixLength | Reserved | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Address Prefix | 704 | ... | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 . . 707 . TLVs . 708 . . 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | ... | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Prefix-Block Length | PrefixLength | Reserved | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Address Prefix | 715 | ... | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 . . 718 . TLVs . 719 . . 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | ... | 723 Prefix-Block Length : Define the length of prefix block including 724 Prefix-Block Length, PrefixLength, Reserved 725 field, Address Prefix and TLVs. 727 All other fields are defined as in [OSPFv3] 729 We define an External Prefix Multi-Topology TLV (EMT-TLV) below. This 730 EMT-TLV could further contain sub-TLVs. 732 E-AS-external-LSA must contain one or more prefix blocks and each 733 prefix block must contain the EMT-TLV. 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | 1 (EMT-TLV) | Length | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | MT-ID | MT-ID metric | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | |E|F|T| PrefixOptions| Referenced LS Type | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | | 745 +- -+ 746 | | 747 +- Forwarding Address (Optional) -+ 748 | | 749 +- -+ 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | External Route Tag (Optional) | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Referenced Link State ID (Optional) | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | ... | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | MT-ID | MT-ID metric | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | |E|F|T| PrefixOptions| Referenced LS Type | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | | 763 +- -+ 764 | | 765 +- Forwarding Address (Optional) -+ 766 | | 767 +- -+ 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | External Route Tag (Optional) | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Referenced Link State ID (Optional) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | ... | 776 Note that when the sub-TLV is present (S-bit set in the 777 PrefixOptions) the sub-TLV is placed after Forwarding address and 778 external route Tag if they are present. 780 20.6 Extended Link-LSA 782 We define a new E-link-LSA with LS type of 0x9008. This LSA is 783 generated for each link and carries each link's prefix in the 784 corresponding topology. It also carries next hop IP information 785 for the supported address families. 787 The processing and generation of this LSA is the same as for link-lsa 788 as defined in [OSPFv3]. This LSA has a fixed portion followed by 789 TLVs. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | LS age |0|0|0|1| 8 | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Link State ID | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Advertising Router | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | LS sequence number | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | LS checksum | length | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Rtr Pri | Options | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 . . 807 . TLVs . 808 . . 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 We define the following three TLVs 813 o IPv6 Next hop TLV (NH6-TLV) 814 o IPv4 Next hop TLV (NH4-TLV) 815 o Prefix Multi-topology TLV (PMT-TLV) 817 Next hop TLVs carry IPv6/IPv4 information for next hop calculation. 818 IPv6 next hop information MUST be a link local IPv6 address. 819 Prefix-TLV carries router link's prefix on multi-access link. This 820 information is used by DR in order to include those prefix in its 821 E-intra-area prefix LSA. 823 NH6-TLV has the following format: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | 1 (NH6-TLV) | Length | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | | 831 +- -+ 832 | | 833 +- Link-local Interface Address -+ 834 | | 835 +- -+ 836 | | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 This TLV MUST be present if the link participate in a MT belonging 840 to IPv6 address family. 842 NH4-TLV has the following format: 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | 2 (NH4-TLV) | Length | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | IPv4 address | 850 +---------------------------------------------------------------+ 852 This TLV MUST be present if the link participate in a MT belonging 853 to IPv4 address family. 855 PMT-TLV extends link-LSA by defining TLV under each address prefix. 856 This TLV should only be present on multi-access links. 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | 3 (PMT-TLV) | Length | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | # prefixes | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Prefix-Block Length | PrefixLength | Reserved | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Address Prefix | 869 | ... | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 . . 872 . TLVs . 873 . . 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | ... | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Prefix-Block Length | PrefixLength | Reserved | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Address Prefix | 880 | ... | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 . . 883 . TLVs . 884 . . 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | ... | 888 Prefix-Block Length : Define the length of prefix block including 889 Prefix-Block Length, PrefixLength, Reserved 890 field, Address Prefix and TLVs. 892 All other fields are defined as in [OSPFv3]. 894 We define a Link Multi-Topology sub-TLV (LMT-sTLV) below. This 895 sub-TLV could further contain sub-TLVs. 897 Each prefix block must contain the LMT-sTLV. 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | 1 (LMT-sTLV) | Length | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | MT-ID | PrefixOptions | 0 | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | ... | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | MT-ID | PrefixOptions | 0 | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | ... | 912 20.7 Extended Intra-Area-Prefix-LSA 914 We define a new E-intra-area-prefix-LSA with LS type of 0xB009. A 915 router generates E-Intra-Area-Prefix-LSAs to advertise one or more 916 prefixes associated with a topology. 918 The processing and generation of this LSA is the same as for 919 intra-area-prefix-LSA defined in [OSPFv3]. 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | LS age |0|0|1|1| 9 | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Link State ID | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Advertising Router | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | LS sequence number | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | LS checksum | length | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | # prefixes | Referenced LS type | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | Referenced Link State ID | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Referenced Advertising Router | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Prefix-Block Length | PrefixLength | Reserved | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Address Prefix | 943 | ... | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 . . 946 . TLVs . 947 . . 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | ... | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Prefix-Block Length | PrefixLength | Reserved | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Address Prefix | 954 | ... | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 . . 957 . TLVs . 958 . . 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | ... | 962 Prefix-Block Length : Define the length of prefix block including 963 Prefix-Block Length, PrefixLength, Reserved 964 field, Address Prefix and TLVs. 966 All other fields are defined as in [OSPFv3]. 968 We define a Prefix Multi-Topology TLV (PMT-TLV) below. This TLV could 969 further contain sub-TLVs. 971 E-intra-area-prefix-LSA must contain one or more prefix blocks and 972 each prefix block must contain the PMT-TLV. 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | 1 (PMT-TLV) | Length | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | MT-ID | PrefixOptions | MT-ID metric | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | ... | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | MT-ID | PrefixOptions | MT-ID metric | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | ... | 987 21. Security Considerations 989 The technique described in this document does not introduce any new 990 security issues to the OSPFv3 protocol. 992 22. Acknowledgements 994 The authors would like to thank Alex Zinin, Acee Lindem, Tom 995 Henderson, Jeff Ahrenholz and Paul Wells for their comments on the 996 document. 998 23. IANA Considerations 999 IANA is requested to create a new registry, "OSPFv3 multi-topology ID 1000 values" with the assignment listed in Section 17 of this document 1001 and registration policies for future assignments. 1003 24. References 1005 Normative References 1007 [OSPFv3] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", 1008 RFC 2740, December 1999. 1010 [RFC3692] Narten, T., "Assigning Experimental and Testing 1011 Numbers Considered Useful", BCP 82, RFC 3692, January 1012 2004. 1014 [RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate 1015 Requirement Levels", RFC 2119, March 1997. 1017 Informative Reference 1019 [INSTANCES] Mirtorabi, S. et al, "Support of address families in 1020 OSPFv3", Internet Draft, work in progress 1022 [M-ISIS] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology 1023 (MT) Routing in IS-IS", Internet Draft, work in progress 1025 Appendix A. Global Parameter 1027 RFC2740Compatibility 1028 This parameter controls which LSAs are used for Default Topology. 1029 When set to "enabled", the Default Topology is described using 1030 existing LSAs [OSPFv3]. When set to "disabled" the Default Topology 1031 is described using Extended LSAs as specified in this memo. This 1032 parameter is set to "enabled" by default. 1034 Authors' Addresses 1036 Sina Mirtorabi Abhay Roy 1037 Force10 Networks Cisco Systems 1038 350 Holger Way 170 W. Tasman Dr. 1039 San Jose, CA 95134, USA San Jose, CA 95134, USA 1041 E-mail: sina@force10netwroks.com E-mail: akr@cisco.com 1043 Full Copyright Statement 1045 Copyright (C) The IETF Trust (2007). 1047 This document is subject to the rights, licenses and restrictions 1048 contained in BCP 78, and except as set forth therein, the authors 1049 retain all their rights. 1051 This document and the information contained herein are provided on an 1052 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1053 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1054 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1055 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1056 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1057 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1059 Intellectual Property 1061 The IETF takes no position regarding the validity or scope of any 1062 Intellectual Property Rights or other rights that might be claimed to 1063 pertain to the implementation or use of the technology described in 1064 this document or the extent to which any license under such rights 1065 might or might not be available; nor does it represent that it has 1066 made any independent effort to identify any such rights. Information 1067 on the procedures with respect to rights in RFC documents can be 1068 found in BCP 78 and BCP 79. 1070 Copies of IPR disclosures made to the IETF Secretariat and any 1071 assurances of licenses to be made available, or the result of an 1072 attempt made to obtain a general license or permission for the use of 1073 such proprietary rights by implementers or users of this 1074 specification can be obtained from the IETF on-line IPR repository at 1075 http://www.ietf.org/ipr. 1077 The IETF invites any interested party to bring to its attention any 1078 copyrights, patents or patent applications, or other proprietary 1079 rights that may cover technology that may be required to implement 1080 this standard. Please address the information to the IETF at 1081 ietf-ipr@ietf.org. 1083 Acknowledgment 1085 Funding for the RFC Editor function is provided by the IETF 1086 Administrative Support Activity (IASA).