One document matched: draft-jeong-manet-maodv6-00.txt
MANET WG
Internet-Draft J. Jeong
J. Park
ETRI
Y. Kim
S. Ahn
University of Seoul
Expires: January 2005 12 July 2004
Multicast Ad hoc On-Demand Distance Vector Routing
for IP version 6 (MAODV6)
draft-jeong-manet-maodv6-00.txt
Status of this Memo
By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been
disclosed, and any of which we become aware will be disclosed, in
accordance with RFC3668.
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.
This Internet-Draft will expire on January 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Jeong, et al. Expires - January 2005 [Page 1]
Internet-Draft MAODV6 July 2004
This document describes multicasting based on shared multicast tree
for IPv6 mobile ad hoc networks, which specifies an extension of
MAODV including message formats. In addition, forwarding mechanism
of multicast data packets is described to prevent duplicate data
packets from being received by multicast group members.
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Message Formats...............................................3
3.1 Route Request (RREQ) Message Format......................3
3.2 Route Reply (RREP) Message Format........................4
3.3 Multicast Activation (MACT) Message Format...............5
3.4 Group Hello (GRPH) Message Format........................5
4. Forwarding of Multicast Data Packets..........................6
5. IANA Considerations...........................................8
6. Security Considerations.......................................8
7. Acknowledgements..............................................8
8. Normative References..........................................8
9. Informative References........................................9
10. Authors' Addresses...........................................9
Intellectual Property Statement.................................10
Full Copyright Statement........................................10
Acknowledgement.................................................11
1. Introduction
The Multicast Ad hoc On-Demand Distance Vector (MAODV) protocol can
be used for multicasting in IPv4 mobile ad hoc networks that use Ad
hoc On-Demand Distance Vector (AODV) as unicast routing protocol
[3][4].
Because IPv6 has abundant address space and auto-configuration
facility, ad hoc networking can play an important role in ubiquitous
networking through using IPv6 as network layer protocol [6].
This document describes multicasting based on shared multicast tree
for IPv6 mobile ad hoc networks, which is an extension of MAODV for
IPv6 (MAODV6). The operation of MAODV6 is intended to mirror the
operation of MAODV for IPv4 [3], with changes necessary to allow for
transmission of 128-bit addresses in use with IPv6 instead of the
more traditional 32-bit addresses. The reader is referred to [3]
for most of the terminology, and the specification of MAODV.
In this document, message formats are described for MAODV6
Jeong, et al. Expires - January 2005 [Page 2]
Internet-Draft MAODV6 July 2004
operations. In addition, forwarding mechanism of multicast data
packets is described to prevent duplicate data packets from being
received by multicast group members.
2. Terminology
This document uses the terminology described in [3]-[5]. In
addition, a new term is defined below:
Multicast AODV for IPv6 (MAODV6)
Multicast Ad hoc On-Demand Distance Vector (MAODV) routing
protocol for IPv6 mobile ad hoc networks.
3. Message Formats
3.1 Route Request (RREQ) Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|R|G|D|U| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit RREQ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Source Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Destination IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Source IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 Route Request message (RREQ) is illustrated
above, and contains the same fields with the same functions as the
RREQ message defined for IP version 4 (in [3][4]), except as follows:
Type TBD
Destination IPv6 Address
The 128-bit IPv6 address of destination for
which a route is desired.
Source IPv6 Address
Jeong, et al. Expires - January 2005 [Page 3]
Internet-Draft MAODV6 July 2004
The 128-bit IPv6 address of the node which
originated the Route Request.
Note also that the order of the fields has been changed to enable
alignment along 128-bit boundaries.
3.2 Route Reply (RREP) Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|A| Reserved | Prefix Size | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Destination Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Destination IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Source IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 Route Reply message (RREP) is illustrated
above, and contains the same fields with the same functions as the
RREP message defined for IP version 4 (in [3][4]), except as follows:
Type TBD
Prefix Size The Prefix Size is 7 bits instead of 5, to
account for the 128-bit IPv6 address space.
Destination Sequence Number
The destination sequence number associated to
the route.
Destination IPv6 Address
The 128-bit IP address of the destination for
which a route is supplied.
Source IPv6 Address
The 128-bit IP address of the source node which
issued the RREQ for which the route is supplied.
Note also that the order of the fields has been changed to enable
Jeong, et al. Expires - January 2005 [Page 4]
Internet-Draft MAODV6 July 2004
alignment along 128-bit boundaries.
3.3 Multicast Activation (MACT) Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |J|P|G|U|R| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Source Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Multicast Group IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Source IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 Multicast Activation (MACT) is illustrated
above, and contains the same fields with the same functions as the
MACT message defined for IP version 4 (in [3]), except as follows:
Type TBD
Multicast Group IPv6 Address
The 128-bit IP address of the Multicast Group
for which a route is supplied.
Source IPv6 Address
The 128-bit IP address of the sending node.
Note also that the order of the fields has been changed to enable
alignment along 128-bit boundaries.
3.4 Group Hello (GRPH) Message Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |U|M| Reserved | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Multicast Group Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Group Leader IPv6 Address :
| |
Jeong, et al. Expires - January 2005 [Page 5]
Internet-Draft MAODV6 July 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: 128-bit Multicast Group IPv6 Address :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the IPv6 Group Hello (GRPH) is illustrated above, and
contains the same fields with the same functions as the GRPH message
defined for IP version 4 (in [3]), except as follows:
Type TBD
Group Leader IPv6 Address
The 128-bit IP address of the group leader.
Multicast Group IPv6 Address
The 128-bit IP address of the Multicast Group
for which the sequence number is supplied.
Note also that the order of the fields has been changed to enable
alignment along 128-bit boundaries.
4. Forwarding of Multicast Data Packets
Forwarding of multicast data packets in MANET is different from that
in wired networks. In wired networks, a network interface of a node
has a one-to-one connection to one of the network interfaces of other
nodes. If the packet coming into an incoming interface needs to be
forwarded, it is delivered to the corresponding outgoing interface.
Hence transmitting node plays a main role of forwarding in wired
networks. However, in wireless ad hoc networks, in most cases each
node has only one network interface, so the incoming interface is the
same as the outgoing one. Because the wireless network interface of
a node has a one-to-many connection to those of neighboring nodes, a
node receiving a packet SHOULD filter unnecessary packets. In the
unicast forwarding case, a node drops a received packet if the
destination MAC address of the packet is different from its MAC
address. In the multicast forwarding case, because the destination
MAC address is a multicast group address, a node receiving a
multicast packet can not know whether it has already received the
packet or not. Here, since this document is focusing only on the
multicast data forwarding, from now on, 'packet' or 'data' implies
'multicast packet' or 'multicast data'.
According to the above-mentioned reason, tree-based ad hoc multicast
routing protocols including MAODV6 may cause data duplication and the
causes of data duplication can be classified as follows:
Jeong, et al. Expires - January 2005 [Page 6]
Internet-Draft MAODV6 July 2004
(a) Data duplication by reverse transmission
When a node forwards a received packet to its next hop or hops,
the packet is also sent to the node which has previously
forwarded the packet to this node. This type of duplication is
named as the "data duplication by reverse transmission".
(b) Data duplication by transmission from non-neighbor
When a packet is forwarded to the next hops which are members
of the corresponding multicast tree, nodes which are not
neighbors in the tree may receive the packet. This type of
duplication is named as the "data duplication by transmission
from non-neighbor".
In IPv4, the data duplication by reverse transmission can be resolved
by making each node maintain a message cache with (Source IPv4
Address, IPv4 Sequence Number) entries, in which IPv4 Sequence Number
can be contained in 'Identification' field in IPv4 header. Upon
receiving a packet, if the message cache of the node does not have
the (Source IPv4 Address of the packet, IPv4 Sequence Number of the
packet) entry, the entry is newly added to the message cache and the
packet is accepted. Otherwise (i.e., the entry is already in the
message cache), the packet is a duplicate and discarded.
In IPv6, the above-mentioned scheme can not be applied since the
'Identification' field for sequence number does not exist in the IPv6
basic header. Furthermore, the message cache requires a lot of
memory in maintaining entries for all non-duplicate packets. In
order to prevent the data duplication by reverse transmission in the
MAODV6 environment, each node is required to maintain a message cache
with (Source IPv6 Address, Multicast Group IPv6 Address, Source MAC
Address) entries. A packet can be accepted if it comes from the node
with the same address as the source MAC address for the (Source IPv6
Address, Multicast Group IPv6 Address) pair. When a node receives a
packet and if the message cache of the node does not have the (Source
IPv6 Address of the packet, Multicast Group IPv6 Address of the
packet, Source MAC Address of the packet) entry, the entry is newly
added to the message cache and the packet is accepted. The number of
entries is smaller than that of the method using the sequence number
because in this case a message cache only has to maintain one entry
per source of a multicast session. This approach is against the
layering concept since the MAC address (which is relevant to the
layer 2) is used in forwarding (which is relevant to the layer 3).
However, this approach allows a node to know the previous node of a
packet efficiently.
To prevent the data duplication by transmission from non-neighbor,
each node maintains a multicast neighbor table with (Multicast Group
IPv6 Address, Neighbor MAC Address List) entries. This entry has the
Jeong, et al. Expires - January 2005 [Page 7]
Internet-Draft MAODV6 July 2004
meaning that a multicast packet is accepted if it comes from the node
with the same address as one of the addresses (i.e., neighbors) in
the neighbor MAC address list for the multicast group IPv6 address.
When MAODV6 adds, deletes and updates entries of the multicast
routing table, the multicast neighbor table SHOULD be updated so that
the routing changes can be reflected.
A node determines whether it has to forward a packet or not according
to the number of neighboring nodes in the corresponding multicast
tree. If the number of neighboring nodes is more than zero in the
case of multicast source, or is more than one in the case of an
intermediate node for forwarding, the packet is forwarded or
transmitted.
Like this, the multicast data forwarding in MAODV6 provides a simple
forwarding mechanism for transmitting nodes and an efficient packet
filtering mechanism for receiving nodes.
5. IANA Considerations
The message types for MAODV6 should be defined by IANA, such as RREQ,
RREP, MACT and GRPH.
6. Security Considerations
Currently, MAODV6 does not specify any special security measures.
Route protocols, however, are prime targets for impersonation attacks
and must be protected by use of authentication techniques involving
generation of unforgeable and cryptographically strong message
digests or digital signatures. It is expected that, in environments
where security is an issue, that IPSec authentication headers will be
deployed along with the necessary key management to distribute keys
to the members of the ad hoc network using MAODV6.
7. Acknowledgements
The authors would like to appreciate the previous contribution of
Charles E. Perkins and Elizabeth M. Belding-Royer.
8. Normative References
[1] S. Bradner, "Intellectual Property Rights in IETF Technology",
RFC 3668, February 2004.
[2] S. Bradner, "IETF Rights in Contributions", RFC 3667,
February 2004.
Jeong, et al. Expires - January 2005 [Page 8]
Internet-Draft MAODV6 July 2004
[3] E. Belding-Royer and C. Perkins, "Multicast Ad hoc On-Demand
Distance Vector (MAODV) Routing", draft-ietf-manet-maodv-
00.txt. July 2000.
[4] C. Perkins, E. Belding-Royer and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC3561, July 2003.
[5] C. Perkins, E. Belding-Royer and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing for IP version 6", draft-
perkins-manet-aodv6-01.txt, November 2000.
9. Informative References
[6] J. Jeong, J. Park and H. Kim, "Auto-Networking Technologies for
IPv6 Mobile Ad Hoc Networks", ICOIN 2004, February 2004.
10.Authors' Addresses
Jaehoon Paul Jeong
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 1664
Fax: +82 42 861 5404
EMail: paul@etri.re.kr
Jungsoo Park
ETRI / PEC
161 Gajeong-dong, Yuseong-gu
Daejeon 305-350
Korea
Phone: +82 42 860 6514
Fax: +82 42 861 5404
EMail: pjs@etri.re.kr
Youngmin Kim
Dept. of Computer Science
University of Seoul
90 Jeonnong-dong, Dongdaemoon-gu
Seoul 130-743
Korea
Phone: +82 2 2210 2957
Fax: +82 2 2210 5275
EMail: blhole@venus.uos.ac.kr
Jeong, et al. Expires - January 2005 [Page 9]
Internet-Draft MAODV6 July 2004
Sanghyun Ahn
Dept. of Computer Science
University of Seoul
90 Jeonnong-dong, Dongdaemoon-gu
Seoul 130-743
Korea
Phone: +82 2 2210 2631
Fax: +82 2 2210 5275
EMail: ahn@venus.uos.ac.kr
Intellectual Property Statement
The following intellectual property notice is copied from RFC3668,
Section 5.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Full Copyright Statement
The following copyright notice is copied from RFC3667, Section 5.4.
It describes the applicable copyright for this document.
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Jeong, et al. Expires - January 2005 [Page 10]
Internet-Draft MAODV6 July 2004
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jeong, et al. Expires - January 2005 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-23 06:17:37 |