idnits 2.17.1 draft-ietf-ospf-mt-07.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 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 827. ** 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 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 27, 2006) is 6359 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-07 -- Obsolete informational reference (is this intentional?): RFC 3137 (ref. 'STUB') (Obsoleted by RFC 6987) Summary: 4 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: May 31, 2007 Force10 Networks 6 A. Roy 7 L. Nguyen 8 P. Pillay-Esnault 9 Cisco Systems 10 November 27, 2006 12 Multi-Topology (MT) Routing in OSPF 13 draft-ietf-ospf-mt-07.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 May 31, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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. 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 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 92 Appendix B. OSPF data formats . . . . . . . . . . . . . . . . . . 18 93 B.1. Router-LSAs . . . . . . . . . . . . . . . . . . . . . . . 18 94 B.2. Network-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 95 B.3. Summary-LSAs . . . . . . . . . . . . . . . . . . . . . . . 19 96 B.4. AS-external-LSAs . . . . . . . . . . . . . . . . . . . . . 20 97 B.5. Type-7 AS-external-LSAs . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 99 Intellectual Property and Copyright Statements . . . . . . . . . . 24 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 Type of Service (TOS) metric in an 106 earlier specification [TOS-OSPF] in order to announce a different 107 link cost based on TOS. TOS based routing as described in [TOS-OSPF] 108 was never deployed and was subsequently deprecated. [M-ISIS] 109 describes a similar mechanism for ISIS. 111 We propose to reuse the TOS based metric fields. They have been 112 redefined and are used to advertise different topologies by 113 advertising separate metrics for each of them. 115 1.1. Differences between Multi-Topology and TOS Based Routing 117 Multi-Topology routing differs from [TOS-OSPF] TOS based routing in 118 the following ways: 120 1. With TOS routing [TOS-OSPF], the TOS or DSCP in the IP header is 121 mapped directly to 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 in section 12.3 of 124 [TOS-OSPF]. With Multi-Topology routing, the classification of 125 what type of traffic maps to which topology is not within the 126 scope of the document. 128 2. With TOS routing [TOS-OSPF], 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 TOS routing [TOS-OSPF], individual links or prefixes could 134 not be excluded from a topology. If the LSA options T-bit was 135 set, 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 RFC 2119 147 [RFC-KEYWORDS]. 149 2.2. Terms 151 We define the following terminology in this document: 153 Non-MT router 154 Routers that do not have the MT capability 156 MT router 157 Routers that have MT capability as described in this document 159 MT-ID 160 Renamed TOS field in LSAs to represent Multi-Topology ID. 162 Default topology 163 Topology that is built using the TOS 0 metric (default metric) 165 MT topology 166 Topology that is built using the corresponding MT-ID metric 168 MT 169 Shorthand notation for MT topology 171 MT#0 topology 172 Representation of TOS 0 metric in MT-ID format 174 Non-MT-Area 175 An area that contains only non-MT routers 177 MT-Area 178 An area that contains both non-MT routers and MT routers or only 179 MT routers 181 3. Base MT Functional Specifications 183 3.1. MT Area Boundary 185 Each OSPF interface belongs to a single area and all MTs sharing that 186 link need to belong to the same area. Therefore the area boundaries 187 for all MTs are the same but each MT's attachment to the area is 188 independent. 190 3.2. Adjacency for MTs 192 Each interface can be configured to belong to a set of topologies. A 193 single adjacency is formed with neighbors on the interface even if 194 the interface is configured to participate in multiple topologies. 195 Furthermore, adjacency formation is independent of the topologies 196 configured on the local interface and the neighboring router. 198 3.3. Sending OSPF control packets 200 Sending OSPF control packets is unchanged from [OSPF]. For OSPF 201 control packets sent to the remote end of a virtual link, the transit 202 area path MUST be composed of links participating in the default 203 topology and the OSPF control packets MUST be forwarded using the 204 default topology. 206 3.4. Advertising MT Adjacencies and the Corresponding IP Prefixes 208 The TOS metric field is reused to advertise topology specific metric 209 for links and prefixes belonging to that topology. The TOS field is 210 redefined as MT-ID in the payload of Router, Summary, Type-5 and 211 Type-7 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 When a router establishes a FULL adjacency over a link that belongs 218 to a set of MTs, it advertises the corresponding cost for each MT-ID. 220 By default, all links are included in the default topology and all 221 advertised prefixes belonging to the default topology will use the 222 TOS0 metric as in [OSPF]. 224 Each MT has its own MT-ID metric field. When a link is not part of a 225 given MT, the corresponding MT-ID metric is excluded from the LSA. 227 The Network-LSA does not contain any MT information since the 228 Designated Router (DR) is shared by all MTs. Hence, there is no 229 change to the Network-LSA. 231 3.4.1. Inter-Area and External Routing 233 In Summary-LSAs, Type-5 and Type-7 AS-external-LSAs the TOS metric 234 fields are redefined as MT-ID metric fields and are used to advertise 235 prefix and router reachability in the corresponding topology. 237 When a router originates a Summary-LSA, Type-5 or Type-7 AS-external- 238 LSA that belongs to a set of MTs, it includes the corresponding cost 239 for each MT-ID. By default, the prefix participates in the default 240 topology and uses the TOS0 metric for the default topology, similar 241 to standard OSPF [OSPF]. 243 Setting the P-bit in Type-7 AS-external-LSA is topology independent 244 and pertains to all MT-ID advertised in the body of the LSA. 246 3.5. Flushing MT Information 248 When a certain link or prefix that existed or was reachable in a 249 certain topology is no longer part of that topology or is unreachable 250 in that topology, a new version of the LSA MUST be originated 251 excluding metric information representing the link or prefix in that 252 topology. 254 The MT metric in the Router-LSA can also be set to the maximum 255 possible metric to enable the router to become a stub in a certain 256 topology [STUB]. 258 3.6. MT SPF Computation 260 By considering MT-ID metrics in the LSAs, OSPF computes multiple 261 topologies and finds paths to IP prefixes for each MT independently. 262 A separate SPF will be computed for each MT-ID to find independent 263 paths to IP prefixes. 265 Network-LSAs are used by all topologies during the SPF computation. 266 During the SPF for a given MT-ID, only the links and metrics for that 267 MT-ID are considered. Entries in the Router Routing table are also 268 MT-ID specific. 270 3.7. MT-ID Values 272 Since AS-External-LSAs use the high order bit in the MT-ID field (E 273 bit) for the external metric-type, only MT-IDs in the 0 to 127 range 274 are valid. The following MT-ID values are reserved: 276 0 - Reserved for advertising the metric associated 277 with the default topology (see Section 4.2) 278 1 - Reserved for advertising the metric associated 279 with the default multicast topology 280 2-127 - Reserved for definition as per local policy and 281 configuration 282 128-255 - Invalid and SHOULD be ignored. 284 3.8. Forwarding in MT 286 It is outside of the scope of this document to specify how the 287 information in various topology specific forwarding structures are 288 used during packet forwarding or how incoming packets are associated 289 with the corresponding topology. For correct operation, both 290 forwarding behavior and methods of associating incoming packets to a 291 corresponding topology must be consistently applied in the network. 293 4. Default Topology Link Exclusion Functional Specifications 295 The Multi-Topologies imply that all the routers participate in the 296 default topology. However, it can be useful to exclude some links 297 from the default topology and reserve them for some specific classes 298 of traffic. 300 The Multi-Topologies extension for the default topology link or 301 prefix exclusion is described in the following subsections. 303 4.1. Exclusion of Links in the Default Topology 305 OSPF does not have the notion of an unreachable link. All links can 306 have a maximum metric of 0xFFFF advertised in the Router-LSA. The 307 link exclusion capability requires routers to ignore TOS0 metrics in 308 Router-LSAs in the default topology and to alternately use the MT- 309 ID#0 metric to advertise the metric associated with the default 310 topology. Hence, all routers within an area MUST agree on how the 311 metric for the default topology will be advertised. 313 The unused T-bit is defined as the MT-bit in the option field in 314 order to assure that a Multi-Topology link-excluding capable router 315 will only form an adjacency with another similarly configured router. 317 +---+---+---+---+---+---+---+---+ 318 |DN |O |DC |EA |NP |MC |E |MT | 319 +---+---+---+---+---+---+---+---+ 321 Figure 1: OSPF Option Bits 323 MT-bit: If DefaultExclusionCapability is enabled, the bit MUST 324 be set in Hello packets and SHOULD be set in Database 325 Description packet (see Section 4.2). 327 4.2. New Area Data Structure Parameter 329 We define a new parameter in the Area Data Structure: 331 DefaultExclusionCapability 332 This configurable parameter ensures that all routers in an area 333 have this capability enabled before the default topology can be 334 disabled on a router link in the area without causing backward 335 compatibility problems. 337 When an area data structure is created, the 338 DefaultExclusionCapability is disabled by default. 340 If DefaultExclusionCapability is disabled: 342 o The MT-bit MUST be cleared in Hello packet and SHOULD be cleared 343 in Database Description packets. 345 o If a link participates in a non-default topology, it is 346 automatically included in the default topology to support backward 347 compatibility between MT and non-MT routers. This is accomplished 348 using the TOS0 metric field as in [OSPF]. 350 If DefaultExclusionCapability is enabled: 352 o The MT-bit MUST be set in Hello packets and SHOULD be set in 353 Database Description packets. 355 o The router will only accept a Hello packet if the MT-bit is set 356 (see Section 4.3). 358 When DefaultExclusionCapability is set to enabled a router is said to 359 be operating in DefaultExclusionCapability mode. 361 4.3. Adjacency Formation with Link Exclusion Capability 363 In order to have a smooth transition from a non-MT area to an MT- 364 area, an MT router with DefaultExclusionCapability disabled will form 365 adjacencies with non-MT routers and will include all links as part of 366 the default topology. 368 A link may cease participating in the default topology if 369 DefaultExclusionCapability is set to enabled. In this state, a 370 router will only form adjacency with routers that set the MT-bit in 371 their Hello packets. This will ensure that all routers have 372 DefaultExclusionCapability enabled before the default topology can be 373 disabled on a link. 375 Receiving OSPF Hello packets as defined in section 10.5 of [OSPF] is 376 modified as follows: 378 o If the DefaultExclusionCapability in the Area Data structure is 379 set to enabled, Hello packets are discarded if the received packet 380 does not have the MT-bit set in the Header Options. 382 Receiving OSPF Database Description packets as defined in section 383 10.6 of [OSPF] is unchanged. While packet options are validated in 384 Hello packets, the only option checking performed for Database 385 Description packets is assuring that the options do not change during 386 the database exchange process. 388 4.4. OSPF Control Packets Transmission Over Excluded Links 390 If DefaultExclusionCapability is enabled, the default topology can be 391 disabled on an interface. Disabling the default topology on an 392 interface does not impact the installation of connected routes for 393 the interface in the default topology. It only affects what a router 394 advertises in its Router-LSA. 396 This allows OSPF control packets to be sent and received over an 397 interface even if the default topology is disabled on the interface. 399 4.5. OSPF LSA Advertisement and SPF Computation for Excluded Links 401 When DefaultExclusionCapability is enabled and the link does not 402 participate in the default topology, MT-ID#0 metric is not 403 advertised. The link's TOS0 metric is ignored during the default 404 topology SPF computation. 406 When DefaultExclusionCapability is enabled and a link participates in 407 the default topology, MT-ID#0 metric is used to advertise the metric 408 associated with the default topology. The link's TOS0 metric is 409 ignored during the default topology SPF computation. 411 Independent of the DefaultExclusionCapability, the TOS0 metric is 412 used for Summary-LSAs, Type-5 and Type-7 AS-external-LSAs. 414 o If the prefix or router does not exist in the default topology, 415 the TOS0 metric is set to infinity (0xFFFFFF). 417 o If the prefix or router exists in the default topology, the TOS0 418 metric is used to advertise the metric in the default topology. 420 During the summary and external prefix calculation for the default 421 topology the TOS0 metric is used for Summary-LSAs, Type-5 and Type-7 422 AS-external-LSAs. 424 5. Interoperability between MT Capable and Non-MT Capable Routers 426 The default metric field is mandatory in all LSAs (even when metric 427 value is 0). Even when a link or prefix does not exist in the 428 default topology, a non-MT router will consider the zero value in the 429 metric field as a valid metric and consider the link or prefix as 430 part of the default topology. 432 In order to prevent the above problem, an MT capable router will 433 include all links as part of the default topology. If links need to 434 be removed from the default topology, an MT capable router must be 435 configured in DefaultExclusionCapability mode. In this mode, routers 436 will assure that all other routers in the area are in the 437 DefaultExclusionCapability mode before considering the MT-ID#0 metric 438 in the SPF calculation. Only then the TOS0 metric field in Router 439 LSAs can be safely ignored during the default topology SPF 440 computation. 442 Note that for any prefix or router to become reachable in a certain 443 topology, a contiguous path inside that topology must exist between 444 the calculating router and the destination prefix or router. 446 5.1. Demand Circuit Compatibility Considerations 448 A change to an area's DefaultExclusionCapability requires additional 449 processing for area neighbors that are suppressing Hello packets as 450 specified in "Extending OSPF to Support Demand Circuits" [DEMAND]. 451 When the DefaultExclusionCapability for an area is changed, Hello 452 suppression must be disabled for these neighbors for a period of 453 RouterDeadInterval seconds. This implies that Hello packets are sent 454 with the DC bit clear as specified in section 3.2.1 of [DEMAND] 455 during this period. After RouterDeadInterval seconds, either the 456 adjacency will be taken down due to rejection of Hello packets with a 457 conflicting MT-bit or Hello suppression will be renegotiated. 459 6. Migration from non-MT-Area to MT-area 461 Introducing MT-OSPF into a network can be done gradually to allow MT 462 routers and non-MT routers to participate in the default topology 463 while MT routers participate in other topologies. 465 If there is a requirement to exclude some links from the default 466 topology in an area, all routers in the area MUST be in 467 DefaultExclusionCapability mode. In this section we describe the 468 migration steps to consider while transitioning from a non-MT network 469 to an MT network. 471 Consider a network with a backbone area and a set of non-backbone 472 areas functioning in standard OSPF mode. We would like to migrate to 473 an MT network either partially or completely. 475 1. As required, part of an area is upgrade to be MT capable. The MT 476 routers will interact with non-MT routers in the default topology 477 and participate in other topologies as required. 479 2. If a new non-backbone area is created for MT routers, it may be 480 configured in DefaultExclusionCapability mode since there is no 481 interaction required with non-MT routers. In this mode, the 482 default topology can be excluded on links as required. 484 3. If there are several non-backbone areas where MT is being used, 485 it is desirable that the backbone area first be upgraded to be MT 486 capable so that inter-area routing is assured for MT destinations 487 in different areas. 489 4. Gradually the whole network can be made MT capable. 491 Note that inter-area routing for the MT-area still depends on the 492 backbone area. Therefore, if different areas configured for a given 493 topology need to communicate, the backbone area also needs to be 494 configured for this topology. 496 7. Security Considerations 498 This document does not raise any security issues that are not already 499 covered in [OSPF]. 501 8. IANA Considerations 503 The T-bit as defined in [TOS-OSPF] for a router's TOS capability is 504 redefined as the MT-bit in this document. No IANA action is required 505 for the MT-bit. 507 Similarly, the TOS field for Router-LSAs, Summary-LSAs, Type-5 and 508 Type-7 AS-external LSAs as defined in [OSPF] is redefined as MT-ID in 509 Section 3.7. 511 MT-ID space is one byte and the entire range is defined by this 512 document. No IANA action is required to manage the MT-ID space. 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 [RFC-KEYWORDS] 527 Bradner, S., "Key words for use in RFC's to Indicate 528 Requirement Levels", RFC 2119, March 1997. 530 [TOS-OSPF] 531 Moy, J., "OSPF Version 2", RFC 1583, March 1994. 533 9.2. Informative References 535 [M-ISIS] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 536 Topology (MT) Routing in IS-IS", 537 draft-ietf-isis-wg-multi-topology-07.txt (work in 538 progress). 540 [STUB] Retana, A., Nguyen, L., White, R., Zinin, A., and D. 541 McPherson, "OSPF Stub Router Advertisement", RFC 3137, 542 June 2001. 544 Appendix A. Acknowledgments 546 The authors would like to thank Scott Sturgess, Alvaro Retana, David 547 Kushi, Yakov Rekhter, Tony Przygienda, and Naiming Shen for their 548 comments on the document. Special thanks to Acee Lindem for editing 549 and to Tom Henderson for an extensive review during the OSPF Working 550 Group last call. 552 Appendix B. OSPF data formats 554 LSA content defined in [OSPF] is modified to introduce the MT-ID. 556 B.1. Router-LSAs 558 Router-LSAs are the Type 1 LSAs. Each router in an area originates a 559 router-LSA. The LSA describes the state and cost of the router's 560 links (i.e., interfaces) to the area. All of the router's links to 561 the area must be described in a single router-LSA. For details 562 concerning the construction of router-LSAs, see Section 12.4.1 of 563 [OSPF]. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | LS age | Options | 1 | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Link State ID | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Advertising Router | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | LS sequence number | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | LS checksum | length | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 |*|*|*|N|W|V|E|B| 0 | # links | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Link ID | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | Link Data | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | # MT-ID | metric | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | MT-ID | 0 | MT-ID metric | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | ... | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | MT-ID | 0 | MT-ID metric | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Link ID | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Link Data | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | ... | 598 Figure 2: Router-LSA Format 600 B.2. Network-LSAs 602 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 603 each broadcast and NBMA network in the area which supports two or 604 more routers. The network-LSA is originated by the network's 605 Designated Router. The LSA describes all routers attached to the 606 network, including the Designated Router itself. The LSA's Link 607 State ID field lists the IP interface address of the Designated 608 Router. 610 The distance from the network to all attached routers is zero. This 611 is why metric fields need not be specified in the network-LSA. For 612 details concerning the construction of network-LSAs, see Section 613 12.4.2 of [OSPF]. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | LS age | Options | 2 | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Link State ID | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Advertising Router | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | LS sequence number | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | LS checksum | length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Network Mask | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Attached Router | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | ... | 634 Figure 3: Network-LSA Format 636 Note that network LSA does not contain any MT-ID fields as the cost 637 of the network to the attached routers is 0 and DR is shared by all 638 topologies. 640 B.3. Summary-LSAs 642 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by 643 area border routers. Summary-LSAs describe inter-area destinations. 644 For details concerning the construction of summary-LSAs, see Section 645 12.4.3 [OSPF]. 647 Type 3 summary-LSAs are used when the destination is an IP network. 648 In this case the LSA's Link State ID field is an IP network number 649 (if necessary, the Link State ID can also have one or more of the 650 network's "host" bits set; see Appendix E [OSPF] for details). When 651 the destination is an AS boundary router, a Type 4 summary-LSA is 652 used, and the Link State ID field is the AS boundary router's OSPF 653 Router ID. (To see why it is necessary to advertise the location of 654 each ASBR, consult Section 16.4 of [OSPF]). Other than the 655 difference in the Link State ID field, the format of Type 3 and 4 656 summary-LSAs is identical. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | LS age | Options | 3 or 4 | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Link State ID | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Advertising Router | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | LS sequence number | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | LS checksum | length | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Network Mask | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | 0 | metric | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | MT-ID | MT-ID metric | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | ... | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | MT-ID | MT-ID metric | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 Figure 4: Summary-LSA Format 684 B.4. AS-external-LSAs 686 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 687 AS boundary routers, and describe destinations external to the AS. 688 For details concerning the construction of AS-external-LSAs, see 689 Section 12.4.3 of [OSPF]. 691 AS-external-LSAs usually describe a particular external destination. 692 For these LSAs the Link State ID field specifies an IP network number 693 (if necessary, the Link State ID can also have one or more of the 694 network's "host" bits set; see Appendix E [OSPF] for details). AS- 695 external-LSAs are also used to describe a default route. Default 696 routes are used when no specific route exists to the destination. 697 When describing a default route, the Link State ID is always set to 698 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | LS age | Options | 5 | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Link State ID | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Advertising Router | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | LS sequence number | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | LS checksum | length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Network Mask | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 |E| 0 | metric | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Forwarding address | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | External Route Tag | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |E| MT-ID | MT-ID metric | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Forwarding address | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | External Route Tag | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | ... | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 |E| MT-ID | MT-ID metric | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Forwarding address | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | External Route Tag | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Figure 5: AS-External-LSA Format 738 B.5. Type-7 AS-external-LSAs 740 Type-7 AS-external-LSAs are originated by AS boundary routers local 741 to an NSSA, and describe destinations external to the AS. The 742 changes to Type-7 AS-external-LSAs are identical to those for AS- 743 external-LSAs (Appendix A.4.5). For details concerning the 744 construction of Type-7 AS-external-LSAs see Section 2.4 of [NSSA]. 746 Authors' Addresses 748 Peter Psenak 749 Cisco Systems 750 Mlynske Nivy 43 751 821 09 752 Bratislava 753 Slovakia 755 Email: ppsenak@cisco.com 757 Sina Mirtorabi 758 Force10 Networks 759 1440 McCarthy Blvd 760 Milpitas, CA 95035 761 USA 763 Email: sina@force10networks.com 765 Abhay Roy 766 Cisco Systems 767 170 West Tasman Drive 768 San Jose, CA 95134 769 USA 771 Email: akr@cisco.com 773 Liem Nguyen 774 Cisco Systems 775 170 West Tasman Drive 776 San Jose, CA 95134 777 USA 779 Email: lhnguyen@cisco.com 781 Padma Pillay-Esnault 782 Cisco Systems 783 170 West Tasman Drive 784 San Jose, CA 95134 785 USA 787 Email: ppe@cisco.com 789 Full Copyright Statement 791 Copyright (C) The Internet Society (2006). 793 This document is subject to the rights, licenses and restrictions 794 contained in BCP 78, and except as set forth therein, the authors 795 retain all their rights. 797 This document and the information contained herein are provided on an 798 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 799 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 800 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 801 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 802 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 803 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 805 Intellectual Property 807 The IETF takes no position regarding the validity or scope of any 808 Intellectual Property Rights or other rights that might be claimed to 809 pertain to the implementation or use of the technology described in 810 this document or the extent to which any license under such rights 811 might or might not be available; nor does it represent that it has 812 made any independent effort to identify any such rights. Information 813 on the procedures with respect to rights in RFC documents can be 814 found in BCP 78 and BCP 79. 816 Copies of IPR disclosures made to the IETF Secretariat and any 817 assurances of licenses to be made available, or the result of an 818 attempt made to obtain a general license or permission for the use of 819 such proprietary rights by implementers or users of this 820 specification can be obtained from the IETF on-line IPR repository at 821 http://www.ietf.org/ipr. 823 The IETF invites any interested party to bring to its attention any 824 copyrights, patents or patent applications, or other proprietary 825 rights that may cover technology that may be required to implement 826 this standard. Please address the information to the IETF at 827 ietf-ipr@ietf.org. 829 Acknowledgment 831 Funding for the RFC Editor function is provided by the IETF 832 Administrative Support Activity (IASA).