idnits 2.17.1 draft-ietf-ospf-opaque-00.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 == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages 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], [DEMD], [EAL]), 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 (November 1996) is 10023 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 365 looks like a reference -- Missing reference section? 'EAL' on line 381 looks like a reference -- Missing reference section? 'MOSPF' on line 369 looks like a reference -- Missing reference section? 'NSSA' on line 373 looks like a reference -- Missing reference section? 'DEMD' on line 377 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Opaque November 1996 4 Expiration Date: May 1997 FORE Systems 5 File name: draft-ietf-ospf-opaque-00.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 Interface Structure ................ 8 51 4.2 Additions To The OSPF Neighbor Structure ................. 8 53 5.0 References ............................................... 9 55 Appendix A: OSPF Data Formats ................................ 10 57 A.1 The Options Field ........................................ 10 59 A.2 Opaque LSA ............................................... 12 61 1.0 Abstract 63 This memo documents enhancements to the OSPF protocol to support a new 64 type of link-state advertisement (LSA) called the Opaque LSA. The 65 Opaque LSA option defines a general mechanism to allow for future 66 extensibility of OSPF. The information contained in Opaque LSAs may be 67 used directly by OSPF or by other protocols. Opaque LSAs contain some 68 number of octets padded to 32-bit alignment. The standard OSPF link- 69 state database flooding mechanisms are use for distribution of Opaque 70 LSAs. Opaque LSAs are flooded throughout all or some limited portion 71 of the OSPF topology. 73 2.0 Overview 75 Over the last few years the OSPF routing protocol [OSPF] has been 76 widely deployed throughout the Internet. As a result of this deploy- 77 ment and the evolution of networking technology, OSPF has been 78 extended to support many options; this evolution will obviously con- 79 tinue. 81 This memo documents enhancements to the OSPF protocol to support a new 82 type of link-state advertisement (LSA) called the Opaque LSA which 83 defines an optional generalized mechanism to allow for future extensi- 84 bility of OSPF. The information contained in Opaque LSAs may be used 85 directly by OSPF or by other protocols. For example, the OSPF LSA may 86 be used to distribute BGP AS Path information (as documented in The 87 OSPF External Attributes LSA [EAL]) which is then used by BGP route- 88 leaking mechanisms. The option may also be used to distribute IP QoS 89 information which may be used directly by an OSPF path computation. 90 The exact use of the Opaque LSA is beyond the scope of this draft. 92 The data contained in the Opaque LSA is some number of 32-bit aligned 93 octets. Like any other LSA, the Opaque LSA uses the link-state data- 94 base distribution mechanism for flooding this information throughout 95 the topology. The Flooding Scope identifies the range of the topology 96 to which this LSA may be distributed to. 98 2.1 Organization Of This Document 100 This document first defines the Opaque LSA followed by a description 101 of OSPF packet processing which includes modifications to the flooding 102 procedure and the neighbor state machine needed to support the Opaque 103 LSA. Appendix A then gives the packet formats. 105 2.2 Acknowledgments 106 The author would like to thank Dennis Ferguson, John Moy, Zhaohui 107 "Jeffrey" Zhang and the rest of the OSPF Working Group for the ideas 108 and support they have given to this project. 110 3.0 The Opaque LSA 112 Opaque LSAs are the Type 15 link-state advertisements. These adver- 113 tisements are originated by any router. The data contained in the 114 Opaque LSA consists of some number of octets aligned to a 32-bit boun- 115 dary. Like any other LSA, the Opaque LSA uses the link-state database 116 distribution mechanism for flooding this information throughout the 117 topology. The Flooding Scope field in the Opaque LSA identifies the 118 range of the topology to which this LSA may be distributed to. This 119 section documents the flooding of Opaque LSAs. 121 The following are possible values of the Flooding Scope field. 123 o A value of 0 denotes a link-local scope. Opaque LSAs with a 124 Flooding Scope of 0 are not flooded beyond the local 125 (sub)network. 127 o A value of 1 denotes an area-local scope. Opaque LSAs with a 128 flooding scope of 1 are not flooded beyond the area that they are 129 originated into. 131 o A value of 2 denotes that the LSA is flooded throughout the 132 Autonomous System. 134 Origination of Opaque LSAs are unique to the application using it. 135 The link-state ID of the Opaque LSA is divided into a type field (the 136 first 8 bits) a type-specific ID (the remaining 24 bits). The packet 137 format of the Opaque LSA is given in Appendix A. 139 The responsibility for proper handling of the Opaque LSA's Flooding 140 Scope field is placed on the sender of the LSA. The receiver must 141 always store a valid received Opaque LSA in its link-state database. 142 Flooding scope effects both the building of the Database summary list 143 during the initial synchronization of the link-state database and the 144 flooding procedure. 146 In order to make the use of the Opaque LSAs predictable, it is recom- 147 mended that all routers within the scope of use have the same Opaque 148 LSA capabilities. For example, if the Opaque LSA is to be used for 149 flooding Opaque information throughout a single area, all routers 150 within the area should support the Opaque option. 152 The following describes the modifications to these procedures that are 153 necessary to insure proper use of the Opaque LSA's Scoping Rules. 155 3.1 Flooding Opaque LSAs 157 The flooding of Opaque LSAs must follow the rules of Flooding Scope as 158 specified in this section. The flooding mechanisms must suppress the 159 flooding of Opaque LSAs as described in the following. 161 o If the Flooding Scope is link-local and the interface that the 162 LSA was received on is not the same as the target interface 163 (e.g., the interface associated with a particular neighbor), the 164 Opaque LSA must not be flooded out that interface (or to that 165 neighbor). An implementation should keep track of the IP inter- 166 face associated with each Opaque LSA having a link-local flooding 167 scope. 169 o If the Flooding Scope is area-local and the area associated 170 with Opaque LSA is not the area associated with a particular 171 interface, the Opaque LSA must not be flooded out the interface. 172 An implementation should keep track of the OSPF area associated 173 with each Opaque LSA having an area-local flooding scope. 175 When opaque-capable routers and non-opaque-capable OSPF routers are 176 mixed together in a routing domain, the Opaque LSAs are not flooded to 177 the non-opaque-capable routers. As a general design principle, 178 optional OSPF advertisements are only flooded to those routers that 179 understand them. 181 An opaque-capable router learns of its neighbor's opaque capability at 182 the beginning of the "Database Exchange Process" (see Section 10.6 of 183 [OSPF], receiving Database Description packets from a neighbor in 184 state ExStart). A neighbor is opaque-capable if and only if it sets 185 the O-bit in the Options field of its Database Description packets. 186 Then, in the next step of the Database Exchange process, Opaque LSAs 187 are included in the Database summary list sent to the neighbor (see 188 Sections 3.2 below and 10.3 of [OSPF]) if and only if the neighbor is 189 opaque-capable. 191 When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable 192 router looks at the neighbor's opaque capability. Opaque LSAs are 193 only flooded to opaque capable neighbors. To be more precise, in Sec- 194 tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state 195 retransmission lists of opaque-capable neighbors. Note however that 196 when sending Link State Update packets as multicasts, a non-opaque- 197 capable neighbor may (inadvertently) receive Opaque LSAs. The non- 198 opaque-capable router will then simply discard the LSA (see Section 13 199 of [OSPF], receiving LSAs having unknown LS types). 201 3.2 Modifications To The Neighbor State Machine 203 The state machine as it exists in section 10.3 of [OSPF] remains 204 unchanged except for the action associated with State: ExStart, Event: 205 NegotiationDone which is where the Database summary list is built. To 206 incorporate the Opaque LSA in OSPF the action is changed to the fol- 207 lowing. 209 State(s): ExStart 211 Event: NegotiationDone 213 New state: Exchange 215 Action: The router must list the contents of its entire area 216 link-state database in the neighbor Database summary 217 list. The area link-state database consists of the 218 Router LSAs, Network LSAs and Summary LSAs 219 contained in the area structure, along with Opaque and 220 AS External LSAs contained in the global structure. 221 AS External LSAs are omitted from a 222 virtual neighbor's Database summary list. AS 223 External LSAs are omitted from the Database 224 summary list if the area has been configured 225 as a stub (see Section 3.6 of [OSPF]). 227 Opaque LSAs are omitted from the Database 228 summary list if the following conditions 229 are met: 1) the Flooding Scope is link-local 230 and the interface associated with the Opaque 231 LSA (upon reception) does not equal the 232 interface associated with the neighbor; 233 2) the Flooding Scope is area-local and the 234 area associated with Opaque LSA is not the 235 area associated with the neighbor's interface. 237 Any advertisement whose age is equal to MaxAge is 238 omitted from the Database summary list. It is 239 instead added to the neighbor's link-state 240 retransmission list. A summary of the Database 241 summary list will be sent to the neighbor in 242 Database Description packets. Each Database 243 Description Packet has a DD sequence number, and is 244 explicitly acknowledged. Only one Database 245 Description Packet is allowed to be outstanding at 246 any one time. For more detail on the sending and 247 receiving of Database Description packets, see 248 Sections 10.8 and 10.6 of [OSPF]. 250 4.0 Protocol data structures 252 The Opaque option is described herein in terms of its operation on 253 various protocol data structures. These data structures are included 254 for explanatory uses only, and are not intended to constrain an OSPF 255 implementation. Besides the data structures listed below, this specif- 256 ication will also reference the various data structures (e.g., OSPF 257 interfaces and neighbors) defined in [OSPF]. 259 In an OSPF router, the following item is added to the list of global 260 OSPF data structures described in Section 5 of [OSPF]: 262 o Opaque capability. Indicates whether the router is running the 263 Opaque option (i.e., capable of storing Opaque LSAs). Such a 264 router will continue to inter-operate with non-opaque-capable 265 OSPF routers. 267 4.1 Additions To The OSPF Interface Structure 269 The OSPF interface structure is described in Section 9 of [OSPF]. In 270 an opaque-capable router, the following item is added to the OSPF 271 interface structure. Note that the Opaque capability parameter is 272 really a description of this router's view of the attached network. 273 As such, it should be configured identically on all routers attached 274 to a common network; otherwise incorrect or incomplete distribution of 275 Opaque LSAs may occur. 277 o OpaqueInterfaceOn. This configurable parameter indicates 278 whether Opaque LSAs should be flooded over the attached network. 279 The parameter can assume a value of disabled or enabled. When 280 set to disabled, Opaque LSAs will not be flooded out the inter- 281 face; when set to enabled Opaque LSAs will be flooded out the 282 interface. The default value for this parameter is enabled when 283 the router's Opaque capability is enabled. This parameter may 284 not be enabled if the router's Opaque capability is disabled. 285 The state of this parameter is reflected by setting (or reset- 286 ting) the O-bit in the option field as appropriate for all OSPF 287 packets sent out this interface. 289 4.2 Additions To The OSPF Neighbor Structure 291 The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an 292 opaque-capable router, the following items are added to the OSPF 293 neighbor structure: 295 o Neighbor Options. This field was already defined in the OSPF 296 specification. However, in opaque-capable routers there is a new 297 option which indicates the neighbor's Opaque capability. This new 298 option is learned in the Database Exchange process through recep- 299 tion of the neighbor's Database Description packets, and deter- 300 mines whether Opaque LSAs are flooded to the neighbor. For a more 301 detailed explanation of the flooding of the Opaque LSA see 3 of 302 this document. 304 5.0 References 306 [OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft, 307 Cascade, September 1996. 309 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, 310 Inc., March 1994. 312 [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, 313 RainbowBridge Communications, Stanford University, March 1994. 315 [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, 316 Cascade, April 1995. 318 [EAL] Ferguson, D., "The OSPF External Attributes LSA", work in 319 progress. 321 Appendix A: OSPF Data formats 323 This appendix describes the format of the Options Field followed by 324 the packet format of the Opaque LSA. 326 A.1 The Options Field 328 The OSPF Options field is present in OSPF Hello packets, Database 329 Description packets and all link-state advertisements. The Options 330 field enables OSPF routers to support (or not support) optional capa- 331 bilities, and to communicate their capability level to other OSPF 332 routers. Through this mechanism routers of differing capabilities can 333 be mixed within an OSPF routing domain. 335 When used in Hello packets, the Options field allows a router to 336 reject a neighbor because of a capability mismatch. Alternatively, 337 when capabilities are exchanged in Database Description packets a 338 router can choose not to forward certain link-state advertisements to 339 a neighbor because of its reduced functionality. Lastly, listing 340 capabilities in link-state advertisements allows routers to forward 341 traffic around reduced functionality routers, by excluding them from 342 parts of the routing table calculation. 344 Seven bits of the OSPF Options field have been assigned, although only 345 the O-bit is described completely by this memo. Each bit is described 346 briefly below. Routers should reset (i.e. clear) unrecognized bits in 347 the Options field when sending Hello packets or Database Description 348 packets and when originating link-state advertisements. Conversely, 349 routers encountering unrecognized Option bits in received Hello Pack- 350 ets, Database Description packets or link-state advertisements should 351 ignore the capability and process the packet/advertisement normally. 353 +------------------------------------+ 354 | * | O | DC | EA | N/P | MC | E | T | 355 +------------------------------------+ 357 The Options Field 359 T-bit 360 This bit describes the router's TOS-based routing capability, as 361 specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of [OSPF]. 363 E-bit 364 This bit describes the way AS-external-LSAs are flooded, as 365 described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. 367 MC-bit 368 This bit describes whether IP multicast datagrams are forwarded 369 according to the specifications in [MOSPF]. 371 N/P-bit 372 This bit describes the handling of Type-7 LSAs, as specified in 373 [NSSA]. 375 DC-bit 376 This bit describes the router's handling of demand circuits, as 377 specified in [DEMD]. 379 EA-bit 380 This bit describes the router's willingness to receive and for- 381 ward External-Attributes-LSAs, as specified in [EAL]. 383 O-bit 384 This bit describes the router's willingness to receive and for- 385 ward Opaque-LSAs as specified in this document. 387 A.2 Opaque LSA 389 Opaque LSAs are the Type 15 link-state advertisements. These adver- 390 tisements are originated by any router and may be used directly by 391 OSPF or indirectly by other protocols such as BGP wishing to distri- 392 bute information throughout the OSPF domain. The primary function of 393 the Opaque LSA is to provide for future extensibility to OSPF. 395 The data contained in the Opaque LSA consists of some number of octets 396 padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses 397 the link-state database distribution mechanism for flooding this 398 information throughout the topology. However, the Opaque LSA has a 399 Flooding Scope associated with it so that the scope of flooding may be 400 link-local, area-local or the entire OSPF routing domain. 402 Origination of Opaque LSAs are unique to the application using it. 403 Section 3 of this document describes the flooding procedures for the 404 Opaque LSA. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | LS age | Options | 15 | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Opaque Type | Opaque ID | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Advertising Router | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | LS Sequence Number | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | LS checksum | Length | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Flooding Scope | Reserved | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | | 422 + + 423 | Opaque Information | 424 + + 425 | ... | 427 Syntax Of The Opaque LSA's Link-State ID 429 The link-state ID of the Opaque LSA is divided into an Opaque 430 Type field (the first 8 bits) and an Opaque ID (the remaining 24 431 bits). Opaque type values in the 128-255 range are reserved for 432 private and experimental use. 434 Flooding Scope 436 The flooding Scope identifies the range of the topology to which 437 this LSA may be distributed to. The following denotes the possi- 438 ble values of the Flooding Scope field. 440 o A value of 0 denotes a link-local scope. Opaque LSAs with a 441 Flooding Scope of 0 are not flooded beyond the local 442 (sub)network. 444 o A value of 1 denotes an area-local scope. Opaque LSAs with a 445 flooding scope of 1 are not flooded beyond the area that they are 446 originated into. 448 o A value of 2 denotes that the LSA is flooded throughout the 449 Autonomous System (e.g., has the same scope as type-5 LSAs).