Extensions to OSPF for Advertising Optional Router Capabilities
obsoleted by
- rfc-7770 — Extensions to OSPF for Advertising Optional Router Capabilities
Extracted elements (20)
OSPFv2 options field bits are fully allocated, so new optional capabilities cannot be advertised there. This document introduces the RI opaque LSA as the mechanism for advertising new capabilities; for existing capabilities it is informational only, but future features MAY use it as the sole advertisement mechanism.
The RI LSA is intentionally limited to TLVs with a single value or very few values and is not meant to be a generic container. The goal is to keep the RI LSA small enough to always fit in a single LSA and to make change-detection between LSA instances simple, requiring engineering judgment on whether new TLVs belong here or in an application-specific LSA.
For existing OSPF capabilities, the RI LSA advertisement is used primarily for informational purposes due to backward-compatibility constraints. Only future OSPF features may use the RI LSA as the sole mechanism for advertisement and discovery.
For OSPFv2, the RI LSA MAY be flooded as type 9 (link-scoped), type 10 (area-scoped), or type 11 (AS-scoped) opaque LSA. The choice of flooding scope is a matter of local policy; the originating router MAY advertise multiple RI LSAs as long as their flooding scopes differ.
If a new OSPFv3 LSA Function Code is documented, the documentation MUST include the valid combinations of the U, S2, and S1 bits for the LSA, and SHOULD describe how the Link State ID is to be assigned.
If AS-wide flooding scope is chosen, the originating router should also advertise area-scoped RI LSA(s) into any attached NSSA areas. TLV flooding scope rules MUST be specified on a per-TLV basis in accompanying specifications for new RI LSA TLVs.
If the Router Informational Capabilities TLV is included in an RI LSA, it MUST be the first TLV in the LSA and MUST accurately reflect the OSPF router's capabilities in the advertised scope.
OSPFv3 LSA function codes in the range 8176-8181 are for experimental use and MUST NOT be mentioned by RFCs. LSAs with function codes in the Vendor Private Use range 8184-8191 MUST include the Vendor Enterprise Code as the first 4 octets following the 20-octet LSA header.
The RI LSA will be originated initially when an OSPF router instance is created and whenever one of the advertised capabilities is configured or changed.
When a new Router 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.
Six informational capability bits are assigned: bit 0 (OSPF graceful restart capable), bit 1 (OSPF graceful restart helper), bit 2 (OSPF Stub Router support), bit 3 (OSPF Traffic Engineering support), bit 4 (OSPF point-to-point over LAN), bit 5 (OSPF Experimental TE). Bits 6-31 are unassigned and require Standards Action.
The OSPF Router Information (RI) LSA is a new LSA type for advertising optional router capabilities. In OSPFv2 it uses Opaque LSA type 4 with Opaque ID 0; in OSPFv3 it uses LSA function code 12. It can be advertised at link, area, or AS flooding scope.
The OSPFv3 RI LSA uses function code 12; the U bit is set to indicate the LSA should be flooded even if not understood. The S1/S2 bits determine flooding scope, and the Link State ID is always 0 since only one RI LSA per flooding scope is advertised.
The Router Informational Capabilities TLV (Type=1) is the first defined TLV in the RI LSA body. Its Value field is a variable-length sequence of capability bits rounded to a multiple of 4 octets; initially 4 octets (32 bits) of capability bits are defined, numbered left-to-right from bit 0.
A new IANA registry for OSPF RI TLVs is created. Value 1 is assigned to the Router Informational Capabilities TLV. Values 2-32767 are unassigned (Standards Action); 32768-32777 for experimentation (not IANA-registered); 32778-65535 reserved pending a Standards Track RFC.
A new IANA registry for OSPFv3 LSA Function Codes is created. Function code 12 is assigned to the OSPFv3 RI LSA. Codes 0 are reserved; 1-9 already assigned; 10-11 and 13-255 unassigned (Standards Action); 256-8175 reserved pending a Standards Track RFC; 8176-8183 for experimentation (not IANA-registered); 8184-8191 for Vendor Private Use.
A new IANA sub-registry for OSPF Router Informational Capability Bits is created as a sub-registry of the OSPF RI TLV registry. All additions require Standards Action. Initial assignments are bits 0-5 as defined in Section 2.4.
The Router Informational Capabilities TLV is less security-critical than topology information advertised by base OSPF. Security considerations for the generic RI LSA mechanism depend on future applications and should be addressed in documents defining additional capabilities. Base OSPF security is covered by RFC 2328 and RFC 2740.
Each TLV in the RI LSA body has a 16-bit Type field, a 16-bit Length field (value portion in octets, excluding padding), and a variable-length Value field. TLVs are padded to 4-octet alignment; unrecognized types are ignored.
The OSPFv2 RI Opaque LSA header uses LS type 9, 10, or 11 (link/area/AS scope), Opaque type field set to 4, and Opaque ID set to 0. The LSA body carries TLVs in the same format as Traffic Engineering Extensions to OSPF (RFC 3630).