idnits 2.17.1 draft-ietf-manet-simple-mbcast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 0) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references (7], [4,5,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Route Discoveries for a multicast or broadcast address SHOULD always be permitted and SHOULD not be rate limited. -- 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 (17 November 2000) is 8561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-10) exists of draft-ietf-manet-dsr-04 ** Downref: Normative reference to an Experimental draft: draft-ietf-manet-dsr (ref. '7') Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF MANET Working Group Jorjeta G. Jetcheva 2 INTERNET-DRAFT Yih-Chun Hu 3 Carnegie Mellon University 4 David A. Maltz 5 AON Networks 6 David B. Johnson 7 Rice University 8 17 November 2000 10 A Simple Protocol for 11 Multicast and Broadcast in Mobile Ad Hoc Networks 13 15 Status of This Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC 2026 except that the right to 19 produce derivative works is not granted. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note 23 that other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The protocol specified in this document is designed to provide 40 multicast and broadcast functionality in mobile ad hoc networks. It 41 utilizes the Route Discovery mechanism defined by the Dynamic Source 42 Routing protocol (DSR) [4, 5, 7] to flood the data packets through 43 the network. Although this protocol is derived from DSR, it can be 44 implemented as a stand-alone protocol. In fact, it does not rely 45 on unicast routing to operate. If DSR is already implemented on 46 the network, very minor modifications are required to enable this 47 protocol. 49 This multicast and broadcast protocol utilizes controlled flooding to 50 distribute data in the network and does not require the establishment 51 of state in the network for data delivery. It is not intended as a 52 general purpose multicast protocol. Its applicability is mainly in 53 environments characterized by very high mobility or by a relatively 54 small number of nodes. In the former case, protocols relying on the 55 establishment of multicast state perform inadequately because they 56 are unable to track the rapid changes in topology. In the latter 57 case, the overhead of keeping multicast state exceeds the overhead of 58 flooding. 60 Contents 62 Status of This Memo i 64 Abstract ii 66 1. Introduction 1 68 2. Assumptions 2 70 3. Protocol Overview 3 71 3.1. Overview of DSR . . . . . . . . . . . . . . . . . . . . . 3 72 3.2. Overview of the Multicast and Broadcast Protocol . . . . 4 74 4. Detailed Operation 5 75 4.1. Originating a Packet . . . . . . . . . . . . . . . . . . 5 76 4.2. Originating a Route Request . . . . . . . . . . . . . . . 5 77 4.3. Processing a Received Route Request Option . . . . . . . 5 79 5. IANA Considerations 6 81 6. Security Considerations 7 83 Acknowledgments 8 85 References 9 87 Chair's Address 10 89 Authors' Addresses 11 90 1. Introduction 92 This document describes a protocol for multicast and broadcast 93 in wireless ad hoc networks. This protocol was developed by the 94 Monarch Project [6, 3] at Rice University and Carnegie Mellon 95 University. This protocol is not meant to be a general purpose 96 multicast protocol. It is applicable to small networks, or networks 97 characterized by very high mobility. 99 The definition of this protocol is derived from the Dynamic Source 100 Routing protocol (DSR) for unicast routing in wireless ad hoc 101 networks described in [4, 5, 7]. Even though this protocol uses some 102 mechanisms that are defined as part of DSR, it can be implemented 103 and used independently. In fact, this protocol does not require any 104 unicast functionality to operate. If DSR is employed as the unicast 105 routing protocol in an ad hoc network, adding this protocol to it 106 requires trivial modifications. 108 DSR is an on-demand routing protocol which allows nodes to 109 dynamically discover a source route across multiple network hops to 110 any destination in the ad hoc network. DSR employs two mechanisms 111 to enable unicast routing -- Route Discovery and Route Maintenance. 112 When a node wishes to communicate with another node, it employs 113 Route Discovery to flood a control packet, called a Route Request, 114 through the network, in search of a route to the destination of the 115 communication. The Route Maintenance mechanism monitors the status 116 of source routes in use, detects link-failures and repairs routes 117 with broken links. 119 Multicast and broadcast forwarding in this protocol is based on the 120 Route Discovery mechanism of DSR. Data packets are included in Route 121 Requests and are thereby flooded through the network. No multicast 122 state is setup in the network for data delivery. 124 This protocol is superior to protocols which require explicit 125 establishment of multicast state for data distribution in certain 126 types of networks. In small networks, this protocol requires less 127 overhead and provides the same level of functionality. In networks 128 with a very high degree of mobility, a stateful protocol may not be 129 able to track the rapidly changing topology and will only contribute 130 overhead. 132 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [2]. 136 2. Assumptions 138 We assume that all nodes wishing to communicate with other nodes 139 within the ad hoc network are willing to participate fully in the 140 protocols of the network. In particular, each node participating in 141 the network should also be willing to forward packets for other nodes 142 in the network. 144 Packets may be lost or corrupted in transmission on the wireless 145 network. A node receiving a corrupted packet can detect the error 146 and discard the packet. 148 3. Protocol Overview 150 3.1. Overview of DSR 152 DSR employs two mechanisms termed Route Discovery and Route 153 Maintenance. Route Discovery is the mechanism whereby a node S 154 wishing to send a packet to a destination D obtains a source route to 155 D. 157 Route Maintenance is the mechanism whereby S is able to detect, while 158 using a source route to D, if the network topology has changed such 159 that it can no longer use its route to D because a link along the 160 route no longer works. When Route Maintenance indicates a source 161 route is broken, S can attempt to use any other route it happens to 162 know to D, or can invoke Route Discovery again to find a new route. 164 When the application layer on S first starts sending data to a 165 destination D, the DSR layer buffers the data and initiates a Route 166 Discovery. A Route Request packet with a target of D is broadcast 167 in the network. It is forwarded hop-by-hop outward from the node 168 initiating the Route Discovery. When the Route Request reaches D or 169 a node N that has a route to D, it is not forwarded on. Instead, 170 a Route Reply packet is sent back to S. The Route Reply packet 171 includes a full source route to the destination D. This source 172 route is included in the source header of each data packet sent to 173 D and enables stateless forwarding by nodes in the network who can 174 determine whether they need to forward the packet by checking whether 175 they are listed on the source route in the data packet's header. 176 Data sent to D by the application layer, is buffered by DSR, until 177 a Route Reply with a route to D is received, at which point, these 178 packets are forwarded to D along the acquired route. 180 A Route Requests is forwarded by a node if the node (1) is not 181 already listed in the recorded source route in this copy of the 182 Request, and (2) has not recently seen another Route Request packet 183 belonging to this same Route Discovery. A node can determine if it 184 has recently seen such a Route Request, since each Route Request 185 packet contains a unique identifier for this Route Discovery, 186 generated by the initiator of the Discovery. Each node maintains an 187 LRU cache, called a Route Request Table, of the unique identifier 188 from each recently received Route Request. By not propagating any 189 copies of a Request after the first, the overhead of forwarding 190 additional copies that reach this node along different paths is 191 avoided. 193 In addition, the Time-to-Live field in the IP header of the packet 194 carrying the Route Request MAY be used to limit the scope over which 195 the Request will propagate, using the normal behavior of Time-to-Live 196 defined by IP [8, 1]. 198 3.2. Overview of the Multicast and Broadcast Protocol 200 When a node wants to send a broadcast packet, it uses the DSR Route 201 Discovery mechanism to propagate the packet in the network. This is 202 accomplished by including the data packet in a Route Request packet. 203 The Route Request is flooded through the ad hoc network using the 204 normal Route Discovery procedure described in Section 3.1, within the 205 specified TTL of the originator. 207 Multicast data packets are flooded through the network in the same 208 fashion. The target of the Route Request is the multicast group 209 address. Multicast group receivers make a copy of the data packet 210 included in the Route Request and pass it up the protocol stack, 211 before forwarding the Route Request onward. 213 4. Detailed Operation 215 4.1. Originating a Packet 217 When node A originates a packet, the following steps MUST be taken 218 before transmitting the packet: 220 If the destination address is a multicast or broadcast address, 221 piggyback the data packet on a Route Request packet targeting that 222 address. Route Request origination is described in Section 4.2. 224 4.2. Originating a Route Request 226 Route Discovery is the on-demand process by which nodes actively 227 obtain source routes to destinations to which they are actively 228 attempting to send packets. Route Discovery is initiated for each 229 multicast or broadcast packet by the originator of this packet as 230 described in Section 4.1. A Route Request is transmitted with the 231 multicast group or broadcast address as the "target" of the Route 232 Discovery. The Route Request initialization proceeds as described 233 in [7], except for the following condition: 235 Route Discoveries for a multicast or broadcast address SHOULD always 236 be permitted and SHOULD not be rate limited. 238 4.3. Processing a Received Route Request Option 240 Processing of a received Route Request option, proceeds as described 241 in [7], except for the following: 243 If node A is a member of the multicast group indicated by 244 Request.Target_Address, then create copy of the data packet 245 piggybacked in the Route Request and pass it up the protocol stack 246 before re-propagating the Route Request. 248 Non-duplicate Route Request packets with multicast or broadcast 249 target addresses MUST always be re-propagated. 251 The Route Cache SHOULD NOT be consulted on behalf of Route Requests 252 with multicast and broadcast targets. 254 5. IANA Considerations 256 This protocol does not define any new constants or packet types. It 257 does use, however, packet types and constants defined by [7] which 258 must be assigned by IANA. 260 6. Security Considerations 262 Security issues relevant to DSR [7] apply also to the protocol 263 described here. This protocol does not introduce any new security 264 considerations. 266 Acknowledgments 268 The protocol described in this draft has been designed within the 269 Monarch Project, a research project at Rice University and Carnegie 270 Mellon University which is developing adaptive networking protocols 271 and protocol interfaces to allow truly seamless wireless and mobile 272 node networking [6, 3]. 274 References 276 [1] Robert T. Braden, editor. Requirements for Internet 277 hosts---communication layers. RFC 1122, October 1989. 279 [2] Scott Bradner. Key words for use in RFCs to indicate requirement 280 levels. RFC 2119, March 1997. 282 [3] Carnegie Mellon University Monarch Project. CMU Monarch Project 283 Home Page. Available at http://www.monarch.cs.cmu.edu/. 285 [4] David B. Johnson. Routing in ad hoc networks of mobile hosts. 286 In Proceedings of the IEEE Workshop on Mobile Computing Systems 287 and Applications, pages 158--163, December 1994. 289 [5] David B. Johnson and David A. Maltz. Dynamic Source Routing in 290 ad hoc wireless networks. In Mobile Computing, edited by Tomasz 291 Imielinski and Hank Korth, chapter 5, pages 153--181. Kluwer 292 Academic Publishers, 1996. 294 [6] David B. Johnson and David A. Maltz. Protocols for adaptive 295 wireless and mobile networking. IEEE Personal Communications, 296 3(1):34--42, February 1996. 298 [7] David B. Johnson, David A. Maltz, Yih-Chun Hu, and Jorjeta 299 Jetcheva. The Dynamic Source Routing protocol for mobile ad hoc 300 networks. Internet-Draft, draft-ietf-manet-dsr-04.txt, November 301 2000. Work in progress. 303 [8] J. B. Postel, editor. Internet Protocol. RFC 791, September 304 1981. 306 Chair's Address 308 The Working Group can be contacted via its current chairs: 310 M. Scott Corson Phone: +1 301 405-6630 311 Institute for Systems Research Email: corson@isr.umd.edu 312 University of Maryland 313 College Park, MD 20742 314 USA 316 Joseph Macker Phone: +1 202 767-2001 317 Information Technology Division Email: macker@itd.nrl.navy.mil 318 Naval Research Laboratory 319 Washington, DC 20375 320 USA 322 Authors' Addresses 324 Questions about this document can also be directed to the authors: 326 Jorjeta Jetcheva Phone: +1 412 268-3053 327 Carnegie Mellon University Fax: +1 412 268-5576 328 Computer Science Department Email: jorjeta@cs.cmu.edu 329 5000 Forbes Avenue 330 Pittsburgh, PA 15213-3891 331 USA 333 Yih-Chun Hu Phone: +1 412 268-3075 334 Carnegie Mellon University Fax: +1 412 268-5576 335 Computer Science Department Email: yihchun@cs.cmu.edu 336 5000 Forbes Avenue 337 Pittsburgh, PA 15213-3891 338 USA 340 David A. Maltz Phone: +1 650 688-3128 341 AON Networks Fax: +1 650 688-3119 342 3045 Park Blvd. Email: dmaltz@cs.cmu.com 343 Palo Alto, CA 94306 344 USA 346 David B. Johnson Phone: +1 713 348-3063 347 Rice University Fax: +1 713 348-5930 348 Computer Science Department, MS 132 Email: dbj@cs.rice.edu 349 6100 Main Street 350 Houston, TX 77005-1892 351 USA