Internet DRAFT - draft-laouiti-manet-olsr-address-autoconf
draft-laouiti-manet-olsr-address-autoconf
IETF MANET C. Adjih
Internet-Draft S. Boudjit
Expires: January 19, 2006 P. Jacquet
A. Laouiti
P. Muhlethaler
INRIA Rocquencourt, France
Pr. Mase
Information and Communication
Network Lab., Niigata University
July 18, 2005
Address autoconfiguration in Optimized Link State Routing Protocol
draft-laouiti-manet-olsr-address-autoconf-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Several MANET routing protocols have been recently promoted to
experimental RFCs. However, autoconfiguration of MANET networks is
Adjih, et al. Expires January 19, 2006 [Page 1]
Internet-Draft Autoconf in OLSR July 2005
still an unsettled area. This document proposes a protocol for
autoconfiguration for both IPv4 or IPv6. Its corner stone is an
conflict-detection algorithm. It aims at conceptual simplicity:
essentially, each node periodically sends its addresses and an
identifier. Conflicts are detected as identifier mismatches. This
protocol might be used with any MANET protocol, although it naturally
suits the OLSR routing protocol (on which we focus), with a light
increase of control message overhead.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Changes . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of the Method . . . . . . . . . . . . . . . . . . . . 6
3.1 Address Assignment . . . . . . . . . . . . . . . . . . . . 6
3.2 Duplicate Address Detection . . . . . . . . . . . . . . . 7
3.3 Conflict Resolution . . . . . . . . . . . . . . . . . . . 7
3.4 Optional: MANET connected to an external network . . . . . 7
3.5 Optional: Routing Table Contamination Avoidance . . . . . 7
3.6 Optional: Passive Duplicate Detection . . . . . . . . . . 8
4. Duplicate Address Detection Algorithms . . . . . . . . . . . . 9
4.1 Overview of the Different Solutions . . . . . . . . . . . 9
4.2 First approach . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Rule 1 . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2 Rule 2 . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3 Second approach . . . . . . . . . . . . . . . . . . . . . 11
4.3.1 Rule 2B . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Third approach . . . . . . . . . . . . . . . . . . . . . . 11
4.4.1 Rule 2C . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
A. MAD Message Format . . . . . . . . . . . . . . . . . . . . . . 15
B. DAD-MPR flooding algorithm . . . . . . . . . . . . . . . . . . 16
C. Precisions for third approach . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Normative References . . . . . . . . . . . . . . . . . . . 19
7.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Adjih, et al. Expires January 19, 2006 [Page 2]
Internet-Draft Autoconf in OLSR July 2005
1. Introduction
Mobile Ad hoc NETworks (MANETs) are infrastructure-free, highly
dynamic wireless networks, where central administration or
configuration by the user is very difficult. In hardwired networks
nodes usually rely on a centralized server and use a dynamic host
configuration protocol, like DHCP[10], to acquire an IP address.
Such a solution cannot be deployed in MANETs due to the
unavailability of any centralized DHCP server. For small scale
MANETs, it may be possible to allocate free IP addresses manually.
However, the procedure becomes impractical for a large-scale or open
systems where mobile nodes are free to join and leave. Most of the
autoconfiguration algorithms proposed for ad hoc networks are
independent of the routing protocols and therefore, generate a
significant overhead. Using the genuine optimization of the
underlying routing protocol can significantly reduce the
autoconfiguration overhead.
Because traditional IP solutions to autoconfiguration cannot be used
as is on MANET networks, a MANET-AUTOCONF effort was set with three
initial goals, which include the two following: an "IPv6 stateless
autoconfiguration mechanism", and a "mechanism promoting address
uniqueness in the situation where different ad hoc networks merge".
This document proposes a protocol that addresses these two issues.
The third one, "stateful address autoconfiguration mechanism", might
be addressed by derivative of the method of the draft.
This comprehensive scheme centers on one control message and one
mechanism, which ensure at the same time conflict avoidance in the
2-hop neighborhood of each node, and conflict avoidance in the entire
network. This algorithm operates on multiple interfaces and is shown
to work in any case of multiple conflicts, especially during network
mergers.
1.1 Changes
Major changes from version 00 to version 01
o Changes in the structure of the document, and important editorial
changes.
o DAD and MPR flooding is ensured in case of multiple interfaces.
o The second (now third) approach does not modify the basic OLSR
HELLO message format anymore.
Adjih, et al. Expires January 19, 2006 [Page 3]
Internet-Draft Autoconf in OLSR July 2005
o Another approach has been added.
1.2 Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [14].
For the OLSR description and terminology, the reader should refer to
the OLSR RFC [12].
Adjih, et al. Expires January 19, 2006 [Page 4]
Internet-Draft Autoconf in OLSR July 2005
2. Problem Statement
The problem solved by the proposed autoconfiguration protocol is the
autoconfiguration in MANET networks. The reader is referred to the
autoconfiguration survey in [1], for the general problem statement,
and a survey of several proposed solutions.
Considering the connectivity scenarios listed in [3], our prime
objective is the autoconfiguration of isolated MANETs, but extending
it to MANETs intermittently connected, or to connected MANETs is
intended and already proposed ([5]).
More importantly, our main goal is promoting configured address
uniqueness in the situation where different ad hoc networks merge.
Precisely, the networks may be isolated, may become partitioned, and
may merge, ... . Under these hypothesis, the only way to ensure
address uniqueness is that, in the critical case of a merge of two
networks, the information about the all the addresses of the first
network is compared to the information about all the addresses of the
second network. That can be done in direct or indirect ways, with
centralized or distributed means (and anything in between).
Adjih, et al. Expires January 19, 2006 [Page 5]
Internet-Draft Autoconf in OLSR July 2005
3. Overview of the Method
With respect to the problem statement, the method is build around a
conceptually simple means of ensuring that information about all
addresses is checked: each node sends its lists of addresses
periodically, and a node identifier. Hence the approach is fully
distributed, and introduces an unique new kind of message. It
deliberately favors simplicity at the expense of bandwidth
efficiency. At least in the case of the OLSR protocol, this is not
an issue.
More precisely, our proposed auto-configuration algorithm is
structured around three building blocks:
1. Address assignment: an IP address is selected by the arriving
node.
2. Duplicate Address Detection (Conflict Detection): each node
checks that there is not another node with the same address.
3. Conflict resolution: when a node detects that another node is
using the same address, it will select a new address.
This method may also integrate a number of optional elements, namely:
1. Route contamination avoidance and gradual entry (borrowed from
[4]).
2. Interface with gateways (see also [5]).
3. Passive duplicate detection methods.
The following sections give an overview of each part of the protocol.
3.1 Address Assignment
Numerous schemes can be used to select an IP address. For instance,
the node can perform a random selection; another technique is that
each node may advertise a set of addresses that (it believes) are not
used, for potential newcomers as in [2]. Another method, more
direct, is that a neighbor node selects this IP address for the
arriving node by control message exchanges [14].
Because it is assumed that the MANET network may be isolated, a
default method is to choose an address at random inside a given
subnet with MANET_PREFIX: the pool of addresses could be for local
use only. For example, it could be reserved by the IANA authority
for local MANET forwarding ( i.e, those addresses must not be
Adjih, et al. Expires January 19, 2006 [Page 6]
Internet-Draft Autoconf in OLSR July 2005
forwarded outside the MANET network, nor reached from outside).
Choice may be more subtle, see Section 3.5. Additional addresses may
be added, see Section 3.4.
3.2 Duplicate Address Detection
As highlighted previously, the DAD algorithm uses a single special
control message to perform conflict detection.
This control packet includes one identifier and all the addresses of
the node. This message is periodically transmitted to the entire
network. The identifier of each node is assumed unique (with
sufficient probability). If a node receives a message with a
different identifier than its own, an address duplication is detected
and the node selects a new address.
This control message is called MAD, for "Multiple Address
Declaration". It is an extension of MID messages for OLSR and it
also advertises all acquired addresses of the node. Because it is
the central part of this method, it is described in the Section 4.
3.3 Conflict Resolution
When two nodes A1 and A2 are configured with the same IP address and
assuming that there is no packet loss, at least one of these two
nodes will receive the MAD message of the other node. Thus the nodes
where the conflict lies are bound to discover the conflict, and can
resolve it by changing addresses. Since a conflicting node knows via
the reception of the MAD control messages the already assigned
addresses, the new address must be selected at random among the
addresses that are believed to be free.
3.4 Optional: MANET connected to an external network
When a MANET is connected to an external network, in case of IPv6,
the node may receive IPv6 router advertisement messages. The intent
of MAD messages was to advertise all the addresses of a node,
including newly formed global addresses when such an IPv6 router
advertisement is received (diffused by a manet multicast), see [14].
A better and more complete protocol to achieve the same goals (and
more) is described in [5], and it can be adapted directly to the
method presented here.
3.5 Optional: Routing Table Contamination Avoidance
In the case that node has just changed its address, an useful
technique is to perform some routing table contamination avoidance
(pioneered in [4]). It consists into letting a node entering
Adjih, et al. Expires January 19, 2006 [Page 7]
Internet-Draft Autoconf in OLSR July 2005
gradually in the network, going through several states: at first it
is only recognized by its immediate neighbors, but not advertised,
and not used for routing. This gives the node opportunity to detect
(passively) an address conflict with an existing node, and change its
address.
3.6 Optional: Passive Duplicate Detection
When the OLSR routing protocol is used (version 1 or version 2), it
is possible to use a derivative of passive detection techniques found
in NOA-OLSR [4] and [2], and pioneered by PACMAN [9]: the topological
information diffused by the OLSR routing protocol is sufficient to
detect address conflict. The address conflicts are essentially
detected in two ways, as analyzed in [9]: inconsistent topological
information (essentially, a node discovers that a control message
incorrectly advertises that it has a link), and inconsistent message
originators (a node discovers that it is credited for originating a
message, which actually, it did not transmit).
Using passive techniques, one still need to ensure that control
messages are propagated properly. Especially in the case of OLSR
with multiple interfaces (but also in the cases given in the figures
of [9]), it is necessary to ensure that MPR selection is done
properly: we propose that MPR selection is ensured by the propagation
of MAD messages at only a distance up to two hops from the
originator, (4 hops when conflict is detected, as the algorithms
proposed here do), which is enough to guarantee sufficient resolution
of short range conflict to permit proper MPR selection.
Hence MAD messages are sent only in a limited local area, to
guarantee proper MPR selection, at limited cost; and longer range
conflicts are detected by passive methods.
For completing all theoretical conflict cases, and in order to
accelerate the detection by passive methods, in the even rarer case
when the topology is symmetric, and nodes in conflict have identical
message sequence numbers, we suggest that one bit somewhere in the
message may be set randomly in the message (or based on node
identifier): this gives an additional 50% chance of resolving the
conflict at each generated message. (such a bit that might be set, is
the last bit of the message sequence number).
Adjih, et al. Expires January 19, 2006 [Page 8]
Internet-Draft Autoconf in OLSR July 2005
4. Duplicate Address Detection Algorithms
4.1 Overview of the Different Solutions
In order to detect address conflicts, each node diffuses periodically
a special message that we call a MAD for ``Multiple Address
Declaration'' to the entire network[14]. This control packet
includes the node addresses and the node identifier.
The node identifier is a sequence of bits of fixed length L which is
randomly generated. Hence we are using the standard idea that the
probability of two nodes having the same node identifier is low, and
the probability of at least one address collision with N nodes, which
is the well known ``birthday problem'', can be set arbitrarily low by
choosing a large enough value of L (eight bytes are enough to code
the random identifier if we consider a network with a maximum of
10000 nodes [13] [16]). The MAD message format is depicted in the
Appendix A
A node detects an address conflict when it receives an MAD message
having the same address as its own, but with a different identifier.
These situations may happen during network mergers. Actually other
nodes will detect the conflict. These nodes could announce the
conflict using a special control message. However this approach may
induce broadcast storm since many nodes may announce the conflict and
special care must be taken to avoid this effect. For that reason we
do not recommend this way. An efficient manner to notify the address
duplication to the nodes in conflict, consists in allowing the MAD
packets to reach all the nodes in the network.
Depending on which routing protocol is actually used, the MAD
messages may be optimized in several kind of ways. Several cases may
be identified:
o OLSR [12]
o OLSRv2 [6]
o A protocol with support for an MPR-based flooding (such as [7] and
[8])
o A protocol without an MPR-based optimization
In the last case, if the protocol has no MPR-based optimization, the
sending of MAD messages is done with the default of using pure
flooding. Additionally, whenever OLSR is not used, the MAD messages
must be encapsulated in proper packets.
Adjih, et al. Expires January 19, 2006 [Page 9]
Internet-Draft Autoconf in OLSR July 2005
Otherwise: when MPR-based flooding is present, to save channel
bandwidth the MAD packets should be broadcasted using this MPR-based
flooding (either as a MPR-CDS or a genuine MPR flooding). Then, of
course, MAD messages are used in order to resolve conflicts, but
conflicts themselves can lead to improper MPR selection. Hence a few
theoretical situations result some conflicts may not be resolved.
This is addressed by special relaying rules for MPR-flooding, and
three different approaches:
o In first one, designed for OLSR, we suggest to ignore the MPR
mechanism for MAD relaying in the one-hop neighborhood and
instead, the MAD messages are repeated by all neighbors (one-hop
pure flooding). Moreover special rules for address conversion are
introduced when using the content of MAD messages. One-hop pure
flooding is sufficient for OLSR, hence the overhead is limited.
o The second one focuses on protocols different from OLSRv1: for
MPR-based flooding protocols, and for OLSRv2, it is necessary that
MAD messages are repeated by neighbors and also 2-hop neighbors.
This method is a derivative of the previous algorithm, and is
slightly more expensive, but more general.
o In the third one, MAD messages are also relayed by one-hop
neighbors, as in the first approach. Moreover, we also modify the
MPR election algorithm of OLSR. The calculation will be based on
node identifiers to guarantee the uniqueness of the direct
neighbors and the 2-hop neighbors. This leads to a correct MPR
set, hence, ensures that the MAD messages reach all the nodes.
4.2 First approach
This approach is based on new rules for MPR flooding for MAD message
(details are given in Appendix B). The proof of correctness of this
algorithm is given in [15] (including cases with multiple interfaces
and multiple conflicts). The two rules are:
4.2.1 Rule 1
When a node X receives a MAD message and if node X has a symmetric or
asymmetric link with a node Y with the same main address as the one
contained in the MAD message, then node X relays this MAD message.
When relaying the MAD message the Hop-Count field is set to 1.
4.2.2 Rule 2
When a node X receives a HELLO message from a node Y, this HELLO
contains interface addresses of 2-hop neighbors of X(1-hop neighbors
Adjih, et al. Expires January 19, 2006 [Page 10]
Internet-Draft Autoconf in OLSR July 2005
of Y). To convert such addresses into main addresses the node X uses
MAD messages that are relayed by Y. The rule 2 will actually avoid
inconsistent main address conversions for 2-hop neighbors. This is
essential in the case of nodes with multiple interfaces.
4.3 Second approach
In this approach, it is assumed that the rule 2 of the first approach
can no longer be applied, because, for instance, the protocol does
not use or has not MID/MAD messages. In this case, the rule 2 is
replaced the rule 2B, and the details are easily derived from
Appendix B:
4.3.1 Rule 2B
When a node X receives a MAD message, which it has not already
retransmitted, with a hop count field equal to one, it relays it.
The rule 2B will actually make all the 2-hop neighbors retransmit the
message.
4.4 Third approach
An issue with this first approach is that the conflicts at 2-hop must
be resolved before one can be sure that the MAD messages are
successfully transmitted within the entire network. An ideal
property would be that the MAD messages reach all the nodes in the
network irrespectively of potential address duplications. This
property can be achieved if the MPR flooding continues to work in
presence of address duplication. A solution is then to base the
selection of MPR not on addresses but on node identifiers. With the
assumption that node identifiers are globally unique in the network,
one can be sure that there will not be identifier duplications at two
hops of a given node and thus the selection of MPRs will be correct.
This solution can be simply implemented, the selection of the MPRs
must follow the principle defined in the OLSR protocol except that
the base for the selection must be the node identifiers i.e. the
2-hop coverage must be considered not on the addresses but on the
node identifiers.
This is achieved in this section by providing an alternative to the
second rule. The Rule 2 is replaced by a Rule 2C:
4.4.1 Rule 2C
The MPR calculation is modified, by using node identifiers. Each
address is converted to a node identifier (using a method described
later): as a result the node computing its MPR set, has its 1-hop and
2-hop topology represented by links between node identifiers.
Adjih, et al. Expires January 19, 2006 [Page 11]
Internet-Draft Autoconf in OLSR July 2005
Details about applying rule 2C in practice are found in Appendix C.
Adjih, et al. Expires January 19, 2006 [Page 12]
Internet-Draft Autoconf in OLSR July 2005
5. IANA Considerations
One new type of control message is defined in this protocol, for MAD
messages.
Adjih, et al. Expires January 19, 2006 [Page 13]
Internet-Draft Autoconf in OLSR July 2005
6. Security Considerations
This memo does not specify any security considerations.
Adjih, et al. Expires January 19, 2006 [Page 14]
Internet-Draft Autoconf in OLSR July 2005
Appendix A. MAD Message Format
An example of MAD message format is depicted in the following figure
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originator node identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OLSR Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
An alternative is to prepend an "Originator node identifier" OLSR
message, to MeID messages
Adjih, et al. Expires January 19, 2006 [Page 15]
Internet-Draft Autoconf in OLSR July 2005
Appendix B. DAD-MPR flooding algorithm
Let us recall the assumptions here. Each node A periodically sends a
message M including:
o The originator address of A, Orig_A, in the OLSR message header.
o The list of interface addresses of node A in the message it self.
o The message sequence number, mssn, in the OLSR message header.
o The node identifier ID_A (a string of bits) in the message itself.
The message is propagated by MPR flooding to the other nodes ; but
for DAD-MPR Flooding, the duplicate table of OLSR is modified, so
that it also includes the node identifier list in the duplicate
tuple. That is, a duplicate tuple, includes the following
information:
o The originator address (as in OLSR standard duplicate table).
o The message sequence number (as in OLSR standard duplicate table).
o The list of node identifiers.
o The list of interface addresses on which the MAD message was
received.
The detailed algorithm for DAD-MPR Flooding is the following:
o When a node B receives a MAD message M on its interface B(i) from
node C with originator Orig_A, with message sequence number mssn,
and with node identifier ID_A, it performs the following tasks:
1. If a duplicate tuple exists with the same originator Orig_A,
the same message sequence number mssn, the ID_A is in the list
of node identifiers, and the interface address of B(i) is in
the list of interface addresses on which the message has
already been received, Then, the message is ignored (it has
already been processed). The algorithm stops here.
2. Else one of the following situations occurs :
1. A duplicate tuple exists with the same originator Orig_A,
the same message sequence number mssn, ID_A is in the list
of node identifiers, but the address of B(i) is not in the
list of interface addresses on which the MAD message has
already been received: then, the message must be
Adjih, et al. Expires January 19, 2006 [Page 16]
Internet-Draft Autoconf in OLSR July 2005
processed. The address of B(i) is added to the list of
interface addresses on which the message has already been
received.
2. A duplicate tuple exists with the same originator Orig_A
and the same message sequence number, but ID_A is not in
the list of node identifiers: then, a conflict is detected
(address Orig_A is duplicated). ID_A is added to the list
of node identifiers.
3. A duplicate tuple exists with the same originator Orig_A,
but with a different message sequence number and ID_A is
not in the list of node identifiers: then, a conflict is
detected (address Orig_A is duplicated). A duplicate
tuple is created with the originator address, message
sequence number and list of node identifiers containing
only ID_A.
4. No duplicate tuple exists. A new one is created with the
originator address Orig_A, message sequence number mssn,
list of interface addresses on which the MAD message has
already been received containing only the address of B(i),
and list of node identifiers containing only ID_A.
3. The MAD messages should be relayed if one or more of the
following rules are met:
1. C had chosen this current receiving node, B, as an MPR.
2. Node B has a symmetric or asymmetric link with a node Y
with the same main address as the one contained in the MAD
message M. In such a case, the Hop-Count field is set to 1
before message M retransmission.
o When a node X receives a HELLO message from a node Y, this HELLO
contains interface addresses of 2-hop neighbors of X. The node X
uses MAD messages relayed by Y to convert such addresses into main
addresses.
Adjih, et al. Expires January 19, 2006 [Page 17]
Internet-Draft Autoconf in OLSR July 2005
Appendix C. Precisions for third approach
The goal is to obtain the one hop neighborhood and the two-hop
neighborhood with node identifiers in place of addresses.
Converting main addresses of neighbor to node identifiers is easily
done: when receiving the MAD messages from neighbors, the main
address can be identified to be the address of a neighbor, and the
node identifier is given. Hence the node may record the information
mapping main addresses of neighbors to their identifiers.
Converting main addresses of two-hop neighbors to node identifiers is
less direct: however the information obtained thanks to the fact that
MAD messages from two-hop neighbors are always retransmitted by one-
hop neighbors. Such MAD messages are identified by the fact that
they arrive with a hop count field (corrected by Rule 1 is
necessary), equal to 1 ; in the following, they are called two-hop
MAD messages. The receiver node can thus maintain the information
Two-Hop Identifier Table: (neighbor address, two-hop neighbor
addresses list, two-hop neighbor identifier) in or in addition to,
the MID/MAD information base. Now taking advantage of the fact that
conflicts at distance 1 to 3 are resolved anyway by Rule 1, it is
know that one neighbor will retransmit neighbor MAD message (two-hop
MAD messages for the receiver) that have all different addresses:
otherwise there would be a 2-hop conflict, necessarily resolved.
Thus the mapping deduced from the Two-Hop Identifier Table, (neighbor
main address, two-hop neighbor main address) -->two-hop neighbor
identifier is unique (and corresponds to reality).
Note also, that the information containted in the two-hop identifier
table, should be also used for processing Hello messages (converting
interface addresses to main addresses) so that the two-hop neighbor
main address in the two-hop tuple is the actual main address.
Adjih, et al. Expires January 19, 2006 [Page 18]
Internet-Draft Autoconf in OLSR July 2005
7. References
7.1 Normative References
7.2 Informative References
[1] Bernardos, C. and M. Calderon, "Survey of IP address
autoconfiguration mechanisms for MANETs",
draft-bernardos-manet-autoconf-survey-00 (work in progress),
July 2005.
[2] Clausen, T. and E. Baccelli, "Simple MANET Address
Autoconfiguration", draft-clausen-manet-address-autoconf-00
(work in progress), February 2005.
[3] Ruffino, S., "Connectivity Scenarios for MANET",
draft-ruffino-conn-scenarios-00 (work in progress),
February 2005.
[4] Mase, K. and C. Adjih, "No Overhead Autoconfiguration OLSR",
draft-mase-manet-autoconf-noaolsr-00 (work in progress),
May 2005.
[5] Ruffino, S. and P. Stupar, "Automatic configuration of IPv6
addresses for nodes in a MANET with multiple gateways",
draft-ruffino-manet-autoconf-multigw-00 (work in progress),
June 2005.
[6] Clausen, T., "The Optimized Link-State Routing Protocol version
2", draft-clausen-manet-olsrv2-00 (work in progress),
July 2005.
[7] Perkins, C., "Multicast With Minimal Congestion Using Connected
Dominating Sets", draft-perkins-manet-smurf-00 (work in
progress), July 2005.
[8] Macker, J., "Simplified Multicast Forwarding for MANET",
draft-ietf-manet-smf-00 (work in progress), July 2005.
[9] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad
hoc Networks", March 2003.
[10] "R. Droms, Ed.,J. Bound, B. Volz, T. Lemon, C. Perkins, M.
Carney, 'Dynamic Host Configuration Protocol for IPv6
(DHCPv6)', IETF RFC 3315, July 2003".
[11] "S. Thomson, T. Narten, 'IPv6 Stateless Address
Autoconfiguration', IETF RFC 2462, December 1998".
Adjih, et al. Expires January 19, 2006 [Page 19]
Internet-Draft Autoconf in OLSR July 2005
[12] "T. Clausen, Ed., P. Jacquet, Ed., 'Optimized Link State
Routing Protocol', Request for Comments (Experimental) 3626,
Internet Engineering Task Force, October 2003".
[13] "S.Boudjit, A. Laouiti, P. Muhlethaler, C. Adjih, 'Duplicate
address detection and autoconfiguration in OLSR', INRIA
Research Report-5475, Jan 2005".
[14] "A. Laouiti, S. Boudjit, P. Minet and C. Adjih, 'OLSR for
IPv6 networks', Proceedings of Med-Hoc-Net, June 2004,Bodrum,
Turkey".
[15] "C. Adjih, S.Boudjit, P. Jacquet, A. Laouiti, P. Muhlethaler,
'An Advanced Configuration and Duplicate Address Detection
mechanism for a multi-interface OLSR Network', INRIA Research
Report, Jul 2005".
[16] "S. Boudjit, C. Adjih, A. Laouiti, P. Muhlethaler,'Duplicate
address detection and autoconfiguration in OLSR', Proceedings
of IEEE SAWN 2005, May 2005, Maryland, USA".
Authors' Addresses
Cedric Adjih
INRIA Rocquencourt, France
Project HIPERCOM
Domaine de Voluceau -Rocquencourt
BP 105
Le Chesnay 78153 cedex
France
Phone: +33 1 3963 5215
Email: cedric.adjih@inria.fr
Saadi Boudjit
INRIA Rocquencourt, France
Project HIPERCOM
Domaine de Voluceau -Rocquencourt
BP 105
Le Chesnay 78153 cedex
France
Phone: +33 1 3963 5039
Email: saadi.boudjit@inria.fr
Adjih, et al. Expires January 19, 2006 [Page 20]
Internet-Draft Autoconf in OLSR July 2005
Philippe Jacquet
INRIA Rocquencourt, France
Project HIPERCOM
Domaine de Voluceau -Rocquencourt
BP 105
Le Chesnay 78153 cedex
France
Phone: +33 1 3963 5263
Email: philippe.jacquet@inria.fr
Anis Laouiti
INRIA Rocquencourt, France
Project HIPERCOM
Domaine de Voluceau -Rocquencourt
BP 105
Le Chesnay 78153 cedex
France
Phone: +33 1 3963 5088
Email: anis.laouiti@inria.fr
Paul Muhlethaler
INRIA Rocquencourt, France
Project HIPERCOM
Domaine de Voluceau -Rocquencourt
BP 105
Le Chesnay 78153 cedex
France
Phone: +33 1 3963 5278
Email: paul.muhlethaler@inria.fr
Pr. Kenichi Mase
Information and Communication Network Lab.,Niigata University
Niigata University
Niigata 950-2181,
Japan
Phone: +81 25 262 7446
Email: mase@ie.niigata-u.ac.jp
URI: http://www.net.ie.niigata-u.ac.jp/
Adjih, et al. Expires January 19, 2006 [Page 21]
Internet-Draft Autoconf in OLSR July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Adjih, et al. Expires January 19, 2006 [Page 22]
