draft-ietf-manet-odmrp-00.txt   draft-ietf-manet-odmrp-01.txt 
IETF MANET Working Group Sung-Ju Lee
IETF MANET Working Group Mario Gerla INTERNET-DRAFT William Su
INTERNET-DRAFT Guangyu Pei Expiration: December 1999 Mario Gerla
Expiration: May 1999 Sung-Ju Lee
University of California, Los Angeles University of California, Los Angeles
Ching-Chuan Chiang June 1999
Chung-Cheng Institute of Technology
November 1998
On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks
<draft-ietf-manet-odmrp-00.txt> <draft-ietf-manet-odmrp-01.txt>
Status of This Memo Status of This Memo
This document is a submission to the Mobile Ad-hoc Networks (manet) This document is an Internet-Draft and is in full conformance with
Working Group of the Internet Engineering Task Force (IETF). all provisions of Section 10 of RFC2026. This document is a
Comments should be submitted to the Working Group mailing list at a submission to the Mobile Ad-hoc Networks (manet) Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the Working Group mailing list at
"manet@itd.nrl.navy.mil". Distribution of this memo is unlimited. "manet@itd.nrl.navy.mil". Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check The list of current Internet-Drafts can be accessed at
the "1id-abstracts.txt" listing contained in the Internet-Drafts http://www.ietf.org/ietf/1id-abstracts.txt
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or The list of Internet-Draft Shadow Directories can be accessed at
ftp.isi.edu (US West Coast). http://www.ietf.org/shadow.html.
Abstract Abstract
On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing
protocol designed for ad-hoc networks with mobile hosts. ODMRP is protocol designed for ad hoc networks with mobile hosts. ODMRP is
a mesh-based, rather than a conventional tree-based, multicast a mesh-based, rather than a conventional tree-based, multicast
scheme and uses a Forwarding Group concept (only a subset of nodes scheme and uses a forwarding group concept (only a subset of nodes
forwards the multicast packets via scoped flooding). It applies forwards the multicast packets via scoped flooding). It applies
on-demand procedures to dynamically set up routes and maintain on-demand procedures to dynamically build routes and maintain
multicast group membership. ODMRP is well suited for ad-hoc multicast group membership. ODMRP is well suited for ad hoc
wireless networks with mobile hosts where bandwidth is limited, wireless networks with mobile hosts where bandwidth is limited,
topology changes frequently and rapidly, and power is constrained. topology changes frequently and rapidly, and power is constrained.
Contents Contents
Status of This Memo 1 Status of This Memo 1
Abstract 1 Abstract 1
1. Introduction 3 1. Introduction 3
2. Terminology 4 2. Terminology 4
2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4 2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Specification Language . . . . . . . . . . . . . . . . . 5 2.2. Specification Language . . . . . . . . . . . . . . . . . 4
3. Protocol Overview 6 3. Protocol Overview 5
3.1. Group Establishment and Route Setup . . . . . . . . . . . 6 3.1. Group Establishment and Route Construction . . . . . . . 5
3.1.1. Mesh Creation . . . . . . . . . . . . . . . . . . 6 3.1.1. Mesh Creation . . . . . . . . . . . . . . . . . . 5
3.1.2. Joining the Group . . . . . . . . . . . . . . . . 7 3.1.2. Adapting the Refresh Interval via
3.1.3. Leaving the Group . . . . . . . . . . . . . . . . 8 Mobility Prediction . . . . . . . . . . . . . . . 7
3.1.4. Timers . . . . . . . . . . . . . . . . . . . . . 8 3.1.3. Soft State . . . . . . . . . . . . . . . . . . . 7
3.2. Contents of Tables . . . . . . . . . . . . . . . . . . . 9 3.2. Contents of Tables . . . . . . . . . . . . . . . . . . . 8
3.2.1. Member Table . . . . . . . . . . . . . . . . . . 9 3.2.1. Routing Table . . . . . . . . . . . . . . . . . . 8
3.2.2. Routing Table . . . . . . . . . . . . . . . . . . 9 3.2.2. Forwarding Group Table . . . . . . . . . . . . . 8
3.2.3. Message Cache . . . . . . . . . . . . . . . . . . 9 3.2.3. Message Cache . . . . . . . . . . . . . . . . . . 8
3.3. Relationship with Unicast Routing Protocols . . . . . . . 10 3.3. Unicast Routing Capability . . . . . . . . . . . . . . . 8
4. Packet and Table Formats 11 4. Packet and Table Formats 9
4.1. Join Request Packet . . . . . . . . . . . . . . . . . . 11 4.1. Join Data Packet Header . . . . . . . . . . . . . . . . 9
4.2. Join Table Packet . . . . . . . . . . . . . . . . . . . 12 4.2. Join Table Packet . . . . . . . . . . . . . . . . . . . 11
5. Operation 14 5. Operation 13
5.1. Forwarding Group Setup . . . . . . . . . . . . . . . . . 14 5.1. Forwarding Group Setup . . . . . . . . . . . . . . . . . 13
5.1.1. Originating a Join Request . . . . . . . . . . . 14 5.1.1. Originating a Join Data . . . . . . . . . . . . . 13
5.1.2. Processing a Join Request . . . . . . . . . . . . 14 5.1.2. Processing a Join Data . . . . . . . . . . . . . 13
5.1.3. Originating a Join Table . . . . . . . . . . . . 15 5.1.3. Processing a Join Data When GPS is Used . . . . . 14
5.1.4. Processing a Join Table . . . . . . . . . . . . . 15 5.1.4. Originating a Join Table . . . . . . . . . . . . 15
5.2. Multicast Data Packet Handling . . . . . . . . . . . . . 15 5.1.5. Processing a Join Table . . . . . . . . . . . . . 15
5.1.6. Processing a Join Table When GPS is Used . . . . 16
5.1.7. Passive Acknowledgments . . . . . . . . . . . . . 17
5.2. Handling a Multicast Data Packet . . . . . . . . . . . . 17
6. Configuration Parameters 16 6. Protocol Applicability 18
6.1. Networking Context . . . . . . . . . . . . . . . . . . . . . 18
6.2. Protocol Characteristics and Mechanisms . . . . . . . . . . 18
7. Protocol Applicability 17 Acknowledgments 20
7.1. Networking Context . . . . . . . . . . . . . . . . . . . . . 17
7.2. Protocol Characteristics and Mechanisms . . . . . . . . . . 17
References 19 References 20
Chair's Address 20 Chair's Address 21
Authors' Addresses 20 Authors' Addresses 22
1. Introduction 1. Introduction
This document describes the On-Demand Multicast Routing Protocol This document describes the On-Demand Multicast Routing Protocol
(ODMRP) developed by the Wireless Adaptive Mobility (WAM) Lab [11] (ODMRP) developed by the Wireless Adaptive Mobility (WAM) Lab [12]
at UCLA. ODMRP applies "on-demand" routing techniques to avoid at UCLA. ODMRP applies "on-demand" routing techniques to avoid
channel overhead and increase scalability. It uses the concept of channel overhead and improve scalability. It uses the concept of
"Forwarding Group," a set of nodes which is responsible for "forwarding group,"[3] a set of nodes responsible for forwarding
forwarding multicast data, to build a forwarding mesh for each multicast data, to build a forwarding mesh for each multicast group.
multicast group. By establishing a mesh, drawbacks of multicast By maintaining and using a mesh instead of a tree, the drawbacks of
trees in mobile wireless networks (e.g., intermittent connectivity, multicast trees in mobile wireless networks (e.g., intermittent
traffic concentration, frequent tree reconfiguration, non-shortest connectivity, traffic concentration, frequent tree reconfiguration,
path in a shared tree, etc.) are avoided. The forwarding group non-shortest path in a shared tree, etc.) are avoided. A soft-state
infrastructure reduces storage overhead and can handle a much approach is taken to maintain multicast group members. No explicit
looser connectivity among multicast members. The reduction of control message is required to leave the group. We believe the
channel/storage overhead and the relaxed connectivity make ODMRP reduction of channel/storage overhead and the relaxed connectivity
more scalable for large networks and more stable for mobile wireless make ODMRP more scalable for large networks and more stable for
networks. The following properties of ODMRP highlight its advantages mobile wireless networks.
as well as limitations.
The following properties of ODMRP highlight its advantages.
* Low channel and storage overhead * Low channel and storage overhead
* Usage of up-to-date and shortest routes * Usage of stable routes
* Robustness to host mobility * Robustness to host mobility
* Maintenance and exploitation of multiple, redundant paths * Maintenance and exploitation of multiple redundant paths
* Scalability to large number of nodes * Scalability to a large number of nodes
* Exploitation of the broadcast nature of wireless environments * Exploitation of the broadcast nature of wireless environments
* Independence from unicast routing protocols * Adaptivity to node movement patterns
* Ease of implementation
* Redundant forwarding due to mesh configuration
* Growth of transmitting table size when the number of group
members increases
The Forwarding Group Multicast Protocol (FGMP) was first introduced * Reconstruction of routes in anticipation of topology changes
in [4] using a conventional routing structure (i.e., DSDV [8]). An
extension of FGMP by incorporating on-demand scheme was proposed in
[3]. ODMRP improves upon its predecessors by exploiting sender
advertisement scheme which is more efficient than receiver
advertisement scheme in a typical multicast environment where more
receivers are present than multicast senders. Moreover, the sender
advertisement fits better with unicast on-demand routing protocols.
2. Terminology 2. Terminology
2.1. General Terms 2.1. General Terms
This section defines terminology used in ODMRP that is not already This section defines terminology used in ODMRP.
defined in [7].
node node
A device that implements IP. A device that implements IP.
neighbor neighbor
Nodes that are within the radio transmission range. Nodes that are within the radio transmission range.
forwarding group forwarding group
A group of nodes participating in multicast packet A group of nodes participating in multicast packet forwarding.
forwarding.
multicast mesh multicast mesh
The topology defined by the link connection between forwarding The topology defined by the link connection between forwarding
group members. group members.
join request join data
The packet sent by multicast sources to establish/update The special data packet sent by multicast sources to establish
group memberships and routes. and update group memberships and routes.
join table join table
The table broadcasted by each multicast receiver and forwarding The table broadcasted by each multicast receiver and forwarding
node to establish/update group memberships and routes node to establish and update group membership and routes
member table
The table maintained by multicast receivers containing
information of multicast sources for each multicast group it is
associated with.
routing table
Table maintained by each node containing route information
(e.g., next hop node) of existing active routes.
2.2. Specification Language 2.2. Specification Language
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Protocol Overview 3. Protocol Overview
3.1. Group Establishment and Route Setup 3.1. Group Establishment and Route Construction
3.1.1. Mesh Creation 3.1.1. Mesh Creation
In ODMRP, group membership and multicast routes are setup and In ODMRP, group membership and multicast routes are established and
updated by the source on demand. While a multicast source has updated by the source on demand. Similar to on-demand unicast
packets to send, it periodically floods a member advertising routing protocols, a request phase and a reply phase comprise the
packet. This packet, called a "Join Request" packet (format will protocol. When a multicast source has packets to send but no route
be shown in Section 4.1.), is broadcasted periodically as long as and group membership is known, it floods a control packet with data
the source has packets to send. This periodic transmission refreshes payload attached. This packet, called "Join Data" (format shown in
the membership information and updates the route in the face of Section 4.1) is periodically broadcasted to the entire network to
node movements. When a node receives a Join Request packet, it refresh the membership information and update the routes. When a
stores multicast group ID, source ID, and sequence number to its node receives a Join Data packet, it stores the source ID and the
"Message Cache" to detect duplicates. Previous node ID is stored as sequence number to its "Message Cache" to detect duplicates. The
well for a use which will be described later. If the Join Request upstream node ID is inserted or updated as the next node for the
packet is not a duplicate and the hop count does not exceed the source node in its "Routing Table." If the Join Data packet is not
Time-To-Live value, it is relayed. a duplicate and the Time-To-Live value is greater than zero,
appropriate fields are updated and it is rebroadcasted (operation
details are explained in Section 5.1.2).
When the Join Request packet reaches a multicast receiver, the When a Join Data packet reaches the multicast receiver, it creates
receiving node creates or updates the source entry in its Member and broadcasts a "Join Table" to its neighbors. When a node receives
Table, whose format will be shown in Section 3.2.1. Expired entries a Join Table, it checks if the next node ID of one of the entries
are deleted from the member table. A multicast receiver also sends matches its own ID. If it does, the node realizes that it is on the
periodic control packets. Namely, from its "Member Table," it builds path to the source and thus is part of the forwarding group;
a "Join Table" and sends it to its neighbors. Section 4.2 will show it sets the FG_FLAG. It then broadcasts its own Join Table built
the format of the Join Table. When a node receives a Join Table, it
checks if the next node ID of one of the entries matches its own ID.
If it does, the node realizes that it is on the path to the source
and thus is part of the forwarding group; it sets the
FORWARDING_GROUP_FLAG. It then broadcasts its own Join Table built
upon matched entries. The next node ID field is filled in by upon matched entries. The next node ID field is filled in by
extracting the information from its Member Cache of received Join extracting the information from its routing table. This way, the
Request packets. Namely, the next node ID is set to the previous Join Table is propagated by each forward group member until it
node ID field of the Join Request that matches multicast group ID reaches the multicast source via the selected path. This process
and sender ID of the Join Table just received. This way, the Join constructs (or updates) the routes from sources to receivers and
Table is propagated by each forward group member until it builds a mesh of nodes, the forwarding group.
reaches the multicast source via the shortest delay path. This
process sets up (or updates) the route from source to each receiver
and builds a mesh of nodes, the forwarding group.
+--+ +--+ +--+ +--+ +--+ +--+
|S1|-------|I1|-------|R1| |S1|-------|I1|-------|R1|
+--+\ +--+ /+--+ Join Table of Node R1 and Node I1 +--+\ +--+ /+--+ Join Table of Node R1 and Node I1
\ / +----------------+ +----------------+ \ / +----------------+ +----------------+
\ / |Sender|Next Node| |Sender|Next Node| \ / |Sender|Next Node| |Sender|Next Node|
\ / |------+---------| |------+---------| \ / |------+---------| |------+---------|
\ / | S1 | I1 | | S1 | S1 | \ / | S1 | I1 | | S1 | S1 |
\ / |------+---------| +----------------+ \ / |------+---------| +----------------+
+--+ \+--+/ +--+ | S2 | I2 | +--+ \+--+/ +--+ | S2 | I2 |
|S2|-------|I2|-------|R2| +----------------+ |S2|-------|I2|-------|R2| +----------------+
+--+ +--+ +--+ +--+ +--+ +--+
Let us consider the above figure as an example of Join Table Let us consider the above figure as an example of Join Table
forwarding process. Nodes S1 and S2 are multicast sources, and nodes forwarding process. Nodes S1 and S2 are multicast sources, and nodes
R1 and R2 are multicast receivers. Node R2 sends its Join Table to R1 and R2 are multicast receivers. Node R2 sends its Join Table to
both S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to both S1 and S2 via I2, and R1 sends its packet to S1 via I1 and to
S2 via I2. When receivers send their Join Tables to next hop nodes, S2 via I2. When receivers send their Join Tables to next hop nodes,
an intermediate node I1 sets the FORWARDING_GROUP_FLAG and builds an intermediate node I1 sets the FG_FLAG and builds its own Join
its own Join Table since there is a next node ID entry in the Table since there is a next node ID entry in the Join Table received
received Join Table that matches its ID. Note that I1 has an entry from R1 that matches its ID. Note that the Join Table build by I1
for sender S1 but not for S2 because the next node ID for S2 in the has an entry for sender S1 but not for S2 because the next node ID
join table received from R1 is not I1. In the meanwhile, node I2 for S2 in the received Join table is not I1. In the meanwhile, node
sets the FORWARDING_GROUP_FLAG, constructs its own Join Table and I2 sets the FG_FLAG, constructs its own Join Table and sends it to
sends it to its neighbors. Note that I2 broadcasts the join table its neighbors. Note that I2 broadcasts the join table only once even
only once even though it receives two Join Tables from the though it receives two Join Tables from the receivers because the
receivers. This is because the second table arrival carries no new second table arrival carries no new source information. Channel
source information. Channel overhead is thus reduced dramatically in overhead is thus reduced dramatically in cases where numerous
cases where numerous multicast receivers share the same links to the multicast receivers share the same links to the source.
source.
After this group establishment and route setup process, a multicast
source can transmit packets to receivers via selected routes and
forwarding groups. The periodic control packets are sent as long as
data packets to send are still present. When receiving the multicast
data packet, a node forwards it only when it is not a duplicate and
the setting of FORWARDING_GROUP_FLAG has not expired. This procedure
minimizes the traffic overhead and prevents sending packets through
stale routes.
3.1.2. Joining the Group
If a node wants to join a particular multicast group as a source,
it simply sends the Join Request packet when it has data packets to
send. Thereafter, this packet is periodically sent as long as the
node has data to multicast.
If a node wants to join a particular multicast group as a receiver,
it needs to send Join Table to its neighbors periodically as well as
every time its Member Table is modified/updated.
3.1.3. Leaving the Group
No explicit control packet needs to be sent to leave the group. If a
multicast source wants to leave the group, it simply stops sending
any Join Request packet since it doesn't have any multicast data to
send to the group.
If a receiver no longer wants to receive from a particular multicast
group, it removes the corresponding entries from its Member Table
and does not forward the Join Table for that group.
3.1.4. Timers
ODMRP uses a soft state approach for maintaining routes and
multicast/forwarding group members. The refresh and timeout
intervals used in ODMRP are defined as follows:
RTE_TIMEOUT
Timeout interval for Routing Table entries (RTE).
MEM_REFRESH
Refresh period of transmitting Join Request by a source when it
has data packets to send.
MEM_TIMEOUT After this group establishment and route construction process, a
source can multicast packets to receivers via selected routes and
forwarding groups. While outgoing data packets exist, the source
sends Join Data every REFRESH_INTERVAL. This Join Data and Join
Table propagation process refreshes forwarding group and routes.
When receiving the multicast data packet, a node forwards it only
when it is not a duplicate and the setting of the FG_FLAG for the
multicast group has not expired. This procedure minimizes the
traffic overhead and prevents sending packets through stale routes.
Timeout interval of Member Table entries. 3.1.2 Adapting the Refresh Interval via Mobility Prediction
JT_REFRESH ODMRP requires periodic flooding of Join Data} to build and refresh
routes. Excessive flooding, however, is not desirable in ad hoc
networks because of bandwidth constraints. Furthermore, flooding
often causes congestion, contention, and collisions. Finding the
optimal flooding interval is critical in ODMRP performance. In
highly mobile networks where nodes are equipped with GPS [9] (e.g.,
tactical netwoks with tanks, ships, aircrafts, etc.), we can
efficiently adapt the REFRESH_INTERVAL to mobility patterns and
speeds by utilizing the location and movement information. Note
that ODMRP can still operate efficiently in networks where no such
information is available, but the protocol can be further improved
if those information can be utilized.
Refresh period of sending Join Tables when there are entries in We use the location and movement information to predict the duration
Member Table. of time routes will remain valid (the detail of the process is
explained in 5.1.3). With the predicted time of route disconnection,
Join Data are only flooded when route breaks of ongoing data
sessions are imminent.
FG_TIMEOUT A different route selection method is applied when we use the
mobility prediction. The idea is inspired by the Associativity-Based
Routing (ABR) protocol [11] which chooses associatively stable
routes. In our algorithm, instead of using the minimum delay path,
we can choose a route that is the most stable (i.e., the one that
will remain connected for the longest duration of time). To select
a route, a multicast receiver must wait for an appropriate amount of
time after receiving the first Join Data so that all possible routes
and their route qualities will be known. The receiver then chooses
the most stable route and broadcasts a Join Table. Route breaks will
occur less often and the number of Join Data propagation will reduce
because stable routes are used.
Timeout interval of FORWARDING_GROUP_FLAG by each forwarding 3.1.3. Soft State
group members.
Sender advertising packets (Join Requests) are issued by source In ODMRP, no explicit control packets need to be sent to leave the
members every MEM_REFRESH interval when there are data packets to group. If a multicast source wants to leave the group, it simply
send; entries in the Member Table which have not been refreshed stops sending any Join Data packets since it does not have any
(did not receive Join Request before MEM_TIMEOUT) are removed. multicast data to send to the group. If a receiver no longer wants
Entries in routing table are deleted if the routes are not used in to receive from a particular multicast group, it does not send the
RTE_TIMEOUT period. Join Tables are issued every JT_REFRESH when Join Table for that group. Nodes in the forwarding group are demoted
valid entries exist in the Member Table. Any update of the member to non-forwarding nodes if not refreshed (no Join Tables received)
table triggers the transmission of a Join Table as well. If before they timeout.
forwarding nodes are not refreshed (by receiving Join Tables)
within FG_TIMEOUT, they are demoted to non-forwarding nodes. These
parameters MUST be set to proper values in order to adapt to a
rapidly changing topology.
3.2. Contents of Tables 3.2. Contents of Tables
Nodes running ODMRP are required to maintain the following tables. Nodes running ODMRP are required to maintain the following tables.
These tables MAY be implemented in any format, but MUST include the These tables MAY be implemented in any format, but MUST include the
fields specified in this document. fields specified in this document.
3.2.1. Member Table 3.2.1. Routing Table
Member table needs to be maintained by multicast receivers. For
each multicast group they are participating, they should store
multicast source IP address and the timestamp value to detect the
expired source. If no Join Request is received from a source in the
Member Table within MEM_TIMEOUT, it is removed from the Member
Table.
3.2.2. Routing Table
A routing table is created on demand and is maintained by each node. A routing table is created on demand and is maintained by each node.
There is no specific routing table format required by ODMRP. An entry is inserted or updated when a non-duplicate Join Data is
However, the routing table MUST include the next hop address for received. The node stores the destination (i.e., the source of the
each destination maintained in the routing table. Join Data) and the next hop to the destination (i.e., the last node
that propagated the Join Data). The routing table provides the next
3.2.3. Message Cache hop information when transmitting Join Tables.
Message Cache is maintained by each node to detect duplicates and to
provide next hop information of routes. When a node receives a new
Join Request, it MUST insert the following information to the
Message Cache:
* Multicast Group ID 3.2.2. Forwarding Group Table
* Source Address When a node is a forwarding group node of the multicast group, it
maintains the group information in the forwarding group table. The
multicast group ID and the time when the node was last refreshed are
recorded.
* Sequence Number 3.2.3. Message Cache
* Previous Hop Address The message cache is maintained by each node to detect duplicates.
When a node receives a new Join Data or data, it stores the source
address and the sequence number of the packet. Note that entries in
the message cache need not be maintained permanently. Schemes such
as LRU (Least Recently Used) or FIFO (First In First Out) can be
employed to expire and remove old entries and prevent the size of
the message cache to be extensive.
3.3. Relationship with Unicast Routing Protocols 3.3. Unicast Routing Capability
ODMRP can coexist with any unicast routing protocol since it finds One of the major strengths of ODMRP is its unicast routing
its own routes independently. From the point of view of scalability capability. Not only ODMRP can work with any unicast routing
and mobility support, it makes most sense to use ODMRP in protocol, it can function as both multicast and unicast. Thus, ODMRP
conjunction with on-demand unicast routing protocols such as can run without any underlying unicast protocol. Other ad hoc
DSR [2], ZRP [5], TORA [6], AODV [9], and ABR [10]. If, on the other multicast routing protocols such as AMRoute [2], CAMP [5], RBM [4],
hand, a conventional table driven unicast routing protocol is used, and LAM [7] must be run on top of a unicast routing protocol. CAMP,
then, a conventional, tree based multicast protocol may be adequate. RBM, and LAM in particular, only work on top of certain underlying
unicast protocols.
4. Packet and Table Formats 4. Packet and Table Formats
4.1. Join Request Packet 4.1. Join Data Packet Header
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Reserved | Time To Live | Hop Count | | Type | Reserved | Time To Live | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group IP Address | | Multicast Group IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address | | Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Hop IP Address | | Previous Hop IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Hop X Coordinate |
Ver +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Hop Y Coordinate |
ODMRP version number. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Hop Moving Speed | Previous Hop Moving Direction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Link Expiration Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
01; ODMRP source Join Request. 01; ODMRP Join Data.
Reserved Reserved
Sent as 0; ignored on reception. Sent as 0; ignored on reception.
Time To Live Time To Live
Maximum number of hops this packet can traverse. Number of hops this packet can traverse.
Hop Count Hop Count
The number of hops traveled so far by this packet. The number of hops traveled so far by this packet.
Multicast Group IP Address Multicast Group IP Address
The IP address of the multicast group. The IP address of the multicast group.
Sequence Number Sequence Number
skipping to change at page 12, line 13 skipping to change at page 10, line 18
identify the packet. identify the packet.
Source IP Address Source IP Address
The IP address of the node originating the packet. The IP address of the node originating the packet.
Previous Hop IP Address Previous Hop IP Address
The IP address of the last node that has processed this packet. The IP address of the last node that has processed this packet.
Previous Hop X Coordinate (Optional)
The x-coordinate of the last node that has processed this
packet. The information can be obtained from the GPS. This
field is required only when network hosts are GPS equipped.
Previous Hop Y Coordinate (Optional)
The y-coordinate of the last node that has processed this
packet. The information can be obtained from the GPS. This
field is required only when network hosts are GPS equipped..
Previous Hop Moving Speed (Optional)
The mobility speed of the last node that has processed this
packet. The information can be obtained from the GPS or the
node's own instruments and sensors (e.g., campus, odometer,
speed sensors, etc.). This field is required only when network
hosts are GPS equipped.
Previous Hop Moving Direction (Optional)
The moving direction of the last node that has processed this
packet. The information can be obtained from the GPS or the
node's own instruments and sensors (e.g., campus, odometer,
speed sensors, etc.). This field is required only when network
hosts are GPS equipped.
Minimum Link Expiration Time (Optional)
The minimum expiration time among the links taken by this
packet so far. This field is required only when network hosts
are GPS equipped.
4.2. Join Table Packet 4.2. Join Table Packet
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Count | Reserved | | Type | Count |R|F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Group IP Address | | Multicast Group IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous Hop IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender IP Address [1] | | Sender IP Address [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address [1] | | Next Hop IP Address [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Expiration Time [1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : | | : |
| : | | : |
| : | | : |
| : | | : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender IP Address [n] | | Sender IP Address [n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop IP Address [n] | | Next Hop IP Address [n] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Expiration Time [n] |
Ver +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ODMRP version number.
Type Type
02; ODMRP receiver Join Table. 02; ODMRP receiver Join Table.
Count Count
Number of (Sender IP Address, Next Hop IP Address) Number of (Sender IP Address, Next Hop IP Address)
combinations. combinations.
R
Acknowledgment request flag. This flag is set when active
acknowledgment packet is requested.
F
Forwarding group flag. This flag is set when the packet is
transmitted by a forwarding group node.
Reserved Reserved
Sent as 0; ignored on reception. Sent as 0; ignored on reception.
Multicast Group IP address Multicast Group IP address
The IP address of the multicast group. The IP address of the multicast group.
Previous Hop IP Address
The IP address of the last node that has processed this packet.
Sequence Number
The sequence number assigned by the previous hop node to
uniquely identify the packet.
Sender IP Address [1..n] Sender IP Address [1..n]
The IP addresses of the sources of this multicast group. The IP addresses of the sources of this multicast group.
Next Hop IP Address [1..n] Next Hop IP Address [1..n]
The IP addresses of next nodes that this packet is target to. The IP addresses of next nodes that this packet is target to.
Route Expiration Time [1..n] (Optional)
The minimum route expiration times of this multicast group.
This field is required only when network hosts are GPS equipped.
5. Operation 5. Operation
5.1. Forwarding Group Setup 5.1. Forwarding Group Setup
5.1.1. Originating a Join Request 5.1.1. Originating a Join Data
When a multicast source has data packets to send, it periodically When a multicast source has data packets to send but no route is
originates "Join Request" packets every MEM_REFRESH interval. The known, it originates a "Join Data" packet. The Type field MUST be
Type field MUST be set to 01. TTL MAY be set to TIME_TO_LIVE_VALUE, set to 01. TTL MAY be set to TIME_TO_LIVE_VALUE, but SHOULD be
but SHOULD be adjusted based on network size and network diameter. adjusted based on network size and network diameter. The Sequence
Sequence number MUST be large enough to prevent wraparound number MUST be large enough to prevent wraparound ambiguity, and the
ambiguity, and Hop Count is initially set to zero. The source puts Hop Count is initially set to zero. The source puts its IP address
its IP address in the Source IP Address and Last Hop IP Address in the Source IP Address and Last Hop IP Address field. It appends
field. Note that Join Request packet is not sent when a source does its location, speed, and direction into JOIN DATA.
not have any multicast packets to send.
5.1.2. Processing a Join Request When location and movement information is utilized, it sets the
MIN_LET (Link Expiration Time) field to the MAX_LET_VALUE since the
source does not have any previous hop node. When the source receives
Join Tables from multicast receivers, it selects the minimum RET
(Route Expiration Time) among all the Join Tables received. Then the
source can build new routes by originating a Join Data before the
minimum RET approaches (i.e., route breaks of ongoing data sessions
are imminent).
When a node receives a Join Request packet: 5.1.2. Processing a Join Data
When a node receives a Join Data packet:
1. Check if it is a duplicate by comparing the (Source IP Address, 1. Check if it is a duplicate by comparing the (Source IP Address,
Sequence Number) combination with the entries in Message Cache. Sequence Number) combination with the entries in message cache.
If duplicate, then discard the packet. DONE. If duplicate, then discard the packet. DONE.
2. If it is not a duplicate, insert an entry into Message Cache 2. If it is not a duplicate, insert an entry into message cache with
with the information of the received packet (i.e., Multicast the information of the received packet (i.e., sequence number and
Group IP Address, Sequence Number, Source IP Address, and source IP address) and insert/update the entry for routing table
Previous Hop IP Address). (i.e., backward learning).
3. If the node is a receiver member of the multicast group, then 3. If the node is a member of the multicast group, it originates a
insert/update the information into the Member Table and Join Table packet with the RET value enclosed (see Section 5.1.4).
originate a Join Table packet (see Section 5.1.3.).
4. Increase the Hop Count field by 1. 4. Increase the Hop Count field by 1 and decrease the TTL field by 1.
5. If the Hop Count field value is equal to or larger than TTL, 5. If the TTL field value is less than or equal to 0, then discard
then discard the packet. DONE. the packet. DONE.
6. If the Hop Count field value is less than TTL, then set the 6. If the TTL field value is greater than 0, then set the node's IP
node's IP Address into Last Hop IP Address field and broadcast. Address into Last Hop IP Address field and broadcast. DONE.
DONE.
5.1.3. Originating a Join Table 5.1.3. Processing a Join Data When GPS is Used
A multicast receiver broadcasts a "Join Table" packet every When a node receives a Join Data packet:
JT_REFRESH as long as there are any entries in its Member Table.
The transmission of Join Table is also triggered by the update of
its Member Table. Each Sender IP Address and Next Hop IP Address
pairs of a multicast group are contained in the Join Table packet.
Next Hop IP Address information can be obtained from the Message
Cache entries(Last Hop IP Address field of the Join Request
packet).
5.1.4. Processing a Join Table 1. Check if it is a duplicate by comparing the (Source IP Address,
Sequence Number) combination with the entries in message cache.
If duplicate, then discard the packet. DONE.
2. If it is not a duplicate, insert an entry into message cache with
the information of the received packet (i.e., sequence number and
source IP address) and insert/update the entry for routing table
(i.e., backward learning).
3. Predict the duration of time the link between the node and the
upstream node will remain connected using the following equation.
Assume node i is the upstream node and node j is the current node.
Let (x_{i}, y_{i}) be the coordinate of node i and (x_{j}, y_{j})
be that of node j. Also let v_{i} and v_{j} be the speeds, and
theta_{i} and theta_{j} be the moving directions of nodes i and j,
respectively. The information of node i (the previous hop node)
can be obtained from the Join Data and the current node's
location and mobility information can be provided by the GPS. The
duration of time that the link between two nodes will stay
connected, D_{t}, is given by:
-(a*b + c*d) + sqrt((a^{2} + c^{2})*r^{2} - (a*d - b*c)^{2})
D_{t} = ------------------------------------------------------------
a^{2} + c^{2}
where
a = v_{i}*cos(theta_{i}) - v_{j}*cos(theta_{j}),
b = x_{i} - x_{j},
c = v_{i}*sin(theta_{i}) - v_{j}*sin(theta_{j}), and
d = y_{i} - y_{j}.
Note that when v_{i} = v_{j} and theta_{i} = theta_{j}, D_{t} is
set to infinity without applying the above equation.
The minimum between this D_{t} value and the indicated value in
MIN_LET field of the Join Data is included in the packet. The
rationale is that as soon as a single link on the path is
disconnected, the entire path is invalidated. The node also
overwrites the location and mobility information field written
by the previous node with its own information.
4. If the node is a member of the multicast group, it calculates the
predicted LET of the last link of the path. The minimum between
the last link expiration time and the MIN_LET value specified in
the Join Data is the RET (Route Expiration Time).
To select a route, a multicast receiver must wait for an
appropriate amount of time after receiving the first Join Data
so that all possible routes and their RET will be known. The
receiver then chooses the most stable route (i.e., the route with
the largest RET) and originates a Join Table packet with the RET
value enclosed (see Section 5.1.3.).
5. Increase the Hop Count field by 1 and decrease the TTL field by 1.
6. If the TTL field value is less than or equal to 0, then discard
the packet. DONE.
7. If the TTL field value is greater than 0, then set the node's IP
Address into Last Hop IP Address field and broadcast. DONE.
5.1.4. Originating a Join Table
A multicast receiver transmits a "Join Table" packet after selecting
the multicast route. Each sender IP address and next hop IP address
of a multicast group are contained in the Join Table packet. The
route expiration time is also included if the network hosts operate
with GPS.
5.1.5. Processing a Join Table
When a Join Table is received: When a Join Table is received:
1. The node looks up the Next Hop IP Address field of the received 1. The node looks up the Next Hop IP Address field of the received
Join Table entries. If no entries match the node's IP Address, Join Table entries. If no entries match the node's IP Address, do
do nothing. DONE. nothing. DONE.
2. If one or more entries coincide with the node's IP Address, set 2. If one or more entries coincide with the node's IP Address, set
the FORWARDING_GROUP_FLAG and build its own Join Table. Next Hop the FG_FLAG and build its own Join Table. The next hop IP address
IP Address information can be obtained from the Join Cache can be obtained from the routing table.
entries (Last Hop IP Address field of the Join Request packet).
3. Broadcast the Join Table packet. 3. Broadcast the Join Table packet to the neighbor nodes. DONE.
5.2. Multicast Data Packet Handling 5.1.6. Processing a Join Table When GPS is Used
Multicast sources broadcast the Data whenever they have packets When a Join Table is received:
to send. Nodes relay data packets only if the packet is not a
duplicate and the FORWARDING_GROUP_FLAG has not expired.
6. Configuration Parameters 1. The node looks up the Next Hop IP Address field of the received
Join Table entries. If no entries match the node's IP Address, do
nothing. DONE.
This section specifies default values associated with ODMRP 2. If one or more entries coincide with the node's IP Address, set
operation. Note that some of the values SHOULD be adjusted to nodes' the FG_FLAG and build its own Join Table. If multiple Join Tables
mobility speed and network size. with different RET values are received (i.e., the node lies in
paths from the same source to multiple receivers), it selects the
minimum RET among them and attaches the chosen RET value. Next
hop IP address can be obtained from the routing table.
FG_TIMEOUT 480 milliseconds 3. Broadcast the Join Table packet to the neighbor nodes.
JT_REFRESH 160 milliseconds 4. If the node is a source, it selects the minimum RET among all the
Join Tables received. Then the source can build new routes by
flooding a Join Data before the minimum RET approaches (i.e.,
route breaks of ongoing data sessions are imminent).
MEM_REFRESH 400 milliseconds In addition to the estimated RET value, other factors need to be
considered when choosing the refresh interval of Join Data. If
the node mobility rate is high and the topology changes
frequently, routes will expire quickly and often. The source may
propagate Join Requests excessively and this excessive flooding
can cause collisions, congestion, and clogs the network with
control packets. Thus, the MIN_REFRESH_INTERVAL should be
enforced to avoid control message overflow. On the other hand, if
nodes are stationary or move slowly and link connectivity remains
unchanged for a long duration of time, routes will hardly expire
and the source will rarely send Join Data. A few problems arise
in this situation. First, if a node in the route suddenly changes
its movement direction or speed, the predicted RET value becomes
obsolete and routes will not be reconstructed. Second, when a
non-member node which is located remotely to multicast members
wants to join the group, it cannot inform the new membership or
receive data until a Join Data is received. Hence, the
MAX_REFRESH_INTERVAL should be set. The selection of the
MIN_REFRESH_INTERVAL and the MAX_REFRESH_INTERVAL should be
adaptive to network situations (e.g., traffic type, traffic load,
mobility pattern, channel capacity, etc.).
MEM_TIMEOUT 960 milliseconds 5.1.7. Passive Acknowledgments
RTE_TIMEOUT 960 milliseconds The reliable transmission of Join Tables plays an important role
in establishing and refreshing multicast routes and forwarding
groups. Hence, if Join Tables are not properly delivered,
effective multicast routing cannot be achieved by ODMRP. The
IEEE 802.11 MAC protocol [6], which is the standard in wireless
networks, performs reliable transmission by retransmitting the
packet if no acknowledgment is received. However, if the packet
is broadcasted, the acknowledgments and retransmissions are not
sent. In ODMRP, the transmission of Join Tables are mostly
broadcasted. Thus, the verification of Join Table delivery and
the retransmissions must be done by the ODMRP layer.
RT_DISCV_TIMEOUT 30 seconds We adopt a scheme that was used in [8]. When a node transmits a
Join Table packet to the immediate upstream node of the route,
the immediate downstream node can hear the transmission if it is
within the transmitter's radio range. Hence, the packet is used
as an "passive acknowledgment." We can utilize this passive
acknowledgments to verify the delivery of Join Tables. Multicast
sources must send active acknowledgments to the previous hops
since they do not have any next hops to send Join Tables to
unless they are forwarding group nodes. When no acknowledgment is
received within the timeout interval, the node retransmits the
message. If packet delivery cannot be verified after an
appropriate number of retransmissions, the node considers the
route to be invalidated. The node then broadcasts a message to
its neighbors specifying that the next hop to the source cannot
be reached. Upon receiving this packet, the neighboring node
builds and unicasts the Join Table to its next hop if it has a
route to the multicast source. If no route is known, it simply
rebroadcasts the packet specifying the next hop is not available.
In both cases, the node sets its FG_FLAG. The FG_FLAG setting of
every neighbors may create excessive redundancy, but most of
these settings will expire because only necessary forwarding
group nodes will be refreshed in the next Join Table propagation
phase.
TIME_TO_LIVE_VALUE 32 hops 5.2. Handling a Multicast Data Packet
7. Protocol Applicability Multicast sources send the Data whenever they have packets to send.
Nodes relay data packets only if the packet is not a duplicate and
the setting of FG_FLAG for the multicast group has not expired.
7.1. Networking Context 6. Protocol Applicability
6.1. Networking Context
ODMRP is best suited for mobile ad hoc wireless networks. ODMRP is best suited for mobile ad hoc wireless networks.
7.2. Protocol Characteristics and Mechanisms 6.2. Protocol Characteristics and Mechanisms
* Does the protocol provide support for unidirectional links? (if so, * Does the protocol provide support for unidirectional links? (if so,
how?) how?)
- No. We assume bidirectional links. - No. We assume bidirectional links.
* Does the protocol require the use of tunneling? (if so, how?) * Does the protocol require the use of tunneling? (if so, how?)
- No. - No.
* Does the protocol require using some form of source routing? (if * Does the protocol require using some form of source routing? (if
so, how?) so, how?)
- No. - No.
* Does the protocol require the use of periodic messaging? (if so, * Does the protocol require the use of periodic messaging? (if so,
how?) how?)
- Yes. The periodic messages are sent by multicast sources as - No.
long as there exist multicast packets to send. Multicast
receivers also send periodic messages while there are multicast
source entries in the Member Table.
* Does the protocol require the use of reliable or sequenced packet * Does the protocol require the use of reliable or sequenced packet
delivery? (if so, how?) delivery? (if so, how?)
- No. - No.
* Does the protocol provide support for routing through a multi- * Does the protocol provide support for routing through a multi-
technology routing fabric? (if so, how?) technology routing fabric? (if so, how?)
- No. - No.
skipping to change at page 18, line 37 skipping to change at page 19, line 37
- No. - No.
* Does the protocol provide loop-free routing? (if so, how?) * Does the protocol provide loop-free routing? (if so, how?)
- Yes. By using the Message Cache, duplicate packets are detected - Yes. By using the Message Cache, duplicate packets are detected
and packets can only go through the loop-free route. and packets can only go through the loop-free route.
* Does the protocol provide for sleep period operation? (if so, how?) * Does the protocol provide for sleep period operation? (if so, how?)
- No. - TBD. The work is in progress.
* Does the protocol provide some form of security? (if so, how?) * Does the protocol provide some form of security? (if so, how?)
- TBD. The work is in progress. - TBD. The work is in progress.
* Does the protocol provide support for utilizing multi-channel, * Does the protocol provide support for utilizing multi-channel,
link-layer technologies? (if so, how?) link-layer technologies? (if so, how?)
- This document assumed an arbitrary single channel link-layer - This document assumed an arbitrary single channel link-layer
protocol. The protocol can work with any MAC and link-layer protocol. The protocol can work with any MAC and link-layer
technology. It can also support multi-channel link-layer technology. It can also support multi-channel link-layer
technology (e.g., separate channels for data, control packets, technology (e.g., separate channels for data, control packets,
etc.). etc.).
Acknowledgments
Authors thank Ching-Chuan Chiang and Guangyu Pei for their initial
contributions.
References References
[1] Scott Bradner. Key words for use in RFCs to Indicate [1] Scott Bradner. Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997. Requirement Levels. RFC 2119, March 1997.
[2] Josh Broch, David B. Johnson, and David A. Maltz. The Dynamic [2] E. Bommaiah, M. Liu, A. McAuley, and R. Talpade. AMRoute:
Source Routing Protocol for Mobile Ad Hoc Networks. Adhoc Multicast Routing Protocol. Internet Draft,
Internet-Draft, draft-ietf-manet-dsr-00.txt, March 1998. Work draft-talpade-manet-amroute-00.txt, Aug. 1998. Work in progress.
in progress.
[3] Ching-Chuan Chiang and Mario Gerla. On-Demand Multicast in
Mobile Wireless Networks. In proceedings of IEEE ICNP'98,
Austin, TX, October 1998. pp. 262-270.
[4] Ching-Chuan Chiang, Mario Gerla, and Lixia Zhang. Forwarding [3] Ching-Chuan Chiang, Mario Gerla, and Lixia Zhang. Forwarding
Group Multicast Protocol (FGMP) for Multihop, Mobile Wireless Group Multicast Protocol (FGMP) for Multihop, Mobile Wireless
Networks. ACM/Baltzer Cluster Computing, vol. 1, no. 2, 1998. Networks. ACM/Baltzer Cluster Computing, vol. 1, no. 2, 1998.
[5] Zygmunt J. Haas and Marc R. Pearlman. The Zone Routing [4] M.S. Corson and S.G. Batsell. A Reservation-Based Multicast
Protocol (ZRP) for Ad Hoc Networks. Internet-Draft, (RBM) Routing Protocol for Mobile Networks: Initial Route
draft-ietf-manet-zone-zrp-01.txt, August 1998. Work in Construction Phase. ACM/Baltzer Wireless Networks, vol. 1,
progress. no. 4, Dec. 1999, pp. 427-450.
[6] Vincent D. Park and M. Scott Corson. Temporally-Ordered [5] J.J. Garcia-Luna-Aceves and E.L. Madruga. A Multicast Routing
Routing Algorithm (TORA) Version 1 - Functional Specification. Protocol for Ad-Hoc Networks. In Proceedings of IEEE
Internet-Draft, draft-ietf-manet-tora-spec-01.txt, August 1998. INFOCOM'99, New York, NY, Mar. 1999, pp. 784-792.
Work in progress.
[7] Charles E. Perkins. Mobile Ad Hoc Networking Terminology. [6] IEEE Computer Society LAN MAN Standards Committee. Wireless
Internet-Draft, draft-ietf-manet-term-00.txt, October 1997. LAN Medium Access Protocol (MAC) and Physical Layer (PHY)
Work in progress. Specification. IEEE std 802.11-1997. The Institute of Electrical
and Electronics Engineers, New York, NY, 1997.
[8] Charles E. Perkins and Pravin Bhagwat. Highly Dynamic [7] L. Ji and M.S. Corson. A Lightweight Adaptive Multicast
Destination-Sequenced Distance-Vector Routing (DSDV) for Algorithm. In Proceedings of IEEE GLOBECOM'98, Sydney,
Mobile Computers. In proceedings of ACM SIGCOMM'94, London, UK, Australia, Nov. 1998, pp. 1036-1042.
September 1994, pp. 234-244.
[9] Charles E. Perkins and Elizabeth M. Royer. Ad Hoc On Demand [8] J. Jubin and J.D. Tornow. The DARPA Packet Radio Network
Distance Vector (AODV) Routing. Internet-Draft, Protocols. Proceedings of the IEEE, vol. 75, no. 1, Jan. 1987,
draft-ietf-manet-aodv-01.txt, August 1998. Work in progress. pp. 21-32.
[10] Chai-Keong Toh. Associativity-Based Routing for Ad-Hoc Mobile [9] E.D. Kaplan (Editor). Understanding the GPS: Principles and
Applications, Artech House, Boston, MA, Feb. 1996.
[10] S.-J. Lee, M. Gerla, and C.-C. Chiang. On-Demand Multicast
Routing Protocol. In Proceedings of IEEE WCNC'99, New Orleans,
LA, Sep. 1999 (to appear).
[11] C.-K. Toh. Associativity-Based Routing for Ad-Hoc Mobile
Networks. Wireless Personal Communications Journal, Special Networks. Wireless Personal Communications Journal, Special
Issue on Mobile Networking and Computing Systems, Kluwer Issue on Mobile Networking and Computing Systems, Kluwer
Academic Publishers, vol. 4, no. 2, March 1997, pp. 103-139. Academic Publishers, vol. 4, no. 2, Mar. 1997, pp. 103-139.
[11] UCLA Wireless Adaptive Mobility (WAM) Laboratory. [12] UCLA Wireless Adaptive Mobility (WAM) Laboratory.
http://www.cs.ucla.edu/NRL/wireless http://www.cs.ucla.edu/NRL/wireless
Chair's Address Chair's Address
The Working Group can be contacted via its current chairs: The Working Group can be contacted via its current chairs:
M. Scott Corson M. Scott Corson
Institute for Systems Research Institute for Systems Research
University of Maryland University of Maryland
College Park, MD 20742 College Park, MD 20742
skipping to change at page 20, line 31 skipping to change at page 22, line 9
Washington, DC 20375 Washington, DC 20375
USA USA
Phone: +1 202 767-2001 Phone: +1 202 767-2001
Email: macker@itd.nrl.navy.mil Email: macker@itd.nrl.navy.mil
Authors' Addresses Authors' Addresses
Questions about this document can also be directed to the authors: Questions about this document can also be directed to the authors:
Mario Gerla Sung-Ju Lee
405 Hilgard Ave. 3771 Boelter Hall
Computer Science Department
University of California
Los Angeles, CA 90095
USA
Phone: +1 310 825-4367
Fax: +1 310 825-2273
Email: gerla@cs.ucla.edu
Guangyu Pei
405 Hilgard Ave.
Computer Science Department Computer Science Department
University of California University of California
Los Angeles, CA 90095 Los Angeles, CA 90095-1596
USA USA
Phone: +1 310 825-1888 Phone: +1 310 206-8589
Email: pei@cs.ucla.edu Fax: +1 310 825-7578
Email: sjlee@cs.ucla.edu
Sung-Ju Lee William Su
405 Hilgard Ave. 3771 Boelter Hall
Computer Science Department Computer Science Department
University of California University of California
Los Angeles, CA 90095 Los Angeles, CA 90095-1596
USA USA
Phone: +1 310 206-8589 Phone: +1 310 206-8589
Email: sjlee@cs.ucla.edu Fax: +1 310 825-7578
Email: wsu@cs.ucla.edu
Ching-Chuang Chiang Mario Gerla
3732F Boelter Hall
Computer Science Department Computer Science Department
Chung-Cheng Institute of Technology University of California
Ta-Shi, TaoYuan 335 Los Angeles, CA 90095-1596
Taiwan USA
Phone: +886 3 380-9331 Phone: +1 310 825-4367
Fax: +886 3 389-4770 Fax: +1 310 825-7578
Email: ccchiang@ccit.edu.tw Email: gerla@cs.ucla.edu
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/