RFC 7038

RFC 7038 🦋 Use of OSPF-MDR in Single-Hop Broadcast Networks

Okay bestie, first the paperwork 📋✨ (it's giving official):

• Stream: Internet Engineering Task Force (IETF)
• Request for Comments: 7038
• Title: Use of OSPF-MDR in Single-Hop Broadcast Networks
• Author: R. Ogier, SRI International
• Date: October 2013
• Category: Experimental 🧪
• Updates: 5614 (so this one tweaks RFC 5614 🌸)
• ISSN: 2070-1721

Abstract 💜

Okay so RFC 5614 (OSPF-MDR) is the glow-up that lets OSPF work in mobile ad hoc networks (MANETs). It does this by defining how OSPF runs on a brand-new OSPF interface type called MANET 💅. This doc is about using OSPF-MDR (MANET Designated Router) on a single-hop broadcast network, which is a special kind of MANET where every router is a one-hop neighbor of every other router ✨. Unlike a regular OSPF broadcast interface, this one can give each neighbor its own cost 🫶. It also includes config recommendations and simplified mechanisms you can use on single-hop broadcast networks 🌸.

Status of This Memo 🎀

This document is not an Internet Standards Track specification 🙈. It's published so people can examine it, try out experimental implementations, and evaluate it.

This document defines an Experimental Protocol for the Internet community. It's a product of the IETF and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 📖.

For the current status, any errata, and how to give feedback, check out http://www.rfc-editor.org/info/rfc7038 🔗.

Copyright Notice 🌈

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please read these documents carefully, because they explain your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️.

---

1. Introduction ✨

OSPF-MDR [RFC5614] is an extension of OSPF [RFC2328, RFC5340] that supports mobile ad hoc networks (MANETs) by defining its operation on the new OSPF interface of type MANET 🦋. It takes the Designated Router (DR) and levels it up into a connected dominating set (CDS), which is a typically small subset of routers called MANET Designated Routers (MDRs). The Backup Designated Router (BDR) gets the same treatment and becomes a subset of routers called Backup MDRs (BMDRs). MDRs give MANETs scalability in the same way DRs do for broadcast networks 💖:

• MDRs have the main job of flooding the Link State Advertisements (LSAs) 📣. Backup MDRs step in with backup flooding when MDRs temporarily fail 🛟.
• MDRs cut the number of adjacencies way down, because adjacencies only form between MDR/BMDR routers and their neighbors 💅.

On top of that, OSPF-MDR has these features 👑:

• MDRs and BMDRs are elected using information from modified Hello packets received from neighbors 🗳️.
• If adjacency reduction is used (the default), adjacencies form between MDRs so they make a connected subgraph. There's an option, AdjConnectivity = 2, that allows extra adjacencies between MDRs/BMDRs to produce a biconnected subgraph 🧠.
• Each non-MDR router becomes adjacent with an MDR called its Parent, and optionally (if AdjConnectivity = 2) becomes adjacent with another MDR or BMDR called its Backup Parent 👯.
• Each router advertises connections to its neighbor routers as point-to-point links in its router-LSA. Network-LSAs are not used 🙅.
• Along with full-topology LSAs, partial-topology LSAs may be used to shrink router-LSAs. They're formatted as standard LSAs but only advertise links to a subset of neighbors 🪄.
• Optionally, differential Hellos can be used, which cut down overhead by only reporting changes in neighbor states 📉.

This document describes OSPF-MDR on a single-hop broadcast network, which is a special case of a MANET where each router is a (one-hop) neighbor of each other router 🌸. You'll need to understand [RFC5614] first, since that's assumed. Unlike an OSPF broadcast interface, this interface can have a different cost associated with each neighbor 💸. An example use case is when the underlying radio system does layer-2 routing but has a different number of (layer-2) hops to (layer-3) neighbors 📡.

So why use this interface type for single-hop broadcast networks instead of a broadcast interface type? It lets you represent the underlying network in a point-to-multipoint way, so each router can advertise different costs to different neighbors in its router-LSA 🦋. In that sense, this document shows how the OSPF-MDR interface type can be configured (and simplified, if you want) to hit the same goals as the OSPF Hybrid Broadcast and Point-to-Multipoint interface type [RFC6845] 🎯.

Section 2 covers how OSPF-MDR operates on a single-hop broadcast network with recommended parameter settings 📝. Section 3 covers an alternative procedure that may be used to decide which neighbors on a single-hop broadcast network to advertise in the router-LSA 🔀. Section 4 covers a simplified version of the MDR selection algorithm for single-hop networks 🧚.

The alternative procedure of Section 3 and the simplified algorithm of Section 4 are optional and MUST NOT be used if it is possible for two routers in the network to be more than one hop from each other. 🚫

1.1. Terminology 📚

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 [RFC2119] 🤓.

2. Operation in a Single-Hop Broadcast Network 🌊

When OSPF-MDR is used in a single-hop broadcast network, the following parameter settings and options (defined in [RFC5614]) should be used 💅:

• AdjConnectivity SHOULD be equal to 2 (biconnected). This gives the smoothest transition when one router replaces another as MDR, since the set of adjacencies forms a biconnected network that stays connected during the transition ✨.
• AdjConnectivity MAY be equal to 1 (uniconnected). That gives a slightly less smooth transition, since adjacencies must be formed between the new MDR and all of its neighbors 😬.
• AdjConnectivity SHOULD NOT be equal to 0 (full topology), since that requires adjacencies to be formed between all pairs of routers, which adds unnecessary message overhead 🙅‍♀️.
• An adjacency SHOULD be eliminated if neither the router nor the neighbor is an MDR or BMDR (see Section 7.3 of [RFC5614]) 🗑️.
• LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are required. (The value 5 is defined in Section 3 of this document.) 🔒
• LSAFullness MAY be equal to 1 (min-cost LSAs) if full-topology LSAs are not required. This option reduces the number of advertised links while still providing shortest paths 🛣️.

If AdjConnectivity equals 1 or 2 and full-topology LSAs are used, OSPF-MDR running on a single-hop broadcast network has these properties 👑:

• A single MDR is selected, and it becomes adjacent with every other router, just like in an OSPF broadcast network 🫂.
• Two BMDRs are selected. That happens because the MDR selection algorithm makes sure the MDR/BMDR backbone is biconnected. If AdjConnectivity = 2, every non-MDR/BMDR router becomes adjacent with one of the BMDRs in addition to the MDR 🥰.
• When all adjacencies are fully adjacent, the router-LSA for each router includes point-to-point (type 1) links to all bidirectional neighbors (in state 2-Way or greater) 🎀.

3. Originating Router-LSAs 🪞

A router running OSPF-MDR with LSAFullness = 4 includes in its router-LSA point-to-point (type 1) links for all fully adjacent neighbors, and for all bidirectional neighbors that are routable. A neighbor is routable if the SPF calculation has produced a route to the neighbor and a flexible quality condition is satisfied 🔍.

This section describes an alternative procedure that MAY be used instead of the procedure described in Section 6 of [RFC5614], to decide which neighbors on a single-hop broadcast network to advertise in the router-LSA 🦋. The alternative procedure corresponds to LSAFullness = 5, and it's interoperable with the other choices for LSAFullness 🤝. The big win is that it skips the need to check whether a neighbor is routable, so it also avoids having to update the set of routable neighbors 🙌.

If LSAFullness = 5, then the Selected Advertised Neighbor Set (SANS) is the same as specified for LSAFullness = 4, and the following steps are performed instead of the first paragraph of Section 9.4 in [RFC5614] 💫.

(1) The MDR includes in its router-LSA a point-to-point (type 1) link for each fully adjacent neighbor. (Note that the MDR becomes adjacent with all of its neighbors.) 👑

(2) Each non-MDR router includes in its router-LSA a point-to-point link for each fully adjacent neighbor, and, if the router is fully adjacent with the MDR, for each bidirectional neighbor j such that the MDR's router-LSA includes a link to j. 🫶

To give the rationale for the above procedure, let i and j be two non-MDR routers. The SPF calculation (Section 16.1 of [RFC2328]) lets router i use router j as a next hop only if router j advertises a link back to router i. So routers i and j both have to advertise a link to each other in their router-LSAs before either one can use the other as a next hop 🔁. That means the procedure above for non-MDR routers (Step 2) implies there must exist a path of fully adjacent links between i and j (via the MDR) in both directions before this can happen 🧵. The procedure for non-MDR routers is similar to the one described in Section 4.6 of [RFC6845] for non-DR routers 🌸.

(part 2 is coming, stay tuned 🧚💕)

4. MDR Selection Algorithm ✨

okay bestie, so the MDR selection algorithm from [RFC5614] gets a glow-up for single-hop networks 💅. The result is kinda like the OSPF DR election 🦋, but not exactly, because two Backup MDRs get picked. main character energy, right? The simplified version is still interoperable with the full MDR selection algorithm, so no drama 🫶

Quick notes before we start: lexicographic order is used when comparing (RtrPri, MDR Level, RID) tuples 💜. Each router also forms adjacencies with its Parents and dependent neighbors 🌸. In here, "neighbor" means a bidirectional neighbor, aka state 2-Way or greater ✨

Phase 1: Creating the neighbor connectivity matrix is not required. ☕

Phase 2: MDR Selection 👑

(2.1) The set of Dependent Neighbors is initialized to be empty.

(2.2) If the router has a larger value of (RtrPri, MDR Level, RID) than all of its (bidirectional) neighbors, the router selects itself as an MDR; selects its BMDR neighbors as Dependent Neighbors if AdjConnectivity = 2; then proceeds to Phase 4. 🔥

(2.3) Otherwise, if the router's MDR Level is currently MDR, then it is changed to BMDR before executing Phase 3. 💅

Phase 3: Backup MDR Selection 🌈

(3.1) Let Rmax be the neighbor with the largest value of (RtrPri, MDR Level, RID).

(3.2) Determine whether or not there exist two neighbors, other than Rmax, with a larger value of (RtrPri, MDR Level, RID) than the router itself.

(3.3) If there exist two such neighbors, then the router sets its MDR Level to MDR Other. 🎀

(3.4) Else, the router sets its MDR Level to BMDR, and if AdjConnectivity = 2, adds Rmax and its MDR/BMDR neighbors as Dependent Neighbors. 🦋

(3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing from MDR Other to BMDR, then execute Step 2.2 again before proceeding to Phase 4. (This is necessary because running Step 2.2 again can cause the MDR Level to change to MDR.) 🙈

Phase 4: Parent Selection 🧚

Each router selects a Parent and (if AdjConnectivity = 2) a Backup Parent for the single-hop broadcast network. The Parent for a non-MDR router will be the MDR. The Backup Parent for an MDR Other, if it exists, will be a BMDR. Each non-MDR router becomes adjacent with its Parent and its Backup Parent, if it exists. The Parent selection algorithm is already simple, so a simplified version is not given here. ✨

The Parent and Backup Parent are analogous to the Designated Router and Backup Designated Router interface data items in OSPF. As in OSPF, these are advertised in the DR and Backup DR fields of each Hello sent on the interface. 💜

---

5. Security Considerations 🛡️

This document describes the use of OSPF-MDR in a single-hop broadcast network, and raises no security issues in addition to those already covered in [RFC5614]. 🔒 So the security tea is all over there, and this doc doesn't add any new drama on top. 😭

6. Normative References 📚

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
• [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
• [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding", RFC 5614, August 2009.

7. Informative References 🌸

• [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, January 2013.

Author's Address 💖

Richard G. Ogier EMail: ogier@earthlink.net