Cisco Systems

510 McCarthy Blvd. Milpitas 95035 CA USA mdubrovs@cisco.com

Cisco Systems

10 West Tasman Drive San Jose 95134 CA USA rashi@cisco.com

Huawei Technologies

2330 Central Expressway Santa Clara 95050 CA USA dean.cheng@huawei.com

This document specifies a generic mechanism that facilitates the deployment of non-backward-compatible changes in OSPF protocol. This mechanism allows the OSPF routers to advertise the capability of non-backward-compatible functionality and to make the functionality operational only when supported by all participating routers. Depending on the functionality scope, capability advertisements must be propagated across a link, area or autonomous system (AS). For link and area scope functionality, Router Information Link State Advertisement (LSA) is utilized to propagate the capability information. For the cases when compatibility must be maintained across the whole OSPF autonomous system, new Area Information (AI) LSA is introduced. The AI LSA is a TLV-based analog of Indication-LSA that is used for demand circuit functionality and described in RFC1793. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The evolution of OSPF protocol brought up changes that are not backward-compatible. Some of those changes (for example RFC1583Compatibility flag) can cause a routing loop in mixed environments. It therefore requires careful deployment planning, which is difficult to achieve in complex multivendor topologies. Most importantly, the lack of standard extendable mechanism that facilitates the deployment of non-backward-compatible changes obstructs the development of new protocol extensions. As a solution for the above described problems, this document proposes an extendable mechanism, which guarantees that the non-backward-compatible functionality is turned on only when supported by all participating routers. The proposed mechanism is not new; the existing demand circuit functionality uses the same approach. This document simply makes the solution generic.

Each participating router advertises the capability of functionality that it supports in the Router Information LSA as described in RFC 4970 . Routers only turn on a new functionality when it is supported by every router within the functionality scope. The routers revert back to their original behavior as soon as one incompatible device is detected. The scope of functionality could be link, area or AS wide. For link and area wide, the router accordingly originates a link or area scope RI LSA. For AS functionality, an area scope RI LSA is used. To propagate compatibility information across area borders, a new LSA type Area Information is introduced.

The Area Border Router inserts a particular capability TLV into an Area Information (AI) LSA to signal that at least one router in the attached areas does not support the functionality. Therefore, the presence of a particular TLV in AI LSA signals the opposite case to the presence of the same TLV in RI LSA. The AI LSA origination algorithm is very similar to the algorithm of Indication-LSA origination and outlined below in . The AI LSA format is very similar to RI LSA . In OSPFv2, the AI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the AI LSA will be implemented with a new LSA type function code. In both protocols, the AI LSA will have an area flooding scope. The exact format of AI LSA is outlined in the sections 3.1 and 3.2.

OSPFv2 routers will advertise an area-scoped Opaque-LSA . The OSPFv2 Area Information LSA has a Link-State type of 10 indicating that the flooding scope is area-local, an Opaque type of TBD and Opaque ID of 0.

The format of the TLVs within the body of an AI LSA is defined in .

The OSPFv3 Area Information LSA has a function code of TBD while the S1/S2 bits are set to 1/0, indicating the area flooding scope for the LSA. The U bit is set indicating that the OSPFv3 AI LSA should be flooded even if it is not understood. The Link State ID (LSID) value for this LSA is 0. This is unambiguous since an OSPFv3 router will only advertise a single AI LSA per flooding scope.

The format of the TLVs within the body of an AI LSA is defined in .

The format of the TLVs within the body of an AI LSA is exactly the same as the corresponding RI LSA TLV format, which in turn is the same as the format used by the Traffic Engineering Extensions to OSPF [TE]. The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets. The format of each TLV is:

The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of 0). The TLV is padded to a 4-octet alignment; padding is not included in the length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-byte value would have the length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored. When new Area Information LSA TLV is defined, the specification MUST explicitly state whether the TLV is applicable to OSPFv2 only, OSPFv3 only, or both OSPFv2 and OSPFv3.

Through the origination of AI LSAs, information about the existence of incapable routers propagates from non-backbone areas, to the backbone area and from there to all other areas. The following two cases summarize the requirements for an area border router to originate AI LSAs: 1. Suppose an area border router (Router X) is connected to a non-backbone OSPF area (Area A). Furthermore, assume that Area A has an incapable router i.e. a router LSA without corresponding RI LSA TLV. Then Router X should originate the AI LSAs into all other directly connected areas, including the backbone area, in accordance with the guidelines of . 2. Suppose an area border router (Router X) is connected to the backbone OSPF area (Area 0.0.0.0). Furthermore, assume that the backbone has an indication of an existing incapable device via either a) the existence of a router LSA without corresponding RI LSA TLV or b) AI LSAs that have been originated by routers other than Router X. Then Router X should originate AI LSAs into all other directly connected non-backbone areas, keeping the guidelines of in mind.

The following guidelines should be observed by an area border router (Router X) when originating AI LSAs in order to limit their number. First, AI LSAs with corresponding TLV are not originated into an Area A when A has incapable routers; i.e. router LSAs without corresponding RI LSA TLV. Secondly, if another area border router has originated an AI LSA with corresponding TLV into Area A, and that area border router has a higher OSPF Router ID than Router X (same tie-breaker as for forwarding the address origination; see Section 12.4.4.1 of ), then Router X should not originate an AI LSA with corresponding TLV into Area A.

For negotiating link scope capability before adjacency is fully formed, link local signaling should be used instead of RI LSA. An example of such a functionality would be a modification to OSPF adjacency formation FSM.

The mechanism is backward compatible with the existing OSPF specification. Setting the U bit in OSPFv3 AI LSA allows LSA propagation even if some routers in the area can not decode the LSA content. The Opaque LSA specification also guarantees the propagation of OSPFv2 AI LSA, even if the content is not understood by some of the transit routers.

The following IANA assignments are to be made from existing registries: The OSPFv2 opaque LSA option type TBD will need to be reserved for the OSPFv2 AI opaque LSA via IETF Consensus. OSPFv3 LSA Function Codes TBD will need to be reserved for the OSPFv3 Area Information (AI) LSA via Standards Action. Both Standards Action and IETF Consensus registration procedures are described in the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis].

This document describes a generic mechanism for deployment of non-backward-compatible changes and it introduces Area-Information LSA for AS scope compatibility. The security considerations for those entities are as critical as the topology information currently advertised by the base OSPF protocol. Security considerations for the base OSPF protocol are covered in [OSPF] and [OSPFV3].

The author would like to acknowledge the helpful comments of Cisco OSPF Development team. This memo is a product of the OSPF Working Group.

This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements. This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility 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. This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. [STANDARDS-TRACK] Ascend Communications, Inc.

1 Robbins Road Westford MA 01886 978-952-1367 978-392-2075 jmoy@casc.com

Routing open shortest-path first protocol routing OSPF This memo documents version 2 of the OSPF protocol. OSPF is a link-state routing protocol. It is designed to be run internal to a single Autonomous System. Each OSPF router maintains an identical database describing the Autonomous System's topology. From this database, a routing table is calculated by constructing a shortest- path tree. OSPF recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. OSPF provides support for equal-cost multipath. An area routing capability is provided, enabling an additional level of routing protection and a reduction in routing protocol traffic. In addition, all OSPF routing protocol exchanges are authenticated. The differences between this memo and RFC 2178 are explained in Appendix G. All differences are backward-compatible in nature. Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate. Please send comments to ospf@gated.cornell.edu. It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. A new Router Information (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a new LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). [STANDARDS-TRACK] This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well-defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track. Cascade Communications Corp.

5 Carlisle Road Westford MA 01886 US +1 508 692 2600 x394 +1 508 692 9214 jmoy@casc.com

This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines. The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic. Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open. While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio. The enhancements defined in this memo are backward-compatible with the OSPF specification defined in, and with the OSPF extensions defined in(OSPF NSSA areas),(MOSPF) and(OSPF Point-to-MultiPoint Interface). This memo provides functionality similar to that specified for RIP in, with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, because OSPF employs link-state routing technology as opposed to RIP's Distance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different. Please send comments to ospf@gated.cornell.edu.