idnits 2.17.1 draft-ietf-ospf-mt-06.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 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 794. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 800. ** 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 321 has weird spacing: '...rder to assur...' == Line 721 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 (February 1, 2006) is 6653 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 280, but not defined == Missing Reference: '128-255' is mentioned on line 289, 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: August 5, 2006 A. Roy 5 L. Nguyen 6 P. Pillay-Esnault 7 Cisco Systems 8 February 1, 2006 10 Multi-Topology (MT) Routing in OSPF 11 draft-ietf-ospf-mt-06.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 August 5, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . 11 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 5.1 Demand Circuit Compatibility Considerations . . . . . . . 12 85 6. Migration from non-MT-Area to MT-area . . . . . . . . . . . . 13 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 90 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 92 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 93 B. OSPF data formats . . . . . . . . . . . . . . . . . . . . . . 19 94 B.1 Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 95 B.2 Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20 96 B.3 Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20 97 B.4 AS-External-LSAs . . . . . . . . . . . . . . . . . . . . . 21 98 B.5 NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . . . 22 99 Intellectual Property and Copyright Statements . . . . . . . . 23 101 1. Introduction 103 OSPF uses a fixed packet format, therefore it is not easy to 104 introduce any backward compatible extensions. However, the OSPF 105 specification [OSPF] introduced TOS metric in an earlier 106 specification [RFC1583] in order to announce a different link cost 107 based on TOS. TOS based routing as described in [RFC1583] was never 108 deployed and was subsequently deprecated. 110 We propose to reuse the TOS based metric fields. They have been 111 redefined as MT-ID and MT-ID Metric and are used to advertise 112 different topologies by advertising separate metrics for each of 113 them. 115 1.1 Differences with RFC 1583 TOS Based Routing 117 Multi-topology routing differs from RFC 1583 TOS based routing in the 118 following ways: 120 1. With RFC 1583 TOS routing, the TOS or DSCP in the IP header is 121 mapped directly to the the corresponding OSPF SPF calculation and 122 routing table. This limits the number and definition of the 123 topologies to the 16 TOS values specified is section 12.3 of RFC 124 1583 [RFC1583]. With multi-topology routing, the classification 125 of what type of traffic maps to which topology is not within the 126 scope of the document. 128 2. With RFC 1583 TOS routing, traffic which is unreachable in the 129 routing table associated with the corresponding TOS will revert 130 to the TOS 0 routing table. With multi-topology routing, this is 131 optional. 133 3. With RFC 1583 TOS routing, individual links or prefixes could not 134 be excluded from a topology. If the LSA options T-bit was set, 135 all links or prefixes were either advertised explicitly or 136 defaulted to the TOS 0 metric. With multi-topology routing, 137 links or prefixes that are not advertised for a specific topology 138 do not exist in that topology. 140 2. Terminology 142 2.1 Requirements notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC2119 [RFC2119]. 148 2.2 Terms 150 We define the following terminology in this document: 152 Non-MT router 153 Routers that do not have the MT capability 155 MT router 156 Routers that have MT capability as described in this document 158 MT-ID 159 Renamed TOS field in LSAs to represent multitopology ID. 161 Default topology 162 Topology that is built using the TOS 0 metric (default metric) 164 MT topology 165 Topology that is built using the corresponding MT-ID metric 167 MT 168 Shorthand notation for MT topology 170 MT#0 topology 171 Representation of TOS 0 metric in MT-ID format 173 Non-MT-Area 174 An area that contains only non-MT routers 176 MT-Area 177 An area that contains both non-MT routers and MT routers or only 178 MT routers 180 3. Base MT Functional Specifications 182 3.1 MT Area Boundary 184 Each OSPF interface belongs to a single area and all MTs sharing that 185 link need to belong to the same area. Therefore the area boundaries 186 for all MTs are the same but each MT's attachment to the area is 187 independent. 189 3.2 Adjacency for MTs 191 Each interface can be configured to belong to a set of topologies. A 192 single adjacency will be formed with neighbors on the interface even 193 if the interface is configured to participate in multiple topologies. 194 Furthermore, adjacency formation will be independent of the 195 topologies configured for the interface or neighbors on that 196 interface. 198 3.3 Sending OSPF control packets 200 Sending OSPF control packets is unchanged from RFC2328. For OSPF 201 control packets sent to the remote end of a virtual link, the transit 202 area path MUST be composed solely of links in the default topology 203 and the OSPF control packets MUST be forwarded using the default 204 topology. 206 3.4 Advertising MT Adjacencies and the Corresponding IP Prefixes 208 We will reuse the TOS metric field in order to advertise a topology 209 and prefixes belonging to that topology. The TOS field is redefined 210 as MT-ID in the payload of Router-LSAs, Summary-LSAs, NSSA-LSAs, and 211 AS-External-LSAs (see Appendix A). 213 MT-ID metrics in LSAs SHOULD be in ascending order of MT-ID. If an 214 MT-ID exists in an LSA or router link multiple times, the metric in 215 the first MT-ID instance MUST be used. 217 3.4.1 Advertising MT Adjacencies and the Corresponding IP Prefixes 219 When a router establishes a FULL adjacency over a link that belongs 220 to a set of MTs, it will advertise the corresponding cost for each 221 MT-ID. 223 By default, all links are included in default topology and all 224 advertised prefixes belonging to the default topology will use the 225 TOS0 metric the same as in standard OSPF [OSPF]. 227 Each MT has its own MT-ID metric field. When a link is not part of a 228 given MT, the corresponding MT-ID metric is excluded from the LSA. 230 The Network-LSA does not contain any MT information since the DR is 231 shared by all MTs. Hence, there is no change to the Network-LSA. 233 3.4.2 Inter-Area and External Routing 235 In Summary-LSAs, NSSA-LSAs, and AS-External-LSAs, the TOS metric 236 fields are defined as MT-ID metric fields and are used in order to 237 advertise prefix and router reachability in the corresponding 238 topology. 240 When a router originates a Summary-LSA, NSSA-LSA, or AS-External-LSA 241 that belongs to a set of MTs, it will include the corresponding cost 242 for each MT-ID. By default, the router participates in the default 243 topology and uses the TOS0 metric for the default topology the same 244 as in standard OSPF [OSPF]. 246 Setting the P-bit in NSSA-LSAs is topology independent and pertains 247 to all MT-ID advertised in the body of the LSA. 249 3.5 Flushing MT Information 251 When a certain link or prefix that existed or was reachable in a 252 certain topology is no longer part of that topology or is unreachable 253 in that topology, a new version of the LSA must be originated 254 excluding metric information representing the link or prefix in that 255 topology. 257 The MT metric in the Router-LSA can also be set to the maximum 258 possible metric to enable the router to become a stub in a certain 259 topology [STUB]. 261 3.6 MT SPF Computation 263 By considering MT-ID metrics in the LSAs, OSPF will be able to 264 compute multiple topologies and find paths to IP prefixes for each MT 265 independently. A separate SPF will be computed for each MT-ID to 266 find independent paths to IP prefixes. Each nexthop computed during 267 the MT SPF MUST belong to the same MT. 269 Network-LSAs are used by all topologies during the SPF computation. 270 During the SPF for a given MT-ID, only the links and metrics for that 271 MT-ID will be considered. Entries in the Router Routing table will 272 be MT-ID specific. 274 During the SPF computation for the default topology only the TOS0 275 metric is considered during the SPF computation. 277 3.7 MT-ID Values 279 Since AS-External-LSAs use the high order bit in the MT-ID field (E 280 bit) for the external metric-type, only MT-IDs in the range [0-127] 281 are valid. The following MT-ID values are reserved: 283 0 - Reserved for advertising the metric associated with the 284 default topology (see Section 4.2) 286 1 - Reserved for advertising the metric associated with the 287 default multicast topology 289 MT-IDs [128-255] SHOULD be ignored. 291 3.8 Forwarding in MT 293 It's outside of the scope of this document to specify how the 294 information in various topology specific forwarding structures are 295 used during packet forwarding or how incoming packets are associated 296 with the corresponding topology. For correct operation, both 297 forwarding behavior and methods of associating incoming packets to a 298 corresponding topology must be consistently applied in the network. 300 4. Default Topology Link Exclusion Functional Specifications 302 The multi-topologies imply that all the routers participate in the 303 default topology. However, it can be useful to exclude some links 304 from the default topology and reserve them for some specific classes 305 of traffic. 307 The multi-topologies extension for default topology link or prefix 308 exclusion is described in the following subsections. 310 4.1 Exclusion of Links in the Default Topology 312 OSPF does not have the notion of an unreachable link. All links can 313 have a maximum metric of 0xFFFF advertised in the Router-LSA. The 314 link exclusion capability requires routers to ignore TOS0 metrics in 315 Router-LSAs in the default topology and to alternately use the MT- 316 ID#0 metric to advertise the metric associated with the default 317 topology. Hence, all routers within an area MUST agree on how the 318 metric for default topology will be advertised. 320 The unused T-bit is defined as the MT-bit in the option field in 321 order to assure that a multi-topology link-excluding capable router 322 will only form an adjacency with another similarly configured router. 324 +---+---+---+---+---+---+---+---+ 325 |DN |O |DC |EA |NP |MC |E |MT | 326 +---+---+---+---+---+---+---+---+ 328 MT-bit: If DefaultExclusionCapability is enable, this bit MUST 329 be set in Hello packets and SHOULD be set in Database 330 Description packet (see Section 4.2). 332 4.2 New Area Data Structure Parameter 334 We define a new parameter in the Area Data Structure: 336 DefaultExclusionCapability 337 This configurable parameter ensures that all routers in an area 338 have this capability enabled before the default topology can be 339 disabled on a router link in the area without causing backward 340 compatibility problems. 342 When an area data structure is created the DefaultExclusionCapability 343 is disabled by default. 345 If DefaultExclusionCapability is disabled: 347 o The MT-bit MUST be cleared in Hello packet and SHOULD be cleared 348 in Database Description packets. 350 o If a link participates in a non-default topology, it is 351 automatically included in the default topology to support backward 352 compatibility between MT and non-MT routers. This is accomplished 353 through advertisement via the TOS0 metric field the same as in 354 standard OSPF [OSPF]. 356 If DefaultExclusionCapability is enabled: 358 o The MT-bit MUST be set in Hello and SHOULD be set in Database 359 Description packets 361 o The router will only accept a Hello packet if the MT-bit is set 362 (see Section 4.3) 364 When DefaultExclusionCapability is set to enabled a router is said to 365 be operating in DefaultExclusionCapability mode. 367 4.3 Adjacency Formation with Link Exclusion Capability 369 In order to have a smooth transition from a non-MT area to an MT- 370 area, an MT router with DefaultExclusionCapability disabled will form 371 adjacencies with non-MT routers and will include all links as part of 372 default topology. 374 A link may cease participating in default topology if 375 DefaultExclusionCapability is set to enabled. In this state, a 376 router will only form adjacency with routers that set the MT-bit in 377 their Hello packets. This will ensure that all routers have 378 DefaultExclusionCapability enabled before the default topology can be 379 disabled on a link. 381 Receiving OSPF Hello packets as defined in section 10.5 of [OSPF] is 382 modified as follows: 384 o If the DefaultExclusionCapability in the Area Data structure is 385 set to enabled, Hello packets are discarded if the the received 386 packet does not have the MT-bit set in the header options. 388 Receiving OSPF Database Description packets as defined in section 389 10.6 of [OSPF] is unchanged. While packet options are validated in 390 hello packets, the only option checking performed for Database 391 Description packets is assuring that the options do not change during 392 the database exchange process. 394 4.4 OSPF Control Packets Transmission Over Excluded Links 396 If DefaultExclusionCapability is enabled, the default topology can be 397 disabled on an interface. Disabling the default topology on an 398 interface does not impact the installation of connected routes for 399 the interface in the default topology. It only affects what a router 400 advertises in its Router-LSA. 402 This allows OSPF control packets to be sent and received over an 403 interface even if the default topology is disabled on the interface. 405 4.5 OSPF LSA Advertisement and SPF Computation for Excluded Links 407 When DefaultExclusionCapability is enabled and the link does not 408 participate in the default topology, the MT-ID#0 metric is not 409 advertised. The link's TOS0 metric is ignored during the default 410 topology SPF computation. 412 When DefaultExclusionCapability is enabled and a link participates in 413 the default topology, MT-ID#0 metric is used to advertise the metric 414 associated with the default topology. The link's TOS0 metric is 415 ignored during the default topology SPF computation. 417 Independent of the DefaultExclusionCapability setting, the TOS0 418 metric is used for Summary-LSAs, NSSA-LSAs, and AS-External-LSAs. 420 o If the prefix or router does not exist in the default topology, 421 the TOS0 metric is set to infinity (0xFFFFFF). 423 o If the prefix or router exists in default the topology, the TOS0 424 metric is used to advertise the metric in the default topology. 426 During the summary and external prefix calculation for the default 427 topology the TOS0 metric is used for Summary-LSAs, NSSA-LSAs, and AS- 428 External-LSAs. 430 5. Interoperability between MT Capable and Non-MT Capable Routers 432 The default metric field is mandatory in all LSAs (even when metric 433 value is 0). Even when a link or prefix does not exist in the 434 default topology, a non-MT router will consider the zero value in the 435 metric field as a valid metric and consider the link or prefix as 436 part of the default topology. 438 In order to prevent the above problem, an MT capable router will 439 include all links as part of the default topology. If links need to 440 be removed from the default topology, an MT capable router MUST be 441 configured in DefaultExclusionCapability mode. In this mode, 442 routers will assure that all other routers in the area are in the 443 DefaultExclusionCapability mode before considering the MT-ID#0 metric 444 in the SPF calculation. Only then can the TOS0 metric field in 445 Router LSAs be safely ignored during the default topology SPF 446 computation. 448 Note that for any prefix or router to become reachable in a certain 449 topology, a contiguous path inside that topology must exist between 450 the calculating router and the destination prefix or router. 452 5.1 Demand Circuit Compatibility Considerations 454 A change to an area's DefaultExclusionCapability requires additional 455 processing for area neighbors that are suppressing hellos as 456 specified in "Extending OSPF to Support Demand Circuits" [DEMAND]. 457 When the DefaultExclusionCapability for an area is changed, hello 458 suppression must be disabled for these neighbors for a period of 459 RouterDeadInterval seconds. This implies that hello packets are sent 460 with the DC bit clear as specified in section 3.2.1 of [DEMAND] 461 during this period. After RouterDeadInterval seconds, either the 462 adjacency will be taken down due to rejection of hellos with a 463 conflicting MT-bit or hello suppression will be renegotiated. 465 6. Migration from non-MT-Area to MT-area 467 Introducing MT-OSPF into a network can be done gradually to allow MT 468 routers and non-MT routers to participate in the default topology 469 while MT routers participate in other topologies. 471 If there is a requirement to exclude some links from the default 472 topology in an area, all routers in the area MUST be in 473 DefaultExclusionCapability mode. In this section we describe the 474 migration steps to consider while transitioning from a non-MT network 475 to an MT network. 477 Consider a network with a backbone area and a set of non-backbone 478 areas functioning in standard OSPF mode. We would like to migrate to 479 an MT network either partially or completely. 481 1. As required, part of an area is upgrade to be MT capable. The MT 482 routers will interact with non-MT routers in the default topology 483 and participate in other topologies as required. 485 2. If a new non-backbone area is created for MT routers, it may be 486 configured in DefaultExclusionCapability mode since there is no 487 interaction required with non-MT routers. In this mode, the 488 default topology can be excluded on links as required. 490 3. If there is more than one non-backbone areas where MT is being 491 used, it is desirable that the backbone area first be upgraded to 492 be MT capable so that inter-area routing is assured for MT 493 destinations in different areas. 495 4. Gradually the whole network can be made MT capable. 497 Note that inter-area routing for the MT-area still depends on the 498 backbone area. Therefore, if different areas configured for a given 499 topology need to communicate, the backbone area also needs to be 500 configured for this topology. 502 7. Security Considerations 504 This document does not raise any security issues that are not already 505 covered in [OSPF]. 507 8. IANA Considerations 509 The T-bit as defined in [RFC1583] for a router's TOS capability is 510 redefined as the MT-bit in this document. Similarly, the TOS field 511 for Router-LSAs, Summary-LSAs, NSSA-LSAs, and AS-External LSAs as 512 defined in [OSPF] is redefined as MT-ID in this document. 514 9. References 516 9.1 Normative References 518 [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", 519 RFC 1793, April 1995. 521 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 522 RFC 3101, January 2003. 524 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 526 [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. 528 [RFC2119] Bradner, S., "Key words for use in RFC's to Indicate 529 Requirement Levels", RFC 2119, March 1997. 531 9.2 Informative References 533 [M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 534 Topology (MT) Routing in IS-IS", 535 draft-ietf-isis-wg-multi-topology-07.txt (work in 536 progress). 538 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 539 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 540 June 2001. 542 Authors' Addresses 544 Peter Psenak 545 Cisco Systems 546 Parc Pegasus, De Kleetlaan 6A 547 1831 Diegem 548 Belgium 550 Email: ppsenak@cisco.com 552 Sina Mirtorabi 553 Cisco Systems 554 225 West Tasman Drive 555 San Jose, CA 95134 556 USA 558 Email: sina@cisco.com 559 Abhay Roy 560 Cisco Systems 561 225 West Tasman Drive 562 San Jose, CA 95134 563 USA 565 Email: akr@cisco.com 567 Liem Nguyen 568 Cisco Systems 569 7025 Kit Creek Road 570 Research Triangle Park, NC 27709 571 USA 573 Email: lhnguyen@cisco.com 575 Padma Pillay-Esnault 576 Cisco Systems 577 225 West Tasman Drive 578 San Jose, CA 95134 579 USA 581 Email: ppe@cisco.com 583 Appendix A. Acknowledgments 585 The authors would like to thank Scott Sturgess, Alvaro Retana, David 586 Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their 587 comments on the document. Special thanks to Acee Lindem for editing 588 and to Tom Henderson for an extensive review during the OSPF Working 589 Group last call. 591 Appendix B. OSPF data formats 593 LSA content defined in [OSPF] is modified to introduce the MT-ID. 595 B.1 Router-LSAs 597 Router-LSAs are the Type 1 LSAs. Each router in an area originates a 598 router-LSA. The LSA describes the state and cost of the router's 599 links (i.e., interfaces) to the area. All of the router's links to 600 the area must be described in a single router-LSA. For details 601 concerning the construction of router-LSAs, see Section 12.4.1 602 [OSPF]. 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 | Options | 1 | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Link State ID | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Advertising Router | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | LS sequence number | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | LS checksum | length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 |*|*|*|N|W|V|E|B| 0 | # links | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Link ID | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Link Data | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | # MT-ID | metric | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | MT-ID | 0 | MT-ID metric | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | ... | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | MT-ID | 0 | MT-ID metric | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Link ID | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Link Data | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | ... | 637 B.2 Network-LSAs 639 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 640 each broadcast and NBMA network in the area which supports two or 641 more routers. The network-LSA is originated by the network's 642 Designated Router. The LSA describes all routers attached to the 643 network, including the Designated Router itself. The LSA's Link 644 State ID field lists the IP interface address of the Designated 645 Router. 647 The distance from the network to all attached routers is zero. This 648 is why metric fields need not be specified in the network-LSA. For 649 details concerning the construction of network-LSAs, see Section 650 12.4.2 [OSPF]. 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 | LS age | Options | 2 | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Link State ID | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Advertising Router | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | LS sequence number | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | LS checksum | length | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Network Mask | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Attached Router | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | ... | 671 Note that network LSA does not contain any MT-ID fields as the cost 672 of the network to the attached routers is 0 and DR is shared by all 673 topologies. 675 B.3 Summary-LSAs 677 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by 678 area border routers. Summary-LSAs describe inter-area destinations. 679 For details concerning the construction of summary- LSAs, see Section 680 12.4.3 [OSPF]. 682 Type 3 summary-LSAs are used when the destination is an IP network. 683 In this case the LSA's Link State ID field is an IP network number 684 (if necessary, the Link State ID can also have one or more of the 685 network's "host" bits set; see Appendix E [OSPF] for details). When 686 the destination is an AS boundary router, a Type 4 summary-LSA is 687 used, and the Link State ID field is the AS boundary router's OSPF 688 Router ID. (To see why it is necessary to advertise the location of 689 each ASBR, consult Section 16.4 of [OSPF]). Other than the 690 difference in the Link State ID field, the format of Type 3 and 4 691 summary-LSAs is identical. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | LS age | Options | 3 or 4 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Link State ID | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Advertising Router | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | LS sequence number | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | LS checksum | length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Network Mask | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | 0 | metric | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | MT-ID | MT-ID metric | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | ... | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | MT-ID | MT-ID metric | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 B.4 AS-External-LSAs 719 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 720 AS boundary routers, and describe destinations external to the AS. 721 For details concerning the construction of AS-external-LSAs, see 722 Section 12.4.3 [OSPF]. 724 AS-external-LSAs usually describe a particular external destination. 725 For these LSAs the Link State ID field specifies an IP network number 726 (if necessary, the Link State ID can also have one or more of the 727 network's "host" bits set; see Appendix E [OSPF] for details). AS- 728 external-LSAs are also used to describe a default route. Default 729 routes are used when no specific route exists to the destination. 731 When describing a default route, the Link State ID is always set to 732 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | LS age | Options | 5 | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Link State ID | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Advertising Router | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | LS sequence number | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | LS checksum | length | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Network Mask | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |E| 0 | metric | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Forwarding address | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | External Route Tag | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 |E| MT-ID | MT-ID metric | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Forwarding address | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | External Route Tag | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | ... | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |E| MT-ID | MT-ID metric | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Forwarding address | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | External Route Tag | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 B.5 NSSA-LSAs 772 NSSA-LSAs are the Type 7 LSAs. These LSAs are originated by AS 773 boundary routers local to an NSSA, and describe destinations external 774 to the AS. The changes to NSSA-LSAs are identical to those for 775 External-LSAs (Appendix A.4.5). For details concerning the 776 construction of NSSA-LSAs see Section 2.4 [NSSA]. 778 Intellectual Property Statement 780 The IETF takes no position regarding the validity or scope of any 781 Intellectual Property Rights or other rights that might be claimed to 782 pertain to the implementation or use of the technology described in 783 this document or the extent to which any license under such rights 784 might or might not be available; nor does it represent that it has 785 made any independent effort to identify any such rights. Information 786 on the procedures with respect to rights in RFC documents can be 787 found in BCP 78 and BCP 79. 789 Copies of IPR disclosures made to the IETF Secretariat and any 790 assurances of licenses to be made available, or the result of an 791 attempt made to obtain a general license or permission for the use of 792 such proprietary rights by implementers or users of this 793 specification can be obtained from the IETF on-line IPR repository at 794 http://www.ietf.org/ipr. 796 The IETF invites any interested party to bring to its attention any 797 copyrights, patents or patent applications, or other proprietary 798 rights that may cover technology that may be required to implement 799 this standard. Please address the information to the IETF at 800 ietf-ipr@ietf.org. 802 Disclaimer of Validity 804 This document and the information contained herein are provided on an 805 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 806 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 807 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 808 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 809 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 810 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 812 Copyright Statement 814 Copyright (C) The Internet Society (2006). This document is subject 815 to the rights, licenses and restrictions contained in BCP 78, and 816 except as set forth therein, the authors retain all their rights. 818 Acknowledgment 820 Funding for the RFC Editor function is currently provided by the 821 Internet Society.