Internet DRAFT - draft-mase-manet-autoconf-noaolsr
draft-mase-manet-autoconf-noaolsr
MANET K. Mase
Internet-Draft Niigata University
Expires: August 31, 2006 C. Adjih
INRIA
Feb 27, 2006
No Overhead Autoconfiguration OLSR
draft-mase-manet-autoconf-noaolsr-01
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 August 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006 ).
Abstract
This document specifies one method for autoconfiguration for the
Optimized Link State Routing (OLSR) protocol for stand-alone ad hoc
networks. OLSR is a routing protocol for mobile ad hoc networks,
designed for use in multi-hop wireless ad hoc networks ; and as such
it specifies how individual nodes can construct routes to each other.
To achieve this, it relies on preliminary assignment of unique IP
addresses to OLSR interfaces ; hence the task of generating
Mase & Adjih Expires August 31, 2006 [Page 1]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
addresses, checking their uniqueness and assigning them to interfaces
is defined externally. This document proposes a complementary
method, called "No Overhead Autoconfiguration for OLSR" (NOA-OLSR),
to perform this task of ensuring uniqueness of addresses which have
been generated. It also performs to ensure uniqueness of addresses
which have been assigned and used when network merger occurs. This
method consists of modifications in the OLSR specification.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Autoconfiguration Method Overview . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Autoconfiguration Algorithms . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Address Generation . . . . . . . . . . . . . . . . . . . . 9
4.3. MANET-wide Duplicate Address Detection(MANET-DAD) . . . . 9
4.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Notation . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.3. MANET-DAD Rules for Neighbor Address Conflict . . . . 11
4.3.3.1. Rule R1 . . . . . . . . . . . . . . . . . . . . . 11
4.3.4. MANET-DAD Rules for Two-hop Address Conflict . . . . . 11
4.3.4.1. Rule R2 . . . . . . . . . . . . . . . . . . . . . 12
4.3.4.2. Rule R3 . . . . . . . . . . . . . . . . . . . . . 12
4.3.5. MANET-DAD Rules for Multihop Address Conflict . . . . 13
4.3.5.1. MANET-DAD Rules for Multihop Address Conflict
with two TC generators . . . . . . . . . . . . . . 14
4.3.5.2. MANET-DAD Rules for Multihop Address Conflict
with two non-generators . . . . . . . . . . . . . 15
4.3.5.3. MANET-DAD Rules for Multihop Address Conflict
with one TC Generator and one Non-Generator . . . 19
4.3.5.4. Three-hop DAD, Specific Case . . . . . . . . . . . 22
4.4. Sequence Number Consistency . . . . . . . . . . . . . . . 23
4.4.1. Minimum Wrap-Around Limit . . . . . . . . . . . . . . 23
4.4.2. HELLO Sequence Number Consistency . . . . . . . . . . 23
4.4.3. TC Sequence Number Consistency . . . . . . . . . . . . 24
4.5. Autoconfiguration State . . . . . . . . . . . . . . . . . 25
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25
4.5.2. Functionning . . . . . . . . . . . . . . . . . . . . . 25
4.6. Node Familiarity . . . . . . . . . . . . . . . . . . . . . 27
5. Requirements notation . . . . . . . . . . . . . . . . . . . . 29
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 30
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Mase & Adjih Expires August 31, 2006 [Page 2]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Mase & Adjih Expires August 31, 2006 [Page 3]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
1. Introduction
A mobile ad hoc network is a collection of nodes, which collaborate
to each other without depending on centralized control for enabling
wireless communication among nodes. When two nodes are within direct
transmission range, they communicate directly (one hop wireless
communication) ; and otherwise they communicate using other nodes as
intermediary nodes (multihop wireless communication), where the
intermediary nodes act as routers for forwarding IP datagrams.
Accordingly, routing is a key problem for mobile ad hoc networks and
many routing protocols have been proposed. In IETF, in the MANET
working group, two proactive routing protocols, OLSR [3] and TBRPF
[4], and two reactive routing protocols, AODV [5] and DSR [6] are or
will progress to experimental RFC status. The former and the latter
are succeeded to OLSRv2 [7] and DYMO [8], respectively for the
standard truck RFCs. However these routing protocols assume that
each node has been assigned an unique IP address on each of its
network interfaces. In the traditional Internet,DHCP is typically
used for mobile stations to obtain their IP address. However, in
stand-alone mobile ad hoc networks, such a centralized mechanism may
not be available and each node needs to obtain its address in a
decentralized fashion. If each node generates addresses at random
from a given address space for its interfaces, uniqueness of these
addresses is not guaranteed. That is, two different nodes generate
and assign the same address (Dupulicate address) to their interface
respectively. This is called address conflict. The chances of
occurrence of address conflict is significant in IPv4 networks, where
the number of bits used for host address is limited. On the other
hand, this issue may be negligible in IPv6 networks, since longer
bits(ex. 64 bits) can be used for host address space. However,
address space should be set as small as possible even in IPv6
networks in order to maximize the effect of address compression, that
is specified in OLSRv2[7]. IP address autoconfiguration is therefore
an important pratical issue, regardless of IPv4 or IPv6 networks.
Many conventional methods are organized independently from routing
protocols so that they can be used for any MANET regardless of the
routing protocols. Unfortunately, all of these proposed methods are
rather expensive as they require significant control message overhead
for either avoiding or resolving address conflicts.
We propose a novel MANET-local address autoconfiguration method for
MANET with OLSR, called "No Overhead Autoconfiguration for OLSR"(NOA-
OLSR). Our method is an duplicate address detection without overhead
based on properties of proactive link state routing protocols. NOA-
OLSR is in accordauce with "a common framework for autoconfiguration
of stand-alone ad hoc networks" [10].
Mase & Adjih Expires August 31, 2006 [Page 4]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
2. Autoconfiguration Method Overview
In this section, an overview of the autoconfiguration method is
given, followed by a description of the structure of the document.
The autoconfiguration algorithm detailed in this document applies to
the OLSR protocol, and changes its operation. The node is assumed to
implement the OLSR protocol ([3], thereafter denoted "standard
OLSR"), complemented by the modifications specified here
(thenceforth, "NOA-OLSR").
Under these assumptions, an OLSR node running NOA-OLSR will proceed
as follows. An address is initially qenerated for its OLSR interface
(manually, or using the autoconfiguration methods suggested in this
document). Then, the node runs the OLSR protocol using this address,
while at the same time constantly checking that it is not conflicting
with the address of another node in the network (using the detection
algorithm of this document). Finally, it doesn't run fully OLSR
protocol initially, because it might be entering in a network where
its address could be already used by another node, and it would
possibly break routes of nodes which are already running. Instead,
the node goes through several states, in the last of which, only, the
node will ultimately run the full OLSR protocol. Similarily, in
order to avoid routing table contamination, the other nodes avoid
relying on this node initially, and will rely on it for routing and
forwarding messages, when it has reached proper states.
To sum up, the autoconfiguration of an OLSR node includes in three
parts:
o Address qeneration
o Ongoing duplicate address detection
o Gradual entry in the OLSR network and routing table contamination
avoidance
Considering the address genenation, it is actually a peripherical
issue of the protocol described in this document, because it is
fairly independent of it. Hence an overview of address generation is
provided, along with guidelines, and pointers to relevant references.
The ongoing duplicate address detection is the main addition to the
OLSR protocol, detailed in Section 4.3 is , checking for
inconsistencies in the routing protocol messages to diagnose
duplicate address detection, using variants of the ideas pioneered by
[2]:
Mase & Adjih Expires August 31, 2006 [Page 5]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
o The first kind of inconsistency is based on information included
in OLSR messages (such as HELLO messages and TC messages): many
cases of duplicate address in one MANET network result into
inconsistent information being received ; topology information,
for instance.
o The second kind of inconsistency is based on sequence numbers:
when two nodes, which selected the same IP address, are present in
a network, they would send control messages that will be
inconsistent.
Finally the protocol runs based on a state for each OLSR node, the
"autoconfiguration state proposed in [10]". It allows one OLSR node
with a newly generated address to enter gradually in running OLSR
network, by sending messages which will be used by more and more
nodes. At the same time, it also prevents routing table
contamination by ensuring that routes go through nodes which have
been present in the network long enough for the duplicate address
detection to have been performed. Specifically there are three
autoconfiguration states, NO_ADDRESS_STATE, ADVERTISING_STATE and
NORMAL_STATE. ADVERTISING_STATE may be further divided into
LOCAL_AD_STATE and GLOBAL_AD_STATE. General definitions of
autoconfiguration states are given in [10]. Definition of
autoconfiguration states, specific to OLSR networks, are generated
straightforwardly from these general definitions, as given in Section
4.5. Note that LOCAL_AD_STATE and GLOBAL_AD_STATE are renamed to
HELLO_STATE and TOPOLOGY_STATE, respectively, reflecting types of
control message used in OLSR.
The remaining of this document is organized as follows:
o Section 3 collects specific terminology used
o Section 4 provides the high-level, algorithmic, part of this
document. It includes:
* Address generation.
* Ongoing duplicate address detection.
* Principles behind checking sequence number consistency of
messages.
* Gradual entry in the OLSR network and routing table
contamination avoidance.
Mase & Adjih Expires August 31, 2006 [Page 6]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
3. Terminology
This section provides definition for terms that have a specific
meaning to the protocol specified in this document and that are used
throughout the text.
MANET-local Address: a unique-local address having scope that is
limited to the MANET.
Tentative Address: an address whose uniqueness in a MANET is being
verified, prior to its assignment to an interface. A tentative
address is not considered assigned to an interface in the usual
sense. An interface discards received packets addressed to a
tentative address, but accepts routing control packets related to
MANET-wide Duplicate Address Detection for the tentative address.
Address Generation: Adress generation is a procedure for a node, that
has currently no address, to obtain a tentative address in the
MANET -either of its own accord or with support of other nodes.
Address Conflict: When two nodes in the same MANET network share the
same address, the situation is described as an "Address Conflict".
The nodes involved are "conflicting nodes" and their shared
address is called "conflicting address". Conflicting nodes may
each send one message with the same sequence number and same
message type: such messages are denoted "conflicting messages".
Autoconfiguration State for OLSR: The current autoconfiguration state
of the node, one of NO_ADDRESS, HELLO, TOPOLOGY, and NORMAL, which
indicates what messages it should (or should not) generate and
processing it should (or should not) do (see Section 4.5).
Busy Address: An address which is being used by some node in the
network (see Section 4.2).
MANET_wide Duplicate Address Detection (MANET-DAD): MANET-DAD is the
action of detecting address conflict, the situation where some
nodes are using the same address in the same MANET network.
MANET-DAD Rule: A MANET-DAD rule is one rule of this document, which
used to detect the existence of address conflict (see
Section 4.3).
Familiar Address (Node): An address is familiar for a node, if the
node has seen it in an OLSR message, for a sufficiently long
period of time (see 4.6 and 5.4.7). A node is familiar for
another node if it has a familiar address for this other node. An
address or a node which is not familiar is said "unfamiliar".
Mase & Adjih Expires August 31, 2006 [Page 7]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
NOA-OLSR: "NOA-OLSR" is the protocol specified by this document. It
is the standard OLSR protocol [3] with the additions and changes
specified in this document.
Routing Table Contamination Avoidance: Routing table contamination
avoidance is the idea of preserving the routing table from
incorrect information due to address conflict. This is achieved
by using the autoconfiguration state (see Section 4.5).
Sequence Number Consistency: All OLSR messages have a sequence
number. One trademark of duplicate addresses, is sequence numbers
of different messages, which could not result from a correct
implementation of the OLSR protocol (such as decrease in sequence
numbers, etc.). The properties of sequence numbers which would
result from the normal OLSR protocol implementation are termed
"Sequence number consistency" (see Section 4.4).
Standard OLSR: The terms "standard OLSR protocol" refer to the OLSR
protocol specified in [3]. The term "standard" is meant to
differentiate with the "non-standard" OLSR protocol proposed in
this document (thereafter, "NOA-OLSR"). It is not meant to
express its normative status within IETF or standardization
organizations.
TC Generator: A node which generates TC messages (as originator).
Mase & Adjih Expires August 31, 2006 [Page 8]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
4. Autoconfiguration Algorithms
4.1. Overview
This section provides a high-level view of the method used for MANET-
local address autoconfiguration of the node: address generation,
duplicate address detection based on rules, principles for sequence
number consistency, use of the autoconfiguration state.
4.2. Address Generation
When a node is in NO_ADDRESS_STATE, it can monitor the protocol
message exchanges and collect information regarding the addresses in
use, the "busy address list". It can then selects its own tentative
address from the pool of free addresses by avoiding the busy address
list. With OLSR, it is possible for each node to obtain busy address
information through routing control messages received from other
nodes (such information is available as part of the State Set
introduced in Section 4.5).
This document doesn't specify how the addresses should be selected,
apart from the fact any selected address should not be the "busy
address list".
Some discussions and references about address generation (including
IPv4 and IPv6 stateless address autoconfiguration) can be found, for
instance, in the document [9].
4.3. MANET-wide Duplicate Address Detection(MANET-DAD)
4.3.1. Overview
MANET-DAD is performed passively, i.e., without additional control
messages. Some various passive DAD techniques were proposed in [2],
we propose some others. MANET-DAD is performed in either
HELLO_STATE, TOPOLOGY_STATE and NORMAL_STATE. MANET-DAD in
HELLO_STATE or TOPOLOGY_STATE is called "pre-service MANET-DAD" and
that in NORMAL_STATE is called "in-service MANET-DAD"[10]
In this section, the detection algorithms are detailed. Protocol
specifications are given in a later section.
In a MANET network with nodes running the OLSR, several different
scenarios of address conflicts may occur. There are classified in
three separated cases:
Mase & Adjih Expires August 31, 2006 [Page 9]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Neighbor Address Conflict: in this case, two neighbor nodes (in range
of each other) have selected the same address.
Two-hop Address Conflict: in this case, two nodes which have selected
the same address are two-hop neighbors. That is, there is another
node in the network which is the neighbor of those both nodes.
Multihop Address Conflict: in this case, the two nodes in address
conflict are separated by two nodes or more.
The three cases of address conflict are different in that they can be
detected by different methods: for instance the multihop address
conflict can be detected by the use of TC message information, while
the first two cases need not.
Also, an additional case is added: it's a specific multihop address
conflict case, where the address conflict results in deficiencies in
the MPR selection.
4.3.2. Notation
In the Section 4.3, the following conventions are used to describe
the duplicate address conflict cases for the algorithms:
o Capital letters are used to denote different nodes: such as "A",
"B", "C", etc...
o Numbers are used to represent different addresses, such as "1",
"2", "3", etc...
o The following notation is employed to represent the node "A" which
has the address "1": "A{1}". In the event of an address conflict,
two nodes may be using the same address, such as "A{1}" and "B{1}"
for instance.
o Each MANET-DAD rule is associated to a figure which graphically
represents the topology. An example is given on Figure 1: one
node "A" with address "1". In the figures which will follow, the
nodes which should apply the MANET-DAD rule, are highlighted by
the mark "**", like "A" is, on the sample figure.
+--------------+
| ** Node A{1} |
+--------------+
Figure 1
Mase & Adjih Expires August 31, 2006 [Page 10]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
4.3.3. MANET-DAD Rules for Neighbor Address Conflict
In the case of "neighbor address conflict", two conflicting nodes are
neighbors (see Figure 2). This case is special since many different
non-OLSR methods could be used to detect the conflict: because the
neighbor nodes would receive messages from each other directly, as
they would, for instance, if they were connected on a Ethernet
network. Thus, most of methods designed for (non-MANET) IP networks,
such as IPv4 autoconfiguration detection methods or IPv6 ones, could
be used.
Still, due to topology changes such methods could fail, or could not
be available in a node. Hence a rule to detect conflicts at the OLSR
protocol level in this case is proposed. At mininum, the two OLSR
nodes should at least periodically generate HELLO messages, hence the
following rule is used:
4.3.3.1. Rule R1
Rule: R1 (see Figure 2)
Context: A node A is either in HELLO_STATE, TOPOLOGY_STATE or
NORMAL_STATE. An HELLO message is received by a node A{1}.
Check: Is the address {1}, the address of the originator node ?
Action: If it is the case, this node(node A) is in conflict and must
enter NO_ADDRESS_STATE.
Rationale: A node doesn't receive its own HELLO messages (they are
not forwarded), hence the occurence of such an event means that a
node with the same address has sent an HELLO.
+--------------+ +--------------+
| ** Node A{1} | <---> | ** Node B{1} |
+--------------+ +--------------+
Figure 2
As mentioned, this rule can be completed by other duplicate address
detection mechanisms, not specified in this document, as they are
beyond its scope.
4.3.4. MANET-DAD Rules for Two-hop Address Conflict
In this case, the two conflicting nodes are two-hop neighbors, that
is: they are not neighbor, but they have a common neighbor (see
Mase & Adjih Expires August 31, 2006 [Page 11]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Figure 3). The rule proposed here relies on the fact that a common
neighbor exists, and will receive the HELLO from both nodes. The
detection proceeds in three steps: the common neighbor detects the
conflict using those HELLOs, then it advertises the conflict in some
message(s) (rule R2), and finally, the conflicting nodes change their
address upon receiving this conflict advertisement (rule R3).
4.3.4.1. Rule R2
Rule: R2 (see Figure 3)
Context: A node B is either HELLO_STATE, TOPOLOGY_STATE or
NORMAL_STATE. In node B{2}: an HELLO message from address {1} was
received previously, and another HELLO from address {1} is just
received by B{2}.
Check: Are the sequence numbers of the HELLOs inconsistent (as
defined in Section 4.4)?
Action: If it is the case, there are two or more neighbors using the
same address {1}. B{2} will advertise that the address {1} is
conflicting in its HELLO messages.
Rationale: If two neighbors of one node have conflicting addresses,
the HELLO sequence numbers will be inconsistent.
+--------------+ +--------------+ +--------------+
| Node A{1} | <---> | ** Node B{2} | <---> | Node C{1} |
+--------------+ +--------------+ +--------------+
Figure 3
4.3.4.2. Rule R3
Rule: R3 (see Figure 4)
Context: A node A is either HELLO_STATE, TOPOLOGY_STATE or
NORMAL_STATE. In node A{1} (and node C{1}): a neighbor B{2} is
advertising that conflict exists with the address {1}.
Check: -
Action: If it is the case, A{1} is a conflicting node and must enter
NO_ADDRESS_STATE.
Mase & Adjih Expires August 31, 2006 [Page 12]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
+--------------+ +--------------+ +--------------+
| ** Node A{1} | <---> | Node B{2} | <---> | ** Node C{1} |
+--------------+ +--------------+ +--------------+
Figure 4
4.3.5. MANET-DAD Rules for Multihop Address Conflict
In this section, DAD rules are proposed to handle the case where the
distance between conflicting nodes is three hops or more. In this
case, in general, it cannot be assumed that a single node has enough
information to detect the conflict using exclusively the HELLO
messages. Hence, the logical choice is here to use information
inside TC messages. However MANET-DAD is complicated by the
optimizations of the OLSR routing protocol: first, not all nodes
originate TC messages ; second, TC messages might include only a
subset of neighbors ; third, OLSR messages may be split and as a
consequence, an individual TC message from one node might not include
all the topology information that the node should periodically
refresh. Finally, the MPR selection algorithm can be affected by
duplicate addresses, and prevent proper operation of the MPR flooding
mechanism, hence prevent proper propagation of the TCs used by MANET-
DAD.
The MANET-DAD rules that are specified in the case of multihop
address conflict are classified depending on the status of the
conflicting nodes with respect to TC generation: a node which
generates TC messages (when it is a multipoint relay of some node) is
called a TC generator. Three cases are possible and are handled:
o Both conflicting nodes are TC generators.
o One of the conflicting nodes is a TC generator, and the other is
not.
o None of the conflicting nodes is TC generator.
In each of the three cases, the MANET-DAD rules allow detection both
on the conflicting nodes (which would then change address) and on
intermediary nodes (which would then avoid routing table
contamination). Finally some MANET-DAD rules are used for preventing
the following case:
o Conflicting nodes are impeding MPR selection.
The following four sections handle individually each case.
Mase & Adjih Expires August 31, 2006 [Page 13]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
4.3.5.1. MANET-DAD Rules for Multihop Address Conflict with two TC
generators
In this case, the two nodes in conflict are both TC generators. Then
each of them would ultimately receive one TC with its own originator
address, but which it did not generate (for it was generated by the
other node). The intermediate nodes would also detect conflict by
noticing discrepancy in the sequence numbers or discrepancy in the
content of the TC messages with same sequence number.
The first rule applies to conflicting nodes (R4 (Section 4.3.5.1.1)),
the second applies to other nodes in the network (R5
(Section 4.3.5.1.2)).
4.3.5.1.1. Rule R4
Rule: R4 (see Figure 5)
Context: A node A is in NORMAL_STATE. In node A{1} (or node C{1}): a
TC with originator address {1} has been received. A{1} keeps
track of the TC messages that it has sent.
Check: Verify whether A has actually sent that TC: the message
sequence number should be the same as one message that A has sent
in the past, and then the content should be the same.
Action: If it is not the case, A{1} is a conflicting node and must
enter NO_ADDRESS state.
+--------------+ +--------------+ +--------------+
| ** Node A{1} | <- .. -> | Node B{2} | <- .. -> | ** Node C{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 5
4.3.5.1.2. Rule R5
Rule: R5 (see Figure 6)
Context: A node B is either in TOPOLOGY_STATE or NORMAL_STATE. In
node B{2}: an TC message with originator address {1} was received
previously by the node, and another TC with originator address {1}
is just received by B{2}
Mase & Adjih Expires August 31, 2006 [Page 14]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Check: Are the sequence numbers of the TC messages consistent (as
defined in Section 4.4)? Is the content of the TC identical to
the one(s) received before?
Action: If it is not the case, there are two or more nodes using the
same address {1}: then the TC should be forwarded if the receiving
node is a MPR(if it has not already been), but the content of the
TC will be ignored and not processed
Rationale: This detects a conflict between TC generators. If the
conflicting nodes are sending TC messages with same sequence
number, standard MPR flooding might not allow the TC messages to
reach the other node. Hence in case of conflict, the TC should be
forwarded by default, if the receiving node is a MPR. Also,
because a conflict has been detected, the received TC is guaranted
to hold information which is inconsistent with the information
already processed because it was issued by a different node ; and
hence, the content of TC message should be ignored.
+--------------+ +--------------+ +--------------+
| Node A{1} | <- .. -> | ** Node B{2} | <- .. -> | Node C{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 6
4.3.5.2. MANET-DAD Rules for Multihop Address Conflict with two non-
generators
In this section, MANET-DAD rules are given for the case where none of
the conflicting nodes is a TC generator. In such a configuration,
the conflict is detected by means of by using the TC messages of the
multi-point relays of the nodes. As one conflicting node selects
some MPR, these MPR will send TC messages indicating this selection:
when one of the TC messages reaches the other conflicting node, this
node will detect inconsistency by discovering that it did not,
actually, select the TC originator as MPR.
The MANET-DAD for intermediate nodes is, however more complex,
because they cannot rely on sequence numbers as in Section 4.3.5.1,
nor they can rely on knowledge of the actual MPR selection of every
node like the nodes in conflict. Hence to detect occurences of such
conflicts, another mechanism is used: it is based on the concept of
familiar nodes. A node (an IP address) is familiar for another node,
when the last one has had knowledge of existence of the first one for
sufficiently long (see Section 4.6).
Mase & Adjih Expires August 31, 2006 [Page 15]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
The hypothesis made now is that most conflicts occur because of
network mergers. In such an address conflict, now, let's assume a
node from one network is now sending TC messages including the
address of one node (in conflict with this network) from another,
newly merged, network. For instance, let us consider Figure 7, and
let us assume that A{1}, C{2}, and E{4} were previously part of one
network, while B{1} and D{3} (one of its MPRs) were part of another.
It is reasonable to assume that D{3} will become the neighbor of few
nodes of the first network, which it will advertise. Hence, most
likely, the TC messages of D{3}, which advertise the conflicting node
B{1}, also include mostly addresses of nodes from the merged network,
which would be unfamiliar nodes for A{1}. Hence the MANET-DAD rule:
ignore the information relative to familiar nodes, when it is inside
TC messages from unfamiliar nodes, which also include too many
unfamiliar nodes.
Another rule is added for neighbors of the node A{1}, such as C{2}:
because they have knowledge of the neighborhood of A{1}, they are
able to directly check if D{3} is a neighbor of A{1}.
4.3.5.2.1. Rule R6
Rule: R6 (see Figure 7)
Context: A node A is either in TOPOLOGY_STATE or NORMAL_STATE. In
node A{1}: a TC message with originator address {3} has been
received.
Check: If this TC includes the address {1} of A, A checks whether it
had recently selected {3} as MPR.
Action: If it is not the case, A{1} is a conflicting node and must
enter NO-ADDRESS_STATE.
Rationale: If A{1} has not selected {3} as MPR, then another node
with address {1} must have done so, hence there is an address
conflict.
Mase & Adjih Expires August 31, 2006 [Page 16]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
+--------------+ +--------------+
| ** Node A{1} | | ** Node B{1} |
| (non-MPR) | | (non-MPR) |
+--------------+ +--------------+
^ ^
| |
V V
+--------------+ +--------------+ +--------------+
| Node C{2} | <- .. -> | Node E{4} | <- .. -> | Node D{3} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 7
4.3.5.2.2. Rule R7
Rule: R7 (see Figure 8)
Context: A node E is either in TOPOLOGY_STATE or NORMAL_STATE. In
node E{4}: a TC message from originator {2}, which is familiar for
E, had been received. It included the familiar (for E) address
{1}. Another TC, from originator {2}, an unfamiliar node for E,
is including the same familiar address {1}.
Check: In this TC, check how many addresses are from familiar nodes.
If too little addresses are familiar, then the TC is assumed to
include an address {1} which is conflicting.
Action: If conflict is assumed, then the information of the TC of {3}
about address {1} is ignored (the previous one from {2} will still
be used), but all other content is kept.
Rationale: This is an heuristic for detecting conflict. Note that in
any case, a route to {1} can still be computed using the TC
message from {2}. Note also that after some time, {3} and all the
nodes advertised by {3} will be familiar to E, ensuring that this
rule will no longer apply.
Mase & Adjih Expires August 31, 2006 [Page 17]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
+--------------+ +--------------+
| Node A{1} | | Node B{1} |
| (non-MPR) | | (non-MPR) |
+--------------+ +--------------+
^ ^
| |
V V
+--------------+ +--------------+ +--------------+
| Node C{2} | <- .. -> | ** Node E{4} | <- .. -> | Node D{3} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 8
4.3.5.2.3. Rule R8
Rule: R8 (see Figure 9)
Context: A node C is in NORMAL_STATE. In node C{2}: a HELLO message
from node {1} was previously received, and a TC message from node
{3} is now received.
Check: If the TC message from {3} includes {1} as MPR selector, the
HELLO from {1} should also have included {3} as symmetrical
neighbor (actually more: as MPR)
Action: If it is not the case, then a conflict is assumed for address
{1}. Then the information of the TC message of {3} about address
{1} is ignored (the previous one from {2} will still be used), but
all other content is kept.
Rationale: This is another heuristic for detecting conflict for every
node which is neighbor of the conflicting nodes.
+--------------+ +--------------+
| Node A{1} | | Node B{1} |
| (non-MPR) | | (non-MPR) |
+--------------+ +--------------+
^ ^
| |
V V
+--------------+ +--------------+ +--------------+
| ** Node C{2} | <- .. -> | Node E{4} | <- .. -> | Node D{3} |
| A's neighbor | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 9
Mase & Adjih Expires August 31, 2006 [Page 18]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
4.3.5.3. MANET-DAD Rules for Multihop Address Conflict with one TC
Generator and one Non-Generator
In case one of the nodes in conflict is a TC generator while the
other one is not, the conflict can be detected by as previously. The
TC generator can conduct MANET-DAD by checking the TC messages of the
MPR of the other node using Rule R6 (Section 4.3.5.2.1)(see
Figure 10). The conflicting node that does not generate TC messages,
can detect conflict with Rule R4 (Section 4.3.5.1.1)(see Figure 11).
However for intermediary nodes, a new case is possible. We still
assume most conflicts occur because of network mergers. Then it is
possible that one conflicting node is a TC generator in one network,
while the other one is not in the other network. Using the same
logic as previously, the TC message of that conflicting node would
include many unfamiliar nodes, hence one MANET-DAD rule is to reject
such TC.
+--------------+
| Node A{1} |
| (non-MPR) |
+--------------+
^
|
V
+--------------+ +--------------+ +--------------+
| Node C{2} | <- .. -> | E{4} | <- .. -> | ** Node B{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 10
+--------------+
| ** Node A{1} |
| (non-MPR) |
+--------------+
^
|
V
+--------------+ +--------------+ +--------------+
| Node C{2} | <- .. -> | ** E{4} | <- .. -> | B{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 11
Mase & Adjih Expires August 31, 2006 [Page 19]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
4.3.5.3.1. Rule R9
Rule: R9 (see Figure 12)
Context: A node E is either in TOPOLOGY_STATE or NORMAL_STATE. In
node E{4}: a TC message from originator {2}, which is familiar for
E, had been received and it included the (familiar for E) address
{1}. Another TC message, from originator {1}, is received.
Check: In this TC, check how many addresses are from familiar nodes.
If too little addresses are familiar, then the TC is assumed to be
from an unfamiliar node from a merged network.
Action: If conflict is assumed, then the information of the TC is
ignored (the previous one from {2} will still be used).
Rationale: This is an heuristic for detecting conflict. Note that in
any case, a route to {1} can still be computed using {2} and note
that in absence of conflict, anyway, after some time, all the
nodes advertised by {1} will be familiar to E, ensuring that this
rule will no longer apply.
+--------------+
| Node A{1} |
| (non-MPR) |
+--------------+
^
|
V
+--------------+ +--------------+ +--------------+
| Node C{2} | <- .. -> | ** Node E{4} | <- .. -> | Node B{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 12
Additionally, still in the case of network merger, the nodes that are
on the border of the network merger can actually use some heuristics
for detecting conflicts. Indeed, if a node, is from another
(merging) network, it is likely to have many unfamiliar nodes as
neighbors. And those unfamiliar nodes will be present in the Hello
messages of the node. Hence when a node detects that one of its
neighbors has too many other neighbors that are unfamiliar, it can
suspect the neighbor is from another network. In case the node is a
TC generator, it will then mark the address of the node as
unfamiliar.
Mase & Adjih Expires August 31, 2006 [Page 20]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
4.3.5.3.2. Rule R10
Rule: R10 (see Figure 13)
Context: A node C is in NORMAL_STATE. In node C{2}: a TC message is
being generated, and it includes neighbor {1}.
Check: In the neighborhood of A{1} (which is obtained from the Hello
messages, in the two-hop tuple set) check how many addresses are
from familiar nodes. If too little addresses are familiar, then
the neighbor is assumed to be an node from a merged network.
Action: If too little address are familiar, the address {1} is
advertised as being "with too many unfamiliar neighbors".
Rationale: This is an heuristic to avoid routing table contamination.
Note that the address {1} is still advertised and can be used by
node E{4} and B{1} to detect the conflict.
+--------------+
| A{1} |
| (non-MPR) |
+--------------+
^
|
V
+--------------+ +--------------+ +--------------+
| ** C{2} | <- .. -> | E{4} | <- .. -> | B{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 13
The following rule uses the information transmitted by the previous
one:
4.3.5.3.3. Rule R11
Rule: R11 (see Figure 14)
Context: A node E is either in TOPOLOGY_STATE or NORMAL_STATE. In
node E{2}: a TC message has been received from originator {2} and
it includes neighbor {1} marked as ``with too many unfamiliar
neighbors'', by rule R10 in node {2}.
Mase & Adjih Expires August 31, 2006 [Page 21]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Check: -
Action: The address {1} should be ignored in the processing of the TC
message. But the other addresses may still be used, and the TC
should still be forwarded with standard MPR flooding.
Rationale: This is an heuristic to avoid routing table contamination,
using information from rule R10.
+--------------+
| A{1} |
| (non-MPR) |
+--------------+
^
|
V
+--------------+ +--------------+ +--------------+
| C{2} | <- .. -> | ** E{4} | <- .. -> | B{1} |
| TC generator | | | | TC generator |
+--------------+ +--------------+ +--------------+
Figure 14
4.3.5.4. Three-hop DAD, Specific Case
It has been noted that in some cases the MPR selection process can
fail because of duplicate addresses (see [2]). As a result, the MPR
flooding mechanism may fail to deliver a message to the entire
network, and then the previous MANET-DAD rules may fail to detect
address conflict. This situation is illustrated in Figure 15. A
specific rule can be devised to prevent this situation and allow
proper MPR selection: in the figure, the node B{2} is able to detect
that there is an inconsistency in the neighborhood advertised by {1}
and {3}, which may possibly arise from {1} being a duplicate address.
In this case, the MPR selection of B would be deficient: so B can
still preventively select {3} as MPR by itself. That way, the
messages from A{1} going through B will reach D{1} (triggering one of
the previous MANET-DAD rules R6 and R8).
4.3.5.4.1. Rule R12
Rule: R12 (see Figure 15)
Context: A node B is in TOPOLOGY_STATE or NORMAL_STATE. In node
B{2}: a HELLO from node {1} had been received, and now an HELLO
from node {3} is received.
Mase & Adjih Expires August 31, 2006 [Page 22]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Check: If the HELLO from {3} includes {1} as symmetrical neighbor,
the HELLO from {1} should also have included {3} as symmetrical
neighbor.
Action: If it is not the case, there is an inconsistency and the node
B should select {3} as MPR.
Rationale: Such inconsistencies should never happen in a static
network, unless there is a conflict. Note also that due to
topology changes, they may do so even if there is no conflict. In
that case, note that the only penalty is an temporary increase of
the number of MPR selected. It is still an excellent heuristic
that will solve the MPR selection problem when the network is
static.
+--------------+ +--------------+
| Node A{1} | | Node D{1} |
+--------------+ +--------------+
^ ^
| |
V V
+--------------+ +--------------+
| ** Node B{2} | <---> | Node C{3} |
+--------------+ +--------------+
Figure 15
4.4. Sequence Number Consistency
In [2], the use of sequence numbers to verify consistency has been
used in some general cases. Here, sequence number consistency is
checked for the OLSR protocol, and consist really of two cases: HELLO
sequence number consistency, and TC sequence number consistency.
4.4.1. Minimum Wrap-Around Limit
In the OLSR protocol [3], it is implicitly assumed that the sequence
number of one node will wrap-around within an interval of time
greater than DUP_HOLD_TIME. Hence this value is a good reference for
the minimum expected interval before a wrap-round the sequence number
of any node in the network, denoted MIN_WRAP_AROUND_INTERVAL.
4.4.2. HELLO Sequence Number Consistency
In case of HELLO messages, it is assumed that they would be received
in the same order as they are transmitted (because they are not
forwarded). In this case, a node observing the HELLO messages from a
Mase & Adjih Expires August 31, 2006 [Page 23]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
neighbor will see that their sequence numbers are permanently
increasing. Now if there are two neighbors B and C of one node A,
the node A will receive alternatively messages from B and C, because
each is transmitting indefinitly. Hence A must receive a sequence of
packets from B, then some packets from C, then some packets from B,
and so on. Let's assume that ultimately a sufficiently long sequence
is received without packet loss, and which then will be in this
order:
o one packet B1 from B (possibly the last one of a sequence of
packets from B)
o some packets from C
o one packet B2 from B (possibly the first one of a sequence of
packets from B)
Now because there was no packet loss, the sequence number of the
packet B2 is the sequence number of the packet B1 plus 1. As a
result, considering the sequence number of any packet from C:
o If it is greater than the sequence number of B1, then: the
sequence number of the packet B2 will be less or equal to the
sequence number of the packets from C.
o Otherwise it is equal to or less than the sequence number of B1.
In both events, A observes a decrease or a repetition of the sequence
numbers of B.
Hence, for HELLO messages, it is sufficient to check if the HELLO
received from one address is equal to, or less than, the sequence
number of the previous HELLO received from this address.
However, because a node may not be constantly a neighbor (and hence,
quite naturally, a large number of successive HELLO messages may not
be received), this condition should be checked only when there was no
wrap-around, hence when the interval between the previous HELLO
received and the last HELLO received from the same address is less
than MIN_WRAP_AROUND_INTERVAL.
4.4.3. TC Sequence Number Consistency
Because TC messages are forwarded with the MPR flooding mechanism,
first, the same message may be received several time, secondly, the
packet order can be changed, especially with the use of jitter.
Hence the algorithm used previously for checking consistency of HELLO
messages (Section 4.4.2) can not be used as is.
Mase & Adjih Expires August 31, 2006 [Page 24]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Hence the following principles are used:
o The sequence number and the receving time of the last TC message
for each originator is recorded.
o Each time a TC message is received from a given originator, with a
given sequence number, the node checks whether if a TC message
with similar identification already was received. If it was, it
checks that the previous content is identical to the current
content.
o If the sequence number difference (in absolute value) between the
new TC and previous TC from the same originator is above a given
threshold MAX_TC_DIFF_SEQ_NUM, then duplicate address can be
suspected. Such an event is possible, for instance if another
node sends many non-TC messages or cease to be TC generator for
some time ; thus an additional check is performed on the message
rate: an approximation of the message rate is computed as the
"sequence number difference divided by the reception time
difference". If this message rate is greater than a threshold
MAX_MESSAGE_RATE, then the TC Sequence Number are deemed
inconsistent.
If precise adjustement is desired for the values of
MAX_TC_DIFF_SEQ_NUM, and MAX_MESSAGE_RATE (peak rate), it can be
observed that one of the worst case occurs when two nodes are in
conflict, and one is using the same sequence numbers of the other
with a delay a little greater than DUP_HOLD_TIME.
4.5. Autoconfiguration State
4.5.1. Introduction
Each node has an "autoconfiguration state". This state is an
indicator of how long the node has been in the network. The central
idea, is that each time a node generates a tentative address, it
should enter the network gradually, running a restrained version of
the OLSR protocol. By this way, that the node can detect which
addresses are being used, checking for duplicates of its own address,
while avoiding to disrupt the routing tables of the other nodes, in
the event that its address is actually found to be in conflict.
4.5.2. Functionning
There are exactly 4 autoconfiguration states, in each of which the
behavior of the node is:
Mase & Adjih Expires August 31, 2006 [Page 25]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
NO_ADDRESS_STATE: In this state a node does not have its own address,
and it MUST NOT process and forward routing control messages
genarated by other nodes. It MUST NOT participate in data
forwarding. It MAY generate a tentative address by means of a
pre-determined address generation method. When it generates its
tentative address, it enters the HELLO_STATE.
HELLO_STATE: In this state, a node generates HELLO messages, but not
topology control (TC) messages. It does not participate in MPR
selection nor MPR flooding, and does not participate in data
packet forwarding either. It doesn't fill the topology set nor
the routing table. When it detects that it has an address
conflict with other nodes based on received hello messages (rules
R1 to R3, and rule R12), it MUST return NO_ADDRESS_STATE. When a
pre-determined time has elapsed, in this state, without detecting
address conflict, the node enters the TOPOLOGY_STATE.
TOPOLOGY_STATE: In this state, a node generates HELLO messages, but
not TC messages. It processes TC messages, and performs MPR
selection, but cannot be MPR itself and hence, does not forward TC
messages. It fills the network topology set but not the routing
table, and does not participate in data packet forwarding. When
it detects that it has an address conflict with another node
(based rules R1 to R12 applied to received messages), it MUST
return NO_ADDRESS_STATE. When a pre-determined time elapses in
the TOPOLOGY_STATE without detecting address conflict, the node
enters the NORMAL_STATE.
NORMAL_STATE: In this state, the node is running the "normal" OLSR
protocol, completed with the algorithms specified in this document
, and without message processing/generation restrictions
associated to the state. More precisely, the node generates both
HELLO messages and TC messages as usual. It processes TC messages
generated by other nodes and forwards them as usual based on MPR
flooding. It fills the topology set, calculates routing tables
and participates in data forwarding. Only nodes in the
NORMAL_STATE are selected as the intermediary nodes (forwarders)
in the routing table calculation. When the node detects that it
has an address conflict with other nodes (according to one of the
rules R1 to R12), it MUST return the NO_ADDRESS_STATE.
Mase & Adjih Expires August 31, 2006 [Page 26]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
The behavior in each state is summarized in the following table:
+--------------------+-----------+-----------+------------+---------+
| State | NO_ | HELLO_ | TOPOLOGY_ | NORMAL_ |
| | ADDRESS_ | STATE | STATE | STATE |
| | STATE | | | |
+--------------------+-----------+-----------+------------+---------+
| Address generation | yes | no | no | no |
| | | | | |
| Selectable as MPR | no | no | no | yes |
| | | | | |
| MPR selection | no | no | yes | yes |
| | | | | |
| TC message | no | no | no | yes |
| forwarding | | | | |
| | | | | |
| TC message | no | no | yes | yes |
| processing | | | | |
| | | | | |
| MPR flooding | no | no | no | yes |
| | | | | |
| TC message | no | no | no | yes |
| generation | | | | |
| | | | | |
| Routing table | no | no | no | yes |
| calculation (and | | | | |
| forwarding) | | | | |
| | | | | |
| DAD rules | no | R1, R2, | R1-R3, | R1-R12 |
| | | R3 | R5-R7, R9, | |
| | | | R11,R12 | |
| | | | | |
| State duration (if | as long | HELLO_ | TOPOLOGY_ | forever |
| no address change) | as no | STATE_ | STATE_ | |
| | address | DURATION | DURATION | |
+--------------------+-----------+-----------+------------+---------+
4.6. Node Familiarity
The concept of "node familiarity" is introduced for use of some
heuristics in MANET-DAD rules. The definition is the following: a
node (or more precisely, an IP address) is "familiar" for another
node, when the last one has had knowledge of existence of the first
one for sufficiently long. An node which is not familiar is
"unfamiliar".
In NOA-OLSR, a node (more precisely, an address) considered familiar
when the time elapsed since the first time that its address has
Mase & Adjih Expires August 31, 2006 [Page 27]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
appeared in any OLSR message, is greater than a fixed time interval
NODE_FAMILIAR_TIME.
Mase & Adjih Expires August 31, 2006 [Page 28]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
5. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
Mase & Adjih Expires August 31, 2006 [Page 29]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
6. Security Consideration
As the standard OLSR does not specify any special security measure,
it makes a target for various attacks (see section 20 of the OLSR
specification [3]) ; NOA-OLSR is subject to the same attacks, but
also to other attacks: such as forging messages in order to
deliberatly trigger some DAD rules, hence forcing an address change,
or increasing OLSR control traffic. However the conditions in which
such attacks can be sucessfully conducted are some conditions in
which more severe attacks can be conducted with the standard OLSR
protocol. Hence, in practice, vulnerability of NOA-OLSR protocol
against deliberate attacks, is identical to the vulnerability of the
standard OLSR protocol.
Mase & Adjih Expires August 31, 2006 [Page 30]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
7. Acknowledgements
This work was funded by Strategic Information and Communications R&D
Promotion Programme (SCOPE), Ministry of Internal Affairs and
Communications, Japan.
The authors would also like to thank Sota Yoshida, Masoto Goto,
Takashi Hasegawa for their valuable contributions to NOA-OLSR, along
wth Yasuhiro Owada, and many other students of Information and
Communication Network Laboratory for other various aspects for
developping and testing of this protocol.
(document generation date: Mon Feb 6 11:34:24 2006)
Mase & Adjih Expires August 31, 2006 [Page 31]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[2] Weniger, K., "Passive Duplicate Address Detection in Mobile Ad
hoc Networks", IEEE Journal of Selected Areas of
Communications(JSAC), vol.23, No.3, 2005.
[3] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[4] Ogier, R., Templin, F., and M. Lewis, "Topology Dissemination
Based on Reverse-Path Forwarding (TBRPF)", RFC 3684,
February 2004.
[5] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC 3561, July 2003.
[6] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad
Hoc Networks (DSR)", draft-ietf-manet-dsr-10 (work in
progress), July 2004.
[7] Clausen, T., "The Optimized Link-State Routing Protocol version
2", draft-ietf-manet-olsrv2-00 (work in progress), August 2005.
[8] Chakeres, I., Belding-Royer, E., and C. Perkins, "Dynamic MANET
On-demand (DYMO) Routing", draft-ietf-manet-dymo-03 (work in
progress), October 2005.
[9] Ruffino, S., Stupar, P., and T. Clausen, "Autoconfiguration in
a MANET: connectivity scenarios and technical issues",
draft-ruffino-manet-autoconf-scenarios-00 (work in progress),
October 2004.
[10] Mase, K. and C. Adjih, "A common framework for
autoconfiguration of stand-alone ad hoc networks
draft-mase-autoconf-framework-01", Feburary 2006.
Mase & Adjih Expires August 31, 2006 [Page 32]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Index
D
Duplicate Address Detection Rule
R1 11
R2 12
R3 12
R4 14
R5 14
R6 16
R7 17
R8 18
R9 20
R10 21
R11 21
R12 22
I
Index
Document structure 6
T
terminology
Address Conflict 7
Autoconfiguration State 7
Busy Address 7
Conflicting Address 7
Conflicting Message 7
Conflicting Node 7
DAD Rule 7
Duplicate Address Detection (DAD) 7
familiar address 7
familiar node 7
NOA-OLSR 8
Routing Table Contamination Avoidance 8
Sequence Number Consistency 8
Standard OLSR 8
TC Generator 8
unfamiliar node 7
Mase & Adjih Expires August 31, 2006 [Page 33]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
Authors' Addresses
K. Kenichi Mase
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/
Cedric Adjih
INRIA
(Domaine de Voluceau, Rocquencourt, France)
Email: cedric.adjih@inria.fr
Mase & Adjih Expires August 31, 2006 [Page 34]
Internet-Draft No Overhead Autoconfiguration OLSR Feb 2006
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 (2006 ). 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.
Mase & Adjih Expires August 31, 2006 [Page 35]
