idnits 2.17.1 draft-ietf-ospf-mt-09.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 844. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 862. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 868. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2007) is 6301 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 1583 (ref. 'TOS-OSPF') (Obsoleted by RFC 2178) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-11 -- Obsolete informational reference (is this intentional?): RFC 3137 (ref. 'STUB') (Obsoleted by RFC 6987) Summary: 2 errors (**), 0 flaws (~~), 2 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 Cisco Systems 4 Intended status: Standards Track S. Mirtorabi 5 Expires: July 5, 2007 Force10 Networks 6 A. Roy 7 L. Nguyen 8 P. Pillay-Esnault 9 Cisco Systems 10 January 2007 12 Multi-Topology (MT) Routing in OSPF 13 draft-ietf-ospf-mt-09.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 5, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This draft describes an extension to Open Shortest Path First (OSPF) 47 in order to define independent IP topologies called Multi-Topologies 48 (MTs). The Multi-Topologies extension can be used for computing 49 different paths for unicast traffic, multicast traffic, different 50 classes of service based on flexible criteria, or an in-band network 51 management topology. 53 An optional extension to exclude selected links from the default 54 topology is also described. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Differences between Multi-Topology and TOS Based 60 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 63 2.2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Base MT Functional Specifications . . . . . . . . . . . . . . 6 65 3.1. MT Area Boundary . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Adjacency for MTs . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Sending OSPF control packets . . . . . . . . . . . . . . . 6 68 3.4. Advertising MT Adjacencies and the Corresponding IP 69 Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.4.1. 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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. MT Network Management Considerations . . . . . . . . . . . . . 14 87 7.1. Create dedicated management topology to include all 88 the nodes . . . . . . . . . . . . . . . . . . . . . . . . 14 89 7.2. Extend the default topology to all the nodes . . . . . . . 14 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 96 Appendix B. OSPF data formats . . . . . . . . . . . . . . . . . . 19 97 B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 98 B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20 99 B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 20 100 B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 21 101 B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 23 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 103 Intellectual Property and Copyright Statements . . . . . . . . . . 25 105 1. Introduction 107 OSPF uses a fixed packet format, therefore it is not easy to 108 introduce any backward compatible extensions. However, the OSPF 109 specification [OSPF] introduced Type of Service (TOS) metric in an 110 earlier specification [TOS-OSPF] in order to announce a different 111 link cost based on TOS. TOS based routing as described in [TOS-OSPF] 112 was never deployed and was subsequently deprecated. [M-ISIS] 113 describes a similar mechanism for ISIS. 115 We propose to reuse the TOS based metric fields. They have been 116 redefined and are used to advertise different topologies by 117 advertising separate metrics for each of them. 119 1.1. Differences between Multi-Topology and TOS Based Routing 121 Multi-Topology routing differs from [TOS-OSPF] TOS based routing in 122 the following ways: 124 1. With TOS routing [TOS-OSPF], the TOS or DSCP in the IP header is 125 mapped directly to the corresponding OSPF SPF calculation and 126 routing table. This limits the number and definition of the 127 topologies to the 16 TOS values specified in section 12.3 of 128 [TOS-OSPF]. With Multi-Topology routing, the classification of 129 what type of traffic maps to which topology is not within the 130 scope of the document. 132 2. With TOS routing [TOS-OSPF], traffic which is unreachable in the 133 routing table associated with the corresponding TOS will revert 134 to the TOS 0 routing table. With Multi-Topology routing, this is 135 optional. 137 3. With TOS routing [TOS-OSPF], individual links or prefixes could 138 not be excluded from a topology. If the LSA options T-bit was 139 set, all links or prefixes were either advertised explicitly or 140 defaulted to the TOS 0 metric. With Multi-Topology routing, 141 links or prefixes that are not advertised for a specific topology 142 do not exist in that topology. 144 2. Terminology 146 2.1. Requirements notation 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 151 [RFC-KEYWORDS]. 153 2.2. Terms 155 We define the following terminology in this document: 157 Non-MT router 158 Routers that do not have the MT capability 160 MT router 161 Routers that have MT capability as described in this document 163 MT-ID 164 Renamed TOS field in LSAs to represent Multi-Topology ID. 166 Default topology 167 Topology that is built using the TOS 0 metric (default metric) 169 MT topology 170 Topology that is built using the corresponding MT-ID metric 172 MT 173 Shorthand notation for MT topology 175 MT#0 topology 176 Representation of TOS 0 metric in MT-ID format 178 Non-MT-Area 179 An area that contains only non-MT routers 181 MT-Area 182 An area that contains both non-MT routers and MT routers or only 183 MT routers 185 3. Base MT Functional Specifications 187 3.1. MT Area Boundary 189 Each OSPF interface belongs to a single area and all MTs sharing that 190 link need to belong to the same area. Therefore the area boundaries 191 for all MTs are the same but each MT's attachment to the area is 192 independent. 194 3.2. Adjacency for MTs 196 Each interface can be configured to belong to a set of topologies. A 197 single adjacency is formed with neighbors on the interface even if 198 the interface is configured to participate in multiple topologies. 199 Furthermore, adjacency formation is independent of the topologies 200 configured on the local interface and the neighboring router. 202 3.3. Sending OSPF control packets 204 Sending OSPF control packets is unchanged from [OSPF]. For OSPF 205 control packets sent to the remote end of a virtual link, the transit 206 area path MUST be composed of links participating in the default 207 topology and the OSPF control packets MUST be forwarded using the 208 default topology. 210 3.4. Advertising MT Adjacencies and the Corresponding IP Prefixes 212 The TOS metric field is reused to advertise topology specific metric 213 for links and prefixes belonging to that topology. The TOS field is 214 redefined as MT-ID in the payload of Router, Summary, Type-5 and 215 Type-7 AS-external LSAs (see Appendix A). 217 MT-ID metrics in LSAs SHOULD be in ascending order of MT-ID. If an 218 MT-ID exists in an LSA or router link multiple times, the metric in 219 the first MT-ID instance MUST be used. 221 When a router establishes a FULL adjacency over a link that belongs 222 to a set of MTs, it advertises the corresponding cost for each MT-ID. 224 By default, all links are included in the default topology and all 225 advertised prefixes belonging to the default topology will use the 226 TOS0 metric as in [OSPF]. 228 Each MT has its own MT-ID metric field. When a link is not part of a 229 given MT, the corresponding MT-ID metric is excluded from the LSA. 231 The Network-LSA does not contain any MT information since the 232 Designated Router (DR) is shared by all MTs. Hence, there is no 233 change to the Network-LSA. 235 3.4.1. Inter-Area and External Routing 237 In Summary-LSAs, Type-5 and Type-7 AS-external-LSAs the TOS metric 238 fields are redefined as MT-ID metric fields and are used to advertise 239 prefix and router reachability in the corresponding topology. 241 When a router originates a Summary-LSA, Type-5 or Type-7 AS-external- 242 LSA that belongs to a set of MTs, it includes the corresponding cost 243 for each MT-ID. By default, the prefix participates in the default 244 topology and uses the TOS0 metric for the default topology, similar 245 to standard OSPF [OSPF]. 247 Setting the P-bit in Type-7 AS-external-LSA is topology independent 248 and pertains to all MT-ID advertised in the body of the LSA. 250 3.5. Flushing MT Information 252 When a certain link or prefix that existed or was reachable in a 253 certain topology is no longer part of that topology or is unreachable 254 in that topology, a new version of the LSA MUST be originated 255 excluding metric information representing the link or prefix in that 256 topology. 258 The MT metric in the Router-LSA can also be set to the maximum 259 possible metric to enable the router to become a stub in a certain 260 topology [STUB]. 262 3.6. MT SPF Computation 264 By considering MT-ID metrics in the LSAs, OSPF computes multiple 265 topologies and finds paths to IP prefixes for each MT independently. 266 A separate SPF will be computed for each MT-ID to find independent 267 paths to IP prefixes. 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 are considered. Entries in the Router Routing table are also 272 MT-ID specific. 274 3.7. MT-ID Values 276 Since AS-External-LSAs use the high order bit in the MT-ID field (E 277 bit) for the external metric-type, only MT-IDs in the 0 to 127 range 278 are valid. The following MT-ID values are reserved: 280 0 - Reserved for advertising the metric associated 281 with the default topology (see Section 4.2) 282 1 - Reserved for advertising the metric associated 283 with the default multicast topology 284 2 - Reserved for IPv4 in-band management purposes. 285 3-31 - Reserved for IETF consensus. 286 32-127 - Reserved for development, experimental and 287 proprietary features [RFC3692]. 288 128-255 - Invalid and SHOULD be ignored. 290 3.8. Forwarding in MT 292 It is 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 the default topology link or 307 prefix 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 the 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 Figure 1: OSPF Option Bits 329 MT-bit: If DefaultExclusionCapability is enabled, the bit MUST 330 be set in Hello packets and SHOULD be set in Database 331 Description packet (see Section 4.2). 333 4.2. New Area Data Structure Parameter 335 We define a new parameter in the Area Data Structure: 337 DefaultExclusionCapability 338 This configurable parameter ensures that all routers in an area 339 have this capability enabled before the default topology can be 340 disabled on a router link in the area without causing backward 341 compatibility problems. 343 When an area data structure is created, the 344 DefaultExclusionCapability is disabled by default. 346 If DefaultExclusionCapability is disabled: 348 o The MT-bit MUST be cleared in Hello packet and SHOULD be cleared 349 in Database Description packets. 351 o If a link participates in a non-default topology, it is 352 automatically included in the default topology to support backward 353 compatibility between MT and non-MT routers. This is accomplished 354 using the TOS0 metric field as in [OSPF]. 356 If DefaultExclusionCapability is enabled: 358 o The MT-bit MUST be set in Hello packets and SHOULD be set in 359 Database 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 the default topology. 374 A link may cease participating in the 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 received packet 386 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, 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, the TOS0 metric is 418 used for Summary-LSAs, Type-5 and Type-7 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 the default 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, Type-5 and Type-7 428 AS-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, routers 442 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 the TOS0 metric field in Router 445 LSAs can 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 Hello packets 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 Hello packets 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 are several non-backbone areas where MT is being used, 491 it is desirable that the backbone area first be upgraded to be MT 492 capable so that inter-area routing is assured for MT destinations 493 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. MT Network Management Considerations 504 When multiple OSPF topologies exist within a domain, some of the 505 routers can be configured to participate in a subset of the MTs in 506 the network. This section discusses some of the options we have to 507 enable operations or the network management stations to access those 508 routers. 510 7.1. Create dedicated management topology to include all the nodes 512 This approach is to setup a dedicated management topology or 'in- 513 band' management topology. This 'mgmt' topology will include all the 514 routers need to be managed. The computed routes in the topology will 515 be installed into the 'mgmt' RIB. In the condition of the 'mgmt' 516 topology uses a set of non-overlapping address space with the default 517 topology, those 'mgmt' routes can also be optionally installed into 518 the default RIB. The advantages of duplicate 'mgmt' routes in both 519 RIBs include: the network management utilities on the system does not 520 have to be modified to use specific RIB other than the default RIB; 521 the 'mgmt' topology can share the same link with the default topology 522 if so designed. 524 7.2. Extend the default topology to all the nodes 526 Even in the case default topology is not used on some of the nodes in 527 the IP forwarding, we may want to extend the default topology to 528 those nodes for the purpose of network management. Operators SHOULD 529 set high cost on the links which belong to the extended portion of 530 the default topology. This way the IP data traffic will not be 531 forwarded through those nodes during network topology changes. 533 8. Security Considerations 535 This document does not raise any security issues that are not already 536 covered in [OSPF]. 538 9. IANA Considerations 540 The T-bit as defined in [TOS-OSPF] for a router's TOS capability is 541 redefined as the MT-bit in this document. IANA is requested to 542 assign the MT-bit as defined in section Section 4.1. 544 Similarly, the TOS field for Router-LSAs, Summary-LSAs, Type-5 and 545 Type-7 AS-external LSAs as defined in [OSPF] is redefined as MT-ID in 546 Section 3.7. 548 IANA is requested to create a new registry, "OSPF multi-topology ID 549 values" with the assignment listed in Section 3.7 of this document 550 and registration policies for future assignments. 552 10. References 554 10.1. Normative References 556 [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", 557 RFC 1793, April 1995. 559 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 560 RFC 3101, January 2003. 562 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 564 [RFC-KEYWORDS] 565 Bradner, S., "Key words for use in RFC's to Indicate 566 Requirement Levels", RFC 2119, March 1997. 568 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 569 Considered Useful", RFC 3692, January 2004. 571 [TOS-OSPF] 572 Moy, J., "OSPF Version 2", RFC 1583, March 1994. 574 10.2. Informative References 576 [M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 577 Topology (MT) Routing in IS-IS", 578 draft-ietf-isis-wg-multi-topology-11.txt (work in 579 progress). 581 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 582 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 583 June 2001. 585 Appendix A. Acknowledgments 587 The authors would like to thank Scott Sturgess, Alvaro Retana, David 588 Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their 589 comments on the document. Special thanks to Acee Lindem for editing 590 and to Tom Henderson for an extensive review during the OSPF Working 591 Group last call. 593 Appendix B. OSPF data formats 595 LSA content defined in [OSPF] is modified to introduce the MT-ID. 597 B.1. Router-LSAs 599 Router-LSAs are the Type 1 LSAs. Each router in an area originates a 600 router-LSA. The LSA describes the state and cost of the router's 601 links (i.e., interfaces) to the area. All of the router's links to 602 the area must be described in a single router-LSA. For details 603 concerning the construction of router-LSAs, see Section 12.4.1 of 604 [OSPF]. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | LS age | Options | 1 | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Link State ID | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Advertising Router | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | LS sequence number | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | LS checksum | length | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 |*|*|*|N|W|V|E|B| 0 | # links | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Link ID | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Link Data | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | # MT-ID | metric | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | MT-ID | 0 | MT-ID metric | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | ... | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | MT-ID | 0 | MT-ID metric | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Link ID | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Link Data | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | ... | 639 Figure 2: Router-LSA Format 641 B.2. Network-LSAs 643 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 644 each broadcast and NBMA network in the area which supports two or 645 more routers. The network-LSA is originated by the network's 646 Designated Router. The LSA describes all routers attached to the 647 network, including the Designated Router itself. The LSA's Link 648 State ID field lists the IP interface address of the Designated 649 Router. 651 The distance from the network to all attached routers is zero. This 652 is why metric fields need not be specified in the network-LSA. For 653 details concerning the construction of network-LSAs, see Section 654 12.4.2 of [OSPF]. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | LS age | Options | 2 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Link State ID | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Advertising Router | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | LS sequence number | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | LS checksum | length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Network Mask | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Attached Router | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | ... | 675 Figure 3: Network-LSA Format 677 Note that network LSA does not contain any MT-ID fields as the cost 678 of the network to the attached routers is 0 and DR is shared by all 679 topologies. 681 B.3. Summary-LSAs 683 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by 684 area border routers. Summary-LSAs describe inter-area destinations. 685 For details concerning the construction of summary-LSAs, see Section 686 12.4.3 of [OSPF]. 688 Type 3 summary-LSAs are used when the destination is an IP network. 689 In this case the LSA's Link State ID field is an IP network number 690 (if necessary, the Link State ID can also have one or more of the 691 network's "host" bits set; see Appendix E [OSPF] for details). When 692 the destination is an AS boundary router, a Type 4 summary-LSA is 693 used, and the Link State ID field is the AS boundary router's OSPF 694 Router ID. (To see why it is necessary to advertise the location of 695 each ASBR, consult Section 16.4 of [OSPF]). Other than the 696 difference in the Link State ID field, the format of Type 3 and 4 697 summary-LSAs is identical. 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | LS age | Options | 3 or 4 | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Link State ID | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Advertising Router | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | LS sequence number | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | LS checksum | length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Network Mask | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | 0 | metric | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | MT-ID | MT-ID metric | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | ... | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | MT-ID | MT-ID metric | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 4: Summary-LSA Format 725 B.4. AS-external-LSAs 727 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 728 AS boundary routers, and describe destinations external to the AS. 729 For details concerning the construction of AS-external-LSAs, see 730 Section 12.4.3 of [OSPF]. 732 AS-external-LSAs usually describe a particular external destination. 733 For these LSAs the Link State ID field specifies an IP network number 734 (if necessary, the Link State ID can also have one or more of the 735 network's "host" bits set; see Appendix E [OSPF] for details). AS- 736 external-LSAs are also used to describe a default route. Default 737 routes are used when no specific route exists to the destination. 738 When describing a default route, the Link State ID is always set to 739 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | LS age | Options | 5 | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Link State ID | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Advertising Router | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | LS sequence number | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | LS checksum | length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Network Mask | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 |E| 0 | metric | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Forwarding address | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | External Route Tag | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 |E| MT-ID | MT-ID metric | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Forwarding address | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | External Route Tag | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | ... | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |E| MT-ID | MT-ID metric | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Forwarding address | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | External Route Tag | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 Figure 5: AS-External-LSA Format 779 B.5. Type-7 AS-external-LSAs 781 Type-7 AS-external-LSAs are originated by AS boundary routers local 782 to an NSSA, and describe destinations external to the AS. The 783 changes to Type-7 AS-external-LSAs are identical to those for AS- 784 external-LSAs (Appendix A.4.5). For details concerning the 785 construction of Type-7 AS-external-LSAs see Section 2.4 of [NSSA]. 787 Authors' Addresses 789 Peter Psenak 790 Cisco Systems 791 Mlynske Nivy 43 792 821 09 793 Bratislava 794 Slovakia 796 Email: ppsenak@cisco.com 798 Sina Mirtorabi 799 Force10 Networks 800 1440 McCarthy Blvd 801 Milpitas, CA 95035 802 USA 804 Email: sina@force10networks.com 806 Abhay Roy 807 Cisco Systems 808 170 West Tasman Drive 809 San Jose, CA 95134 810 USA 812 Email: akr@cisco.com 814 Liem Nguyen 815 Cisco Systems 816 170 West Tasman Drive 817 San Jose, CA 95134 818 USA 820 Email: lhnguyen@cisco.com 822 Padma Pillay-Esnault 823 Cisco Systems 824 170 West Tasman Drive 825 San Jose, CA 95134 826 USA 828 Email: ppe@cisco.com 830 Full Copyright Statement 832 Copyright (C) The IETF Trust (2007). 834 This document is subject to the rights, licenses and restrictions 835 contained in BCP 78, and except as set forth therein, the authors 836 retain all their rights. 838 This document and the information contained herein are provided on an 839 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 840 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 841 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 842 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 843 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 844 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 846 Intellectual Property 848 The IETF takes no position regarding the validity or scope of any 849 Intellectual Property Rights or other rights that might be claimed to 850 pertain to the implementation or use of the technology described in 851 this document or the extent to which any license under such rights 852 might or might not be available; nor does it represent that it has 853 made any independent effort to identify any such rights. Information 854 on the procedures with respect to rights in RFC documents can be 855 found in BCP 78 and BCP 79. 857 Copies of IPR disclosures made to the IETF Secretariat and any 858 assurances of licenses to be made available, or the result of an 859 attempt made to obtain a general license or permission for the use of 860 such proprietary rights by implementers or users of this 861 specification can be obtained from the IETF on-line IPR repository at 862 http://www.ietf.org/ipr. 864 The IETF invites any interested party to bring to its attention any 865 copyrights, patents or patent applications, or other proprietary 866 rights that may cover technology that may be required to implement 867 this standard. Please address the information to the IETF at 868 ietf-ipr@ietf.org. 870 Acknowledgment 872 Funding for the RFC Editor function is provided by the IETF 873 Administrative Support Activity (IASA).