Internet-Draft Opaque December 1995 Expiration Date: June 1996 FORE Systems File name: draft-coltun-ospf-opaque-00.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 December 1995 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 ..................................... 4 3.2 Modifications To The Neighbor State Machine .............. 5 4.0 Protocol data structures ................................. 7 4.1 Additions To The OSPF Interface Structure ................ 7 4.2 Additions To The OSPF Neighbor Structure ................. 7 5.0 References ............................................... 8 Appendix A: OSPF Data Formats ................................ 9 A.1 The Options Field ........................................ 9 A.2 Opaque LSA ............................................... 11 A.2.1 Link-Local Opaque LSA .................................. 13 Coltun [Page 2] Internet-Draft Opaque December 1995 1.0 Abstract This memo documents enhancements to the OSPF protocol to support a new type of link-state advertisement (LSA) called the Opaque LSA. The Opaque LSA option presents a general mechanism to allow for future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or by other protocols. Opaque LSAs contain some number of octets padded to 32-bit alignment. Opaque LSAs use OSPF's link-state database distribution mechanism for flooding this informa- tion throughout all or some limited portion of the OSPF topology. 2.0 Overview Over the last few 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 documents enhancements to the OSPF protocol to support a new type of link-state advertisement (LSA) called the Opaque LSA. The Opaque LSA option presents a general mechanism to allow for future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or by other protocols. For example, the OSPF LSA may be used to distribute BGP AS Path information (as documented in The OSPF External Attributes LSA [EAL]) which is used by BGP route-leaking mechanism. The option may also be used to distribute IP QoS information which may be used directly by a OSPF path computation. The exact use of the Opaque LSA is beyond the scope of this draft. The data contained in the Opaque LSA is some number 32-bit aligned octets. Like any other LSA, the Opaque LSA uses the link-state data- base distribution mechanism for flooding this information throughout the topology. The Flooding Scope identifies the range of the topology to which this LSA may be distributed to. 2.1 Organization Of This Document This document defines the Opaque LSA followed by a description of the OSPF packet processing including modifications to the flooding pro- cedure and to the neighbor state machine. Appendix A gives the packet formats. 2.2 Acknowledgments Coltun [Page 3] Internet-Draft Opaque December 1995 The author would like to thank John Moy 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 the Type 15 link-state advertisements. These adver- tisements are originated by any router. The data contained in the Opaque LSA is some number of octets aligned to a 32-bit boundary. Like any other LSA, the Opaque LSA uses the link-state database dis- tribution mechanism for flooding this information throughout the topology. The Flooding Scope field in the Opaque LSA identifies the range of the topology to which this LSA may be distributed to. This section documents the flooding of Opaque LSAs. The following are possible values of the Flooding Scope field. o A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. o A value of 1 denotes an area-local scope. Opaque LSAs with a flooding scope of 1 are not flooded beyond the area that they are originated into. o A value of 2 denotes that the LSA is flooded throughout (but not beyond) the Autonomous System. That is, the information con- tained within these LSAs will not be distributed to any protocols beyond the confinements of the OSPF system. o A value of 3 or greater denotes distribution throughout as well as beyond the Autonomous System. Origination of Opaque LSAs are unique to the application using it. The link-state ID of the Opaque LSA is divided into a type field (the first 8 bits) 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 field is placed on both on the sender and receiver of the LSA. The receiver must always store a valid received Opaque LSA in its link-state database. Flooding scope effects both the building of the Database summary list during the initial synchronization of the link- state database and the flooding procedure. The following describes the modifications to these procedures necessary for insuring proper use of the Opaque LSA's Scoping Rules. Coltun [Page 4] Internet-Draft Opaque December 1995 In order to make the use of the Opaque LSAs predictable, it is recom- mended that all routers within the scope of use have the same Opaque LSA capabilities. For example, if the Opaque LSA is to be used for flooding Opaque information throughout a single area, all routers within the area should support the Opaque option. 3.1 Flooding Opaque LSAs The flooding of Opaque LSAs must follow the rules of Flooding Scope as specified in this section. The flooding mechanisms must suppress the flooding of Opaque LSAs as follows. o If the Flooding Scope is link-local and the interface address and mask in the Opaque advertisement does not equal the address and mask found in the neighbor's interface, the Opaque LSA must not be flooded out to or received by the interface. The link- local Opaque LSA is used to distribute information on a multi- access network. A side-effect of limiting the flooding of the information to networks having the same network number is that link-local Opaque LSAs are not useful on point-to-point links. o If the Flooding Scope is area-local and the area associated with Opaque LSA is not the area associated with a particular interface, the Opaque LSA must not be flooded out the interface. This means that the link-state database must keep track of the area an Opaque LSA is associated with. 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. A 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 sent to the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) if and only if the 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 Coltun [Page 5] Internet-Draft Opaque December 1995 Section 13.3 of [OSPF], Opaque LSAs are only placed on the link-state retransmission lists of opaque-capable neighbors. Note however that when sending 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 the 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 and Summary LSAs contained in the area structure, along with Opaque and AS External LSAs contained in the global structure. AS External LSAs are omitted from a virtual neighbor's Database summary list. AS External LSAs are omitted from the Database summary list if the area has been configured as a stub (see Section 3.6 of [OSPF]). Opaque LSAs are omitted from the from the Database summary list if the following conditions are met: 1) the Flooding Scope is link-local and the interface address and mask in the Opaque LSA does not equal the interface address and mask found in the neighbor's interface; 2) the Flooding Scope is area-local and the area associated with Opaque LSA is not the area associated with the neighbor's interface. 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 Coltun [Page 6] Internet-Draft Opaque December 1995 Database Description packets. Each Database Description Packet has a DD sequence number, and is explicitly acknowledged. Only one Database Description Packet is allowed outstanding at any one time. For more detail on the sending and receiving of Database Description packets, see Sections 10.8 and 10.6 of [OSPF]. Coltun [Page 7] Internet-Draft Opaque December 1995 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 OSPF implementation. Besides the data structures listed below, this specif- ication will also reference the various data structures (e.g., OSPF interfaces and 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 interoperate with non-opaque-capable OSPF routers. 4.1 Additions To The OSPF Interface Structure The OSPF interface structure is described in Section 9 of [OSPF]. In an opaque-capable router, the following item is added to the OSPF interface structure. Note that the Opaque capability parameter is really a description of this router's view of the attached network. As such, it should be configured identically on all routers attached to a common network; otherwise incorrect distribution of Opaque LSAs may occur. o OpaqueInterfaceOn. This configurable parameter indicates whether Opaque LSAs should be flooded over the attached network. The parameter can assume a value disabled or enabled. When set to disabled, Opaque LSAs will not be flooded out the interface; when set to enabled Opaque LSAs will be flooded out the inter- face. The default value for this parameter is enabled when the router's Opaque capability is enabled. This parameter may not be enabled if the router's Opaque capability is disabled. The state of this parameter is reflected by setting (or resetting) the 0- bit in the option field as appropriate for all OSPF packets sent out this interface. 4.2 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 Coltun [Page 8] Internet-Draft Opaque December 1995 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. See the items concerning flooding in Section 3 of this document for a more detailed explanation. 5.0 References [OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft, Cascade, November 1995. [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., March 1994. [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, RainbowBridge Communications, Stanford University, March 1994. [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, Cascade, April 1995. [EAL] Ferguson, D., "The OSPF External Attributes LSA", work in progress. Coltun [Page 9] Internet-Draft Opaque December 1995 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. Seven 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 | T | +------------------------------------+ The Options Field T-bit This bit describes the router's TOS-based routing capability, as specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of [OSPF]. Coltun [Page 10] Internet-Draft Opaque December 1995 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 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 December 1995 A.2 Opaque LSA Opaque LSAs are the Type 15 link-state advertisements. These adver- tisements are originated by any router and may be used directly by OSPF or indirectly by other protocols such as BGP wishing to distri- bute information throughout the OSPF domain. The primary function of the Opaque LSA is to provide for future extensibility to OSPF. The data contained in the Opaque LSA is some number of octets padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this informa- tion throughout the topology. However, the Opaque LSA has a Flooding Scope associated with it so that the scope of flooding may be link- local, area-local, the OSPF routing domain or beyond. Origination of Opaque LSAs are unique to the application using it. 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 | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | 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). Coltun [Page 12] Internet-Draft Opaque December 1995 Flooding Scope Flooding Scope identifies the range of the topology to which this LSA may be distributed to. The following denotes the possible values of the Flooding Scope field. o A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. The local network is identified by the interface's network number and network mask length. See Section A.2.1 below for a description of the Link-Local Opaque LSA. o A value of 1 denotes an area-local scope. Opaque LSAs with a flooding scope of 1 are not flooded beyond the area that they are originated into. o A value of 2 denotes that the LSA is flooded throughout (but not beyond) the Autonomous System. That is, the information con- tained within these LSAs will not be distributed to any protocols beyond the range of the OSPF system. o A value of 3 or greater denotes distribution throughout as well as beyond the Autonomous System. Network Mask Length The Network Mask Length field is an integer representing the length in bits of the address' mask. This field may be used when the first 32 bits of the Opaque Information is a network address (the interpretation of this field is dependent on the Opaque Type). When unused the Network Mask Length should be set to 0. Coltun [Page 13] Internet-Draft Opaque December 1995 A.2.1 Link-Local Opaque LSA Link-Local Opaque LSAs the Type 15 link-state advertisements. These advertisements are originated by any router and may be used directly by OSPF; they are a useful tool for providing for future extensibility to OSPFv6. The contents of the Opaque LSA is some number of octets 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, area-local, the OSPF routing domain or beyond. This section provides the packet format for Link-Local Opaque LSAs which must include the IP address and mask of the IP interface to insure that the intended Flooding Scope is realized. Origination of Opaque LSAs are unique to the application using it. 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 | 15 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opaque Type | Opaque ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flooding Scope = 0 | Network Mask Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Interface Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Opaque Information | + + | ... | Syntax Of The Opaque LSA's Link-State ID Coltun [Page 14] Internet-Draft Opaque December 1995 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). Flooding Scope Flooding Scope identifies the range of the topology to which this LSA may be distributed to. A value of 0 denotes a link-local scope. Opaque LSAs with a Flooding Scope of 0 are not flooded beyond the local (sub)network. Network Mask Length The Network Mask Length field is an integer representing the length in bits of the IP interface network mask. The length is used along with the IP interface address to insure that the intended Flooding Scope is realized. IP Interface Address The IP interface address of the (sub)network to which the link- local flooding of this Opaque LSA is limited to. The IP Inter- face Address is used along with the Network Mask Length field to insure that the intended Flooding Scope is realized. Coltun [Page 15]