Extensions to OSPF for Advertising Optional Router Capabilities
obsoletes
- rfc-4970 — Extensions to OSPF for Advertising Optional Router Capabilities
Extracted elements (28)
OSPFv2 options field bits are fully allocated, so additional optional capabilities cannot be advertised there. The RI LSA mechanism using Opaque LSAs (OSPFv2) and a new LSA type (OSPFv3) was introduced to extend capability advertisement without modifying existing options fields.
Support for multiple RI LSA instances was added (vs. RFC 4970's single instance) to allow advertisement of information that doesn't fit within a single LSA instance, while preserving the convention that Instance 0 carries the primary capability TLVs.
Two separate TLVs are defined — Informational Capabilities (Type 1) and Functional Capabilities (Type 2) — to distinguish capabilities advertised purely for informational purposes (no impact on protocol operation) from those that actively dictate OSPF protocol behavior.
For existing OSPF capabilities, backwards compatibility dictates that RI LSA advertisement is used primarily for informational purposes. For future OSPF extensions, the RI LSA advertisement MAY be used as the sole mechanism for advertisement and discovery.
If a Router Information TLV is advertised in multiple RI LSA instances and the multiple-instance processing is not explicitly specified in the defining RFC, the TLV from the RI LSA with the numerically smallest Instance ID is used and subsequent instances are ignored.
The OSPFv3 RI LSA sets the U bit to indicate the LSA should be flooded even if not understood by receiving routers, ensuring capability information propagates across mixed-version deployments.
For backwards compatibility, previously advertised Router Information TLVs SHOULD continue to be advertised in the first instance (Instance 0) of the Router Information LSA.
If the Router Informational Capabilities TLV is included in the RI LSA, it MUST be the first TLV in the first instance (Instance 0) of the OSPF RI LSA and MUST accurately reflect the router's capabilities in the advertised scope.
OSPFv3 LSA function codes 8176-8183 are for experimental use and MUST NOT be mentioned by RFCs. LSAs with function codes in the vendor private use range 8184-8190 MUST include the Enterprise Code as the first 4 octets following the 20-octet LSA header.
Specifications for functional capabilities advertised in the Router Functional Capabilities TLV MUST describe protocol behavior and address backwards compatibility, since these capabilities MAY be used by other OSPF routers to dictate protocol operation.
The first RI LSA instance (Instance ID 0) SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV.
The Router Functional Capabilities TLV, if included, MUST be present in the first instance of the RI LSA and MUST reflect the advertising router's actual functional capabilities, since this information is used to dictate OSPF protocol operation.
TLV flooding-scope rules MUST be specified on a per-TLV basis in the accompanying specifications for future Router Information LSA TLVs.
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.
Six OSPF Router Informational Capability bits are assigned: bit 0 (graceful restart capable), bit 1 (graceful restart helper), bit 2 (stub router support), bit 3 (TE support), bit 4 (point-to-point over LAN), and bit 5 (experimental TE). Bits 6-31 are unassigned and require IETF Review.
The flooding scope of the RI LSA is determined by LSA type: OSPFv2 uses type 9 (link-scoped), 10 (area-scoped), or 11 (AS-scoped) Opaque LSAs; OSPFv3 uses the S1/S2 bits. If AS-wide scope is used, area-scoped LSAs must also be advertised into attached NSSA areas.
The Router Information (RI) LSA is defined for advertising optional router capabilities in both OSPFv2 and OSPFv3. In OSPFv2 it uses an Opaque LSA with type 4; in OSPFv3 it uses LSA function code 12. Multiple instances are supported, with Instance ID 0 being the primary instance.
A new 'OSPF Router Functional Capability Bits' subregistry is created within the OSPFv2 Parameters registry. Initially empty, it is available for future capabilities assigned through IETF Review.
IANA updated the 'Opaque Link-State Advertisements (LSA) Option Types' registry: OSPFv2 Opaque type 4 is assigned to the Router Information LSA. The reference is updated from RFC 4970 to RFC 7770.
The 'OSPF Router Information (RI) TLVs' registry assigns value 1 to the Router Informational Capabilities TLV and value 2 to the Router Functional Capabilities TLV. Values 10-32767 are unassigned (IETF Review); 32768-32777 for experimentation; 32778-65535 reserved.
The 'OSPF Router Informational Capability Bits' registry, created by RFC 4970 and updated here, assigns bits 0-5 to specific capabilities. All additions require IETF Review.
The 'OSPFv3 LSA Function Codes' registry assigns function code 12 to the OSPFv3 RI LSA. Codes 16-255 are assigned via IETF Review; 256-8175 reserved; 8176-8183 for experimentation; 8184-8190 vendor private use; 8191 reserved.
The RI LSA capability TLVs are considered less critical than the topology information advertised by base OSPF. Security considerations for the generic mechanism depend on future application and should be described as additional capabilities are proposed. Base OSPF security applies from RFC 2328 and RFC 5340.
RI LSA TLVs use a Type (16-bit) / Length (16-bit) / Value format identical to the TE Extensions to OSPF. TLVs are padded to 4-octet alignment; padding is not included in the Length field. Unrecognized TLV types are ignored.
The OSPFv2 RI LSA is an Opaque LSA with Opaque type field set to 4 and the Opaque ID field carrying the RI LSA Instance ID. The standard OSPFv2 LSA header fields (LS age, Options, LS type 9/10/11, Advertising Router, LS sequence number, checksum, length) precede the TLV payload.
The OSPFv3 RI LSA uses function code 12 in the LSA type field; S1/S2 bits determine flooding scope and the U bit is set to 1 to ensure flooding even when unrecognized. The Link State ID field carries the Instance ID.
The Router Functional Capabilities TLV has Type=2, a Length field that is a multiple of 4 octets (initially 4), and a variable-length value containing functional capability bits numbered left-to-right from bit 0.
The Router Informational Capabilities TLV has Type=1, a Length field that is a multiple of 4 octets (initially 4), and a variable-length value containing capability bits numbered left-to-right from the most significant bit (bit 0).