OSPF Two-Part Metric
updates
- rfc-2328 — OSPF Version 2
Extracted elements (17)
The metric is abstracted as to/from the 'network' rather than to/from the 'satellite' because the satellite operates only at layer 2 and does not participate in layer-3 packet forwarding, making the abstraction more general.
The two-part metric extension addresses scalability problems with RFC 6845 hybrid interface type on satellite radio networks. When a mobile terminal's capability changes, RFC 6845 requires all other routers to update their Router-LSAs; with two-part metrics, only the affected router updates its own LSA.
Backward compatibility is enforced by requiring all routers in an area with two-part metric networks to advertise capability bit 6. Routers that do not set this bit cause all other routers to fall back to ignoring network-to-router costs in SPF.
Network-to-Router metric advertisement in OSPFv3 using Extended Router-LSA will be described in a separate document; this RFC covers only OSPFv2 encoding.
All routers connected to the same multi-access network SHOULD have the same configuration for their corresponding interfaces with respect to the two-part metric setting.
If an area contains one or more two-part metric networks, then all routers in the area MUST support the extensions specified in RFC 8042.
The Network-to-Router Metric Sub-TLV MUST ONLY appear in Extended-Link TLVs for Link Type 2 (link to transit network) and MUST be ignored if received for other link types.
To advertise two-part metric capability, routers MUST include a Router Functional Capabilities TLV in a Router Information LSA with bit 6 ('Two-Part Metric support') set.
Upon detecting a reachable Router-LSA without a companion RI LSA that has the Two-Part Metric support bit set, all routers MUST recalculate routes without considering any network-to-router costs.
When advertising as a stub router (RFC 6987) on a two-part metric network, only the Router-to-Network metric in the stub router's Router-LSA links is set to MaxLinkMetric; the Network-to-Router metric is not affected.
A Traffic Engineering Network-to-Router Metric Sub-TLV (type 35) is defined, identical in format to the TE Metric Sub-TLV from RFC 3630 Section 2.5.5 except for the type value. It MUST only appear in Type 2 Link TLVs of TE LSAs and MUST appear at most once per Link TLV.
Multiple Network-to-Router Metric Sub-TLVs can exist in a single OSPF Extended Link TLV, one per topology (RFC 4915), each with a unique MT-ID. The sub-TLV is carried in an OSPFv2 Extended-Link Opaque LSA.
SPF calculation modification: when adding adjacent vertex W from a Network-LSA vertex V to the candidate list, the cost from V to W is taken from the Network-to-Router Metric Sub-TLV in W's Extended-Link Opaque LSA for the corresponding topology; if absent, the cost is 0.
Two new router interface parameters are defined: 'Two-part metric' (boolean, TRUE if the interface connects to a multi-access network using two-part metric) and 'Interface input cost' (the Network-to-Router link-state metric, defaulting to the Interface output cost).
Three IANA registry assignments: 'Two-Part Metric support' bit 6 added to 'OSPF Router Informational Capability Bits'; sub-TLV type 4 added to 'OSPFv2 Extended Link TLV Sub-TLVs'; sub-TLV type 35 added to 'Types for sub-TLVs of TE Link TLV (Value 2)'.
RFC 8042 does not introduce new security risks; existing security considerations in OSPFv2 and OSPFv3 apply without modification.
The OSPFv2 Network-to-Router Metric Sub-TLV has type 4, length 4, and a 32-bit value field encoding an 8-bit MT-ID, an 8-bit zero field, and a 16-bit MT Metric.