OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
Extracted elements (18)
Broadcast networks with non-uniform link costs (e.g., radio networks with varying signal strength) cannot accurately advertise per-neighbor costs using standard OSPF broadcast mode, which only allows a single cost per interface. P2MP mode solves this but requires O(N^2) adjacencies. The hybrid mode combines broadcast efficiency with P2MP's per-neighbor cost flexibility.
Using the hybrid-broadcast-and-P2MP interface type results in O(N^2) links in router-LSAs to represent an N-router network instead of O(N) as with broadcast mode, increasing memory usage and negatively impacting route calculation performance across the area. Network designers must weigh this cost against the benefit of per-neighbor cost accuracy.
All routers on the network must support the hybrid-broadcast-and-P2MP interface type for successful operation; otherwise the interface should be configured as a standard broadcast interface. Mixed configurations cause adjacencies to form but result in no traffic traversing certain router pairs, without causing loops or black-holing.
A non-DR router that does not have a full adjacency to the DR MUST NOT add any Type 1 links to its router-LSA for the hybrid interface.
A non-DR router with a full adjacency to the DR, where both agree on the DR role, MUST add a Type 1 link for each neighbor in state 2-Way or higher to which the DR's router-LSA includes a link.
An implementation SHOULD log a message if a network-LSA is received for a locally configured hybrid interface, to detect and flag possible misconfigured neighbors using broadcast mode instead of hybrid mode.
During graceful restart, if a router is the DR on the hybrid interface, the pre-restart network-LSA MUST NOT be used to determine the previous set of adjacencies. If in state DROther, an adjacency to a non-DR or non-BDR neighbor is considered reestablished when the neighbor reaches state 2-Way.
In OSPFv2, routers MUST add a Type 3 link for their own IP address and MUST also add a Type 3 link with Link ID set to the IP subnet address, Link Data set to the IP subnet mask, and cost equal to the configured output cost of the interface.
In OSPFv3, routers MUST add globally scoped IPv6 addresses and all globally scoped IPv6 prefixes on the interface to the intra-area-prefix-LSA, with Metric set to the configured output cost. The DR MUST NOT generate an intra-area-prefix-LSA for the transit network for this interface.
Neighbor discovery and maintenance on hybrid-broadcast-and-P2MP interfaces MUST use broadcast procedures as specified in RFC 2328 and RFC 5340, including sending and receiving Hellos per broadcast interface rules.
Next-hops to destinations directly connected via the hybrid interface are calculated using point-to-multipoint procedures from Section 16.1.1 of RFC 2328.
Routers elect a DR and BDR for hybrid-broadcast-and-P2MP interfaces and use them for database synchronization using broadcast interface procedures from RFC 2328 and RFC 5340.
The cost for a Type 1 link in the router-LSA corresponding to a neighbor SHOULD be set to the value of the Neighbor Output Cost field defined in Section 4.2.
The DR MUST NOT generate a network-LSA for a hybrid-broadcast-and-P2MP interface, since the interface is described in router-LSAs as a collection of point-to-point links.
A new hybrid-broadcast-and-P2MP interface type is defined for OSPF. Neighbor discovery, maintenance, and database synchronization follow broadcast procedures, but the network is represented as a collection of point-to-point links in router-LSAs as in P2MP mode.
A new 'Neighbor Output Cost' field is added to the neighbor data structure, representing the cost of sending a data packet to a specific neighbor in the link state metric. Its default value is the Interface output cost, and it may be overridden by static per-neighbor configuration or dynamic discovery mechanisms.
The 'Router Priority' interface parameter from OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340) applies to the hybrid-broadcast-and-P2MP interface. The 'LinkLSASuppression' parameter also applies, with a default value of 'disabled' that may be enabled via configuration.
This document raises no new security issues for OSPF. Security considerations for the base OSPF protocol are covered in RFC 2328, RFC 5340, and RFC 6506.