idnits 2.17.1 draft-ietf-ospf-manet-single-hop-mdr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5614, but the abstract doesn't seem to directly say this. It does mention RFC5614 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5614, updated by this document, for RFC5378 checks: 2008-02-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 2013) is 3914 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Ogier 3 Internet-Draft SRI International 4 Updates: 5614 August 7, 2013 5 Intended status: Experimental 6 Expires: February 8, 2014 8 Use of OSPF-MDR in Single-Hop Broadcast Networks 9 draft-ietf-ospf-manet-single-hop-mdr-04.txt 11 Abstract 13 RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks 14 (MANETs) by specifying its operation on the new OSPF interface of type 15 MANET. This document describes the use of OSPF-MDR in a single-hop 16 broadcast network, which is a special case of a MANET in which each 17 router is a (one-hop) neighbor of each other router. Unlike an OSPF 18 broadcast interface, such an interface can have a different cost 19 associated with each neighbor. The document includes configuration 20 recommendations and simplified mechanisms that can be used in single-hop 21 broadcast networks. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 OSPF-MDR [RFC5614] specifies an extension of OSPF [RFC2328, RFC5340] 56 to support mobile ad-hoc networks (MANETs) by specifying its 57 operation on the new OSPF interface of type MANET. OSPF-MDR 58 generalizes the Designated Router (DR) to a connected dominating set 59 (CDS) consisting of a typically small subset of routers called MANET 60 Designated Routers (MDRs). Similarly, the Backup Designated Router 61 (BDR) is generalized to a subset of routers called Backup MDRs 62 (BMDRs). MDRs achieve scalability in MANETs similar to the way DRs 63 achieve scalability in broadcast networks: 65 o MDRs have primary responsibility for flooding LSAs. Backup MDRs 66 provide backup flooding when MDRs temporarily fail. 68 o MDRs allow the number of adjacencies to be dramatically reduced, 69 by requiring adjacencies to be formed only between MDR/BMDR 70 routers and their neighbors. 72 In addition, OSPF-MDR has the following features: 74 o MDRs and BMDRs are elected based on information obtained from 75 modified Hello packets received from neighbors. 77 o If adjacency reduction is used (the default), adjacencies are 78 formed between MDRs so as to form a connected subgraph. 79 An option (AdjConnectivity = 2) allows for additional adjacencies 80 to be formed between MDRs/BMDRs to form a biconnected subgraph. 82 o Each non-MDR router becomes adjacent with an MDR called its 83 Parent, and optionally (if AdjConnectivity = 2) becomes adjacent 84 with another MDR or BMDR called its Backup Parent. 86 o Each router advertises connections to its neighbor routers as 87 point-to-point links in its router-LSA. Network-LSAs are not used. 89 o In addition to full-topology LSAs, partial-topology LSAs may be 90 used to reduce the size of router-LSAs. Such LSAs are formatted 91 as standard LSAs, but advertise links to only a subset of 92 neighbors. 94 o Optionally, differential Hellos can be used, which reduce 95 overhead by reporting only changes in neighbor states. 97 This document describes the use of OSPF-MDR in a single-hop broadcast 98 network, which is a special case of a MANET in which each router is a 99 (one-hop) neighbor of each other router. An understanding of 100 [RFC5614] is assumed. Unlike an OSPF broadcast interface, such an 101 interface can have a different cost associated with each neighbor. 102 An example use case is when the underlying radio system performs 103 layer-2 routing, but has a different number of (layer-2) hops to 104 (layer-3) neighbors. 106 The rationale for using this interface type for single-hop broadcast 107 networks, instead of a broadcast interface type, is to represent the 108 underlying network in a point-to-multipoint manner, allowing each 109 router to advertise different costs to different neighbors in its 110 router-LSA. In this sense, this document shows how the OSPF-MDR 111 interface type can be configured (and simplified if desired) to 112 achieve the same goals as the OSPF Hybrid Broadcast and Point-to- 113 Multipoint interface type [RFC6845]. 115 Section 2 describes the operation of OSPF-MDR in a single-hop 116 broadcast network with recommended parameter settings. Section 3 117 describes an alternative procedure which may be used to decide which 118 neighbors on a single-hop broadcast network to advertise in the 119 router-LSA. Section 4 describes a simplified version of the MDR 120 selection algorithm for single-hop networks. 122 The alternative procedure of Section 3 and the simplified algorithm 123 of Section 4 are optional and MUST NOT be used if it is possible for 124 two routers in the network to be more than one hop from each other. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in [RFC2119]. 132 2. Operation in a Single-Hop Broadcast Network 134 When OSPF-MDR is used in a single-hop broadcast network, the 135 following parameter settings and options (defined in [RFC5614]) 136 should be used: 138 o AdjConnectivity SHOULD be equal to 2 (biconnected); this provides 139 the smoothest transition when one router replaces another as MDR, 140 since the set of adjacencies forms a biconnected network which 141 remains connected during the transition. 143 o AdjConnectivity MAY be equal to 1 (uniconnected), resulting in a 144 slightly less smooth transition since adjacencies must be formed 145 between the new MDR and all of its neighbors. 147 o AdjConnectivity SHOULD NOT be equal to 0 (full topology) since 148 this requires adjacencies to be formed between all pairs of 149 routers, adding unnecessary message overhead. 151 o An adjacency SHOULD be eliminated if neither the router nor 152 the neighbor is an MDR or BMDR (see Section 7.3 of [RFC5614]). 154 o LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are 155 required. (The value 5 is defined in Section 3 of this document.) 157 o LSAFullness MAY be equal to 1 (min-cost LSAs) if full-topology 158 LSAs are not required. This option reduces the number of 159 advertised links while still providing shortest paths. 161 If AdjConnectivity equals 1 or 2 and full-topology LSAs are used, 162 OSPF-MDR running on a single-hop broadcast network has the following 163 properties: 165 o A single MDR is selected, which becomes adjacent with every other 166 router, as in an OSPF broadcast network. 168 o Two BMDRs are selected. This occurs because the MDR selection 169 algorithm ensures that the MDR/BMDR backbone is biconnected. 170 If AdjConnectivity = 2, every non-MDR/BMDR router becomes adjacent 171 with one of the BMDRs in addition to the MDR. 173 o When all adjacencies are fully adjacent, the router-LSA for each 174 router includes point-to-point (type 1) links to all bidirectional 175 neighbors (in state 2-Way or greater). 177 3. Originating Router-LSAs 179 A router running OSPF-MDR with LSAFullness = 4 includes in its 180 router-LSA point-to-point (type 1) links for all fully adjacent 181 neighbors, and for all bidirectional neighbors that are routable. A 182 neighbor is routable if the SPF calculation has produced a route to 183 the neighbor and a flexible quality condition is satisfied. 185 This section describes an alternative procedure which MAY be used 186 instead of the procedure described in Section 6 of [RFC5614], to 187 decide which neighbors on a single-hop broadcast network to advertise 188 in the router-LSA. The alternative procedure will correspond to 189 LSAFullness = 5, and is interoperable with the other choices for 190 LSAFullness. This procedure avoids the need to check whether a 191 neighbor is routable, and thus avoids having to update the set of 192 routable neighbors. 194 If LSAFullness = 5, then the Selected Advertised Neighbor Set (SANS) 195 is the same as specified for LSAFullness = 4, and the following steps 196 are performed instead of the first paragraph of Section 9.4 in 197 [RFC5614]. 199 (1) The MDR includes in its router-LSA a point-to-point (type 1) link 200 for each fully adjacent neighbor. (Note that the MDR becomes 201 adjacent with all of its neighbors.) 203 (2) Each non-MDR router includes in its router-LSA a point-to-point 204 link for each fully adjacent neighbor, and, if the router is 205 fully adjacent with the MDR, for each bidirectional neighbor j 206 such that the MDR's router-LSA includes a link to j. 208 To provide rationale for the above procedure, let i and j be two non- 209 MDR routers. Since the SPF calculation (Section 16.1 of [RFC2328]) 210 allows router i to use router j as a next hop only if router j 211 advertises a link back to router i, routers i and j must both 212 advertise a link to each other in their router-LSAs before either can 213 use the other as a next hop. Therefore, the above procedure for non- 214 MDR routers (Step 2) implies there must exist a path of fully 215 adjacent links between i and j (via the MDR) in both directions 216 before this can happen. The above procedure for non-MDR routers is 217 similar to one described in Section 4.6 of [RFC6845] for non-DR 218 routers. 220 4. MDR Selection Algorithm 222 The MDR selection algorithm of [RFC5614] simplifies as follows in 223 single-hop networks. The resulting algorithm is similar to the DR 224 election algorithm of OSPF, but is slightly different (e.g., two 225 Backup MDRs are selected). The following simplified algorithm is 226 interoperable with the full MDR selection algorithm. 228 Note that lexicographic order is used when comparing tuples of the 229 form (RtrPri, MDR Level, RID). Also note that each router will form 230 adjacencies with its parents and dependent neighbors. In the 231 following, the term "neighbor" refers to a bidirectional neighbor (in 232 state 2-Way or greater). 234 Phase 1 (creating the neighbor connectivity matrix) is not required. 236 Phase 2: MDR Selection 238 (2.1) The set of Dependent Neighbors is initialized to be empty. 240 (2.2) If the router has a larger value of (RtrPri, MDR Level, RID) 241 than all of its (bidirectional) neighbors: the router selects 242 itself as an MDR, selects its BMDR neighbors as Dependent 243 Neighbors if AdjConnectivity = 2, then proceeds to Phase 4. 245 (2.3) Otherwise, if the router's MDR Level is currently MDR, then it 246 is changed to BMDR before executing Phase 3. 248 Phase 3: Backup MDR Selection 250 (3.1) Let Rmax be the neighbor with the largest value of (RtrPri, MDR 251 Level, RID). 253 (3.2) Determine whether or not there exist two neighbors, other than 254 Rmax, with a larger value of (RtrPri, MDR Level, RID) than the 255 router itself. 257 (3.3) If there exist two such neighbors, then the router sets its MDR 258 Level to MDR Other. 260 (3.4) Else, the router sets its MDR Level to BMDR, and if 261 AdjConnectivity = 2, adds Rmax and its MDR/BMDR neighbors as 262 Dependent Neighbors. 264 (3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing 265 from MDR Other to BMDR, then execute Step 2.2 again before 266 proceeding to Phase 4. (This is necessary because running Step 267 2.2 again can cause the MDR Level to change to MDR.) 269 Phase 4: Parent Selection 271 Each router selects a Parent and (if AdjConnectivity = 2) a Backup 272 Parent for the single-hop broadcast network. The Parent for a non- 273 MDR router will be the MDR. The Backup Parent for an MDR Other, if 274 it exists, will be a BMDR. Each non-MDR router becomes adjacent with 275 its Parent and its Backup Parent, if it exists. The parent selection 276 algorithm is already simple, so a simplified version is not given 277 here. 279 The Parent and Backup Parent are analogous to the Designated Router 280 and Backup Designated Router interface data items in OSPF. As in 281 OSPF, these are advertised in the DR and Backup DR fields of each 282 Hello sent on the interface. 284 5. Security Considerations 286 This document describes the use of OSPF-MDR in a single-hop broadcast 287 network, and raises no security issues in addition to those already 288 covered in [RFC5614]. 290 6. IANA Considerations 292 This document has no IANA considerations. 294 7. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 301 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 302 for IPv6", RFC 5340, July 2008. 304 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 305 Extension of OSPF Using Connected Dominating Set (CDS) 306 Flooding", RFC 5614, August 2009. 308 8. Informative References 310 [RFC6845] Sheth, N., L. Wang, and J. Zhang, "OSPF Hybrid Broadcast 311 and Point-to-Multipoint Interface Type", RFC 6845, January 312 2013. 314 Author's Address 316 Richard G. Ogier 317 Email: ogier@earthlink.net