idnits 2.17.1 draft-ietf-manet-bcast-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad Hoc Networking Working Group Charles E. Perkins 2 INTERNET DRAFT Nokia Research Center 3 14 November 2001 Elizabeth M. Belding-Royer 4 University of California, Santa Barbara 5 Samir R. Das 6 University of Cincinnati 8 IP Flooding in Ad hoc Mobile Networks 9 draft-ietf-manet-bcast-00.txt 11 Status of This Memo 13 This document is a submission by the Mobile Ad Hoc Networking Working 14 Group of the Internet Engineering Task Force (IETF). Comments should 15 be submitted to the manet@itd.nrl.navy.mil mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 33 http://www.ietf.org/shadow.html. 35 Abstract 37 An ad hoc mobile network is a collection of nodes, each of which 38 communicates over wireless channels and is capable of movement. 39 Nodes participating in such an ad hoc network communicate on 40 a peer-to-peer basis. Flooding is often a desired form of 41 communication in these networks, as it can enable both the 42 dissemination of control information and the delivery of data 43 packets. This document describes a method for sending packets to 44 every node in an d hoc networks. 46 1. Introduction 48 This document makes a particular specification for a classical 49 flooding algorithm, as it can be used to disseminate IP packets 50 across ad hoc networks. Flooding is needed in many circumstances; in 51 particular, it is useful for the kind of route discovery operations 52 that are required for on-demand route acquisition in several 53 candidate manet protocols. 55 This protocol specification works when the nodes flooding packets 56 ensure that each distinct such packet that they send is tagged with a 57 distinct value in the ident field of the IP header. 59 In IPv4, there are two kinds of broadcast address, and it seems 60 that neither one of them is likely to present a good choice for the 61 IP address to be used for flooding. The IPv4 address for "limited 62 broadcast" is 255.255.255.255, and is not supposed to be forwarded. 63 Since the nodes in an ad hoc network are asked to forward the flooded 64 packets, the limited broadcast address is a poor choice. The other 65 available choice, the "directed broadcast" address, would presume a 66 choice of routing prefix for the ad hoc network and thus is not a 67 reasonable choice. 69 Thus, in this specification, new multicast groups for flooding to all 70 nodes of an ad hoc network are specified. These multicast groups 71 are specified to contain all nodes of a contiguous ad hoc network, 72 so that packets transmitted to the multicast address associated with 73 the group will be delivered to all nodes as desired. For IPv6, 74 the multicast address is specified to be "site-local". The names 75 of the multicast groups are given as "ALL_IPv4_MANET_NODES" and 76 "ALL_IPv6_MANET_NODES". 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC 2119 [1]. 82 2. Flooding 84 For the purposes of this document, the IPv4 flooding address is 85 "ALL_IPv4_MANET_NODES" (TBD). The analogous address for transmissions 86 to all IPv6 ad hoc network nodes is "ALL_IPv6_MANET_NODES" (TBD). 87 This document does not specify transmissions to any directed 88 broadcast address. Transmissions to the IPv4 "limited broadcast" 89 address, that is 255.255.255.255, are not forwarded by nodes obeying 90 this specification. 92 Every node maintains a list to keep track of which flooded packets 93 have already been received and retransmitted. The list contains, for 94 each distinct flooded packet received, a value called the Flooded 95 Packet Identifier (FPI). For IPv4, this FPI is composed of the source 96 IP address, the IP ident value, and the fragment offset values 97 obtained from the IP header of the flooded packet. For IPv6, the FPI 98 is calculated as specified in section 3. 100 When a node receives a flooded packet, it checks its list for the 101 FPI of the flooded packet's IP header [2]. If there is such a list 102 entry with matching FPI, the node silently discards the flooded 103 packet since it has already been received and forwarded. The node 104 then checks to see whether it is enabled for retransmitting flooded 105 packets. By default, all nodes in the ad hoc network are so enabled; 106 however, this is not required (see section 5) and may be changed by 107 configuration. If the node is not enabled for retransmitting flooded 108 packets, it takes no further action. If there is no existing list 109 entry containing the same FPI, and if the node has been enabled to 110 forward flooded packets, the node retransmits the packet. 112 List entries SHOULD be kept for at least BROADCAST_RECORD_TIME 113 before the node expunges the record. BROADCAST_RECORD_TIME 114 is a configurable parameter, but it MUST be at least equal to 115 NET_TRAVERSAL_TIME. 117 3. FPI computation for IPv6 119 To obtain the FPI for IPv6 packets, a node uses MD5 [3] to perform 120 the following calculation for the incoming flooded packet: 122 FPI = MD5 (IPv6 packet data). 124 The IP packet data includes all non-mutable IPv6 headers and 125 extensions, as well as any higher-level protocol data. The source 126 node for each flooded packet MUST ensure that this FPI is distinct 127 from the FPI from every other flooded packet which the node has 128 transmitted during the last BROADCAST_RECORD_TIME. In the unlikely 129 event that the FPI value is identical to some such recently 130 transmitted packet, the source node MUST add a Unique Identifier 131 Destination Option to the flooded packet (see section 4). 133 4. Unique Identifier Destination Option 135 The Unique Identifier option is encoded in type-length-value (TLV) 136 format as follows: 138 0 1 2 3 139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Option Type | Option Length | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Uniquifying Value | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Option Type 148 TBD 150 Option Length 152 2 154 Uniquifying Value 156 The 16-bit Uniquifying Value is chosen to make the flooded 157 packet FPI computation different than that for any other 158 flooded packet from the same source node. 160 The Unique Identifier MUST be placed in the Destination Options 161 before the Routing Header (and, thus, before the fragment header). 162 This allows proper handling by all intermediate forwarding nodes 164 5. Selective Retransmission for Flooded Packets 166 By default, each node in the ad hoc network is enabled to retransmit 167 each distinct flooded packet that it receives. However, in some 168 cases, there may be additional control signaling in place that is 169 used to reduce the number of nodes that perform this retransmission, 170 in order to reduce the overall bandwidth consumption and congestion 171 which can be caused by excessive flooding. This document does not 172 specify any such control protocol to disable or enable such node 173 selection. However, an ad hoc network which employs such a node 174 selection protocol can still be considered to be compliant with the 175 flooding protocol specified in this document. 177 6. Configuration Parameters 179 This section gives default values for some important values 180 associated with flooding operations. Mobile nodes in particular 181 ad hoc networks may wish to change certain of the parameters, in 182 particular the NET_DIAMETER and NODE_TRAVERSAL values. Choice of 183 these parameters may affect the robustness of the flooding operation. 185 Parameter Name Value 186 ---------------------- ----- 187 BROADCAST_RECORD_TIME 2 * NET_TRAVERSAL_TIME 188 NET_DIAMETER 35 189 NODE_TRAVERSAL_TIME 40 milliseconds 190 NET_TRAVERSAL_TIME 3 * NODE_TRAVERSAL_TIME * NET_DIAMETER / 2 192 NET_DIAMETER measures the maximum possible number of hops between 193 two nodes in the network. NODE_TRAVERSAL_TIME is a conservative 194 estimate of the average one hop traversal time for packets and should 195 include queuing delays, interrupt processing times and transfer 196 times. NET_TRAVERSAL_TIME is a conservative estimate of how long it 197 should take for a message to traverse the entire ad hoc network. 199 7. Security Considerations 201 This draft specifies a general mechanism for flooding packets in an 202 ad hoc network. It does not make any provision for securing the 203 contents of the flooded data, either to protect against tampering or 204 to protect against unauthorized inspection of the data. 206 8. Acknowledgments 208 This flooding method is a codification of a well known algorithm 209 which has been assumed for general use in various ad hoc protocols. 210 Thus, the protocol specification in this draft should be considered 211 the joint work of many engineers who have worked on producing ad hoc 212 network protocols. The authors of this draft hope that we have been 213 able to faithfully and usefully represent the work of these many 214 engineers. 216 References 218 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 219 Levels. Request for Comments (Best Current Practice) 2119, 220 Internet Engineering Task Force, March 1997. 222 [2] J. Postel. Internet Protocol. Request for Comments (Standard) 223 791, Internet Engineering Task Force, September 1981. 225 [3] R. Rivest. The MD5 Message-Digest Algorithm. Request for 226 Comments (Informational) 1321, Internet Engineering Task Force, 227 April 1992. 229 A. Changes since the last revision 231 - Changed terminology from "broadcast" to "flood", to avoid 232 ambiguity with the various flavors of IPv4 broadcast. 234 - Specified a new IPv4 multicast address and a new IPv6 multicast 235 address. 237 Author's Addresses 239 Questions about this memo can be directed to: 241 Charles E. Perkins 242 Communications Systems Laboratory / Nokia Research Center 243 313 Fairchild Drive 244 Mountain View, CA 94303 245 +1 650 625 2986 246 +1 650 625-2502 (fax) 247 charliep@iprg.nokia.com 249 Elizabeth M. Royer 250 Dept. of Electrical and Computer Engineering 251 University of California, Santa Barbara 252 Santa Barbara, CA 93106 253 +1 805 893 7788 254 +1 805 893 3262 (fax) 255 eroyer@alpha.ece.ucsb.edu 257 Samir R. Das 258 Dept. of Electrical and Computer Engineering & Computer 259 Science 260 University of Cincinnati 261 Cincinnati, OH 45221-0030 262 +1 513 556 2594 263 +1 513 556 7326 (fax) 264 sdas@ececs.uc.edu