idnits 2.17.1 draft-ietf-ospf-opaque-03.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-25) 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 124 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: ---------------------------------------------------------------------------- -- 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 1998) is 9597 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 346 looks like a reference -- Missing reference section? 'ARA' on line 294 looks like a reference -- Missing reference section? 'MOSPF' on line 350 looks like a reference -- Missing reference section? 'NSSA' on line 354 looks like a reference -- Missing reference section? 'DEMD' on line 358 looks like a reference -- Missing reference section? 'EAL' on line 362 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Opaque January 1998 4 Expiration Date: July 1998 FORE Systems 5 File name: draft-ietf-ospf-opaque-03.txt 7 The OSPF Opaque LSA Option 9 Rob Coltun 10 FORE Systems 11 (301) 571-2521 12 rcoltun@fore.com 14 Status Of This Memo 16 This document is an Internet-Draft. Internet-Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute work- 19 ing documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress". 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net 29 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Table Of Contents 33 1.0 Abstract ................................................. 3 35 2.0 Overview ................................................. 3 37 2.1 Organization Of This Document ............................ 3 39 2.2 Acknowledgments .......................................... 3 41 3.0 The Opaque LSA ........................................... 4 43 3.1 Flooding Opaque LSAs ..................................... 5 45 3.2 Modifications To The Neighbor State Machine .............. 6 47 4.0 Protocol Data Structures ................................. 8 49 4.1 Additions To The OSPF Neighbor Structure ................. 8 51 5.0 References ............................................... 8 53 Appendix A: OSPF Data Formats ................................ 10 55 A.1 The Options Field ........................................ 10 57 A.2 Opaque LSA ............................................... 12 59 1.0 Abstract 61 This memo defines enhancements to the OSPF protocol to support a new 62 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 63 LSAs provide a generalized mechanism to allow for the future extensi- 64 bility of OSPF. Opaque LSAs consist of a standard LSA header followed 65 by application-specific information. The information field may be 66 used directly by OSPF or by other applications. Standard OSPF link- 67 state database flooding mechanisms are used to distribute Opaque LSAs 68 to all or some limited portion of the OSPF topology. 70 2.0 Overview 72 Over the last several years the OSPF routing protocol [OSPF] has been 73 widely deployed throughout the Internet. As a result of this deploy- 74 ment and the evolution of networking technology, OSPF has been 75 extended to support many options; this evolution will obviously con- 76 tinue. 78 This memo defines enhancements to the OSPF protocol to support a new 79 class of link-state advertisements (LSA) called Opaque LSAs. Opaque 80 LSAs provide a generalized mechanism to allow for the future extensi- 81 bility of OSPF. The information contained in Opaque LSAs may be used 82 directly by OSPF or indirectly by some application wishing to distri- 83 bute information throughout the OSPF domain. For example, the OSPF 84 LSA may be used by routers to distribute IP to link-layer address 85 resolution information (see [ARA] for more information). The exact 86 use of Opaque LSAs is beyond the scope of this draft. 88 Opaque LSAs consist of a standard LSA header followed by a 32-bit 89 aligned application-specific information field. Like any other LSA, 90 the Opaque LSA uses the link-state database distribution mechanism for 91 flooding this information throughout the topology. The link-state 92 type field of the Opaque LSA identifies the LSA's range of topological 93 distribution. This range is referred to as the Flooding Scope. 95 2.1 Organization Of This Document 97 This document first defines the three types of Opaque LSAs followed by 98 a description of OSPF packet processing. The packet processing sec- 99 tions include modifications to the flooding procedure and to the 100 neighbor state machine. Appendix A then gives the packet formats. 102 2.2 Acknowledgments 103 The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, 104 Sandra Murphy, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Work- 105 ing Group for the ideas and support they have given to this project. 107 3.0 The Opaque LSA 109 Opaque LSAs are types 9, 10 and 11 link-state advertisements. Each 110 type has a unique flooding scope. Opaque LSAs consist of a standard 111 LSA header followed by a 32-bit aligned application-specific informa- 112 tion field. Standard link-state database flooding mechanisms are used 113 for distribution of Opaque LSAs. The range of topological distribu- 114 tion (i.e., the flooding scope) of an Opaque LSA is identified by its 115 link-state type. This section documents the flooding of Opaque LSAs. 117 The flooding scope associated with each Opaque link-state type is 118 defined as follows. 120 o Link-state type 9 denotes a link-local scope. Type-9 Opaque 121 LSAs are not flooded beyond the local (sub)network. 123 o Link-state type 10 denotes an area-local scope. Type-10 Opaque 124 LSAs are not flooded beyond the borders of their associated area. 126 o Link-state type 11 denotes that the LSA is flooded throughout 127 the Autonomous System (AS). The flooding scope of type-11 LSAs 128 are equivalent to the flooding scope of AS-external (type-5) 129 LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout 130 all transit areas, 2) not flooded into stub areas from the back- 131 bone and 3) not originated by routers into their connected stub 132 areas. As with type-5 LSAs, if a type-11 Opaque LSA is received 133 in a stub area from a neighboring router within the stub area the 134 LSA is rejected. 136 The link-state ID of the Opaque LSA is divided into a type field (the 137 first 8 bits) and a type-specific ID (the remaining 24 bits). The 138 packet format of the Opaque LSA is given in Appendix A. 140 The responsibility for proper handling of the Opaque LSA's flooding 141 scope is placed on both the sender and receiver of the LSA. The 142 receiver must always store a valid received Opaque LSA in its link- 143 state database. The receiver must not accept Opaque LSAs that violate 144 the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not 145 accepted in a stub area). The flooding scope effects both the build- 146 ing of the Database Summary List during the initial synchronization of 147 the link-state database and the flooding procedure. 149 The following describes the modifications to these procedures that are 150 necessary to insure conformance to the Opaque LSA's Scoping Rules. 152 3.1 Flooding Opaque LSAs 154 The flooding of Opaque LSAs must follow the rules of Flooding Scope as 155 specified in this section. Section 13 of [OSPF] describes the OSPF 156 flooding procedure. The following describes the Opaque LSA's type- 157 specific flooding restrictions. 159 o If the Opaque LSA is type 9 (the flooding scope is link-local) 160 and the interface that the LSA was received on is not the same as 161 the target interface (e.g., the interface associated with a par- 162 ticular target neighbor), the Opaque LSA must not be flooded out 163 that interface (or to that neighbor). An implementation should 164 keep track of the IP interface associated with each Opaque LSA 165 having a link-local flooding scope. 167 o If the Opaque LSA is type 10 (the flooding scope is area-local) 168 and the area associated with Opaque LSA (upon reception) is not 169 the same as the area associated with the target interface, the 170 Opaque LSA must not be flooded out the interface. An implementa- 171 tion should keep track of the OSPF area associated with each 172 Opaque LSA having an area-local flooding scope. 174 o If the Opaque LSA is type 11 (the LSA is flooded throughout the 175 AS) and the target interface is associated with a stub area the 176 Opaque LSA must not be flooded out the interface. A type-11 177 Opaque LSA that is received on an interface associated with a 178 stub area must be discarded and not acknowledged (the neighboring 179 router has flooded the LSA in error). 181 When opaque-capable routers and non-opaque-capable OSPF routers are 182 mixed together in a routing domain, the Opaque LSAs are not flooded to 183 the non-opaque-capable routers. As a general design principle, 184 optional OSPF advertisements are only flooded to those routers that 185 understand them. 187 An opaque-capable router learns of its neighbor's opaque capability at 188 the beginning of the "Database Exchange Process" (see Section 10.6 of 189 [OSPF], receiving Database Description packets from a neighbor in 190 state ExStart). A neighbor is opaque-capable if and only if it sets 191 the O-bit in the Options field of its Database Description packets. 192 Then, in the next step of the Database Exchange process, Opaque LSAs 193 are included in the Database summary list that is sent to the neighbor 194 (see Sections 3.2 below and 10.3 of [OSPF]) if and only if the 195 neighbor is opaque capable. 197 When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable 198 router looks at the neighbor's opaque capability. Opaque LSAs are 199 only flooded to opaque-capable neighbors. To be more precise, in Sec- 200 tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state 201 retransmission lists of opaque-capable neighbors. However, when send- 202 ing Link State Update packets as multicasts, a non-opaque-capable 203 neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- 204 capable router will then simply discard the LSA (see Section 13 of 205 [OSPF], receiving LSAs having unknown LS types). 207 3.2 Modifications To The Neighbor State Machine 209 The state machine as it exists in section 10.3 of [OSPF] remains 210 unchanged except for the action associated with State: ExStart, Event: 211 NegotiationDone which is where the Database summary list is built. To 212 incorporate the Opaque LSA in OSPF this action is changed to the fol- 213 lowing. 215 State(s): ExStart 217 Event: NegotiationDone 219 New state: Exchange 221 Action: The router must list the contents of its entire area 222 link-state database in the neighbor Database summary 223 list. The area link-state database consists of the 224 Router LSAs, Network LSAs, Summary LSAs and types 9 225 and 10 Opaque LSAs contained in the area structure, 226 along with AS External and type-11 Opaque LSAs 227 contained in the global structure. AS External and 228 type-11 Opaque LSAs are omitted from a virtual 229 neighbor's Database summary list. AS External LSAs 230 and type-11 Opaque LSAs are omitted from the 231 Database summary list if the area has been 232 configured as a stub area (see Section 3.6 of [OSPF]). 234 Opaque LSAs are omitted from the Database 235 summary list if the following conditions exist. 236 1) the LSA type is type 9 (the flooding scope 237 is link-local) and interface associated with the 238 neighbor is not the interface associated with 239 the Opaque LSA (as noted upon reception); 240 2) the LSA type is 10 (the flooding scope is 241 area-local) and the area associated with the 242 neighbor's interface is not the area associated 243 with the Opaque LSA (as noted upon reception). 245 Any advertisement whose age is equal to MaxAge is 246 omitted from the Database summary list. It is 247 instead added to the neighbor's link-state 248 retransmission list. A summary of the Database 249 summary list will be sent to the neighbor in 250 Database Description packets. Each Database 251 Description Packet has a DD sequence number, and is 252 explicitly acknowledged. Only one Database 253 Description Packet is allowed to be outstanding at 254 any one time. For more detail on the sending and 255 receiving of Database Description packets, see 256 Sections 10.6 and 10.8 of [OSPF]. 258 4.0 Protocol data structures 260 The Opaque option is described herein in terms of its operation on 261 various protocol data structures. These data structures are included 262 for explanatory uses only, and are not intended to constrain an imple- 263 mentation. In addition to the data structures listed below, this 264 specification references the various data structures (e.g., OSPF 265 neighbors) defined in [OSPF]. 267 In an OSPF router, the following item is added to the list of global 268 OSPF data structures described in Section 5 of [OSPF]: 270 o Opaque capability. Indicates whether the router is running the 271 Opaque option (i.e., capable of storing Opaque LSAs). Such a 272 router will continue to inter-operate with non-opaque-capable 273 OSPF routers. 275 4.1 Additions To The OSPF Neighbor Structure 277 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an 278 opaque-capable router, the following items are added to the OSPF 279 neighbor structure: 281 o Neighbor Options. This field was already defined in the OSPF 282 specification. However, in opaque-capable routers there is a new 283 option which indicates the neighbor's Opaque capability. This new 284 option is learned in the Database Exchange process through recep- 285 tion of the neighbor's Database Description packets, and deter- 286 mines whether Opaque LSAs are flooded to the neighbor. For a more 287 detailed explanation of the flooding of the Opaque LSA see sec- 288 tion 3 of this document. 290 5.0 References 292 [OSPF] Moy, J., "OSPF Version 2", RFC 2178 Cascade, July 1997. 294 [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution 295 Advertisement Option", draft-ietf-ospf-ara-01.txt, November 1997. 297 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 298 Inc., March 1994. 300 [NSSA] Coltun, R., Fuller, V., Murphy, P., "The OSPF NSSA Option", 301 draft-ietf-ospf-nssa-update-02.txt, April 1997. 303 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 304 Cascade, April 1995. 306 Appendix A: OSPF Data formats 308 This appendix describes the format of the Options Field followed by 309 the packet format of the Opaque LSA. 311 A.1 The Options Field 313 The OSPF Options field is present in OSPF Hello packets, Database 314 Description packets and all link-state advertisements. The Options 315 field enables OSPF routers to support (or not support) optional capa- 316 bilities, and to communicate their capability level to other OSPF 317 routers. Through this mechanism routers of differing capabilities can 318 be mixed within an OSPF routing domain. 320 When used in Hello packets, the Options field allows a router to 321 reject a neighbor because of a capability mismatch. Alternatively, 322 when capabilities are exchanged in Database Description packets a 323 router can choose not to forward certain link-state advertisements to 324 a neighbor because of its reduced functionality. Lastly, listing 325 capabilities in link-state advertisements allows routers to forward 326 traffic around reduced functionality routers by excluding them from 327 parts of the routing table calculation. 329 Six bits of the OSPF Options field have been assigned, although only 330 the O-bit is described completely by this memo. Each bit is described 331 briefly below. Routers should reset (i.e., clear) unrecognized bits in 332 the Options field when sending Hello packets or Database Description 333 packets and when originating link-state advertisements. Conversely, 334 routers encountering unrecognized Option bits in received Hello Pack- 335 ets, Database Description packets or link-state advertisements should 336 ignore the capability and process the packet/advertisement normally. 338 +------------------------------------+ 339 | * | O | DC | EA | N/P | MC | E | * | 340 +------------------------------------+ 342 The Options Field 344 E-bit 345 This bit describes the way AS-external-LSAs are flooded, as 346 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 348 MC-bit 349 This bit describes whether IP multicast datagrams are forwarded 350 according to the specifications in [MOSPF]. 352 N/P-bit 353 This bit describes the handling of Type-7 LSAs, as specified in 354 [NSSA]. 356 DC-bit 357 This bit describes the router's handling of demand circuits, as 358 specified in [DEMD]. 360 EA-bit 361 This bit describes the router's willingness to receive and for- 362 ward External-Attributes-LSAs, as specified in [EAL]. 364 O-bit 365 This bit describes the router's willingness to receive and for- 366 ward Opaque-LSAs as specified in this document. 368 A.2 Opaque LSA 370 Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These 371 advertisements may be used directly by OSPF or indirectly by some 372 application wishing to distribute information throughout the OSPF 373 domain. The function of the Opaque LSA option is to provide for 374 future extensibility of OSPF. 376 Opaque LSAs contain some number of octets (of application-specific 377 data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA 378 uses the link-state database distribution mechanism for flooding this 379 information throughout the topology. However, the Opaque LSA has a 380 flooding scope associated with it so that the scope of flooding may be 381 link-local (type 9), area-local (type 10) or the entire OSPF routing 382 domain (type 11). Section 3 of this document describes the flooding 383 procedures for the Opaque LSA. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | LS age | Options | 9, 10 or 11 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Opaque Type | Opaque ID | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Advertising Router | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | LS Sequence Number | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | LS checksum | Length | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | | 399 + + 400 | Opaque Information | 401 + + 402 | ... | 404 Link-State Type 406 The link-state type of the Opaque LSA identifies the LSA's range 407 of topological distribution. This range is referred to as the 408 Flooding Scope. The following explains the flooding scope of 409 each of the link-state types. 411 o A value of 9 denotes a link-local scope. Opaque LSAs with a 412 link-local scope are not flooded beyond the local (sub)network. 414 o A value of 10 denotes an area-local scope. Opaque LSAs with a 415 area-local scope are not flooded beyond the area that they are 416 originated into. 418 o A value of 11 denotes that the LSA is flooded throughout the 419 Autonomous System (e.g., has the same scope as type-5 LSAs). 420 Opaque LSAs with AS-wide scope are not flooded into stub areas. 422 Syntax Of The Opaque LSA's Link-State ID 424 The link-state ID of the Opaque LSA is divided into an Opaque 425 Type field (the first 8 bits) and an Opaque ID (the remaining 24 426 bits). Opaque type values in the range of 128-255 are reserved 427 for private and experimental use.