idnits 2.17.1 draft-ietf-manet-simple-mbcast-01.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 60 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 (20 July 2001) is 8309 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-05 ** 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. -------------------------------------------------------------------------------- 2 IETF MANET Working Group Jorjeta G. Jetcheva 3 INTERNET-DRAFT Yih-Chun Hu 4 Carnegie Mellon University 5 David A. Maltz 6 AON Networks 7 David B. Johnson 8 Rice University 9 20 July 2001 11 A Simple Protocol for 12 Multicast and Broadcast in Mobile Ad Hoc Networks 14 16 Status of This Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026 except that the right to 20 produce derivative works is not granted. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note 24 that other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at 29 any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 The protocol specified in this document is designed to provide 41 multicast and broadcast functionality in mobile ad hoc networks. It 42 utilizes the Route Discovery mechanism defined by the Dynamic Source 43 Routing protocol (DSR) [4, 5, 7] to flood the data packets through 44 the network. Although this protocol is derived from DSR, it can be 45 implemented as a stand-alone protocol. In fact, it does not rely 46 on unicast routing to operate. If DSR is already implemented on 47 the network, very minor modifications are required to enable this 48 protocol. 50 This multicast and broadcast protocol utilizes controlled flooding to 51 distribute data in the network and does not require the establishment 52 of state in the network for data delivery. It is not intended as a 53 general purpose multicast protocol. Its applicability is mainly in 54 environments characterized by very high mobility or by a relatively 55 small number of nodes. In the former case, protocols relying on the 56 establishment of multicast state perform inadequately because they 57 are unable to track the rapid changes in topology. In the latter 58 case, the overhead of keeping multicast state exceeds the overhead of 59 flooding. 61 Contents 63 Status of This Memo i 65 Abstract ii 67 1. Introduction 1 69 2. Assumptions 2 71 3. Protocol Overview 3 72 3.1. Overview of DSR . . . . . . . . . . . . . . . . . . . . . 3 73 3.2. Overview of the Multicast and Broadcast Protocol . . . . 4 75 4. Detailed Operation 5 76 4.1. Originating a Packet . . . . . . . . . . . . . . . . . . 5 77 4.2. Originating a Route Request . . . . . . . . . . . . . . . 5 78 4.3. Processing a Received Route Request Option . . . . . . . 5 80 5. IANA Considerations 6 82 6. Security Considerations 7 84 Acknowledgments 8 86 References 9 88 Chair's Address 10 90 Authors' Addresses 11 91 1. Introduction 93 This document describes a protocol for multicast and broadcast 94 in wireless ad hoc networks. This protocol was developed by the 95 Monarch Project [6, 3] at Rice University and Carnegie Mellon 96 University. This protocol is not meant to be a general purpose 97 multicast protocol. It is applicable to small networks, or networks 98 characterized by very high mobility. 100 The definition of this protocol is derived from the Dynamic Source 101 Routing protocol (DSR) for unicast routing in wireless ad hoc 102 networks described in [4, 5, 7]. Even though this protocol uses some 103 mechanisms that are defined as part of DSR, it can be implemented 104 and used independently. In fact, this protocol does not require any 105 unicast functionality to operate. If DSR is employed as the unicast 106 routing protocol in an ad hoc network, adding this protocol to it 107 requires trivial modifications. 109 DSR is an on-demand routing protocol which allows nodes to 110 dynamically discover a source route across multiple network hops to 111 any destination in the ad hoc network. DSR employs two mechanisms 112 to enable unicast routing -- Route Discovery and Route Maintenance. 113 When a node wishes to communicate with another node, it employs 114 Route Discovery to flood a control packet, called a Route Request, 115 through the network, in search of a route to the destination of the 116 communication. The Route Maintenance mechanism monitors the status 117 of source routes in use, detects link-failures and repairs routes 118 with broken links. 120 Multicast and broadcast forwarding in this protocol is based on the 121 Route Discovery mechanism of DSR. Data packets are included in Route 122 Requests and are thereby flooded through the network. No multicast 123 state is setup in the network for data delivery. 125 This protocol is superior to protocols which require explicit 126 establishment of multicast state for data distribution in certain 127 types of networks. In small networks, this protocol requires less 128 overhead and provides the same level of functionality. In networks 129 with a very high degree of mobility, a stateful protocol may not be 130 able to track the rapidly changing topology and will only contribute 131 overhead. 133 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [2]. 137 2. Assumptions 139 We assume that all nodes wishing to communicate with other nodes 140 within the ad hoc network are willing to participate fully in the 141 protocols of the network. In particular, each node participating in 142 the network should also be willing to forward packets for other nodes 143 in the network. 145 Packets may be lost or corrupted in transmission on the wireless 146 network. A node receiving a corrupted packet can detect the error 147 and discard the packet. 149 3. Protocol Overview 151 3.1. Overview of DSR 153 DSR employs two mechanisms termed Route Discovery and Route 154 Maintenance. Route Discovery is the mechanism whereby a node S 155 wishing to send a packet to a destination D obtains a source route to 156 D. 158 Route Maintenance is the mechanism whereby S is able to detect, while 159 using a source route to D, if the network topology has changed such 160 that it can no longer use its route to D because a link along the 161 route no longer works. When Route Maintenance indicates a source 162 route is broken, S can attempt to use any other route it happens to 163 know to D, or can invoke Route Discovery again to find a new route. 165 When the application layer on S first starts sending data to a 166 destination D, the DSR layer buffers the data and initiates a Route 167 Discovery. A Route Request packet with a target of D is broadcast 168 in the network. It is forwarded hop-by-hop outward from the node 169 initiating the Route Discovery. When the Route Request reaches D or 170 a node N that has a route to D, it is not forwarded on. Instead, 171 a Route Reply packet is sent back to S. The Route Reply packet 172 includes a full source route to the destination D. This source 173 route is included in the source header of each data packet sent to 174 D and enables stateless forwarding by nodes in the network who can 175 determine whether they need to forward the packet by checking whether 176 they are listed on the source route in the data packet's header. 177 Data sent to D by the application layer, is buffered by DSR, until 178 a Route Reply with a route to D is received, at which point, these 179 packets are forwarded to D along the acquired route. 181 A Route Requests is forwarded by a node if the node (1) is not 182 already listed in the recorded source route in this copy of the 183 Request, and (2) has not recently seen another Route Request packet 184 belonging to this same Route Discovery. A node can determine if it 185 has recently seen such a Route Request, since each Route Request 186 packet contains a unique identifier for this Route Discovery, 187 generated by the initiator of the Discovery. Each node maintains an 188 LRU cache, called a Route Request Table, of the unique identifier 189 from each recently received Route Request. By not propagating any 190 copies of a Request after the first, the overhead of forwarding 191 additional copies that reach this node along different paths is 192 avoided. 194 In addition, the Time-to-Live field in the IP header of the packet 195 carrying the Route Request MAY be used to limit the scope over which 196 the Request will propagate, using the normal behavior of Time-to-Live 197 defined by IP [8, 1]. 199 3.2. Overview of the Multicast and Broadcast Protocol 201 When a node wants to send a broadcast packet, it uses the DSR Route 202 Discovery mechanism to propagate the packet in the network. This is 203 accomplished by including the data packet in a Route Request packet. 204 The Route Request is flooded through the ad hoc network using the 205 normal Route Discovery procedure described in Section 3.1, within the 206 specified TTL of the originator. 208 Multicast data packets are flooded through the network in the same 209 fashion. The target of the Route Request is the multicast group 210 address. Multicast group receivers make a copy of the data packet 211 included in the Route Request and pass it up the protocol stack, 212 before forwarding the Route Request onward. 214 4. Detailed Operation 216 4.1. Originating a Packet 218 When node A originates a packet, the following steps MUST be taken 219 before transmitting the packet: 221 If the destination address is a multicast or broadcast address, 222 piggyback the data packet on a Route Request packet targeting that 223 address. Route Request origination is described in Section 4.2. 225 4.2. Originating a Route Request 227 Route Discovery is the on-demand process by which nodes actively 228 obtain source routes to destinations to which they are actively 229 attempting to send packets. Route Discovery is initiated for each 230 multicast or broadcast packet by the originator of this packet as 231 described in Section 4.1. A Route Request is transmitted with the 232 multicast group or broadcast address as the "target" of the Route 233 Discovery. The Route Request initialization proceeds as described 234 in [7], except for the following condition: 236 Route Discoveries for a multicast or broadcast address SHOULD always 237 be permitted and SHOULD not be rate limited. 239 4.3. Processing a Received Route Request Option 241 Processing of a received Route Request option, proceeds as described 242 in [7], except for the following: 244 If node A is a member of the multicast group indicated by 245 Request.Target_Address, then create copy of the data packet 246 piggybacked in the Route Request and pass it up the protocol stack 247 before re-propagating the Route Request. 249 Non-duplicate Route Request packets with multicast or broadcast 250 target addresses MUST always be re-propagated. 252 The Route Cache SHOULD NOT be consulted on behalf of Route Requests 253 with multicast and broadcast targets. 255 5. IANA Considerations 257 This protocol does not define any new constants or packet types. It 258 does use, however, packet types and constants defined by [7] which 259 must be assigned by IANA. 261 6. Security Considerations 263 Security issues relevant to DSR [7] apply also to the protocol 264 described here. This protocol does not introduce any new security 265 considerations. 267 Acknowledgments 269 The protocol described in this draft has been designed within the 270 Monarch Project, a research project at Rice University and Carnegie 271 Mellon University which is developing adaptive networking protocols 272 and protocol interfaces to allow truly seamless wireless and mobile 273 node networking [6, 3]. 275 References 277 [1] Robert T. Braden, editor. Requirements for Internet 278 hosts---communication layers. RFC 1122, October 1989. 280 [2] Scott Bradner. Key words for use in RFCs to indicate requirement 281 levels. RFC 2119, March 1997. 283 [3] Carnegie Mellon University Monarch Project. CMU Monarch Project 284 Home Page. Available at http://www.monarch.cs.cmu.edu/. 286 [4] David B. Johnson. Routing in ad hoc networks of mobile hosts. 287 In Proceedings of the IEEE Workshop on Mobile Computing Systems 288 and Applications, pages 158--163, December 1994. 290 [5] David B. Johnson and David A. Maltz. Dynamic Source Routing in 291 ad hoc wireless networks. In Mobile Computing, edited by Tomasz 292 Imielinski and Hank Korth, chapter 5, pages 153--181. Kluwer 293 Academic Publishers, 1996. 295 [6] David B. Johnson and David A. Maltz. Protocols for adaptive 296 wireless and mobile networking. IEEE Personal Communications, 297 3(1):34--42, February 1996. 299 [7] David B. Johnson, David A. Maltz, Yih-Chun Hu, and Jorjeta 300 Jetcheva. The Dynamic Source Routing protocol for mobile ad hoc 301 networks. Internet-Draft, draft-ietf-manet-dsr-05.txt, March 2 302 2001. Work in progress. 304 [8] J. B. Postel, editor. Internet Protocol. RFC 791, September 305 1981. 307 Chair's Address 309 The Working Group can be contacted via its current chairs: 311 M. Scott Corson Phone: +1 301 405-6630 312 Institute for Systems Research Email: corson@isr.umd.edu 313 University of Maryland 314 College Park, MD 20742 315 USA 317 Joseph Macker Phone: +1 202 767-2001 318 Information Technology Division Email: macker@itd.nrl.navy.mil 319 Naval Research Laboratory 320 Washington, DC 20375 321 USA 323 Authors' Addresses 325 Questions about this document can also be directed to the authors: 327 Jorjeta Jetcheva Phone: +1 412 268-3053 328 Carnegie Mellon University Fax: +1 412 268-5576 329 Computer Science Department Email: jorjeta@cs.cmu.edu 330 5000 Forbes Avenue 331 Pittsburgh, PA 15213-3891 332 USA 334 Yih-Chun Hu Phone: +1 412 268-3075 335 Carnegie Mellon University Fax: +1 412 268-5576 336 Computer Science Department Email: yihchun@cs.cmu.edu 337 5000 Forbes Avenue 338 Pittsburgh, PA 15213-3891 339 USA 341 David A. Maltz Phone: +1 650 688-3128 342 AON Networks Fax: +1 650 688-3119 343 3045 Park Blvd. Email: dmaltz@cs.cmu.com 344 Palo Alto, CA 94306 345 USA 347 David B. Johnson Phone: +1 713 348-3063 348 Rice University Fax: +1 713 348-5930 349 Computer Science Department, MS 132 Email: dbj@cs.rice.edu 350 6100 Main Street 351 Houston, TX 77005-1892 352 USA