idnits 2.17.1 draft-ietf-ospf-manet-single-hop-or-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5820, updated by this document, for RFC5378 checks: 2008-02-11) -- 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 (December 18, 2013) is 3775 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft S. Ratliff 4 Updates: 5820 (if approved) Cisco Systems, Inc. 5 Intended status: Experimental December 18, 2013 6 Expires: June 21, 2014 8 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks 9 draft-ietf-ospf-manet-single-hop-or-04 11 Abstract 13 This document describes the use of the OSPF-MANET interface in 14 single-hop broadcast networks. It includes a mechanism to 15 dynamically determine the presence of such a network and specific 16 operational considerations due to its nature. 18 This document updates RFC5820. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 21, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 3. Single-Hop Network Operation . . . . . . . . . . . . . . . . 3 58 3.1. Use of Router Priority . . . . . . . . . . . . . . . . . 4 59 3.2. Unsynchronized Adjacencies . . . . . . . . . . . . . . . 5 60 4. Single-Hop Network Detection . . . . . . . . . . . . . . . . 5 61 4.1. Transition from multi-hop to single-hop mode . . . . . . 6 62 4.2. Transition from single-hop to multi-hop mode . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 70 A.1. Changes between the -00 and -01 versions. . . . . . . . . 8 71 A.2. Changes between the -01 and -02 versions. . . . . . . . . 8 72 A.3. Changes between the -02 and -03 versions. . . . . . . . . 8 73 A.4. Changes betwen the -03 and -04 versions . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The OSPF-MANET interface [RFC5820] uses the point-to-multipoint 79 adjacency model over a broadcast media to allow the following: 81 o all router-to-router connections are treated as if they were 82 point-to-point links. 84 o Link metric can be set on a per-neighbor basis. 86 o Broadcast and multicast can be accomplished through the Layer 2 87 broadcast capabilities of the media. 89 It is clear that the characteristics of the MANET interface can also 90 be beneficial in other types of network deployments; specifically in 91 single-hop broadcast capable networks which may have a different cost 92 associated with any pair of nodes. 94 This document updates [RFC5820] by describing the use of the MANET 95 interface in single-hop broadcast networks, which consists of its 96 simplified operation by not requiring the use of Overlapping Relays 97 as well as introducing a new heuristic for Smart Peering using the 98 Router Priority. 100 1.1. Single-Hop Broadcast Networks 102 The OSPF extensions for MANET networks assume the ad-hoc formation of 103 a network over bandwidth-constrained wireless links, where packets 104 may traverse several intermediate nodes before reaching their 105 destination (multi-hop paths on the interface). By contrast, a 106 single-hop broadcast network (as considered in this document) is one 107 that is structured in such a way that all the nodes in it are 108 directly connected to each other. An Ethernet interface is a good 109 example of the connectivity model. 111 Furthermore, the single-hop networks considered may have different 112 link metrics associated to the connectivity between a specific pair 113 of neighbors. The OSPF broadcast model [RFC2328] can't accurately 114 describe these differences. A point-to-multipoint description is 115 more appropriate given that each node can reach every other node 116 directly. 118 In summary, the single-hop broadcast interfaces considered in this 119 document have the following characteristics: 121 o direct connectivity between all the nodes 123 o different link metrics may exist per-neighbor 125 o it has broadcast/multicast capabilities 127 2. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Single-Hop Network Operation 135 The operation of the MANET interface doesn't change when implemented 136 on a single-hop broadcast interface. However, the operation of some 137 of the proposed enhancements can be simplified. Explicitly, the 138 Overlapping Relay Discovery Process SHOULD NOT be executed and the 139 A-bit SHOULD NOT be set by any of the nodes: the result is an empty 140 set of Active Overlapping Relays. 142 This document describes the use of already defined mechanisms and 143 requires no additional on-the-wire changes. 145 3.1. Use of Router Priority 147 Smart Peering [RFC5820] can be used to reduce the burden of requiring 148 a full mesh of adjacencies. In short, a new adjacency is not 149 required if reachability to the node is already available through the 150 existing SPT. In general, the reachability is verified on a first- 151 come-first-served basis; i.e. in a typical network, the neighbors 152 with which a FULL adjacency is set up depend on the order of 153 discovery. 155 The Smart Peering state machine allows for the definition of 156 heuristics, beyond the SPT reachability, to decide whether or not it 157 considers a new adjacency to be of value. This section describes one 158 such heuristic to be used in Step (3) of the state machine, in place 159 of the original one. 161 The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3 162 [RFC5340]) is used in the election of the (Backup) Designated Router, 163 and can be configured only in broadcast and NBMA interfaces. The 164 MANET interface is a broadcast interface using the point-to- 165 multipoint adjacency model, which means that no (Backup) Designated 166 Router is elected. For its use with the MANET interface, the Router 167 Priority is defined as: 169 Router Priority 170 An 8-bit unsigned integer. Used to determine the precedence of 171 which router(s) to establish a FULL adjacency with during the 172 Smart Peering selection process. When more than one router 173 attached to a network is present, the one with the highest 174 Router Priority takes precedence. If there is still a tie, the 175 router with the highest Router ID takes precedence. 177 The heuristic for the smart peering state machine is described as: 179 (3) | 180 ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''| 181 | ............................ | 182 | |Determine if the number of| | 183 | |existing adjacencies is < | | 184 | |the maximum configured | | 185 | |value | | 186 | '`'''''''\'''''''''''''''/'' | 187 | \ / | 188 | ................\.........../.............. | 189 | |Determine if the neighbor has the highest| | 190 | |(Router Priority, Router ID) combination | | 191 | ''''''''''''`'''/'''''''\'''''''''''''''''' | 192 | / \ | 193 '`'''''''''''''''''''''/'''''''''''\''''''''''''''''''''''' 195 Smart Peering Algorithm 197 In order to avoid churn in the selection and establishment of the 198 adjacencies, every router SHOULD wait until the ModeChange timer 199 (Section 4) expires before running the Smart Peering state machine. 200 Note that this wait should cause the selection process to consider 201 all the nodes on the link, instead of being triggered based on 202 receiving a Hello message from a potential neighbor. The nodes 203 selected using this process are referred to simply as Smart Peers. 205 It is RECOMMENDED that the maximum number of adjacencies be set to 2. 207 3.2. Unsynchronized Adjacencies 209 An unsynchronized adjacency [RFC5820] is one for which the database 210 synchronization is postponed, but that is announced as FULL because 211 SPT reachability can be proven. A single-hop broadcast network has a 212 connectivity model in which all the nodes are directly connected to 213 each other. This connectivity results in a simplified reachability 214 check through the SPT: the adjacency to a specific peer MUST be 215 advertized as FULL by at least one Smart Peer. 217 The single-hop nature of the interface allows then the advertisement 218 of the reachable adjacencies as FULL without additional signaling. 219 Flooding SHOULD be enabled for all the unsynchronized adjacencies to 220 take advantage of the broadcast nature of the media. As a result, 221 all the nodes in the interface will be able to use all the LSAs 222 received. 224 4. Single-Hop Network Detection 225 A single-hop network is one in which all the nodes are directly 226 connected. Detection of such an interface can be easily done at 227 every node by comparing the speaker's 1-hop neighbors with its 2-hop 228 neighborhood. If for every 1-hop neighbor, the set of 2-hop 229 neighbors contains the whole set of the remaining 1-hop neighbors, 230 then the interface is a single-hop network; this condition is called 231 the Single-Hop Condition. 233 A new field is introduced in the MANET interface data structure. The 234 name of the field is SingleHop, and it is a flag indicating whether 235 the interface is operating in single-hop mode (as described in 236 Section 3). The SingleHop flag is set when the node meets the 237 Single-Hop Condition on the interface. If the Single-Hop Condition 238 is no longer met then the SingleHop flag MUST be cleared. 240 A new timer is introduced to guide the transition of the interface 241 from/to multi-hop mode (which is the default mode described in 242 [RFC5820]) to/from single-hop mode: 244 o ModeChange: Every time a node changes the state of the SingleHop 245 flag for the interface, the corresponding ModeChange timer MUST be 246 set. The ModeChange timer represents the length of time in 247 seconds that an interface SHOULD wait before changing between 248 multi-hop and single-hop modes. It is RECOMMENDED that this timer 249 be set to Wait Time [RFC2328]. 251 The following sections describe the steps to be taken to transition 252 between interface modes. 254 4.1. Transition from multi-hop to single-hop mode 256 Detection of the Single-Hop Condition triggers the transition into 257 single-hop mode by setting both the SingleHop flag and the ModeChange 258 timer. 260 Once the ModeChange timer expires, the heuristic defined in 261 Section 3.1 MAY be executed to optimize the set of adjacencies on the 262 interface. Note that an adjacency MUST NOT transition from FULL to 263 2-Way unless the simplified reachabiity check (Section 3.2) can be 264 verified. 266 4.2. Transition from single-hop to multi-hop mode 268 Not meeting the Single-Hop Condition triggers the transition into 269 multi-hop mode by clearing the SingleHop flag and setting the 270 ModeChange timer. The A-bit MUST be set if the Single-Hop condition 271 is no longer met because of one of the following cases: 273 o an increase in the set of 1-hop neighbors, without the 274 corresponding increase of the 2-hop neighborhood 276 o a decrease of the 2-hop neighborhood while maintaining all the 277 previous 1-hop neighbors 279 Once the ModeChange timer expires, the multi-hop operation described 280 in [RFC5820] takes over. 282 Note that the cases listed above may result in the interface either 283 gaining or losing a node before the ModeChange timer expires. In 284 both cases the heuristic defined in Section 3.1 MAY be executed to 285 optimize the set of adjacencies on the interface. 287 In the case that a node joins the interface, the Designated Router 288 and Backup Designated Router fields in the Hello packet [RFC2328] MAY 289 be used to inform the new node of the identity (Router ID) of the 290 current Smart Peers (and avoid the optimization). 292 5. IANA Considerations 294 This document includes no request to IANA. 296 6. Security Considerations 298 No new security concerns beyond the ones expressed in [RFC5820] are 299 introduced in this document. 301 7. Acknowledgements 303 The authors would like to thank Anton Smirnov, Jeffrey Zhang, Alia 304 Atlas, Juan Antonio Cordero, Richard Ogier and Christer Holmberg for 305 their comments. 307 8. References 309 8.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 316 [RFC5820] Roy, A. and M. Chandra, "Extensions to OSPF to Support 317 Mobile Ad Hoc Networking", RFC 5820, March 2010. 319 8.2. Informative References 321 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 322 for IPv6", RFC 5340, July 2008. 324 Appendix A. Change Log 326 To be removed prior to publication. 328 A.1. Changes between the -00 and -01 versions. 330 o Updated contact information. 332 A.2. Changes between the -01 and -02 versions. 334 o Indicated the nature of the RFC5820 update. 336 o Clarified the Single-Hop Condition and the SingleHop flag. 338 o Reshuffled the references. 340 A.3. Changes between the -02 and -03 versions. 342 No changes..just a refresh. 344 A.4. Changes betwen the -03 and -04 versions 346 o Clarified how this document updates RFC5820. 348 o Updated ACKs. 350 Authors' Addresses 352 Alvaro Retana 353 Cisco Systems, Inc. 354 7025 Kit Creek Rd. 355 Research Triangle Park, NC 27709 356 USA 358 Email: aretana@cisco.com 360 Stan Ratliff 361 Cisco Systems, Inc. 362 7025 Kit Creek Rd. 363 Research Triangle Park, NC 27709 364 USA 366 Email: sratliff@cisco.com