idnits 2.17.1 draft-retana-ospf-manet-single-hop-01.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2011) is 4746 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft Hewlett-Packard Co. 4 Updates: RFC5820 (if approved) S. Ratliff 5 Intended status: Experimental Cisco Systems, Inc. 6 Expires: October 30, 2011 April 28, 2011 8 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks 9 draft-retana-ospf-manet-single-hop-01 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 deterministically reduce the number of adjacencies using Smart 16 Peering and other considerations due to the nature of the network. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 30, 2011. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Single-Hop Broadcast Networks . . . . . . . . . . . . . . . 3 54 1.2. MANET Interface Considerations . . . . . . . . . . . . . . 4 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 56 3. Use of Router Priority . . . . . . . . . . . . . . . . . . . . 4 57 4. Unsynchronized Adjacencies . . . . . . . . . . . . . . . . . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Changes from version -00 . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 The OSPF-MANET interface [RFC5820] uses the point-to-multipoint 70 adjacency model over a broadcast media to allow the following: 72 o all router-to-router connections are treated as if they were 73 point-to-point links. 75 o Link metric can be set on a per-neighbor basis. 77 o Broadcast and multicast can be accomplished through the Layer 2 78 broadcast capabilities of the media. 80 It is clear that the characteristics of the MANET interface can also 81 be beneficial in fixed network deployments; specifically in single- 82 hop broadcast capable networks which may have a different cost 83 associated with any pair of nodes. 85 This document describes the use of the MANET interface in single-hop 86 broadcast networks. 88 1.1. Single-Hop Broadcast Networks 90 The OSPF extensions for MANET networks assume the ad-hoc formation of 91 a network over bandwidth-constrained wireless links, where packets 92 may traverse several intermediate nodes before reaching their 93 destination (multi-hop paths on the interface). By contrast, a 94 single-hop broadcast network (as considered in this document) is one 95 that is structured in such a way that all the nodes in it are 96 directly connected to each other. An Ethernet interface is a good 97 example of the connectivity model. 99 Furthermore, the single-hop networks considered may have different 100 link metrics associated to the connectivity between a specific pair 101 of neighbors. The OSPF broadcast model [RFC2328] can't accurately 102 describe these differences. A point-to-multipoint description is 103 more appropriate given that each node can reach every other node 104 directly. 106 In summary, the single-hop broadcast interfaces considered in this 107 document have the following characteristics: 109 o direct connectivity between all the nodes 111 o different link metrics may exist per-neighbor 113 o it has broadcast/multicast capabilities 115 1.2. MANET Interface Considerations 117 The operation of the MANET interface doesn't change when implemented 118 on a single-hop broadcast interface. However, some of the proposed 119 enhancements are not needed; explicitly, Incremental Hellos and 120 Overlapping Relays are not required due to the connectivity model. 121 If Overlapping Relays are used, then the A-bit SHOULD NOT be set by 122 any of the nodes: the result is an empty set of Active Overlapping 123 Relays. 125 Smart Peering can be used to reduce the burden of requiring a full 126 mesh of adjacencies. In short, a new adjacency is not required if 127 reachability to the node is already available through the existing 128 STP. In general, the reachability is verified on a first-come-first- 129 served basis; i.e. in a typical network, the neighbors with which a 130 FULL adjacency is set up depend on the order of discovery. Section 3 131 explains the use of Router Priority to create a deterministic 132 mechanism to select which nodes to form FULL adjacencies with. 134 Section 4 explains the operation with unsynchronized adjacencies. 136 The operation described in this document uses already defined 137 mechanisms and requires no additional on-the-wire changes. 139 2. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 3. Use of Router Priority 147 The Smart Peering state machine [RFC5820] allows for the definition 148 of heuristics, beyond the SPT reachability, to decide whether or not 149 it considers a new adjacency to be of value. This section describes 150 one such heuristic to be used in Step (3) of the state machine. 152 The Router Priority (as defined in OSPFv2 [RFC2328] and OSPFv3 153 [RFC5340]) is used in the election of the (Backup) Designated Router, 154 and can be configured only in broadcast and NBMA interfaces. The 155 MANET interface is a broadcast interface using the point-to- 156 multipoint adjacency model, which means that no (Backup) Designated 157 Router is elected. For its use with the MANET interface, the Router 158 Priority is defined as: 160 Router Priority 161 An 8-bit unsigned integer. Used to determine the precedence of 162 which router(s) to establish a FULL adjacency with during the 163 Smart Peering selection process. When more than one router 164 attached to a network is present, the one with the highest 165 Router Priority takes precedence. If there is still a tie, the 166 router with the highest Router ID takes precedence. 168 The heuristic for the smart peering state machine is described as: 170 (3) | 171 ,'''''''''''''''''''''''''''''''''''''''''''''''''''''''''| 172 | ............................ | 173 | |Determine if the number of| | 174 | |existing adjacencies is < | | 175 | |the maximum configured | | 176 | |value | | 177 | '`'''''''\'''''''''''''''/'' | 178 | \ / | 179 | ................\.........../.............. | 180 | |Determine if the neighbor has the highest| | 181 | |(Router Priority, Router ID) combination | | 182 | ''''''''''''`'''/'''''''\'''''''''''''''''' | 183 | / \ | 184 '`'''''''''''''''''''''/'''''''''''\''''''''''''''''''''''' 186 Smart Peering Algorithm 188 In order to avoid churn in the selection and establishment of the 189 adjacencies, every router SHOULD wait Wait Time [RFC2328] before 190 running the Smart Peering state machine. Note that this wait should 191 cause the selection process to consider all the nodes on the link, 192 instead of being triggered based on receiving a Hello message from a 193 potential neighbor. The nodes selected using this process are 194 referred to simply as Smart Peers. 196 It is RECOMMENDED that the maximum number of adjacencies be set to 2. 198 4. Unsynchronized Adjacencies 200 An unsynchronized adjacency [RFC5820] is one for which the database 201 synchronization is postponed, but that is announced as FULL because 202 SPT reachability can be proven. A single-hop broadcast network has a 203 connectivity model in which all the nodes are directly connected to 204 each other. This connectivity results in a simplified reachability 205 check through the SPT: the adjacency to a specific peer MUST be 206 advertized as FULL by at least one Smart Peer. 208 The single-hop nature of the interface allows then the advertisement 209 of the reachable adjacencies as FULL without additional signaling. 210 Flooding SHOULD be enabled for all the unsynchronized adjacencies to 211 take advantage of the broadcast nature of the media. As a result, 212 all the nodes in the interface will be able to use all the LSAs 213 received. 215 5. IANA Considerations 217 This document includes no request to IANA. 219 6. Security Considerations 221 No new security concerns beyond the ones expressed in [RFC5820] are 222 introduced in this document. In fact, due to the application in 223 fixed networks, some of the concerns may actually be reduced. 225 7. Acknowledgements 227 The authors would like to thank Anton Smirnov, Jeffrey Zhang and Alia 228 Atlas for their comments. 230 8. References 232 8.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 239 8.2. Informative References 241 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 242 for IPv6", RFC 5340, July 2008. 244 [RFC5820] Roy, A. and M. Chandra, "Extensions to OSPF to Support 245 Mobile Ad Hoc Networking", RFC 5820, March 2010. 247 Appendix A. Changes from version -00 248 o Updated author information. 250 o Explicitly recommended the maximum number of adjacencies to be set 251 to 2. 253 o Updated ack section. 255 Authors' Addresses 257 Alvaro Retana 258 Hewlett-Packard Co. 259 2610 Wycliff Road 260 Raleigh, NC 27607 261 USA 263 Email: alvaro.retana@hp.com 265 Stan Ratliff 266 Cisco Systems, Inc. 267 7025 Kit Creek Rd. 268 Research Triangle Park, NC 27709 269 USA 271 Email: sratliff@cisco.com