idnits 2.17.1 draft-ietf-ospf-mt-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 775. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([M-ISIS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 320 has weird spacing: '...rder to assur...' == Line 696 has weird spacing: '...ing the const...' -- 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 (April 20, 2005) is 6939 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) == Missing Reference: '0-127' is mentioned on line 279, but not defined == Missing Reference: '128-255' is mentioned on line 288, but not defined ** Obsolete normative reference: RFC 1583 (Obsoleted by RFC 2178) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-07 -- Obsolete informational reference (is this intentional?): RFC 3137 (ref. 'STUB') (Obsoleted by RFC 6987) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Psenak 3 Internet-Draft S. Mirtorabi 4 Expires: October 22, 2005 A. Roy 5 L. Nguyen 6 P. Pillay-Esnault 7 Cisco Systems 8 April 20, 2005 10 Multi-Topology (MT) Routing in OSPF 11 draft-ietf-ospf-mt-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 22, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This draft describes an extension to OSPF in order to define 45 independent IP topologies called Multi-Topologies (MTs). The MT 46 extension can be used for computing different paths for unicast 47 traffic, multicast traffic, different classes of service based on 48 flexible criteria, or an in-band network management topology. 50 [M-ISIS] describes a similar mechanism for ISIS. 52 An optional extension to exclude selected links from the default 53 topology is also described. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Differences with RFC 1583 TOS Based Routing . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1 Requirements notation . . . . . . . . . . . . . . . . . . 5 61 2.2 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Base MT Functional Specifications . . . . . . . . . . . . . . 6 63 3.1 MT Area Boundary . . . . . . . . . . . . . . . . . . . . . 6 64 3.2 Adjacency for MTs . . . . . . . . . . . . . . . . . . . . 6 65 3.3 Sending OSPF control packets . . . . . . . . . . . . . . . 6 66 3.4 Advertising MT Adjacencies and the Corresponding IP 67 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.4.1 Advertising MT Adjacencies and the Corresponding 69 IP Prefixes . . . . . . . . . . . . . . . . . . . . . 6 70 3.4.2 Inter-Area and External Routing . . . . . . . . . . . 7 71 3.5 Flushing MT Information . . . . . . . . . . . . . . . . . 7 72 3.6 MT SPF Computation . . . . . . . . . . . . . . . . . . . . 7 73 3.7 MT-ID Values . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.8 Forwarding in MT . . . . . . . . . . . . . . . . . . . . . 8 75 4. Default Topology Link Exclusion Functional Specifications . . 9 76 4.1 Exclusion of Links in the Default Topology . . . . . . . . 9 77 4.2 New Area Data Structure Parameter . . . . . . . . . . . . 9 78 4.3 Adjacency Formation with Link Exclusion Capability . . . . 10 79 4.4 OSPF Control Packets Transmission Over Excluded Links . . 10 80 4.5 OSPF LSA Advertisement and SPF Computation for 81 Excluded Links . . . . . . . . . . . . . . . . . . . . . . 11 82 5. Interoperability between MT Capable and Non-MT Capable 83 Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6. Migration from non-MT-Area to MT-area . . . . . . . . . . . . 13 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 89 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 91 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 92 B. OSPF data formats . . . . . . . . . . . . . . . . . . . . . . 19 93 B.1 Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 94 B.2 Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20 95 B.3 Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20 96 B.4 AS-External-LSAs . . . . . . . . . . . . . . . . . . . . . 21 97 B.5 NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . . . 22 98 Intellectual Property and Copyright Statements . . . . . . . . 23 100 1. Introduction 102 OSPF uses a fixed packet format, therefore it is not easy to 103 introduce any backward compatible extensions. However, the OSPF 104 specification [OSPF] introduced TOS metric in an earlier 105 specification [RFC1583] in order to announce a different link cost 106 based on TOS. TOS based routing as described in [RFC1583] was never 107 deployed and was subsequently deprecated. 109 We propose to reuse the TOS based metric fields. They have been 110 redefined as MT-ID and MT-ID Metric and are used to advertise 111 different topologies by advertising separate metrics for each of 112 them. 114 1.1 Differences with RFC 1583 TOS Based Routing 116 Multi-topology routing differs from RFC 1583 TOS based routing in the 117 following ways: 119 1. With RFC 1583 TOS routing, the TOS or DSCP in the IP header is 120 mapped directly to the the corresponding OSPF SPF calculation and 121 routing table. This limits the number and definition of the 122 topologies to the 16 TOS values specified is section 12.3 of RFC 123 1583 [RFC1583]. With multi-topology routing, the classification 124 of what type of traffic maps to which topology is not within the 125 scope of the document. 127 2. With RFC 1583 TOS routing, traffic which is unreachable in the 128 routing table associated with the corresponding TOS will revert 129 to the TOS 0 routing table. With multi-topology routing, this is 130 optional. 132 3. With RFC 1583 TOS routing, individual links or prefixes could not 133 be excluded from a topology. If the LSA options T-bit was set, 134 all links or prefixes were either advertised explicitly or 135 defaulted to the TOS 0 metric. With multi-topology routing, 136 links or prefixes that are not advertised for a specific topology 137 do not exist in that topology. 139 2. Terminology 141 2.1 Requirements notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC2119 [RFC2119]. 147 2.2 Terms 149 We define the following terminology in this document: 151 Non-MT router 152 Routers that do not have the MT capability 154 MT router 155 Routers that have MT capability as described in this document 157 MT-ID 158 Renamed TOS field in LSAs to represent multitopology ID. 160 Default topology 161 Topology that is built using the TOS 0 metric (default metric) 163 MT topology 164 Topology that is built using the corresponding MT-ID metric 166 MT 167 Shorthand notation for MT topology 169 MT#0 topology 170 Representation of TOS 0 metric in MT-ID format 172 Non-MT-Area 173 An area that contains only non-MT routers 175 MT-Area 176 An area that contains both non-MT routers and MT routers or only 177 MT routers 179 3. Base MT Functional Specifications 181 3.1 MT Area Boundary 183 Each OSPF interface belongs to a single area and all MTs sharing that 184 link need to belong to the same area. Therefore the area boundaries 185 for all MTs are the same but each MT's attachment to the area is 186 independent. 188 3.2 Adjacency for MTs 190 Each interface can be configured to belong to a set of topologies. A 191 single adjacency will be formed with neighbors on the interface even 192 if the interface is configured to participate in multiple topologies. 193 Furthermore, adjacency formation will be independent of the 194 topologies configured for the interface or neighbors on that 195 interface. 197 3.3 Sending OSPF control packets 199 Sending OSPF control packets is unchanged from RFC2328. For OSPF 200 control packets sent to the remote end of a virtual link, the transit 201 area path MUST be composed solely of links in the default topology 202 and the OSPF control packets MUST be forwarded using the default 203 topology. 205 3.4 Advertising MT Adjacencies and the Corresponding IP Prefixes 207 We will reuse the TOS metric field in order to advertise a topology 208 and prefixes belonging to that topology. The TOS field is redefined 209 as MT-ID in the payload of Router-LSAs, Summary-LSAs, NSSA-LSAs, and 210 AS-External-LSAs (see Appendix A). 212 MT-ID metrics in LSAs SHOULD be in ascending order of MT-ID. If an 213 MT-ID exists in an LSA or router link multiple times, the metric in 214 the first MT-ID instance MUST be used. 216 3.4.1 Advertising MT Adjacencies and the Corresponding IP Prefixes 218 When a router establishes a FULL adjacency over a link that belongs 219 to a set of MTs, it will advertise the corresponding cost for each 220 MT-ID. 222 By default, all links are included in default topology and all 223 advertised prefixes belonging to the default topology will use the 224 TOS0 metric the same as in standard OSPF [OSPF]. 226 Each MT has its own MT-ID metric field. When a link is not part of a 227 given MT, the corresponding MT-ID metric is excluded from the LSA. 229 The Network-LSA does not contain any MT information since the DR is 230 shared by all MTs. Hence, there is no change to the Network-LSA. 232 3.4.2 Inter-Area and External Routing 234 In Summary-LSAs, NSSA-LSAs, and AS-External-LSAs, the TOS metric 235 fields are defined as MT-ID metric fields and are used in order to 236 advertise prefix and router reachability in the corresponding 237 topology. 239 When a router originates a Summary-LSA, NSSA-LSA, or AS-External-LSA 240 that belongs to a set of MTs, it will include the corresponding cost 241 for each MT-ID. By default, the router participates in the default 242 topology and uses the TOS0 metric for the default topology the same 243 as in standard OSPF [OSPF]. 245 Setting the P-bit in NSSA-LSAs is topology independent and pertains 246 to all MT-ID advertised in the body of the LSA. 248 3.5 Flushing MT Information 250 When a certain link or prefix that existed or was reachable in a 251 certain topology is no longer part of that topology or is unreachable 252 in that topology, a new version of the LSA must be originated 253 excluding metric information representing the link or prefix in that 254 topology. 256 The MT metric in the Router-LSA can also be set to the maximum 257 possible metric to enable the router to become a stub in a certain 258 topology [STUB]. 260 3.6 MT SPF Computation 262 By considering MT-ID metrics in the LSAs, OSPF will be able to 263 compute multiple topologies and find paths to IP prefixes for each MT 264 independently. A separate SPF will be computed for each MT-ID to 265 find independent paths to IP prefixes. Each nexthop computed during 266 the MT SPF MUST belong to the same MT. 268 Network-LSAs are used by all topologies during the SPF computation. 269 During the SPF for a given MT-ID, only the links and metrics for that 270 MT-ID will be considered. Entries in the Router Routing table will 271 be MT-ID specific. 273 During the SPF computation for the default topology only the TOS0 274 metric is considered during the SPF computation. 276 3.7 MT-ID Values 278 Since AS-External-LSAs use the high order bit in the MT-ID field (E 279 bit) for the external metric-type, only MT-IDs in the range [0-127] 280 are valid. The following MT-ID values are reserved: 282 0 - Reserved for advertising the metric associated with the 283 default topology (see Section 4.2) 285 1 - Reserved for advertising the metric associated with the 286 default multicast topology 288 MT-IDs [128-255] SHOULD be ignored. 290 3.8 Forwarding in MT 292 It's outside of the scope of this document to specify how the 293 information in various topology specific forwarding structures are 294 used during packet forwarding or how incoming packets are associated 295 with the corresponding topology. For correct operation, both 296 forwarding behavior and methods of associating incoming packets to a 297 corresponding topology must be consistently applied in the network. 299 4. Default Topology Link Exclusion Functional Specifications 301 The multi-topologies imply that all the routers participate in the 302 default topology. However, it can be useful to exclude some links 303 from the default topology and reserve them for some specific classes 304 of traffic. 306 The multi-topologies extension for default topology link or prefix 307 exclusion is described in the following subsections. 309 4.1 Exclusion of Links in the Default Topology 311 OSPF does not have the notion of an unreachable link. All links can 312 have a maximum metric of 0xFFFF advertised in the Router-LSA. The 313 link exclusion capability requires routers to ignore TOS0 metrics in 314 Router-LSAs in the default topology and to alternately use the MT- 315 ID#0 metric to advertise the metric associated with the default 316 topology. Hence, all routers within an area MUST agree on how the 317 metric for default topology will be advertised. 319 The unused T-bit is defined as the MT-bit in the option field in 320 order to assure that a multi-topology link-excluding capable router 321 will only form an adjacency with another similarly configured router. 323 +---+---+---+---+---+---+---+---+ 324 |DN |O |DC |EA |NP |MC |E |MT | 325 +---+---+---+---+---+---+---+---+ 327 MT-bit: This bit MUST be set in the Hello packet only if 328 DefaultExclusionCapability is enabled (see Section 4.2) 330 4.2 New Area Data Structure Parameter 332 We define a new parameter in the Area Data Structure: 334 DefaultExclusionCapability 335 This configurable parameter ensures that all routers in an area 336 have this capability enabled before the default topology can be 337 disabled on a router link in the area without causing backward 338 compatibility problems. 340 When an area data structure is created the DefaultExclusionCapability 341 is disabled by default. 343 If DefaultExclusionCapability is disabled: 345 o The MT-bit MUST be cleared in Hello packets. 347 o If a link participates in a non-default topology, it is 348 automatically included in the default topology to support backward 349 compatibility between MT and non-MT routers. This is accomplished 350 through advertisement via the TOS0 metric field the same as in 351 standard OSPF [OSPF]. 353 If DefaultExclusionCapability is enabled: 355 o The MT-bit MUST be set in Hello packets 357 o The router will only accept a Hello if the MT-bit is set (see 358 Section 4.3) 360 When DefaultExclusionCapability is set to enabled a router is said to 361 be operating in DefaultExclusionCapability mode. 363 4.3 Adjacency Formation with Link Exclusion Capability 365 In order to have a smooth transition from a non-MT area to an MT- 366 area, an MT router with DefaultExclusionCapability disabled will form 367 adjacencies with non-MT routers and will include all links as part of 368 default topology. 370 A link may cease participating in default topology if 371 DefaultExclusionCapability is set to enabled. In this state, a 372 router will only form adjacency with routers that set the MT-bit in 373 their Hello packets. This will ensure that all routers have 374 DefaultExclusionCapability enabled before the default topology can be 375 disabled on a link. 377 Receiving OSPF Hello packets as defined in section 10.5 of [OSPF] is 378 modified as follows: 380 o If the DefaultExclusionCapability of the Area Data structure is 381 set to enabled, the Hello packets are discarded if the the 382 received Hello packet does not have the MT-bit in the hello 383 options set. 385 4.4 OSPF Control Packets Transmission Over Excluded Links 387 If DefaultExclusionCapability is enabled, the default topology can be 388 disabled on an interface. Disabling the default topology on an 389 interface does not impact the installation of connected routes for 390 the interface in the default topology. It only affects what a router 391 advertises in its Router-LSA. 393 This allows OSPF control packets to be sent and received over an 394 interface even if the default topology is disabled on the interface. 396 4.5 OSPF LSA Advertisement and SPF Computation for Excluded Links 398 When DefaultExclusionCapability is enabled and the link does not 399 participate in the default topology, the MT-ID#0 metric is not 400 advertised. The link's TOS0 metric is ignored during the default 401 topology SPF computation. 403 When DefaultExclusionCapability is enabled and a link participates in 404 the default topology, MT-ID#0 metric is used to advertise the metric 405 associated with the default topology. The link's TOS0 metric is 406 ignored during the default topology SPF computation. 408 Independent of the DefaultExclusionCapability setting, the TOS0 409 metric is used for Summary-LSAs, NSSA-LSAs, and AS-External-LSAs. 411 o If the prefix or router does not exist in the default topology, 412 the TOS0 metric is set to infinity (0xFFFFFF). 414 o If the prefix or router exists in default the topology, the TOS0 415 metric is used to advertise the metric in the default topology. 417 During the summary and external prefix calculation for the default 418 topology the TOS0 metric is used for Summary-LSAs, NSSA-LSAs, and AS- 419 External-LSAs. 421 5. Interoperability between MT Capable and Non-MT Capable Routers 423 The default metric field is mandatory in all LSAs (even when metric 424 value is 0). Even when a link or prefix does not exist in the 425 default topology, a non-MT router can consider the zero value in the 426 metric field as a valid metric and consider the link or prefix as 427 part of the default topology. 429 In order to prevent the above problem, an MT capable router will 430 include all links as part of the default topology. If links need to 431 be removed from the default topology, an MT capable router MUST be 432 configured in DefaultExclusionCapability mode. In this mode, 433 routers will assure that all other routers in the area are in the 434 DefaultExclusionCapability mode before considering the MT-ID#0 metric 435 in the SPF calculation. Only then can the TOS0 metric field in 436 Router LSAs be safely ignored during the default topology SPF 437 computation. 439 Note that for any prefix or router to become reachable in a certain 440 topology, a contiguous path inside that topology must exist between 441 the calculating router and the destination prefix or router. 443 6. Migration from non-MT-Area to MT-area 445 Introducing MT-OSPF into a network can be done gradually to allow MT 446 routers and non-MT routers to participate in the default topology 447 while MT routers participate in other topologies. 449 If there is a requirement to exclude some links from the default 450 topology in an area, all routers in the area MUST be in 451 DefaultExclusionCapability mode. In this section we describe the 452 migration steps to consider while transitioning from a non-MT network 453 to an MT network. 455 Consider a network with a backbone area and a set of non-backbone 456 areas functioning in standard OSPF mode. We would like to migrate to 457 an MT network either partially or completely. 459 1. As required, part of an area is upgrade to be MT capable. The MT 460 routers will interact with non-MT routers in the default topology 461 and participate in other topologies as required. 463 2. If a new non-backbone area is created for MT routers, it may be 464 configured in DefaultExclusionCapability mode since there is no 465 interaction required with non-MT routers. In this mode, the 466 default topology can be excluded on links as required. 468 3. If there is more than one non-backbone areas where MT is being 469 used, it is desirable that the backbone area first be upgraded to 470 be MT capable so that inter-area routing is assured for MT 471 destinations in different areas. 473 4. Gradually the whole network can be made MT capable. 475 Note that inter-area routing for the MT-area still depends on the 476 backbone area. Therefore, if different areas configured for a given 477 topology need to communicate, the backbone area also needs to be 478 configured for this topology. 480 7. Security Considerations 482 This document does not raise any security issues that are not already 483 covered in [OSPF]. 485 8. IANA Considerations 487 The T-bit as defined in [RFC1583] for a router's TOS capability is 488 redefined as the MT-bit in this document. Similarly, the TOS field 489 for Router-LSAs, Summary-LSAs, NSSA-LSAs, and AS-External LSAs as 490 defined in [OSPF] is redefined as MT-ID in this document. 492 9. References 494 9.1 Normative References 496 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 497 RFC 3101, January 2003. 499 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 501 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 503 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 504 Requirement Levels", RFC 2119, March 1997. 506 9.2 Informative References 508 [M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 509 Topology (MT) Routing in IS-IS", 510 draft-ietf-isis-wg-multi-topology-07.txt (work in 511 progress). 513 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 514 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 515 June 2001. 517 Authors' Addresses 519 Peter Psenak 520 Cisco Systems 521 Parc Pegasus, De Kleetlaan 6A 522 1831 Diegem 523 Belgium 525 Email: ppsenak@cisco.com 527 Sina Mirtorabi 528 Cisco Systems 529 225 West Tasman Drive 530 San Jose, CA 95134 531 USA 533 Email: sina@cisco.com 534 Abhay Roy 535 Cisco Systems 536 225 West Tasman Drive 537 San Jose, CA 95134 538 USA 540 Email: akr@cisco.com 542 Liem Nguyen 543 Cisco Systems 544 7025 Kit Creek Road 545 Research Triangle Park, NC 27709 546 USA 548 Email: lhnguyen@cisco.com 550 Padma Pillay-Esnault 551 Cisco Systems 552 225 West Tasman Drive 553 San Jose, CA 95134 554 USA 556 Email: ppe@cisco.com 558 Appendix A. Acknowledgments 560 The authors would like to thank Scott Sturgess, Alvaro Retana, David 561 Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their 562 comments on the document. Special thanks to Acee Lindem for editing 563 and to Tom Henderson for an extensive review during the OSPF Working 564 Group last call. 566 Appendix B. OSPF data formats 568 LSA content defined in [OSPF] is modified to introduce the MT-ID. 570 B.1 Router-LSAs 572 Router-LSAs are the Type 1 LSAs. Each router in an area originates a 573 router-LSA. The LSA describes the state and cost of the router's 574 links (i.e., interfaces) to the area. All of the router's links to 575 the area must be described in a single router-LSA. For details 576 concerning the construction of router-LSAs, see Section 12.4.1 577 [OSPF]. 579 0 1 2 3 580 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 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | LS age | Options | 1 | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Link State ID | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Advertising Router | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | LS sequence number | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | LS checksum | length | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 |*|*|*|N|W|V|E|B| 0 | # links | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Link ID | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Link Data | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Type | # MT-ID | metric | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | MT-ID | 0 | MT-ID metric | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | ... | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | MT-ID | 0 | MT-ID metric | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Link ID | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Link Data | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | ... | 612 B.2 Network-LSAs 614 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 615 each broadcast and NBMA network in the area which supports two or 616 more routers. The network-LSA is originated by the network's 617 Designated Router. The LSA describes all routers attached to the 618 network, including the Designated Router itself. The LSA's Link 619 State ID field lists the IP interface address of the Designated 620 Router. 622 The distance from the network to all attached routers is zero. This 623 is why metric fields need not be specified in the network-LSA. For 624 details concerning the construction of network-LSAs, see Section 625 12.4.2 [OSPF]. 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | LS age | Options | 2 | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Link State ID | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Advertising Router | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | LS sequence number | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | LS checksum | length | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Network Mask | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Attached Router | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | ... | 646 Note that network LSA does not contain any MT-ID fields as the cost 647 of the network to the attached routers is 0 and DR is shared by all 648 topologies. 650 B.3 Summary-LSAs 652 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by 653 area border routers. Summary-LSAs describe inter-area destinations. 654 For details concerning the construction of summary- LSAs, see Section 655 12.4.3 [OSPF]. 657 Type 3 summary-LSAs are used when the destination is an IP network. 658 In this case the LSA's Link State ID field is an IP network number 659 (if necessary, the Link State ID can also have one or more of the 660 network's "host" bits set; see Appendix E [OSPF] for details). When 661 the destination is an AS boundary router, a Type 4 summary-LSA is 662 used, and the Link State ID field is the AS boundary router's OSPF 663 Router ID. (To see why it is necessary to advertise the location of 664 each ASBR, consult Section 16.4 of [OSPF]). Other than the 665 difference in the Link State ID field, the format of Type 3 and 4 666 summary-LSAs is identical. 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | LS age | Options | 3 or 4 | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | Link State ID | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Advertising Router | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | LS sequence number | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | LS checksum | length | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Network Mask | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | 0 | metric | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | MT-ID | MT-ID metric | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | ... | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | MT-ID | MT-ID metric | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 B.4 AS-External-LSAs 694 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 695 AS boundary routers, and describe destinations external to the AS. 696 For details concerning the construction of AS-external-LSAs, see 697 Section 12.4.3 [OSPF]. 699 AS-external-LSAs usually describe a particular external destination. 700 For these LSAs the Link State ID field specifies an IP network number 701 (if necessary, the Link State ID can also have one or more of the 702 network's "host" bits set; see Appendix E [OSPF] for details). AS- 703 external-LSAs are also used to describe a default route. Default 704 routes are used when no specific route exists to the destination. 706 When describing a default route, the Link State ID is always set to 707 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 709 0 1 2 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | LS age | Options | 5 | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Link State ID | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Advertising Router | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | LS sequence number | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | LS checksum | length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Network Mask | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 |E| 0 | metric | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Forwarding address | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | External Route Tag | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |E| MT-ID | MT-ID metric | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Forwarding address | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | External Route Tag | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | ... | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 |E| MT-ID | MT-ID metric | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Forwarding address | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | External Route Tag | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 B.5 NSSA-LSAs 747 NSSA-LSAs are the Type 7 LSAs. These LSAs are originated by AS 748 boundary routers local to an NSSA, and describe destinations external 749 to the AS. The changes to NSSA-LSAs are identical to those for 750 External-LSAs (Appendix A.4.5). For details concerning the 751 construction of NSSA-LSAs see Section 2.4 [NSSA]. 753 Intellectual Property Statement 755 The IETF takes no position regarding the validity or scope of any 756 Intellectual Property Rights or other rights that might be claimed to 757 pertain to the implementation or use of the technology described in 758 this document or the extent to which any license under such rights 759 might or might not be available; nor does it represent that it has 760 made any independent effort to identify any such rights. Information 761 on the procedures with respect to rights in RFC documents can be 762 found in BCP 78 and BCP 79. 764 Copies of IPR disclosures made to the IETF Secretariat and any 765 assurances of licenses to be made available, or the result of an 766 attempt made to obtain a general license or permission for the use of 767 such proprietary rights by implementers or users of this 768 specification can be obtained from the IETF on-line IPR repository at 769 http://www.ietf.org/ipr. 771 The IETF invites any interested party to bring to its attention any 772 copyrights, patents or patent applications, or other proprietary 773 rights that may cover technology that may be required to implement 774 this standard. Please address the information to the IETF at 775 ietf-ipr@ietf.org. 777 Disclaimer of Validity 779 This document and the information contained herein are provided on an 780 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 781 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 782 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 783 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 784 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 785 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Copyright Statement 789 Copyright (C) The Internet Society (2005). This document is subject 790 to the rights, licenses and restrictions contained in BCP 78, and 791 except as set forth therein, the authors retain all their rights. 793 Acknowledgment 795 Funding for the RFC Editor function is currently provided by the 796 Internet Society.