HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:05:04 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 14 Jan 1998 13:36:00 GMT ETag: "304b75-5cbf-34bcbf40" Accept-Ranges: bytes Content-Length: 23743 Connection: close Content-Type: text/plain Internet-Draft Opaque January 1998 Expiration Date: July 1998 FORE Systems File name: draft-ietf-ospf-opaque-03.txt The OSPF Opaque LSA Option Rob Coltun FORE Systems (301) 571-2521 rcoltun@fore.com Status Of This Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Coltun [Page 1] Internet-Draft Opaque January 1998 Table Of Contents 1.0 Abstract ................................................. 3 2.0 Overview ................................................. 3 2.1 Organization Of This Document ............................ 3 2.2 Acknowledgments .......................................... 3 3.0 The Opaque LSA ........................................... 4 3.1 Flooding Opaque LSAs ..................................... 5 3.2 Modifications To The Neighbor State Machine .............. 6 4.0 Protocol Data Structures ................................. 8 4.1 Additions To The OSPF Neighbor Structure ................. 8 5.0 References ............................................... 8 Appendix A: OSPF Data Formats ................................ 10 A.1 The Options Field ........................................ 10 A.2 Opaque LSA ............................................... 12 Coltun [Page 2] Internet-Draft Opaque January 1998 1.0 Abstract This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensi- bility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link- state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology. 2.0 Overview Over the last several years the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deploy- ment and the evolution of networking technology, OSPF has been extended to support many options; this evolution will obviously con- tinue. This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensi- bility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distri- bute information throughout the OSPF domain. For example, the OSPF LSA may be used by routers to distribute IP to link-layer address resolution information (see [ARA] for more information). The exact use of Opaque LSAs is beyond the scope of this draft. Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific information field. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. The link-state type field of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the Flooding Scope. 2.1 Organization Of This Document This document first defines the three types of Opaque LSAs followed by a description of OSPF packet processing. The packet processing sec- tions include modifications to the flooding procedure and to the neighbor state machine. Appendix A then gives the packet formats. 2.2 Acknowledgments Coltun [Page 3] Internet-Draft Opaque January 1998 The author would like to thank Dennis Ferguson, Acee Lindem, John Moy, Sandra Murphy, Zhaohui "Jeffrey" Zhang and the rest of the OSPF Work- ing Group for the ideas and support they have given to this project. 3.0 The Opaque LSA Opaque LSAs are types 9, 10 and 11 link-state advertisements. Each type has a unique flooding scope. Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific informa- tion field. Standard link-state database flooding mechanisms are used for distribution of Opaque LSAs. The range of topological distribu- tion (i.e., the flooding scope) of an Opaque LSA is identified by its link-state type. This section documents the flooding of Opaque LSAs. The flooding scope associated with each Opaque link-state type is defined as follows. o Link-state type 9 denotes a link-local scope. Type-9 Opaque LSAs are not flooded beyond the local (sub)network. o Link-state type 10 denotes an area-local scope. Type-10 Opaque LSAs are not flooded beyond the borders of their associated area. o Link-state type 11 denotes that the LSA is flooded throughout the Autonomous System (AS). The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS-external (type-5) LSAs. Specifically type-11 Opaque LSAs are 1) flooded throughout all transit areas, 2) not flooded into stub areas from the back- bone and 3) not originated by routers into their connected stub areas. As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub area from a neighboring router within the stub area the LSA is rejected. The link-state ID of the Opaque LSA is divided into a type field (the first 8 bits) and a type-specific ID (the remaining 24 bits). The packet format of the Opaque LSA is given in Appendix A. The responsibility for proper handling of the Opaque LSA's flooding scope is placed on both the sender and receiver of the LSA. The receiver must always store a valid received Opaque LSA in its link- state database. The receiver must not accept Opaque LSAs that violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not accepted in a stub area). The flooding scope effects both the build- ing of the Database Summary List during the initial synchronization of the link-state database and the flooding procedure. Coltun [Page 4] Internet-Draft Opaque January 1998 The following describes the modifications to these procedures that are necessary to insure conformance to the Opaque LSA's Scoping Rules. 3.1 Flooding Opaque LSAs The flooding of Opaque LSAs must follow the rules of Flooding Scope as specified in this section. Section 13 of [OSPF] describes the OSPF flooding procedure. The following describes the Opaque LSA's type- specific flooding restrictions. o If the Opaque LSA is type 9 (the flooding scope is link-local) and the interface that the LSA was received on is not the same as the target interface (e.g., the interface associated with a par- ticular target neighbor), the Opaque LSA must not be flooded out that interface (or to that neighbor). An implementation should keep track of the IP interface associated with each Opaque LSA having a link-local flooding scope. o If the Opaque LSA is type 10 (the flooding scope is area-local) and the area associated with Opaque LSA (upon reception) is not the same as the area associated with the target interface, the Opaque LSA must not be flooded out the interface. An implementa- tion should keep track of the OSPF area associated with each Opaque LSA having an area-local flooding scope. o If the Opaque LSA is type 11 (the LSA is flooded throughout the AS) and the target interface is associated with a stub area the Opaque LSA must not be flooded out the interface. A type-11 Opaque LSA that is received on an interface associated with a stub area must be discarded and not acknowledged (the neighboring router has flooded the LSA in error). When opaque-capable routers and non-opaque-capable OSPF routers are mixed together in a routing domain, the Opaque LSAs are not flooded to the non-opaque-capable routers. As a general design principle, optional OSPF advertisements are only flooded to those routers that understand them. An opaque-capable router learns of its neighbor's opaque capability at the beginning of the "Database Exchange Process" (see Section 10.6 of [OSPF], receiving Database Description packets from a neighbor in state ExStart). A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets. Then, in the next step of the Database Exchange process, Opaque LSAs are included in the Database summary list that is sent to the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) if and only if the Coltun [Page 5] Internet-Draft Opaque January 1998 neighbor is opaque capable. When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable router looks at the neighbor's opaque capability. Opaque LSAs are only flooded to opaque-capable neighbors. To be more precise, in Sec- tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state retransmission lists of opaque-capable neighbors. However, when send- ing Link State Update packets as multicasts, a non-opaque-capable neighbor may (inadvertently) receive Opaque LSAs. The non-opaque- capable router will then simply discard the LSA (see Section 13 of [OSPF], receiving LSAs having unknown LS types). 3.2 Modifications To The Neighbor State Machine The state machine as it exists in section 10.3 of [OSPF] remains unchanged except for the action associated with State: ExStart, Event: NegotiationDone which is where the Database summary list is built. To incorporate the Opaque LSA in OSPF this action is changed to the fol- lowing. State(s): ExStart Event: NegotiationDone New state: Exchange Action: The router must list the contents of its entire area link-state database in the neighbor Database summary list. The area link-state database consists of the Router LSAs, Network LSAs, Summary LSAs and types 9 and 10 Opaque LSAs contained in the area structure, along with AS External and type-11 Opaque LSAs contained in the global structure. AS External and type-11 Opaque LSAs are omitted from a virtual neighbor's Database summary list. AS External LSAs and type-11 Opaque LSAs are omitted from the Database summary list if the area has been configured as a stub area (see Section 3.6 of [OSPF]). Opaque LSAs are omitted from the Database summary list if the following conditions exist. 1) the LSA type is type 9 (the flooding scope is link-local) and interface associated with the neighbor is not the interface associated with the Opaque LSA (as noted upon reception); 2) the LSA type is 10 (the flooding scope is area-local) and the area associated with the Coltun [Page 6] Internet-Draft Opaque January 1998 neighbor's interface is not the area associated with the Opaque LSA (as noted upon reception). Any advertisement whose age is equal to MaxAge is omitted from the Database summary list. It is instead added to the neighbor's link-state retransmission list. A summary of the Database summary list will be sent to the neighbor in Database Description packets. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. Only one Database Description Packet is allowed to be outstanding at any one time. For more detail on the sending and receiving of Database Description packets, see Sections 10.6 and 10.8 of [OSPF]. Coltun [Page 7] Internet-Draft Opaque January 1998 4.0 Protocol data structures The Opaque option is described herein in terms of its operation on various protocol data structures. These data structures are included for explanatory uses only, and are not intended to constrain an imple- mentation. In addition to the data structures listed below, this specification references the various data structures (e.g., OSPF neighbors) defined in [OSPF]. In an OSPF router, the following item is added to the list of global OSPF data structures described in Section 5 of [OSPF]: o Opaque capability. Indicates whether the router is running the Opaque option (i.e., capable of storing Opaque LSAs). Such a router will continue to inter-operate with non-opaque-capable OSPF routers. 4.1 Additions To The OSPF Neighbor Structure The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an opaque-capable router, the following items are added to the OSPF neighbor structure: o Neighbor Options. This field was already defined in the OSPF specification. However, in opaque-capable routers there is a new option which indicates the neighbor's Opaque capability. This new option is learned in the Database Exchange process through recep- tion of the neighbor's Database Description packets, and deter- mines whether Opaque LSAs are flooded to the neighbor. For a more detailed explanation of the flooding of the Opaque LSA see sec- tion 3 of this document. 5.0 References [OSPF] Moy, J., "OSPF Version 2", RFC 2178 Cascade, July 1997. [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution Advertisement Option", draft-ietf-ospf-ara-01.txt, November 1997. [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. Coltun [Page 8] Internet-Draft Opaque January 1998 [NSSA] Coltun, R., Fuller, V., Murphy, P., "The OSPF NSSA Option", draft-ietf-ospf-nssa-update-02.txt, April 1997. [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995. Coltun [Page 9] Internet-Draft Opaque January 1998 Appendix A: OSPF Data formats This appendix describes the format of the Options Field followed by the packet format of the Opaque LSA. A.1 The Options Field The OSPF Options field is present in OSPF Hello packets, Database Description packets and all link-state advertisements. The Options field enables OSPF routers to support (or not support) optional capa- bilities, and to communicate their capability level to other OSPF routers. Through this mechanism routers of differing capabilities can be mixed within an OSPF routing domain. When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to forward certain link-state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link-state advertisements allows routers to forward traffic around reduced functionality routers by excluding them from parts of the routing table calculation. Six bits of the OSPF Options field have been assigned, although only the O-bit is described completely by this memo. Each bit is described briefly below. Routers should reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating link-state advertisements. Conversely, routers encountering unrecognized Option bits in received Hello Pack- ets, Database Description packets or link-state advertisements should ignore the capability and process the packet/advertisement normally. +------------------------------------+ | * | O | DC | EA | N/P | MC | E | * | +------------------------------------+ The Options Field E-bit This bit describes the way AS-external-LSAs are flooded, as described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF]. MC-bit Coltun [Page 10] Internet-Draft Opaque January 1998 This bit describes whether IP multicast datagrams are forwarded according to the specifications in [MOSPF]. N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [NSSA]. DC-bit This bit describes the router's handling of demand circuits, as specified in [DEMD]. EA-bit This bit describes the router's willingness to receive and for- ward External-Attributes-LSAs, as specified in [EAL]. O-bit This bit describes the router's willingness to receive and for- ward Opaque-LSAs as specified in this document. Coltun [Page 11] Internet-Draft Opaque January 1998 A.2 Opaque LSA Opaque LSAs are Type 9, 10 and 11 link-state advertisements. These advertisements may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The function of the Opaque LSA option is to provide for future extensibility of OSPF. Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a flooding scope associated with it so that the scope of flooding may be link-local (type 9), area-local (type 10) or the entire OSPF routing domain (type 11). Section 3 of this document describes the flooding procedures for the Opaque LSA. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 9, 10 or 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Link-State Type The link-state type of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the Flooding Scope. The following explains the flooding scope of each of the link-state types. o A value of 9 denotes a link-local scope. Opaque LSAs with a link-local scope are not flooded beyond the local (sub)network. Coltun [Page 12] Internet-Draft Opaque January 1998 o A value of 10 denotes an area-local scope. Opaque LSAs with a area-local scope are not flooded beyond the area that they are originated into. o A value of 11 denotes that the LSA is flooded throughout the Autonomous System (e.g., has the same scope as type-5 LSAs). Opaque LSAs with AS-wide scope are not flooded into stub areas. Syntax Of The Opaque LSA's Link-State ID The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 8 bits) and an Opaque ID (the remaining 24 bits). Opaque type values in the range of 128-255 are reserved for private and experimental use. Coltun [Page 13]