idnits 2.17.1 draft-ietf-ospf-mt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 4) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 164: '...d during the MT SPF MUST belong to the...' RFC 2119 keyword, line 193: '...ser configuration MUST be consistently...' RFC 2119 keyword, line 217: '...s within an area MUST agree on how the...' RFC 2119 keyword, line 228: '...MT-bit: This bit MUST be set in the He...' RFC 2119 keyword, line 244: '... o MT-bit MUST be cleared in th...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 106 has weird spacing: '...rrectly class...' == Line 137 has weird spacing: '...lds and are u...' == Line 169 has weird spacing: '...Routing table...' == Line 194 has weird spacing: '...out the netwo...' -- 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 (October 2004) is 7105 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) -- Looks like a reference, but probably isn't: '0-127' on line 177 == Unused Reference: '1' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-06 ** Obsolete normative reference: RFC 1583 (ref. '3') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 3137 (ref. '4') (Obsoleted by RFC 6987) Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Peter Psenak 3 Internet Draft Sina Mirtorabi 4 Expiration Date: April 2005 Abhay Roy 5 File name: draft-ietf-ospf-mt-00.txt Liem Nguyen 6 Cisco Systems 8 Padma Pillay-Esnault 9 Juniper Networks 11 October 2004 13 MT-OSPF: Multi Topology (MT) Routing in OSPF 15 Status of This Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its Areas, and its Working Groups. Note that other 22 groups may also distribute working documents as Internet Drafts. 24 Internet Drafts are draft documents valid for a maximum of six 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a "working 28 draft" or "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 Abstract 38 This draft describes the extension to OSPF in order to define 39 independent IP topologies called Multi-Topologies (MTs). The MT 40 extension can be used for computing different paths for different 41 classes of service, in-band management network or incongruent 42 topologies for unicast and multicast. M-ISIS describes a similar 43 mechanism for ISIS. 44 This draft also describes an optional extension of 45 Multi-topologies whereby some links might be excluded from the 46 default topology. 48 1. Introduction 50 OSPF uses a fixed packet format, therefore it is not easy to 51 introduce any backward compatible extensions. However the OSPF 52 specification [2] introduced TOS metric in an earlier specification 53 [3] in order to announce a different link's cost based on TOS. The 54 TOS based routing as described in [3] was never deployed in the field 55 and later was removed from the spec. 57 We propose to reuse the TOS based metric fields. They have been 58 redefined as MT-ID and MT-ID Metric, to announce different topologies 59 by advertising separate metrics for each of them. 61 2. Terminology 63 We define the following terminology in this document: 65 Non-MT router : Routers that do not have the MT capability 67 MT router : Routers that have MT capability as described in 68 this document 70 MT-ID : Renamed TOS field in LSAs to represent multi 71 topology ID. 73 Default topology : Topology that is built using the TOS 0 metric 74 (default metric) 76 MT topology : Topology that is built using the corresponding 77 MT-ID metric 79 MT#0 topology : Representation of TOS 0 metric in MT-ID format 81 Non-MT-Area : An area that contains only non-MT routers 83 MT-Area : An area that contains both non-MT routers and MT 84 routers or only MT routers 86 3. MT area boundary 88 Each OSPF interface belongs to a single area and all MTs sharing that 89 link need to belong to the same area. Therefore the area boundaries 90 for all MTs are the same but each MT's attachment to the area is 91 independent. 93 4. Adjacency for MTs 95 Each interface can be configured to belong to a set of topologies. A 96 single adjacency will be formed with the remote neighbor even if the 97 interface is configured to participate in multiple topologies and 98 independently of the MT-IDs. 100 5. Sending OSPF control packets 102 OSPF control packets should be sent over the default topology. 104 OSPF control packets sent to the remote end-point of the virtual 105 link may need to traverse multiple hops. These control packets 106 should be correctly classified by the routers as packets belonging 107 to the default topology. Event though the VL may belong to other than 108 default topology (or multiple of them), OSPF control packets sent to 109 the remote end of the virtual link should be forwarded using the 110 default topology. 112 6. Advertising MT adjacencies and corresponding IP prefixes 114 We will reuse the TOS metric field in order to announce a topology or 115 prefixes that belongs to a given MT. The TOS field is renamed to 116 MT-ID in the LSAs payload (see Appendix A). 118 6.1 Intra-area routing 120 When a router establishes a FULL adjacency over a link that belongs 121 to a set of MTs, it will advertise the corresponding cost for each 122 MT-ID. 124 All links are by default included in default topology, all 125 advertised adjacency belonging to the default topology will use 126 the TOS0 metric as in standard OSPF. 128 Each MT has its own MT-ID metric field and when a link is not part of 129 a given MT, the corresponding MT-ID metric will not appear in the LSA. 131 The Network LSA does not contain any MT information as the DR is 132 shared by all MTs and thus there is no change to the Network LSA. 134 6.2 Inter-area and external routing 136 In Summary and External LSAs, the TOS metric fields are renamed to 137 MT-ID metric fields and are used in order to announce prefix/router 138 reachability in the corresponding topology. 140 When a router originates a type 3/4/5/7 LSA that belongs to a set of MTs, 141 it will include the corresponding cost for each MT-ID. The router 142 by default participate in default topology and use the TOS0 metric 143 for default topology as in standard OSPF. 145 7. Flushing MT information 147 When a certain link/prefix that existed or was reachable in a certain 148 topology is no longer part of this topology or the reachability of 149 the link/prefix in this topology was lost, a new version of the LSA 150 that advertised the link/prefix must be originated. This new version 151 of the LSA must not include any metric information representing the 152 link/prefix in this topology. 154 The MT metric in the Router-LSA can also be set to the maximum 155 possible metric to enable the router to become a stub in a certain 156 topology [4]. 158 8. MT SPF Computation 160 By considering MT-ID metrics in the LSAs, OSPF will be able to 161 compute multiple topologies, one for each MT the router is part of 162 and find paths to IP prefixes for each MT independently. A separate 163 SPF will be computed for each MT-ID to find independent paths to IP 164 prefixes. Each nexthop computed during the MT SPF MUST belong to the 165 same MT. 167 Network LSAs are used by all topologies during the SPF computation. 168 During SPF for a given MT-ID, only the link/metric for the given 169 MT-ID will be considered. Entries in the Router Routing table will 170 be MT-ID specific. 172 During the SPF computation for default topology the TOS0 metric is 173 considered during the SPF computation. 175 9. MT ID Values 177 Only MT-IDs in the range [0-127] are valid, because external LSAs use 178 one bit in the MT-ID field (E bit) for the external metric-type. 179 Following MT-ID values are reserved: 181 0 - reserved for routers in MTRoutingExclusionCapability mode 182 to advertise the metric associated with default topology 183 (see section 11.2). 185 1 - reserved for default multicast topology. 187 Any unknown MT-ID should be ignored. 189 10. Forwarding in MT 191 Forwarding must make sure that only routes belonging to the single 192 topology are used to forward the packet along its way from source to 193 destination, therefore user configuration MUST be consistently 194 applied throughout the network so that an incoming packet is 195 associated with the same topology on each hop as it is being 196 forwarded. It is outside of the scope of this document to consider 197 different methods of associating an incoming packet to the 198 corresponding MT. 200 11. Exclusion of links in the default topology 202 The multi-topologies imply that all the routers participate in the 203 default topology. However, it is useful in some circumstances 204 to exclude some links from the default topology and reserve them 205 for some specific classes of traffic. 207 The multi-topologies extension for default topology link exclusion 208 is described in the following sections. 210 11.1 MT-bit in Hello packet 212 OSPF does not have the notion of unreachable link. All links can 213 have a maximum metric of 0xFFFF carried in the Router LSA. The link 214 exclusion capability requires routers to ignore TOS 0 metric in 215 router-LSA in default topology and use MT-ID#0 metric instead to 216 advertise the metric associated with the default topology. Hence, 217 all routers within an area MUST agree on how the metric for default 218 topology will be advertised. 220 The unused T-bit is renamed (MT) in the option field in order to 221 enforce that a multi-topology link-excluding capable router will 222 only interact with another similarly configured router. 224 +---+---+---+---+---+---+---+---+ 225 |DN |O |DC |EA |NP |MC |E |MT | 226 +---+---+---+---+---+---+---+---+ 228 MT-bit: This bit MUST be set in the Hello packet only if 229 MTRoutingExclusionCapability is Enabled (see section 11.2). 231 11.2 New parameter in the Area Data Structure 233 We define a new parameters in the Area Data Structure: 235 MTRoutingExclusionCapability 236 This is a configurable parameter that will be used to facilitate 237 the introduction of MT routers in an area and ensure the backward 238 compatibility. 240 By default, when an area data structure is created the 241 MTRoutingExclusionCapabilty is disabled. 243 If MTRoutingExclusionCapability is disabled: 244 o MT-bit MUST be cleared in the Hello packet 245 o If a link participates in a non-default topology, 246 it is automatically included in default topology (by using 247 the default metric field as it is done in standard OSPF [2]) 248 so that MT routers interact correctly with non-MT routers. 250 If MTRoutingExclusionCapability is set to Enabled: 251 o MT-bit MUST be set in the Hello packet 252 o The router will only accept a Hello if the MT-bit is set (see 253 section 11.3) 255 We call MTRoutingExclusionCapability "mode", when 256 MTRoutingExclusionCapability is set to Enabled. 258 11.3. Forming adjacency with link exclusion capability. 260 In order to have a smooth transition from a non-MT area to MT-area, a 261 MT router with MTRoutingExclusionCapability set to disable will form 262 adjacency with non-MT routers and it will include all links as part 263 of default topology. 265 A link can cease participating in default topology if 266 MTRoutingExclusionCapability is set to Enabled. In this state, a 267 router will only form adjacency with routers that set the MT-bit 268 in their Hello packets. This will ensure that all routers are in 269 Enabled mode before default topology can be disabled on a link. 271 Receiving OSPF Hello packets defined in section 8.2 of [2] are 272 modified as follows: 274 If the MTRoutingExclusionCapability of the Area Data structure 275 is set to Enabled, the Hello packets are discarded if: 277 o the received Hello packet does not have the MT-bit set 279 11.4. Sending OSPF control packets over an excluded link. 281 If MTRoutingExclusionCapability is set to Enabled and default 282 topology is not configured on the interface, connected route should 283 still exist for a default topology that would enable the OSPF 284 control packets to be sent and received. 286 11.5. Modified MT SPF Computation with link exclusion capability. 288 When MTRoutingExclusionCapability is set to Enabled, MT#0 can be 289 removed if a link does not participate in default topology. In that 290 case the TOS0 metric is set to infinity (0xFFFF) and ignored during 291 the MT#0 SPF computation. 293 When MTRoutingExclusionCapability is set to Enabled and a link 294 participates in default topology, MT-ID#0 metric is used to advertise 295 metric associated with the default topology. Further TOS0 metric is 296 set to the same value as MT-ID#0 metric. However TOS 0 metric is 297 ignored during SPF for default topology and only MT-ID#0 metric 298 is used for SPF in default topology. 300 When originating Summary and External LSAs, if 301 MTRoutingExclusionCapability is set to Enabled: 303 o if the prefix / router does not exist in default topology, TOS0 304 metric is set to infinity (0xFFFFFF). 306 o if the prefix / router exist in default topology, TOS0 metric 307 is used to announce a prefix / router in default topology. 309 During the Summary and External prefix calculation for default topology 310 TOS0 metric is used in LSA Type-3/4/5/7. 312 12. Interoperability between MT capable and non-MT capable routers 314 The default metric field is mandatory in all LSAs (even when metric 315 value is 0). Even when the link or a prefix does not exist in the 316 default topology, a non MT capable router can consider the zero value 317 in the metric field as a valid metric and consider the link/prefix as 318 part of the default topology. 320 In order to prevent the above problem, a MT capable router will 321 by default include all links as part of the default topology. If links 322 need to be removed from the default topology, a MT capable router 323 MUST be configured in MTRoutingExclusionCapability mode. In this mode 324 the router will make sure that all routers in the area are in the 325 MTRoutingExclusionCapability mode before forming any adjacency so that 326 TOS0 metric field can be safely ignored during the MT#0 SPF computation. 328 Note that for any prefix or router to become reachable in a certain 329 topology, a contiguous path inside that topology must exist between the 330 calculating router and the destination prefix or router. 332 13. Migration from non-MT-Area to MT-area 334 Introducing MT-OSPF in a network can be gradually done since MT 335 routers will interact in default topology with non-MT routers, 336 yet exchanging information about other topologies with other MT 337 capable routers. 339 If there is a requirement to exclude some links from default topology 340 in an area, all routers MUST be in MTRoutingExclusionCapability mode. 341 In this section we describe migrations steps to consider while 342 transitioning from a non-MT network to a MT network. 344 Migration Steps 345 --------------- 346 Consider a network with a backbone area and a sets of non-backbone 347 areas functioning in standard OSPF mode. We would like to migrate to 348 a MT network either partially or completely. 350 1) Part of an area is upgraded as needed to have MT capability, the 351 MT routers will interact with non-MT routers in default topology, 352 further MT routers will participate in MT topology as needed. 354 2) If a new non-backbone area is created for MT routers, it may be 355 set in MTRoutingExclusionCapability mode as there is no interaction 356 required with non-MT routers, in this mode default topology 357 can be excluded if required. 359 3) If there is more than one non-backbone areas where MT is being 360 used, it is desirable that area 0 be first upgraded to MT capable 361 routers so that inter-area routing is assured for MT destinations 362 in different areas. 364 4) Gradually the whole network can be made MT aware 366 Note that Inter-area routing for the MT-area still depends on the 367 backbone area. Therefore if different areas in a given MT-ID need to 368 communicate, the backbone area also needs to be configured for this 369 MT-ID. 371 14. Acknowledgments 373 The authors would like to thank Scott Sturgess and Alvaro Retana for 374 their comments on the document. 376 15. Security Consideration 378 No specific security issues with the proposed solutions are known. 380 16. IANA Considerations 382 T-bit defined in [3] for router's TOS capability is reclaimed as 383 MT-bit in this document. Likewise, TOS field in type 1,3,4,5,7 LSAs 384 defined in [2] is reclaimed as MT-ID in this document. 386 17. References 388 [1] Przygienda, Shen, Sheth, "Multi Topology (MT) Routing in IS-IS", 389 draft-ietf-isis-wg-multi-topology-06.txt, Work in progress. 391 [2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 393 [3] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994. 395 [4] Retana, Nguyen, White, "OSPF Stub Router Advertisement", 396 RFC 3137, June 2001. 398 Appendix A. 400 LSAs content defined in [2] are modified to introduce MT-ID. 402 A.1 Router-LSAs 404 Router-LSAs are the Type 1 LSAs. Each router in an area originates 405 a router-LSA. The LSA describes the state and cost of the router's 406 links (i.e., interfaces) to the area. All of the router's links to 407 the area must be described in a single router-LSA. For details 408 concerning the construction of router-LSAs, see Section 12.4.1. [2] 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | LS age | Options | 1 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Link State ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Advertising Router | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | LS sequence number | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | LS checksum | length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |*|*|*|N|W|V|E|B| 0 | # links | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Link ID | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Link Data | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | # MT-ID | metric | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | MT-ID | 0 | MT-ID metric | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | ... | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | MT-ID | 0 | MT-ID metric | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Link ID | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Link Data | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | ... | 444 A.2 Network-LSAs 446 Network-LSAs are the Type 2 LSAs. A network-LSA is originated for 447 each broadcast and NBMA network in the area which supports two or 448 more routers. The network-LSA is originated by the network's 449 Designated Router. The LSA describes all routers attached to the 450 network, including the Designated Router itself. The LSA's Link 451 State ID field lists the IP interface address of the Designated 452 Router. 454 The distance from the network to all attached routers is zero. This 455 is why metric fields need not be specified in the network-LSA. For 456 details concerning the construction of network-LSAs, see Section 457 12.4.2. [2] 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | LS age | Options | 2 | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Link State ID | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Advertising Router | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | LS sequence number | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | LS checksum | length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Network Mask | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Attached Router | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | ... | 478 Note that network LSA does not contain any MT-ID field as the cost of 479 the network to the attached routers is 0 and DR is shared by all MT. 481 A.3 Summary-LSAs 483 Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated 484 by area border routers. Summary-LSAs describe inter-area 485 destinations. For details concerning the construction of summary- 486 LSAs, see Section 12.4.3. [2] 488 Type 3 summary-LSAs are used when the destination is an IP network. 489 In this case the LSA's Link State ID field is an IP network number 490 (if necessary, the Link State ID can also have one or more of the 491 network's "host" bits set; see Appendix E [2] for details). When the 492 destination is an AS boundary router, a Type 4 summary-LSA is used, 493 and the Link State ID field is the AS boundary router's OSPF Router 494 ID. (To see why it is necessary to advertise the location of each 495 ASBR, consult Section 16.4 of [2]). Other than the difference in the 496 Link State ID field, the format of Type 3 and 4 summary-LSAs is 497 identical. 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | LS age | Options | 3 or 4 | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Link State ID | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Advertising Router | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | LS sequence number | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | LS checksum | length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Network Mask | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | 0 | metric | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | MT-ID | MT-ID metric | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | ... | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | MT-ID | MT-ID metric | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 A.4.5 AS-external-LSAs 525 AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by 526 AS boundary routers, and describe destinations external to the AS. 527 For details concerning the construction of AS-external-LSAs, see 528 Section 12.4.3. [2] 530 AS-external-LSAs usually describe a particular external destination. 531 For these LSAs the Link State ID field specifies an IP network 532 number (if necessary, the Link State ID can also have one or more of 533 the network's "host" bits set; see Appendix E [2] for details). AS- 534 external-LSAs are also used to describe a default route. Default 535 routes are used when no specific route exists to the destination. 536 When describing a default route, the Link State ID is always set to 537 DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | LS age | Options | 5 | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Link State ID | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Advertising Router | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | LS sequence number | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | LS checksum | length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Network Mask | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |E| 0 | metric | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Forwarding address | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | External Route Tag | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 |E| MT-ID | MT-ID metric | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Forwarding address | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | External Route Tag | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | ... | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 |E| MT-ID | MT-ID metric | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Forwarding address | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | External Route Tag | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Authors' address 577 Peter Psenak Abhay Roy 578 Cisco Systems Cisco systems 579 Parc Pegasus, 170 W. Tasman Dr. 580 De Kleetlaan 6A San Jose, CA 95134 581 1831 Diegem, Belgium USA 582 E-mail: ppsenak@cisco.com E-mail: akr@cisco.com 584 Sina Mirtorabi Liem Nguyen 585 Cisco Systems Cisco Systems 586 225 West Tasman drive 7025 Kit Creek Rd. 587 San Jose, CA 95134 Research Triangle Park, NC 27709 588 USA USA 589 E-mail: sina@cisco.com E-mail: lhnguyen@cisco.com 591 Padma PIllay-Esnault 592 Juniper Networks 593 1194 N. Mathilda Avenue 594 Sunnyvale, CA 94089 595 USA 596 E-mail: padma@juniper.net