idnits 2.17.1 draft-ietf-ospf-manet-single-hop-mdr-00.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 (October 13, 2011) is 4572 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-ospf-hybrid-bcast-and-p2mp-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Ogier 3 Updates: 5614 October 13, 2011 4 Internet-Draft 5 Intended status: Experimental 6 Expires: April 15, 2012 8 Use of OSPF-MDR in Single-Hop Broadcast Networks 9 draft-ietf-ospf-manet-single-hop-mdr-00.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) 2011 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 Section 2 describes the operation of OSPF-MDR in a single-hop 106 broadcast network with recommended parameter settings. Section 3 107 describes an alternative procedure which may be used to decide which 108 neighbors on a single-hop broadcast network to advertise in the 109 router-LSA. Section 4 describes a simplified version of the MDR 110 selection algorithm for single-hop networks. 112 The alternative procedure of Section 3 and the simplified algorithm 113 of Section 4 are optional and MUST NOT be used if it is possible for 114 two routers in the network to be more than one hop from each other. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2. Operation in a Single-Hop Broadcast Network 124 When OSPF-MDR is used in a single-hop broadcast network, the 125 following parameter settings and options (defined in [RFC5614]) 126 should be used: 128 o AdjConnectivity SHOULD be equal to 2 (biconnected), MAY be equal 129 to 1 (uniconnected), and SHOULD NOT be equal to 0 (full topology). 131 o An adjacency SHOULD be eliminated if neither the router nor 132 the neighbor is an MDR or BMDR (see Section 7.3 of [RFC5614]). 134 o LSAFullness MUST be equal to 4 or 5 if full-topology LSAs are 135 required. (The value 5 is defined in Section 3 of this document.) 137 o LSAFullness MAY be equal to 1 (min-cost LSAs) if full-topology 138 LSAs are not required. This option reduces the number of 139 advertised links while still providing shortest paths. 141 If AdjConnectivity equals 1 or 2 and full-topology LSAs are used, 142 OSPF-MDR running on a single-hop broadcast network has the following 143 properties: 145 o A single MDR is selected, which becomes adjacent with every other 146 router, as in an OSPF broadcast network. 148 o Two BMDRs are selected. This occurs because the MDR selection 149 algorithm ensures that the MDR/BMDR backbone is biconnected. 150 If AdjConnectivity = 2, every non-MDR/BMDR router becomes adjacent 151 with one of the BMDRs in addition to the MDR. 153 o When all adjacencies are fully adjacent, the router-LSA for each 154 router includes point-to-point (type 1) links to all bidirectional 155 neighbors (in state 2-Way or greater). 157 3. Originating Router-LSAs 159 A router running OSPF-MDR with LSAFullness = 4 includes in its 160 router-LSA point-to-point (type 1) links for all fully adjacent 161 neighbors, and for all bidirectional neighbors that are routable. A 162 neighbor is routable if the SPF calculation has produced a route to 163 the neighbor and a flexible quality condition is satisfied. 165 This section describes an alternative procedure which MAY be used 166 instead of the procedure described in Section 6 of [RFC5614], to 167 decide which neighbors on a single-hop broadcast network to advertise 168 in the router-LSA. The alternative procedure will correspond to 169 LSAFullness = 5, and is interoperable with the other choices for 170 LSAFullness. This procedure avoids the need to check whether a 171 neighbor is routable, and thus avoids having to update the set of 172 routable neighbors. 174 If LSAFullness = 5, then the Selected Advertised Neighbor Set (SANS) 175 is the same as specified for LSAFullness = 4, and the following steps 176 are performed instead of the first paragraph of Section 9.4 in 177 [RFC5614]. 179 (1) The MDR includes in its router-LSA a point-to-point (type 1) link 180 for each fully adjacent neighbor. (Note that the MDR becomes 181 adjacent with all of its neighbors.) 183 (2) Each non-MDR router includes in its router-LSA a point-to-point 184 link for each fully adjacent neighbor, and, if the router is 185 fully adjacent with the MDR, for each bidirectional neighbor j 186 such that the MDR's router-LSA includes a link to j. 188 To provide rationale for the above procedure, let i and j be two 189 non-MDR routers. Since the SPF calculation (Section 16.1 of 190 [RFC2328]) allows router i to use router j as a next hop only if 191 router j advertises a link back to router i, routers i and j must 192 both advertise a link to each other in their router-LSAs before 193 either can use the other as a next hop. Therefore, the above 194 procedure for non-MDR routers (Step 2) implies there must exist a 195 path of fully adjacent links between i and j (via the MDR) in 196 both directions before this can happen. The above procedure for 197 non-MDR routers is similar to one described in Section 3.6 of 198 [HYBRID] for non-DR routers. 200 4. MDR Selection Algorithm 202 The MDR selection algorithm of [RFC5614] simplifies as follows in 203 single-hop networks. The resulting algorithm is similar to the DR 204 election algorithm of OSPF, but is slightly different (e.g., two 205 Backup MDRs are selected). The following simplified algorithm is 206 interoperable with the full MDR selection algorithm. 208 Note that lexicographic order is used when comparing tuples of the 209 form (RtrPri, MDR Level, RID). Also note that each router will form 210 adjacencies with its parents and dependent neighbors. In the 211 following, the term "neighbor" refers to a bidirectional neighbor (in 212 state 2-Way or greater). 214 Phase 1 (creating the neighbor connectivity matrix) is not required. 216 Phase 2: MDR Selection 218 (2.1) The set of Dependent Neighbors is initialized to be empty. 220 (2.2) If the router has a larger value of (RtrPri, MDR Level, RID) 221 than all of its (bidirectional) neighbors: the router selects 222 itself as an MDR, selects its BMDR neighbors as Dependent 223 Neighbors if AdjConnectivity = 2, then proceeds to Phase 4. 225 (2.3) Otherwise, if the router's MDR Level is currently MDR, then it 226 is changed to BMDR before executing Phase 3. 228 Phase 3: Backup MDR Selection 230 (3.1) Let Rmax be the neighbor with the largest value of (RtrPri, MDR 231 Level, RID). 233 (3.2) Determine whether or not there exist two neighbors, other than 234 Rmax, with a larger value of (RtrPri, MDR Level, RID) than the 235 router itself. 237 (3.3) If there exist two such neighbors, then the router sets its MDR 238 Level to MDR Other. 240 (3.4) Else, the router sets its MDR Level to BMDR, and if 241 AdjConnectivity = 2, adds Rmax and its MDR/BMDR neighbors as 242 Dependent Neighbors. 244 (3.5) If steps 3.1 through 3.4 resulted in the MDR Level changing 245 from MDR Other to BMDR, then execute Step 2.2 again before 246 proceeding to Phase 4. (This is necessary because running Step 247 2.2 again can cause the MDR Level to change to MDR.) 249 Phase 4: Parent Selection 251 Each router selects a Parent and (if AdjConnectivity = 2) a Backup 252 Parent for the single-hop broadcast network. The Parent for a non- 253 MDR router will be the MDR. The Backup Parent for an MDR Other, if 254 it exists, will be a BMDR. Each non-MDR router becomes adjacent with 255 its Parent and its Backup Parent, if it exists. The parent selection 256 algorithm is already simple, so a simplified version is not given 257 here. 259 The Parent and Backup Parent are analogous to the Designated Router 260 and Backup Designated Router interface data items in OSPF. As in 261 OSPF, these are advertised in the DR and Backup DR fields of each 262 Hello sent on the interface. 264 5. Security Considerations 266 This document describes the use of OSPF-MDR in a single-hop broadcast 267 network, and raises no security issues in addition to those already 268 covered in [RFC5614]. 270 6. IANA Considerations 272 This document has no IANA considerations. 274 7. Normative References 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 281 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 282 for IPv6", RFC 5340, July 2008. 284 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 285 Extension of OSPF Using Connected Dominating Set (CDS) 286 Flooding", RFC 5614, August 2009. 288 8. Informative References 290 [HYBRID] Sheth, N., L. Wang, and J. Zhang, "OSPF Hybrid Broadcast 291 and P2MP Interface Type", draft-ietf-ospf-hybrid-bcast-and- 292 p2mp-00.txt, October 2011, work in progress. 294 Author's Address 296 Richard G. Ogier 297 Email: rich.ogier@earthlink.net