Mobile Ad Hoc Networking Working Group Charles E. Perkins
INTERNET DRAFT Nokia Research Center
14 July 2000 Elizabeth M. Royer
University of California, Santa Barbara
Samir R. Das
University of Cincinnati
IP Broadcast in Ad hoc Mobile Networks
draft-perkins-manet-bcast-00.txt
Status of This Memo
This document is a submission by the Mobile Ad Hoc Networking Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the manet@itd.nrl.navy.mil mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
An ad hoc mobile network is a collection of nodes, each of which
communicates over wireless channels and is capable of movement.
Nodes participating in such an ad hoc network communicate on
a peer-to-peer basis. Broadcast is often a desired form of
communication in these networks, as it can enable both the
dissemination of control information and the delivery of data
packets. This document describes a method for providing broadcast
communication in ad hoc networks.
Perkins, Royer, Das Expires 14 January 2001 [Page i]
Internet Draft IP Broadcast in Ad hoc Networks 14 July 2000
1. Introduction
This document makes a particular specification for a classical
broadcast algorithm, as it can be used to disseminate IP packets
across ad hoc networks. Broadcast is needed in many circumstances;
in particular, it is useful for the kind of route discovery
operations that are required for on-demand route acquisition in
several candidate manet protocols.
This protocol specification works when the nodes sending broadcast
packets ensure that each distinct broadcast packet that they send is
tagged with a distinct value in the ident field of the IP header.
This document uses conventional meanings [1] for capitalized words
such as MUST, SHOULD, etc., to indicate requirement levels for
various protocol features.
2. Broadcast
When a node wishes to generate a broadcast, it sends the broadcast
packet to address 255.255.255.255. This document does not specify
transmissions to any directed broadcast address.
Every node maintains a list to keep track of which broadcast packets
have already been received and retransmitted. The list contains, for
each distinct broadcast packet received, the source IP address and
the IP ident value from the IP header of the broadcast packet.
When a node receives a packet broadcast to address 255.255.255.255,
it checks its list for the source IP address and the IP ident
value of the broadcast packet's IP header [2]. If there is such a
list entry with matching source IP address and IP ident field, the
node silently discards the broadcast packet since it has already
been received. The node then checks to see whether it is enabled
for retransmitting broadcast packets. By default, all nodes in
the ad hoc network are so enabled; however, this is not required
(see section 3). If the node is not enabled for retransmitting
broadcasts, it takes no further action. If there is no existing list
entry containing the same source IP address and IP ident value, and
if the node has been enabled to forward broadcast packets, the node
retransmits the broadcast packet.
List entries SHOULD be kept for at least BROADCAST_RECORD_TIME
before the node expunges the record. BROADCAST_RECORD_TIME
is a configurable parameter, but it MUST be at least equal to
NET_TRAVERSAL_TIME.
Perkins, Royer, Das Expires 14 January 2001 [Page 1]
Internet Draft IP Broadcast in Ad hoc Networks 14 July 2000
3. Selective Broadcast Retransmission
By default, each node in the ad hoc network is enabled to retransmit
each distinct broadcast packet that it receives. However, in some
cases, there may be additional control signaling in place that is
used to reduce the number of nodes that perform this retransmission,
in order to reduce the overall bandwidth consumption and congestion
which can be caused by excessive broadcast. This document does not
specify any such control protocol to disable or enable such node
selection. However, an ad hoc network which employs such a node
selection protocol can still be considered to be compliant with the
broadcast protocol specified in this document.
4. Configuration Parameters
This section gives default values for some important values
associated with broadcast operations. Mobile nodes in particular
ad hoc networks may wish to change certain of the parameters, in
particular the NET_DIAMETER and NODE_TRAVERSAL values. Choice
of these parameters may affect the robustness of the broadcast
operation.
Parameter Name Value
---------------------- -----
BROADCAST_RECORD_TIME 2 * NET_TRAVERSAL_TIME
NET_DIAMETER 35
NODE_TRAVERSAL_TIME 40
NET_TRAVERSAL_TIME 3 * NODE_TRAVERSAL_TIME * NET_DIAMETER / 2
NET_DIAMETER measures the maximum possible number of hops between
two nodes in the network. NODE_TRAVERSAL_TIME is a conservative
estimate of the average one hop traversal time for packets and should
include queuing delays, interrupt processing times and transfer
times. NET_TRAVERSAL_TIME is a conservative estimate of how long it
should take for a message to traverse the entire ad hoc network.
5. Security Considerations
This draft specifies a general mechanism for handling broadcast.
It does not make any provision for securing the contents of the
broadcast data, either to protect against tampering or to protect
against unauthorized inspection of the data.
Perkins, Royer, Das Expires 14 January 2001 [Page 2]
Internet Draft IP Broadcast in Ad hoc Networks 14 July 2000
6. IPv6 consideration
The method described in this draft for identifying broadcast packets,
using the Ident field in the IP header, does not work. A new packet
identification method will have to be developed.
7. Acknowledgments
This broadcast method is a codification of a well known algorithm
which has been assumed for general use in various ad hoc protocols.
Thus, the protocol specification in this draft should be considered
the joint work of many engineers who have worked on producing ad hoc
network protocols. The authors of this draft hope that we have been
able to faithfully and usefully represent the work of these many
engineers.
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] J. Postel. Internet Protocol. Request for Comments (Standard)
791, Internet Engineering Task Force, September 1981.
Author's Addresses
Questions about this memo can be directed to:
Charles E. Perkins
Communications Systems Laboratory / Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94303
+1 650 625 2986
+1 650 625-2502 (fax)
charliep@iprg.nokia.com
Elizabeth M. Royer
Dept. of Electrical and Computer Engineering
University of California, Santa Barbara
Santa Barbara, CA 93106
+1 805 893 7788
+1 805 893 3262 (fax)
eroyer@alpha.ece.ucsb.edu
Perkins, Royer, Das Expires 14 January 2001 [Page 3]
Internet Draft IP Broadcast in Ad hoc Networks 14 July 2000
Samir R. Das
Dept. of Electrical and Computer Engineering & Computer
Science
University of Cincinnati
Cincinnati, OH 45221-0030
+1 513 556 2594
+1 513 556 7326 (fax)
sdas@ececs.uc.edu
Perkins, Royer, Das Expires 14 January 2001 [Page 4]