idnits 2.17.1 draft-ietf-ospf-mt-ospfv3-01.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 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1040. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 284: '...uring the MT SPF MUST belong to the sa...' RFC 2119 keyword, line 299: '...ser configuration MUST be consistently...' RFC 2119 keyword, line 806: '... hop information MUST be a link local ...' RFC 2119 keyword, line 827: '... This TLV MUST be present if the link...' RFC 2119 keyword, line 840: '... This TLV MUST be present if the link...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 2006) is 6614 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: 7 errors (**), 0 flaws (~~), 3 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 Abhay Roy 4 Expiration Date: September 2006 Cisco Systems 5 File name: draft-ietf-ospf-mt-ospfv3-01.txt 6 March 2006 8 Multi-topology routing in OSPFv3 (MT-OSPFv3) 9 draft-ietf-ospf-mt-ospfv3-01.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 5, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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. Motivation 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 2. Potential Solutions 60 In order to support multiple topologies at least two different 61 solutions are possible. We discuss them briefly below, and describe 62 issues with each of them. 64 2.1 Using Different Instance IDs 66 [INSTANCES] defines a range of Instance IDs for each address family. 67 It is therefore possible to define multiple topologies by using 68 different Instance IDs. However this approach is inefficient due to 69 the overhead involved in having to manage multiple adjacencies, 70 multiple link-state databases etc. 72 2.2 Using an integrated approach with existing LSAs 74 Another solution would be to define multiple topologies as an 75 integrated approach within each instance. This can be done by 76 redefining an unused field in the link description of Router LSA and 77 define it as a multi-topology identifier (MT-ID). We will have to 78 generate N link descriptions for a link with N topologies configured 79 on it. This seems wasteful as the link description is replicated 80 N times, further we have some backward compatibility issues. 82 Also, there is a need to identify prefixes carried for each topology, 83 i.e. prefix-LSAs need to carry MT-IDs and there is no possibility to 84 reuse the existing prefix-LSAs. 86 3. Proposed Solution 88 We propose to define new LSAs in order to achieve this. Not only does 89 this allow an optimum definition of topologies within OSPFv3, it 90 also does not have any backward compatibility issues as new LSAs will 91 be ignored by old routers. 93 The flexible encoding proposed for the new LSAs can also facilitate 94 any future extension in OSPFv3. 96 4. MT Capability 98 We define a Multi-topology capability bit in Options filed. 100 0 1 2 101 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 102 -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+ 103 | | | | | | | | | | | | | |MT|AF|* |* |DC| R| N|MC| E|V6| 104 -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+ 106 The Options field 108 MT-bit 109 This bit is set when a router supports MT-OSPFv3 as specified 110 in this memo. 112 5. T-bit in LS type 114 We define a new T-bit (TLV based) in LS type field in order to extend 115 the existing LSAs. This will define new LSA types homogeneously 116 compared to the existing LSA types. The U-bit and the T-bit are set. 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 119 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 120 |U |S2|S1|T | LSA Function Code | 121 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 123 For the function codes defined in [OSPFv3] the LS types become: 125 LSA function code LS Type Description 126 ---------------------------------------------------- 127 1 0xB001 E-Router-LSA 128 2 0xB002 E-Network-LSA 129 3 0xB003 E-Inter-Area-Prefix-LSA 130 4 0xB004 E-Inter-Area-Router-LSA 131 5 0xD005 E-AS-External-LSA 132 6 0xB006 E-Group-membership-LSA 133 7 0xB007 E-Type-7-LSA 134 8 0x9008 E-Link-LSA 135 9 0xB009 E-Intra-Area-Prefix-LSA 137 6. OSPFv3 TLVs and sub-TLVs 139 All the Extended LSAs have a flexible TLV format encoding. OSPFv3 140 TLVs have a 16 bit Type and a 16 bit Length field followed by the 141 TLV value. TLV Length is set to the length of Value field in bytes. 142 Any unknown TLV/sub-TLV should be ignored. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | TLV Type | TLV Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 . . 150 . TLV Value . 151 . . 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 OSPFv3 TLV Format 156 sub-TLVs are similar to TLVs with an additional 16 bit Total sub-TLV 157 length (in bytes) and a 16 bit reserved field. If the TLV has 158 multiple Values, total sub-TLV length allows to locate the next 159 Value, when there are variable number of sub-TLVs present. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Total sub-TLV length | 0 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 . . 167 . TLVs . 168 . . 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 OSPFv3 sub-TLV Format 173 The presence of sub-TLVs is indicated by a S-bit in the value field 174 of TLVs. If the S-bit is set, the format of sub-TLVs is as specified 175 above. If the S-bit is clear, no sub-TLVs are added. 177 For LSAs which carry a prefix, we define S-bit in PrefixOptions. Note 178 that S-bit in PrefixOptions is only defined in Extended LSAs. 180 0 1 2 3 4 5 6 7 181 +--+--+--+--+--+--+--+--+ 182 |S | | | | P|MC|LA|NU| 183 +--+--+--+--+--+--+--+--+ 185 The Prefix Options field 187 7. Default Topology 189 In order to interact with non-MT capable routers we define default 190 topology as the topology that is built by using the existing LSAs as 191 specified in OSPFv3 [OSPFv3]. 193 We define MT topologies as topologies which are other than the 194 Default Topology. A MT topology will be defined by using the new LSAs 195 as specified in this memo. 197 When all routers are MT capable, there is no need to generate 198 existing LSAs as defined in [OSPFv3]. The new LSAs can be used even 199 for Default Topology. A global configurable parameter 200 RFC2740Compatibility (see Appendix A) is used to control the 201 generation of existing or new LSAs. 203 8. MT-ID Fields 205 We define a 8 bit MT-ID field which is present in various LSA types. 206 Each MT-ID is also accompanied with a MT-ID Metric field which 207 carries a metric specific to one MT. 209 When a MT capable router participates in Default Topology, depending 210 on RFC2740Compatibility (see Appendix A) it will generate existing 211 LSAs or extended LSAs for the Default Topology. 213 MT-ID value 0 is reserved for carrying information about Default 214 Topology in the new LSAs. 216 9. MT Control packet and IPv6 link local address 218 IPv6 link local address is MT independent and is used for MT-OSPFv3 219 control packets. 221 10. Forming adjacency in MT 223 Each interface can be configured to belong to a set of topologies. 224 A single adjacency will be formed even if the interface is configured 225 to participate in multiple topologies. 227 11. Advertising MT topology 229 When a router is configured with multiple topologies on a link, it 230 advertises the list of MT-IDs and their corresponding metrics in 231 E-router-LSA. When a MT-capable router participates in default 232 topology, based on RFC2740Compatibility it may generate existing or 233 Extended Router-LSAs. 235 Network LSAs are common to all MT. The DR will announce an adjacency 236 to all attached routers independently of their MT-ID value. When 237 RFC2740Compatibility is disabled on DR (and all routers should be MT 238 capable) E-network-LSA will be used instead of network-LSA. This 239 allow a smooth migration to extended LSAs. 241 12. Advertising MT prefix 243 When a MT-capable router participate in non-Default Topology, it 244 generates extended prefix LSAs with MT-ID in which it participates. 245 When a MT-capable router participates in default topology, based 246 on RFC2740Compatibility it may generate existing or Extended 247 prefix LSAs. 249 13. Advertising intra-area-prefix-LSA on multi-access link 251 On multi-access links, the DR is responsible to generate prefix-LSA 252 on behalf of the LAN, this is done by considering the prefix 253 advertised in link-LSAs. 255 If RFC2740Compatibility is disabled the DR will generate Extended 256 prefix-LSAs. If RFC2740Compatibility is enabled we select a 257 Multi-Topology DR (MT-DR) which generates the E-intra-area-prefix-LSA 258 on behalf of the LAN. 260 MT-DR is elected by considering the highest Router ID among 261 MT-capable routers (done by examining MT-bit of neighbors). 263 The E-intra-area-prefix-LSA generated by the MT-DR will have the 264 Referenced LS type set to 2, Referenced Link State ID set to DR's 265 Router ID and Referenced Advertising Router set to DR's Router ID. 266 Note that MT-DR's role is to just generate the 267 E-intra-area-prefix-LSA whereas DR is responsible for network LSA 268 generation and helping in flooding on the multi-access link. 270 14. MT Area Boundary 272 Area boundaries for all topologies are the same but an interface can 273 be configured to not participate in all topologies. This will make a 274 router's B-bit setting topology independent whereas reachability to 275 the ABR will be topology dependent. 277 15. MT SPF Computation 279 When a link participates in a topology, it's MT-ID value is carried 280 in extended Router-LSA. A separate SPF is computed for each topology 281 by considering only the link/metric for the corresponding topology. 283 Network LSAs are used by all topologies during the SPF computation. 284 Nexthops computed during the MT SPF MUST belong to the same topology. 286 Similarly when processing prefix-LSAs or external-LSAs, only prefixes 287 which contain a valid MT Metric for that MT SPF are considered 288 reachable in that topology. 290 During SPF computation for the Default Topology, independently of 291 RFC2740Compatibility value, extended LSA are used when present 292 otherwise existing LSA are used. This allows a smooth transition 293 across RFC2740Compatibility changes. 295 16. Forwarding in MT 297 Forwarding must make sure that only routes belonging to the single 298 topology are used to forward the packet along its way from source to 299 destination. Therefore user configuration MUST be consistently 300 applied throughout the network so that an incoming packet be 301 associated with the corresponding topology. It is outside of the 302 scope of this document to consider different methods of associating 303 an incoming packet to the corresponding topology routes. 305 17. MT reserved value 307 The following MT range are pre-assigned: 309 MT#0 - MT#7 IPv6 Unicast 310 MT#8 - MT#15 IPv6 Multicast 311 MT#16 - MT#23 IPv4 Unicast 312 MT#24 - MT#31 IPv4 Multicast 313 MT#33 - MT#255 Reserved 315 18. IPv4 address family considerations 317 OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses 318 for OSPFv3 control packets and next hop calculations. Although IPV6 319 link local addresses could be used as next hops for IPv4 address 320 families, it is desirable to have IPv4 next hop addresses. For 321 example, in IPv4 multicast having the nexthop address the same as 322 the PIM neighbor address (IPv4 address) makes it easier to know to 323 which upstream neighbor to send a PIM join when doing a RPF lookup 324 for a source. It is also easier for troubleshooting purposes to have 325 a next hop with the same semantics as the AF. 327 In order to achieve this, the link's IPv4 address will be advertised 328 in the E-link-LSA, see section 20.6. 330 We call direct interface address (DIA) the address that is reachable 331 directly via the link provided that a layer 3 to layer 2 mapping is 332 available. Note that there is no explicit need for the IPv4 link 333 addresses to be on the same subnet. An implementation should resolve 334 layer 3 to layer 2 mappings via ARP or ND for a DIA even if the IPv4 335 address is not on the same subnet as the router's interface IP 336 address. 338 19. Backward compatibility and interaction with non-MT routers 340 An MT capable router will interact (in Default Topology) with non-MT 341 capable routers by using the existing LSAs. MT information is carried 342 in new LSAs which are ignored by non-MT routers therefore this 343 document does not introduce any backward compatibility issues. 345 When all routers are MT capable, RFC2740Compatibility can be set to 346 disable and only extended LSAs are used for Default Topology. 348 20. Extended LSA Formats 350 20.1 Extended Router-LSA 352 We define a new E-router-LSA with LS type equal to 0xB001. This LSA, 353 extends router LSA by defining TLVs within the LSA payload. The LSA 354 has a fixed portion followed by TLVs. Each TLV could further contains 355 sub-TLVs. 357 The processing and generation of this LSA is the same as for 358 router-LSA defined in [OSPFv3]. 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | LS age |0|0|1|1| 1 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Link State ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Advertising Router | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | LS sequence number | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | LS checksum | length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | 0 |W|V|E|B| Options | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 . . 376 . TLVs . 377 . . 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 All fields are defined as in [OSPFv3]. 381 We define a Link-description TLV (LD-TLV). This TLV extends the 382 router-LSA payload by defining sub-TLVs within each link description. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | 1 (LD-TLV) | TLV Length | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Link-Type | Reserved | Link-Block Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Interface ID | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Neighbor Interface ID | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Neighbor Router ID | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 . . 398 . sub-TLVs . 399 . . 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | ... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Link-Type | Reserved | Link-Block Length | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Interface ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Neighbor Interface ID | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Neighbor Router ID | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 . . 412 . sub-TLVs . 413 . . 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | ... | 417 Link-Block Length : Define the length of link block including 418 Link-Type, Reserved, Link-Block Length, fixed ID 419 fields and sub-TLVs. 421 All other fields are defined as in [OSPFv3]. 423 LD-TLV is the only top level TLV defined in this document. This TLV 424 should not be repeated within an E-router-LSA fragment, instead 425 multiple link descriptions are included within the LD-TLV (Total 426 sub-TLV length indicates the next link description). 428 We define a Router Multi-Topology sub-TLV (RMT-sTLV) below. This 429 sub-TLV could further contain sub-TLVs. 431 E-router-LSA must contain the LD-TLV and each link description must 432 contain the RMT-sTLV. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | 1 (RMT-sTLV) | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | MT-ID | 0 |S| MT-ID metric | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | ... | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | MT-ID | 0 |S| MT-ID metric | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | ... | 447 When a link participates in different topologies, it will include the 448 RMT-sTLV with MT-IDs and MT-ID metrics for corresponding topologies. 450 20.2 Extended Network-LSA 452 The network LSA does not contain any MT information as the DR is 453 shared by all topologies therefore the existing network LSA can be 454 used independently of the router participation in a MT. 456 However we define an E-network-LSA in order to allow for any future 457 extensions. The LS type is equal to 0xB002. This LSA extends 458 network-LSA by defining TLVs within the LSA payload. 460 The processing and generation of this LSA is the same as for 461 network-LSA defined in [OSPFv3]. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | LS age |0|0|1|1| 2 | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Link State ID | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Advertising Router | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | LS sequence number | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | LS checksum | length | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 . . 477 . TLVs . 478 . . 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 All fields are defined as in [OSPFv3]. 483 We define a Attached-Router TLV (AR-TLV). This TLV has similar 484 contents as the network-LSA payload. 486 E-network-LSA must contain AR-TLV. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | 1 (AR-TLV) | TLV Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | 0 | Options | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Attached Router | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ... | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Attached Router | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | ... | 503 All fields are defined as in [OSPFv3]. 505 20.3 Extended Inter-Area-Prefix-LSA 507 We define a new E-inter-area-prefix-LSA with LS type of 0xB003. It is 508 originated by area border routers to describe routes to prefixes 509 associated with a MT-ID that belong to other areas. 511 An implementation could decide to advertise one or more prefixes 512 within one E-inter-area-prefix-LSA. 514 The processing and generation of this LSA is the same as for as 515 inter-area-prefix-LSA as defined in [OSPFv3]. 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | LS age |0|0|1|1| 3 | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Link State ID | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Advertising Router | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | LS sequence number | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | LS checksum | length | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Prefix-Block Length | PrefixLength | Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Address Prefix | 533 | ... | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 . . 536 . TLVs . 537 . . 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | ... | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Prefix-Block Length | PrefixLength | Reserved | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Address Prefix | 544 | ... | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 . . 547 . TLVs . 548 . . 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | ... | 551 Prefix-Block Length : Define the length of prefix block including 552 Prefix-Block Length, PrefixLength, Reserved 553 field, Address Prefix and TLVs. 555 All other fields are defined as in [OSPFv3]. 557 We define an Inter Prefix Multi-Topology TLV (IPMT-TLV) below. This 558 TLV could further contain sub-TLVs. 560 E-inter-area-prefix-LSA must contain one or more prefix blocks and 561 each prefix block must contain the IPMT-TLV. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | 1 (IPMT-TLV) | Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | MT-ID | MT-ID metric | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | PrefixOptions | 0 | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | ... | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | MT-ID | MT-ID metric | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | PrefixOptions | 0 | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | ... | 580 20.4 Extended Inter-Area-Router-LSA 582 We define a new E-inter-area-router-LSA with LS type of 0xB004. This 583 LSA is originated by area border routers and describes routes to 584 routers in other areas. 586 An implementation could decide to advertise information about one or 587 more routers within one E-inter-area-router-LSA. 589 The processing and generation of this LSA is the same as for as 590 inter-area-router-LSA as defined in [OSPFv3]. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | LS age |0|0|1|1| 4 | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Link State ID | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Advertising Router | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | LS sequence number | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | LS checksum | length | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | 0 | Options | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 . . 609 . TLVs . 610 . . 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 All fields are defined as in [OSPFv3]. 615 We define a Dest-Router TLV (DR-TLV) below. This TLV extends the 616 Inter-area-router-LSA payload by defining sub-TLVs within each 617 Destination Router. 619 E-inter-area-router-LSA must contain the DR-TLV. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | 1 (DR-TLV) | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Destination Router ID | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 . . 629 . sub-TLVs . 630 . . 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | ... | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Destination Router ID | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 . . 637 . sub-TLVs . 638 . . 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | ... | 641 Destination Router ID: It is defined in [OSPFv3]. 643 DR-TLV is the only top level TLV defined by this document. This TLV 644 should not be repeated within an E-Inter-area-router-LSA, instead 645 multiple destination router values are included within the DR-TLV 646 (Total sub-TLV length indicates the next destination router value). 648 We define an Inter Router Multi-Topology sub-TLV (IRMT-sTLV) below. 650 DR-TLV must contain the IRMT-sTLV. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | 1 (IRMT-sTLV) | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | MT-ID | MT-ID metric | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | ... | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | MT-ID | MT-ID metric | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | ... | 665 20.5 Extended AS-external-LSA 667 We define a new E-AS-external-LSA with LS type of 0xD005. This LSA is 668 originated by AS boundary routers, and describes destinations 669 external to the AS associated to a MT-ID. An implementation could 670 decide to advertise one or more prefixes within one 671 E-AS-external-LSA. 673 The processing and generation of this LSA is the same as for an 674 AS-external-LSA as defined in [OSPFv3]. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | LS age |0|1|0|1| 5 | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Link State ID | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Advertising Router | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | LS sequence number | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | LS checksum | length | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Prefix-Block Length | PrefixLength | Reserved | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Address Prefix | 692 | ... | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 . . 695 . TLVs . 696 . . 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | ... | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Prefix-Block Length | PrefixLength | Reserved | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Address Prefix | 703 | ... | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 . . 706 . TLVs . 707 . . 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | ... | 711 Prefix-Block Length : Define the length of prefix block including 712 Prefix-Block Length, PrefixLength, Reserved 713 field, Address Prefix and TLVs. 715 All other fields are defined as in [OSPFv3] 717 We define an External Prefix Multi-Topology TLV (EMT-TLV) below. This 718 EMT-TLV could further contain sub-TLVs. 720 E-AS-external-LSA must contain one or more prefix blocks and each 721 prefix block must contain the EMT-TLV. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | 1 (EMT-TLV) | Length | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | MT-ID | MT-ID metric | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | |E|F|T| PrefixOptions| Referenced LS Type | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | | 733 +- -+ 734 | | 735 +- Forwarding Address (Optional) -+ 736 | | 737 +- -+ 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | External Route Tag (Optional) | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Referenced Link State ID (Optional) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | ... | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | MT-ID | MT-ID metric | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | |E|F|T| PrefixOptions| Referenced LS Type | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 +- -+ 752 | | 753 +- Forwarding Address (Optional) -+ 754 | | 755 +- -+ 756 | | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | External Route Tag (Optional) | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Referenced Link State ID (Optional) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | ... | 764 Note that when the sub-TLV is present (S-bit set in the 765 PrefixOptions) the sub-TLV is placed after Forwarding address and 766 external route Tag if they are present. 768 20.6 Extended Link-LSA 770 We define a new E-link-LSA with LS type of 0x9008. This LSA is 771 generated for each link and carries each link's prefix in the 772 corresponding topology. It also carries next hop IP information 773 for the supported address families. 775 The processing and generation of this LSA is the same as for link-lsa 776 as defined in [OSPFv3]. This LSA has a fixed portion followed by 777 TLVs. 779 0 1 2 3 780 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 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | LS age |0|0|0|1| 8 | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Link State ID | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Advertising Router | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | LS sequence number | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | LS checksum | length | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Rtr Pri | Options | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 . . 795 . TLVs . 796 . . 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 We define the following three TLVs 801 o IPv6 Next hop TLV (NH6-TLV) 802 o IPv4 Next hop TLV (NH4-TLV) 803 o Prefix Multi-topology TLV (PMT-TLV) 805 Next hop TLVs carry IPv6/IPv4 information for next hop calculation. 806 IPv6 next hop information MUST be a link local IPv6 address. 807 Prefix-TLV carries router link's prefix on multi-access link. This 808 information is used by DR in order to include those prefix in its 809 E-intra-area prefix LSA. 811 NH6-TLV has the following format: 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | 1 (NH6-TLV) | Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | | 819 +- -+ 820 | | 821 +- Link-local Interface Address -+ 822 | | 823 +- -+ 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 This TLV MUST be present if the link participate in a MT belonging 828 to IPv6 address family. 830 NH4-TLV has the following format: 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | 2 (NH4-TLV) | Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | IPv4 address | 838 +---------------------------------------------------------------+ 840 This TLV MUST be present if the link participate in a MT belonging 841 to IPv4 address family. 843 PMT-TLV extends link-LSA by defining TLV under each address prefix. 844 This TLV should only be present on multi-access links. 846 0 1 2 3 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | 3 (PMT-TLV) | Length | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | # prefixes | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Prefix-Block Length | PrefixLength | Reserved | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Address Prefix | 857 | ... | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 . . 860 . TLVs . 861 . . 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | ... | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Prefix-Block Length | PrefixLength | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Address Prefix | 868 | ... | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 . . 871 . TLVs . 872 . . 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | ... | 876 Prefix-Block Length : Define the length of prefix block including 877 Prefix-Block Length, PrefixLength, Reserved 878 field, Address Prefix and TLVs. 880 All other fields are defined as in [OSPFv3]. 882 We define a Link Multi-Topology sub-TLV (LMT-sTLV) below. This 883 sub-TLV could further contain sub-TLVs. 885 Each prefix block must contain the LMT-sTLV. 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | 1 (LMT-sTLV) | Length | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | MT-ID | PrefixOptions | 0 | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | ... | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | MT-ID | PrefixOptions | 0 | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | ... | 900 20.7 Extended Intra-Area-Prefix-LSA 902 We define a new E-intra-area-prefix-LSA with LS type of 0xB009. A 903 router generates E-Intra-Area-Prefix-LSAs to advertise one or more 904 prefixes associated with a topology. 906 The processing and generation of this LSA is the same as for 907 intra-area-prefix-LSA defined in [OSPFv3]. 909 0 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | LS age |0|0|1|1| 9 | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Link State ID | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Advertising Router | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | LS sequence number | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | LS checksum | length | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | # prefixes | Referenced LS type | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Referenced Link State ID | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Referenced Advertising Router | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Prefix-Block Length | PrefixLength | Reserved | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Address Prefix | 931 | ... | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 . . 934 . TLVs . 935 . . 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | ... | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | Prefix-Block Length | PrefixLength | Reserved | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Address Prefix | 942 | ... | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 . . 945 . TLVs . 946 . . 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | ... | 950 Prefix-Block Length : Define the length of prefix block including 951 Prefix-Block Length, PrefixLength, Reserved 952 field, Address Prefix and TLVs. 954 All other fields are defined as in [OSPFv3]. 956 We define a Prefix Multi-Topology TLV (PMT-TLV) below. This TLV could 957 further contain sub-TLVs. 959 E-intra-area-prefix-LSA must contain one or more prefix blocks and 960 each prefix block must contain the PMT-TLV. 962 0 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | 1 (PMT-TLV) | Length | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | MT-ID | PrefixOptions | MT-ID metric | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | ... | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | MT-ID | PrefixOptions | MT-ID metric | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | ... | 975 21. Security Considerations 977 The technique described in this document does not introduce any new 978 security issues to the OSPFv3 protocol. 980 22. Acknowledgements 982 The authors would like to thank Alex Zinin, Acee Lindem, Tom 983 Henderson, Jeff Ahrenholz and Paul Wells for their comments on the 984 document. 986 23. References 988 Normative References 990 [OSPFv3] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6", 991 RFC 2740, December 1999. 993 Informative Reference 995 [INSTANCES] Mirtorabi, S. et al, "Support of address families in 996 OSPFv3", Internet Draft, work in progress 998 [M-ISIS] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology 999 (MT) Routing in IS-IS", Internet Draft, work in progress 1001 Appendix A. Global Parameter 1003 RFC2740Compatibility 1004 This parameter controls which LSAs are used for Default Topology. 1005 When set to "enabled", the Default Topology is described using 1006 existing LSAs [OSPFv3]. When set to "disabled" the Default Topology 1007 is described using Extended LSAs as specified in this memo. This 1008 parameter is set to "enabled" by default. 1010 Authors' Addresses 1012 Sina Mirtorabi Abhay Roy 1013 Cisco Systems Cisco Systems 1014 170 W. Tasman Dr. 170 W. Tasman Dr. 1015 San Jose, CA 95134, USA San Jose, CA 95134, USA 1016 E-mail: sina@cisco.com E-mail: akr@cisco.com 1018 Intellectual Property Statement 1020 The IETF takes no position regarding the validity or scope of any 1021 Intellectual Property Rights or other rights that might be claimed to 1022 pertain to the implementation or use of the technology described in 1023 this document or the extent to which any license under such rights 1024 might or might not be available; nor does it represent that it has 1025 made any independent effort to identify any such rights. Information 1026 on the procedures with respect to rights in RFC documents can be 1027 found in BCP 78 and BCP 79. 1029 Copies of IPR disclosures made to the IETF Secretariat and any 1030 assurances of licenses to be made available, or the result of an 1031 attempt made to obtain a general license or permission for the use of 1032 such proprietary rights by implementers or users of this 1033 specification can be obtained from the IETF on-line IPR repository at 1034 http://www.ietf.org/ipr. 1036 The IETF invites any interested party to bring to its attention any 1037 copyrights, patents or patent applications, or other proprietary 1038 rights that may cover technology that may be required to implement 1039 this standard. Please address the information to the IETF at 1040 ietf-ipr@ietf.org. 1042 Disclaimer of Validity 1044 This document and the information contained herein are provided on an 1045 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1046 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1047 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1048 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1049 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1050 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1052 Copyright Statement 1054 Copyright (C) The Internet Society (2004). This document is subject 1055 to the rights, licenses and restrictions contained in BCP 78, and 1056 except as set forth therein, the authors retain all their rights. 1058 Acknowledgment 1060 Funding for the RFC Editor function is currently provided by the 1061 Internet Society.