idnits 2.17.1 draft-ietf-ospf-manet-single-hop-mdr-03.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 (June 3, 2013) is 3980 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 June 3, 2013 5 Intended status: Experimental 6 Expires: December 5, 2013 8 Use of OSPF-MDR in Single-Hop Broadcast Networks 9 draft-ietf-ospf-manet-single-hop-mdr-03.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. Unlike an OSPF broadcast 100 interface, such an interface can have a different cost associated 101 with each neighbor. An example use case is when the underlying radio 102 system performs layer-2 routing, but has a different number of 103 (layer-2) hops to (layer-3) neighbors. 105 The rationale for using this interface type for single-hop broadcast 106 networks, instead of a broadcast interface type, is to represent the 107 underlying network in a point-to-multipoint manner, allowing each 108 router to advertise different costs to different neighbors in its 109 router-LSA. In this sense, this document shows how the OSPF-MDR 110 interface type can be configured (and simplified if desired) to 111 achieve the same goals as the OSPF Hybrid Broadcast and Point-to- 112 Multipoint interface type [RFC6845]. 114 Section 2 describes the operation of OSPF-MDR in a single-hop 115 broadcast network with recommended parameter settings. Section 3 116 describes an alternative procedure which may be used to decide which 117 neighbors on a single-hop broadcast network to advertise in the 118 router-LSA. Section 4 describes a simplified version of the MDR 119 selection algorithm for single-hop networks. 121 The alternative procedure of Section 3 and the simplified algorithm 122 of Section 4 are optional and MUST NOT be used if it is possible for 123 two routers in the network to be more than one hop from each other. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2. Operation in a Single-Hop Broadcast Network 133 When OSPF-MDR is used in a single-hop broadcast network, the 134 following parameter settings and options (defined in [RFC5614]) 135 should be used: 137 o AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal 138 to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology). 140 o An adjacency SHOULD be eliminated if neither the router nor 141 the neighbor is an MDR or BMDR (see Section 7.3 of [RFC5614]). 143 o LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are 144 required. (The value 5 is defined in Section 3 of this document.) 146 o LSAFullness MAY be equal to 1 (min-cost LSAs) if full-topology 147 LSAs are not required. This option reduces the number of 148 advertised links while still providing shortest paths. 150 If AdjConnectivity equals 1 or 2 and full-topology LSAs are used, 151 OSPF-MDR running on a single-hop broadcast network has the following 152 properties: 154 o A single MDR is selected, which becomes adjacent with every other 155 router, as in an OSPF broadcast network. 157 o Two BMDRs are selected. This occurs because the MDR selection 158 algorithm ensures that the MDR/BMDR backbone is biconnected. 159 If AdjConnectivity = 2, every non-MDR/BMDR router becomes adjacent 160 with one of the BMDRs in addition to the MDR. 162 o When all adjacencies are fully adjacent, the router-LSA for each 163 router includes point-to-point (type 1) links to all bidirectional 164 neighbors (in state 2-Way or greater). 166 3. Originating Router-LSAs 168 A router running OSPF-MDR with LSAFullness = 4 includes in its 169 router-LSA point-to-point (type 1) links for all fully adjacent 170 neighbors, and for all bidirectional neighbors that are routable. A 171 neighbor is routable if the SPF calculation has produced a route to 172 the neighbor and a flexible quality condition is satisfied. 174 This section describes an alternative procedure which MAY be used 175 instead of the procedure described in Section 6 of [RFC5614], to 176 decide which neighbors on a single-hop broadcast network to advertise 177 in the router-LSA. The alternative procedure will correspond to 178 LSAFullness = 5, and is interoperable with the other choices for 179 LSAFullness. This procedure avoids the need to check whether a 180 neighbor is routable, and thus avoids having to update the set of 181 routable neighbors. 183 If LSAFullness = 5, then the Selected Advertised Neighbor Set (SANS) 184 is the same as specified for LSAFullness = 4, and the following steps 185 are performed instead of the first paragraph of Section 9.4 in 186 [RFC5614]. 188 (1) The MDR includes in its router-LSA a point-to-point (type 1) link 189 for each fully adjacent neighbor. (Note that the MDR becomes 190 adjacent with all of its neighbors.) 192 (2) Each non-MDR router includes in its router-LSA a point-to-point 193 link for each fully adjacent neighbor, and, if the router is 194 fully adjacent with the MDR, for each bidirectional neighbor j 195 such that the MDR's router-LSA includes a link to j. 197 To provide rationale for the above procedure, let i and j be two 198 non-MDR routers. Since the SPF calculation (Section 16.1 of 199 [RFC2328]) allows router i to use router j as a next hop only if 200 router j advertises a link back to router i, routers i and j must 201 both advertise a link to each other in their router-LSAs before 202 either can use the other as a next hop. Therefore, the above 203 procedure for non-MDR routers (Step 2) implies there must exist a 204 path of fully adjacent links between i and j (via the MDR) in 205 both directions before this can happen. The above procedure for 206 non-MDR routers is similar to one described in Section 4.6 of 207 [RFC6845] for non-DR routers. 209 4. MDR Selection Algorithm 211 The MDR selection algorithm of [RFC5614] simplifies as follows in 212 single-hop networks. The resulting algorithm is similar to the DR 213 election algorithm of OSPF, but is slightly different (e.g., two 214 Backup MDRs are selected). The following simplified algorithm is 215 interoperable with the full MDR selection algorithm. 217 Note that lexicographic order is used when comparing tuples of the 218 form (RtrPri, MDR Level, RID). Also note that each router will form 219 adjacencies with its parents and dependent neighbors. In the 220 following, the term "neighbor" refers to a bidirectional neighbor (in 221 state 2-Way or greater). 223 Phase 1 (creating the neighbor connectivity matrix) is not required. 225 Phase 2: MDR Selection 227 (2.1) The set of Dependent Neighbors is initialized to be empty. 229 (2.2) If the router has a larger value of (RtrPri, MDR Level, RID) 230 than all of its (bidirectional) neighbors: the router selects 231 itself as an MDR, selects its BMDR neighbors as Dependent 232 Neighbors if AdjConnectivity = 2, then proceeds to Phase 4. 234 (2.3) Otherwise, if the router's MDR Level is currently MDR, then it 235 is changed to BMDR before executing Phase 3. 237 Phase 3: Backup MDR Selection 239 (3.1) Let Rmax be the neighbor with the largest value of (RtrPri, MDR 240 Level, RID). 242 (3.2) Determine whether or not there exist two neighbors, other than 243 Rmax, with a larger value of (RtrPri, MDR Level, RID) than the 244 router itself. 246 (3.3) If there exist two such neighbors, then the router sets its MDR 247 Level to MDR Other. 249 (3.4) Else, the router sets its MDR Level to BMDR, and if 250 AdjConnectivity = 2, adds Rmax and its MDR/BMDR neighbors as 251 Dependent Neighbors. 253 (3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing 254 from MDR Other to BMDR, then execute Step 2.2 again before 255 proceeding to Phase 4. (This is necessary because running Step 256 2.2 again can cause the MDR Level to change to MDR.) 258 Phase 4: Parent Selection 260 Each router selects a Parent and (if AdjConnectivity = 2) a Backup 261 Parent for the single-hop broadcast network. The Parent for a non- 262 MDR router will be the MDR. The Backup Parent for an MDR Other, if 263 it exists, will be a BMDR. Each non-MDR router becomes adjacent with 264 its Parent and its Backup Parent, if it exists. The parent selection 265 algorithm is already simple, so a simplified version is not given 266 here. 268 The Parent and Backup Parent are analogous to the Designated Router 269 and Backup Designated Router interface data items in OSPF. As in 270 OSPF, these are advertised in the DR and Backup DR fields of each 271 Hello sent on the interface. 273 5. Security Considerations 275 This document describes the use of OSPF-MDR in a single-hop broadcast 276 network, and raises no security issues in addition to those already 277 covered in [RFC5614]. 279 6. IANA Considerations 281 This document has no IANA considerations. 283 7. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 290 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 291 for IPv6", RFC 5340, July 2008. 293 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 294 Extension of OSPF Using Connected Dominating Set (CDS) 295 Flooding", RFC 5614, August 2009. 297 8. Informative References 299 [RFC6845] Sheth, N., L. Wang, and J. Zhang, "OSPF Hybrid Broadcast 300 and Point-to-Multipoint Interface Type", RFC 6845, January 301 2013. 303 Author's Address 305 Richard G. Ogier 306 Email: ogier@earthlink.net