idnits 2.17.1 draft-ietf-ospf-opaque-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.0 Abstract' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 127 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([MOSPF], [NSSA], [OSPF], [EAL], [DEMD], [ARA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 157 has weird spacing: '...and the inter...' -- 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 1997) is 9652 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'OSPF' on line 345 looks like a reference -- Missing reference section? 'ARA' on line 293 looks like a reference -- Missing reference section? 'MOSPF' on line 349 looks like a reference -- Missing reference section? 'NSSA' on line 353 looks like a reference -- Missing reference section? 'DEMD' on line 357 looks like a reference -- Missing reference section? 'EAL' on line 361 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Opaque November 1997 3 Expiration Date: November 1998 FORE Systems 4 File name: draft-ietf-ospf-opaque-02.txt 6 The OSPF Opaque LSA Option 8 Rob Coltun 9 FORE Systems 10 (301) 571-2521 11 rcoltun@fore.com 13 Status Of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working docu- 16 ments of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute work- 18 ing documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress". 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 Table Of Contents 32 1.0 Abstract ................................................. 3 34 2.0 Overview ................................................. 3 36 2.1 Organization Of This Document ............................ 3 38 2.2 Acknowledgments .......................................... 3 40 3.0 The Opaque LSA ........................................... 4 42 3.1 Flooding Opaque LSAs ..................................... 5 44 3.2 Modifications To The Neighbor State Machine .............. 6 46 4.0 Protocol Data Structures ................................. 8 48 4.1 Additions To The OSPF Neighbor Structure ................. 8 50 5.0 References ............................................... 8 52 Appendix A: OSPF Data Formats ................................ 10 54 A.1 The Options Field ........................................ 10 56 A.2 Opaque LSA ............................................... 12 57 1.0 Abstract 59 This memo defines enhancements to the OSPF protocol to support a new 60 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 61 LSAs provide a generalized mechanism to allow for the future extensi- 62 bility of OSPF. Opaque LSAs consist of a standard LSA header followed 63 by application-specific information. The information field may be 64 used directly by OSPF or by other applications. Standard OSPF link- 65 state database flooding mechanisms are used to distribute Opaque LSAs 66 to all or some limited portion of the OSPF topology. 68 2.0 Overview 70 Over the last several years the OSPF routing protocol [OSPF] has been 71 widely deployed throughout the Internet. As a result of this deploy- 72 ment and the evolution of networking technology, OSPF has been 73 extended to support many options; this evolution will obviously con- 74 tinue. 76 This memo defines enhancements to the OSPF protocol to support a new 77 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 78 LSAs provide a generalized mechanism to allow for the future extensi- 79 bility of OSPF. The information contained in Opaque LSAs may be used 80 directly by OSPF or indirectly by some application wishing to distri- 81 bute information throughout the OSPF domain. For example, the OSPF 82 LSA may be used by routers to distribute IP to link-layer address 83 resolution information (see [ARA] for more information). The exact 84 use of Opaque LSAs is beyond the scope of this draft. 86 Opaque LSAs consist of a standard LSA header followed by a 32-bit 87 aligned application-specific information field. Like any other LSA, 88 the Opaque LSA uses the link-state database distribution mechanism for 89 flooding this information throughout the topology. The link-state 90 type field of the Opaque LSA identifies the LSA's range of topological 91 distribution. This range is referred to as the Flooding Scope. 93 2.1 Organization Of This Document 95 This document first defines the three types of Opaque LSAs followed by 96 a description of OSPF packet processing. The packet processing sec- 97 tions include modifications to the flooding procedure and to the 98 neighbor state machine. Appendix A then gives the packet formats. 100 2.2 Acknowledgments 101 The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, 102 Sandra Murphy, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Work- 103 ing Group for the ideas and support they have given to this project. 105 3.0 The Opaque LSA 107 Opaque LSAs are types 9, 10 and 11 link-state advertisements. Each 108 type has a unique flooding scope. Opaque LSAs consist of a standard 109 LSA header followed by a 32-bit aligned application-specific informa- 110 tion field. Standard link-state database flooding mechanisms are used 111 for distribution of Opaque LSAs. The range of topological distribu- 112 tion (i.e., the flooding scope) of an Opaque LSA is identified by its 113 link-state type. This section documents the flooding of Opaque LSAs. 115 The flooding scope associated with each Opaque link-state type is 116 defined as follows. 118 o Link-state type 9 denotes a link-local scope. Type-9 Opaque 119 LSAs are not flooded beyond the local (sub)network. 121 o Link-state type 10 denotes an area-local scope. Type-10 Opaque 122 LSAs are not flooded beyond the borders of their associated area. 124 o Link-state type 11 denotes that the LSA is flooded throughout 125 the Autonomous System (AS). The flooding scope of type-11 LSAs 126 are equivalent to the flooding scope of AS-external (type-5) 127 LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout 128 all transit areas, 2) not flooded into stub areas from the back- 129 bone and 3) not originated by routers into their connected stub 130 areas. As with type-5 LSAs, if a type-11 Opaque LSA is received 131 in a stub area from a neighboring router within the stub area the 132 LSA is rejected. 134 The link-state ID of the Opaque LSA is divided into a type field (the 135 first 8 bits) and a type-specific ID (the remaining 24 bits). The 136 packet format of the Opaque LSA is given in Appendix A. 138 The responsibility for proper handling of the Opaque LSA's flooding 139 scope is placed on both the sender and receiver of the LSA. The 140 receiver must always store a valid received Opaque LSA in its link- 141 state database. The receiver must not accept Opaque LSAs that violate 142 the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not 143 accepted in a stub area). The flooding scope effects both the build- 144 ing of the Database Summary List during the initial synchronization of 145 the link-state database and the flooding procedure. 147 The following describes the modifications to these procedures that are 148 necessary to insure conformance to the Opaque LSA's Scoping Rules. 150 3.1 Flooding Opaque LSAs 152 The flooding of Opaque LSAs must follow the rules of Flooding Scope as 153 specified in this section. The following describes the Opaque LSA's 154 type-specific flooding restrictions. 156 o If the Opaque LSA is type 9 (the flooding scope is link-local) 157 and the interface that the LSA was received on is not the same 158 as the target interface (e.g., the interface associated with a 159 particular target neighbor), the Opaque LSA must not be flooded 160 out that interface (or to that neighbor). An implementation 161 should keep track of the IP interface associated with each Opaque 162 LSA having a link-local flooding scope. 164 o If the Opaque LSA is type 10 (the flooding scope is area-local) 165 and the area associated with Opaque LSA (upon reception) is not 166 the same as the area associated with the target interface, the 167 Opaque LSA must not be flooded out the interface. An implementa- 168 tion should keep track of the OSPF area associated with each 169 Opaque LSA having an area-local flooding scope. 171 o If the Opaque LSA is type 11 (the flooding scope is the entire 172 AS) and the target interface is associated with a stub area the 173 Opaque LSA must not be flooded out the interface. 175 o If an Opaque LSA is received on an interface associated with a 176 stub area, the LSA is to be discarded and not acknowledged since 177 neighboring router has flooded the LSA in error (see Section 13 178 of [OSPF], receiving LSAs having unknown LS types). 180 When opaque-capable routers and non-opaque-capable OSPF routers are 181 mixed together in a routing domain, the Opaque LSAs are not flooded to 182 the non-opaque-capable routers. As a general design principle, 183 optional OSPF advertisements are only flooded to those routers that 184 understand them. 186 An opaque-capable router learns of its neighbor's opaque capability at 187 the beginning of the "Database Exchange Process" (see Section 10.6 of 188 [OSPF], receiving Database Description packets from a neighbor in 189 state ExStart). A neighbor is opaque-capable if and only if it sets 190 the O-bit in the Options field of its Database Description packets. 191 Then, in the next step of the Database Exchange process, Opaque LSAs 192 are included in the Database summary list that is sent to the neighbor 193 (see Sections 3.2 below and 10.3 of [OSPF]) if and only if the neigh- 194 bor is opaque capable. 196 When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable 197 router looks at the neighbor's opaque capability. Opaque LSAs are 198 only flooded to opaque-capable neighbors. To be more precise, in Sec- 199 tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state 200 retransmission lists of opaque-capable neighbors. However, when send- 201 ing Link State Update packets as multicasts, a non-opaque-capable 202 neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- 203 capable router will then simply discard the LSA (see Section 13 of 204 [OSPF], receiving LSAs having unknown LS types). 206 3.2 Modifications To The Neighbor State Machine 208 The state machine as it exists in section 10.3 of [OSPF] remains 209 unchanged except for the action associated with State: ExStart, Event: 210 NegotiationDone which is where the Database summary list is built. To 211 incorporate the Opaque LSA in OSPF this action is changed to the fol- 212 lowing. 214 State(s): ExStart 216 Event: NegotiationDone 218 New state: Exchange 220 Action: The router must list the contents of its entire area 221 link-state database in the neighbor Database summary 222 list. The area link-state database consists of the 223 Router LSAs, Network LSAs, Summary LSAs and types 9 224 and 10 Opaque LSAs contained in the area structure, 225 along with AS External and type-11 Opaque LSAs 226 contained in the global structure. AS External and 227 type-11 Opaque LSAs are omitted from a virtual 228 neighbor's Database summary list. AS External LSAs 229 and type-11 Opaque LSAs are omitted from the 230 Database summary list if the area has been 231 configured as a stub area (see Section 3.6 of [OSPF]). 233 Opaque LSAs are omitted from the Database 234 summary list if the following conditions exist. 235 1) the LSA type is type 9 (the flooding scope 236 is link-local) and interface associated with the 237 neighbor is not the interface associated with 238 the Opaque LSA (as noted upon reception); 239 2) the LSA type is 10 (the flooding scope is 240 area-local) and the area associated with the 241 neighbor's interface is not the area associated 242 with the Opaque LSA (as noted upon reception). 244 Any advertisement whose age is equal to MaxAge is 245 omitted from the Database summary list. It is 246 instead added to the neighbor's link-state 247 retransmission list. A summary of the Database 248 summary list will be sent to the neighbor in 249 Database Description packets. Each Database 250 Description Packet has a DD sequence number, and is 251 explicitly acknowledged. Only one Database 252 Description Packet is allowed to be outstanding at 253 any one time. For more detail on the sending and 254 receiving of Database Description packets, see 255 Sections 10.6 and 10.8 of [OSPF]. 257 4.0 Protocol data structures 259 The Opaque option is described herein in terms of its operation on 260 various protocol data structures. These data structures are included 261 for explanatory uses only, and are not intended to constrain an imple- 262 mentation. In addition to the data structures listed below, this 263 specification references the various data structures (e.g., OSPF 264 neighbors) defined in [OSPF]. 266 In an OSPF router, the following item is added to the list of global 267 OSPF data structures described in Section 5 of [OSPF]: 269 o Opaque capability. Indicates whether the router is running the 270 Opaque option (i.e., capable of storing Opaque LSAs). Such a 271 router will continue to inter-operate with non-opaque-capable 272 OSPF routers. 274 4.1 Additions To The OSPF Neighbor Structure 276 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an 277 opaque-capable router, the following items are added to the OSPF 278 neighbor structure: 280 o Neighbor Options. This field was already defined in the OSPF 281 specification. However, in opaque-capable routers there is a new 282 option which indicates the neighbor's Opaque capability. This new 283 option is learned in the Database Exchange process through recep- 284 tion of the neighbor's Database Description packets, and deter- 285 mines whether Opaque LSAs are flooded to the neighbor. For a more 286 detailed explanation of the flooding of the Opaque LSA see sec- 287 tion 3 of this document. 289 5.0 References 291 [OSPF] Moy, J., "OSPF Version 2", RFC 2178 Cascade, July 1997. 293 [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution 294 Advertisement Option", draft-ietf-ospf-ara-01.txt, November 1997. 296 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 297 Inc., March 1994. 299 [NSSA] Coltun, R., Fuller, V., Murphy, P., "The OSPF NSSA Option", 300 draft-ietf-ospf-nssa-update-02.txt, April 1997. 302 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 303 Cascade, April 1995. 305 Appendix A: OSPF Data formats 307 This appendix describes the format of the Options Field followed by 308 the packet format of the Opaque LSA. 310 A.1 The Options Field 312 The OSPF Options field is present in OSPF Hello packets, Database 313 Description packets and all link-state advertisements. The Options 314 field enables OSPF routers to support (or not support) optional capa- 315 bilities, and to communicate their capability level to other OSPF 316 routers. Through this mechanism routers of differing capabilities can 317 be mixed within an OSPF routing domain. 319 When used in Hello packets, the Options field allows a router to 320 reject a neighbor because of a capability mismatch. Alternatively, 321 when capabilities are exchanged in Database Description packets a 322 router can choose not to forward certain link-state advertisements to 323 a neighbor because of its reduced functionality. Lastly, listing 324 capabilities in link-state advertisements allows routers to forward 325 traffic around reduced functionality routers by excluding them from 326 parts of the routing table calculation. 328 Six bits of the OSPF Options field have been assigned, although only 329 the O-bit is described completely by this memo. Each bit is described 330 briefly below. Routers should reset (i.e., clear) unrecognized bits in 331 the Options field when sending Hello packets or Database Description 332 packets and when originating link-state advertisements. Conversely, 333 routers encountering unrecognized Option bits in received Hello Pack- 334 ets, Database Description packets or link-state advertisements should 335 ignore the capability and process the packet/advertisement normally. 337 +------------------------------------+ 338 | * | O | DC | EA | N/P | MC | E | * | 339 +------------------------------------+ 341 The Options Field 343 E-bit 344 This bit describes the way AS-external-LSAs are flooded, as 345 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 347 MC-bit 348 This bit describes whether IP multicast datagrams are forwarded 349 according to the specifications in [MOSPF]. 351 N/P-bit 352 This bit describes the handling of Type-7 LSAs, as specified in 353 [NSSA]. 355 DC-bit 356 This bit describes the router's handling of demand circuits, as 357 specified in [DEMD]. 359 EA-bit 360 This bit describes the router's willingness to receive and for- 361 ward External-Attributes-LSAs, as specified in [EAL]. 363 O-bit 364 This bit describes the router's willingness to receive and for- 365 ward Opaque-LSAs as specified in this document. 367 A.2 Opaque LSA 369 Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These 370 advertisements may be used directly by OSPF or indirectly by some 371 application wishing to distribute information throughout the OSPF 372 domain. The function of the Opaque LSA option is to provide for 373 future extensibility of OSPF. 375 Opaque LSAs contain some number of octets (of application-specific 376 data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA 377 uses the link-state database distribution mechanism for flooding this 378 information throughout the topology. However, the Opaque LSA has a 379 flooding scope associated with it so that the scope of flooding may be 380 link-local (type 9), area-local (type 10) or the entire OSPF routing 381 domain (type 11). Section 3 of this document describes the flooding 382 procedures for the Opaque LSA. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | LS age | Options | 9, 10 or 11 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Opaque Type | Opaque ID | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Advertising Router | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | LS Sequence Number | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | LS checksum | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | | 398 + + 399 | Opaque Information | 400 + + 401 | ... | 403 Link-State Type 405 The link-state type of the Opaque LSA identifies the LSA's range 406 of topological distribution. This range is referred to as the 407 Flooding Scope. The following explains the flooding scope of 408 each of the link-state types. 410 o A value of 9 denotes a link-local scope. Opaque LSAs with a 411 link-local scope are not flooded beyond the local (sub)network. 413 o A value of 10 denotes an area-local scope. Opaque LSAs with a 414 area-local scope are not flooded beyond the area that they are 415 originated into. 417 o A value of 11 denotes that the LSA is flooded throughout the 418 Autonomous System (e.g., has the same scope as type-5 LSAs). 419 Opaque LSAs with AS-wide scope are not flooded into stub areas. 421 Syntax Of The Opaque LSA's Link-State ID 423 The link-state ID of the Opaque LSA is divided into an Opaque 424 Type field (the first 8 bits) and an Opaque ID (the remaining 24 425 bits). Opaque type values in the range of 128-255 are reserved 426 for private and experimental use.