LSIIT - ULP C. Jelger
Internet-Draft T. Noel
Expires: October 22, 2004 A. Frey
LSIIT
April 23, 2004
Gateway and address autoconfiguration for IPv6 adhoc networks
draft-jelger-manet-gateway-autoconf-v6-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Adhoc networks are formed by the spontaneous collaboration of
wireless nodes when no networking infrastructure is available. When
communication to the Internet is desired, one or more nodes must act
as gateways for the adhoc network. In this case, global addressing of
adhoc nodes is required. This document specifies a protocol (node
behaviour, information propagation, message format) which allows
nodes in an adhoc network to discover a gateway/prefix pair which is
used in order to build an IPv6 global address and, when necessary, to
maintain a default route towards the Internet.
Jelger, et al. Expires October 22, 2004 [Page 1]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Summary of the protocol operation . . . . . . . . . . . . . . 4
3. Format of the GW_INFO message . . . . . . . . . . . . . . . . 6
4. Processing GW_INFO messages . . . . . . . . . . . . . . . . . 7
4.1 GW_INFO messages sent by gateways . . . . . . . . . . . . . . 7
4.2 Forwarding an updated GW_INFO message . . . . . . . . . . . . 7
4.3 Prefix continuity validation . . . . . . . . . . . . . . . . . 7
4.4 Using GW_INFO information . . . . . . . . . . . . . . . . . . 8
5. Detailed mode of operation . . . . . . . . . . . . . . . . . . 10
5.1 BOOTSTRAP alogorithms for initial upstream neighbor
selection . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 REFRESH algorithms for upstream neighbor selection . . . . . . 11
5.3 Validating bi-directional links . . . . . . . . . . . . . . . 12
6. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 15
7. Protocol parameters values . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20
Jelger, et al. Expires October 22, 2004 [Page 2]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
1. Introduction
In contrast with current wireless networks, adhoc networks require no
pre- existing infrastructure to exist. Because of the inherent
limited propagation range of radio transmissions, adhoc nodes
collaborate to forward (and route) packets within this spontaneous
multi-hop network. Two families of protocols have been proposed by
the IETF MANET working group to achieve routing in adhoc networks.
Reactive protocols like [1] and [2] build routes "on-demand", i.e.
only when a route to a certain destination is needed. In contrast,
proactive protocols like [3] and [4] maintain an up-to- date view of
the network topology and routing tables entries are updated
accordingly.
One of the challenge of adhoc networking is the autoconfiguration of
global addresses, allowing nodes to be reachable from outside the
adhoc network. To achieve this functionality, one (or possibly more)
node of the adhoc network must provide connectivity to the rest of
the Internet, thus acting as a gateway for the other adhoc nodes.
There has been a few proposals (mainly for IP version 4) for
automatic address allocation in adhoc networks, and there has also
been proposals [5] which present ways of discovering a gateway. This
work differs from previous work as follows. First, we combine both
problems (global address configuration and gateway discovery) as done
in classic wired IPv6 networks : the gateway is therefore responsible
for prefix announcement. Second and in contract with some previous
work, our method supports multiple gateways which may announce
different global prefixes. And third, this work aims to propose a
method that is independent (in terms of message semantics) of the
underlying routing protocol, as our proposed method can be used with
both proactive and reactive routing protocols. When multiple
(different) prefixes are available, the prefix selection policy and
the information propagation technique that are used both naturally
leads to the concept of "prefix continuity". With prefix continuity,
any node A that selected a given prefix P has at least one neighbor
with prefix P on its path to the selected gateway G. The prefix
continuity feature ensures that there exists, between the node A and
its gateway G, a path of nodes such that each node on this path uses
the same prefix P than the node A and its gateway G.
Jelger, et al. Expires October 22, 2004 [Page 3]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
2. Summary of the protocol operation
Each gateway is responsible for sending periodical information in
order to notify nodes in the ad hoc network about its existence and
the prefix it uses. Such information is periodically sent by each
gateway in a type of message which will further be noted GW_INFO
message. Each GW_INFO message contains a number of fields which allow
nodes to exchange gateway information and which also allow a node to
select which gateway is most appropriate if more than one gateway is
available. Without going into details (they are given in sections 3
and 4), the GW_INFO message contains the global address of the
gateway, the length of the prefix part of the address, a sequence
number used to avoid the forwarding of obsolete information, and the
distance to the gateway as perceived by the node sending the GW_INFO
message.
A GW_INFO message MUST be sent with a hop limit of 1. Therefore the
initial GW_INFO message sent by the gateway is only received by its
directly connected neighbors. If such a neighbor decides to use the
information contained in the GW_INFO message, it must immediately
forward an updated version of the message (as detailed in Section
4.2). The updated message MUST also be sent with a hop limit of 1. If
a node receives multiple GW_INFO messages it must only forward an
updated version of the message whose content has been used by this
node to create (or refresh) its global address. When a given node A
decides to use the GW_INFO message sent by its neighbor B, B becomes
what we define as the upstream neighbor of A. The term is used
throughout this document to refer to node B when node A is
considered. Upon reception of a GW_INFO sent by its upstream
neighbor, a node immediately forwards (to its 1-hop neighborhood) an
updated version of the GW_INFO message. The prefix information
contained in an initial GW_INFO message (sent by a gateway) is
therefore propagated in a hop-by-hop manner among a subset of nodes
of the ad hoc network which have decided to use this prefix and
gateway. This method of propagation naturally leads to prefix
continuity. The main advantage of prefix continuity is that routing
via the gateway can be achieved without the need of an IPv6 routing
header. This is detailed later in this document.
The mechanisms proposed in this document (i.e. message format, prefix
selection algorithms, forwarding method) can be integrated in the
routing daemon itself or can run as a parallel stand-alone daemon. As
described later, our proposal requires the use of a bi-directional
link between a node and its upstream neighbor. If our proposal is
integrated as part of the operation of a proactive routing protocol,
it can benefit from the mechanisms used by such a routing protocol to
maintain bi-directionnal links with its neighbors (i.e. exchange of
HELLO messages). This information is mainly used by a node to ensure
Jelger, et al. Expires October 22, 2004 [Page 4]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
that it has a bi-directional link with its upstream neighbor. In
contrast, if our proposal is not integrated as part of the routing
protocol operation (either proactive or reactive), or even if it is
integrated into a reactive routing protocol, a specific light
mechanism must be used by each node to ensure it has a bi-directional
link with its upstream neighbor. This is detailed in Section 5.3.
It is also here worth mentioning that, in contrast to the work
proposed in [5] for AODV and in the particular case of reactive
protocols, the GW_INFO information is not used to add a default route
towards the gateway. We indeed believe that the reactive nature of
such protocols avoids the need of keeping a default route which, by
nature, prevents such a protocol from being reactive. Details about
this concern are given in Section 4.4.
The rest of this document is organized as such. The next section
details the format of the GW_INFO message. Section 4 details the
methods that should be used to send (and forward) GW_INFO messages.
It also describes the method that is used by nodes in order to check
prefix continuity, i.e. to detect that a node becomes isolated from
other nodes using the same prefix. Section 5 defines a light
mechanism that can be used to check if a link is bi- directional
between two neighboring nodes. This section also details the
algorithms used by a node to select and update its upstream neighbor.
Jelger, et al. Expires October 22, 2004 [Page 5]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
3. Format of the GW_INFO message
The format of the GW_INFO message used to dissemate the gateway and
prefix information is shown in Figure 1. This message can be sent via
control packets of a routing protocol if it is integrated as part of
its operation, or via UDP packets sent to a not yet assigned port
number. In both cases, The GW_INFO MUST be sent in an IPv6 packet
with a hop limit of 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Reserved | Neighborhood connectivity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Distance | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Global Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. GW_INFO message format
Option Length : 8-bit unsigned integer. Gives the length, in bytes,
of the GW_INFO message.
Reserved : unused (for future use). Must be set to 0.
Neighborhood connectivity : these 16 bits are used by a node to check
if it has bi-directional links with its neighbors. This is detailed
in Section 5.3.
Prefix Length : 8-bit unsigned integer. Gives the length, in bits, of
the prefix part of the gateway address given in the Gateway Global
Address field. The maximum allowed value is 64 (for a /64 prefix).
Distance : 8-bit unsigned integer. Gives the distance to the gateway,
in hops, as perceived by the node sending the GW_INFO message. A
gateway itself MUST set this field to zero.
Sequence number : 16-bit unsigned integer. An integer value used to
avoid the forwarding of duplicate information. Details about the use
of this field are given in Section 5.
Gateway Global Address : 128-bit global address of the gateway.
Jelger, et al. Expires October 22, 2004 [Page 6]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
4. Processing GW_INFO messages
Our proposed protocol strongly relies on the way by which GW_INFO
messages are exchanged and processed. These messages are used by each
node to select their gateway and the prefix associated to it. They
are also used by each node to ensure that it is not isolated from
other nodes sharing the same prefix that it decided to use, or in
other words, to ensure that the prefix continuity condition is
satisfied. A GW_INFO message MUST always be sent in a packet with a
hop limit of 1, and the destination address of the IPv6 header of the
packet containing the GW_INFO message MUST be ff02::2 (all routers).
The source address of such a packet must be the link local address of
the sender.
4.1 GW_INFO messages sent by gateways
As described earlier, each gateway is responsible for the initial
sending of periodical GW_INFO messages. Each gateway MUST send every
GW_INFO_REFRESH_PERIOD a GW_INFO message. The "Distance" field of
this message MUST be set to 0. Initially (e.g. after a reboot, upon
restart of the daemon) the "Sequence number" field must be set to 0
by the gateway. This number must be increased by one upon each
sending of a GW_INFO message. When the maximum possible value of this
field is reached, the subsequent value MUST be 0. Both the "Prefix
Length" field and the "Gateway Global Address" field are used to
indicate the prefix that should be used by an ad hoc node to build
its IPv6 global address. It is preferable if a gateway announces a /
64 prefix.
4.2 Forwarding an updated GW_INFO message
Depending on the topology of the ad hoc network and on the selection
algorithms used by each node to choose its upstream neighbor (the
algorithms are described in sections 5.1 and 5.2), each node may
receive multiple GW_INFO messages. It then selects one of its
neighbor as its upstream neighbor. Each node subsequently forwards an
updated version of the GW_INFO sent by its upstream neighbor. The
"Distance" field of the updated GW_INFO message (say N) must be equal
to the "Distance" field of the GW_INFO message (say O) sent by the
upstream neighbor plus one, i.e. N.Distance = O.Distance + 1. The
field "Neighborhood connectivity" must be updated according to what
is described in Section 5.3. A node MUST forward an updated GW_INFO
message immediately after the reception of the GW_INFO sent by its
upstream neighbor. A node MUST NOT forward a GW_INFO message sent by
a node that is not its upstream neighbor.
4.3 Prefix continuity validation
Jelger, et al. Expires October 22, 2004 [Page 7]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
Each node uses all the GW_INFO messages it receives to maintain a
list of its neighbors (the NEIGHBORS table) along with the prefix(es)
they use. This table allows a node to check the prefix continuity
condition. It is also used by the bootstrap algorithm (described in
Section 5.1) which is used when a new prefix (or an initial prefix)
must be chosen by a node. Upon reception of a GW_INFO message, a node
must add the address of the sender of the message to its list of
neighbors. The prefix information contained in the GW_INFO message
must also be stored. A lifetime timer equal to NEIGH_LIFE must be
associated with each new entry. If a neighbor was already in the
NEIGHBORS table, the lifetime timer must be reset to NEIGH_LIFE, and
the prefix information must be updated according to the information
contained in the newly received GW_INFO message. For a given node, if
the timer associated to its current upstream neighbor expires, the
node MUST use its REFRESH algorithm to find a new upstream neighbor
(see Section 5.2 on REFRESH algorithms).
4.4 Using GW_INFO information
The GW_INFO received by a node from its upstream neighbor must be
used by this node to create a global IPv6 address. This global
address is created by adding the EUI of the interface from which the
GW_INFO message has been received to the prefix P contained in the
GW_INFO message. If the prefix length is smaller than 64 bits, it
must be padded with zeros to reach a length equal to 64 bits. The
lifetime of the address MUST be set to ADDRESS_LIFE. The lifetime of
the address MUST be reset to ADDRESS_LIFE each time that the upstream
neighbor of the node sends a GW_INFO message that contains the prefix
P. The IPv6 duplicate address detection (DAD) procedure MUST NOT be
performed, mainly because it has been designed to work on a broadcast
medium, and also because there is a very low probability of address
duplication when EUIs are used.
With proactive routing protocols, each node MUST also add in its
routing table a default entry with its upstream neighbor as next hop.
The prefix continuity condition ensures that all nodes on the path to
the gateway use the same prefix and have coherent default routes to
reach the gateway. This feature permits to avoid the use of an IPv6
routing header.
default/0 upstream_neighbor
The link between a node and its upstream neighbor MUST therefore be
bi- directional. If our proposed protocol is not integrated in the
operation of the proactive routing protocol (in this case the state
of this link can be known), a simple procedure as described in
Section 5.3 MUST be used to validate the bi-directional nature of the
link. This MUST be done before a node is selected as upstream
Jelger, et al. Expires October 22, 2004 [Page 8]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
neighbor, as defined in Section 5. Note that the default route entry
does not prevent direct routing between ad hoc nodes, as there should
be a /128 host entry in the routing table for each ad hoc node, even
for nodes that use a different prefix.
With reactive routing protocols, the GW_INFO information is not used
to add a default route towards the gateway. We indeed believe that
the reactive nature of such protocols avoids the need of keeping a
default route which, by nature, prevents such a protocol from being
reactive. However, the link between a node and its upstream neighbor
MUST be validated as bi-directional, by using the method described in
Section 5.3. This condition ensures that there is at least one path
for "route requests" sent by this node to reach the gateway it has
selected to build its global address. This is crucial if the requests
are for a correspondent which is outside the ad hoc network and if
ingress filtering is used by other gateways. Moreover, to ensure that
direct routing through the ad hoc network is always achieved between
nodes with different prefixes, the route discovery procedure of the
reactive routing protocol SHOULD follow a path accumulation paradigm
such as the one used in [6].
Jelger, et al. Expires October 22, 2004 [Page 9]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
5. Detailed mode of operation
This section gives a detailed description of the mode of operation of
our proposed protocol. We first detail the mechanism that is used by
a node to check if it has a bi-directional link with a potential
upstream neighbor, i.e. a neighbor it is about to select as upstream
neighbor. We then explain the bootstrap algorithm used by a node to
select its initial upstream neighbor and which is also used to select
a new upstream neighbor when the prefix continuity condition is
broken. Third, we detail the different algorithms that can be used by
a node to choose its upstream neighbor.
5.1 BOOTSTRAP alogorithms for initial upstream neighbor selection
As presented in the next section, we propose a number of algorithms
which are used by each node to select its upstream neighbor. These
algorithms, which we call REFRESH algorithms, are used when a node
already has a global address (and an upstream neighbor) and their
objective is to maintain or update the selection of the upstream
neighbor. Each REFRESH algorithm gives preference to a certain number
of criteria. In parallel, we propose two different BOOTSTRAP
algorithms, and each one is linked with the REFRESH algorithms
proposed in the next section. The BOOTSTRAP algorithms are used when
a node cannot find an upstream neighbor with its REFRESH algorithm.
In all cases, a neighbor MUST be validated as bi-directional neighbor
before being selected as an upstream neighbor (see Section 5.3).
The first BOOTSTRAP algorithm which we call B_DISTANCE is very
simple. It MUST be used with the REFRESH algorithms F_DISTANCE. With
B_DISTANCE, a node which does not have an upstream neighbor selects,
as its upstream neighbor, the first node from which it receives a
GW_INFO message.
The second BOOTSTRAP algorithm which we call B_NOWAIT must be used
with the REFRESH algorithm F_STABILITY. With B_NOWAIT, a node A which
does not have an upstream neighbor waits until it receives a GW_INFO
message. Upon reception of a GW_INFO message, this node immediately
chooses the sender of the GW_INFO message as its new upstream
neighbor.
The third BOOTSTRAP algorithm which we call B_SLOWSTART must be used
with the REFRESH algorithm F_STABILITY. With B_SLOWSTART, a node A
which does not have an upstream neighbor waits until it receives a
GW_INFO message. Upon reception of a GW_INFO message, this node MUST
wait B_STAB_WAIT_TIME and gather all the GW_INFO it receives during
that period of time. If a GW_INFO message is sent by a neighbor for
which node A already has a stored GW_INFO message, the old GW_INFO
message MUST be replaced by the new one. When the period
Jelger, et al. Expires October 22, 2004 [Page 10]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
B_STAB_WAIT_TIME expires, node A MUST select its upstream neighbor
among the nodes from which it has received a GW_INFO message. To do
so, node A proceeds as such. First, it must group the GW_INFO
messages with respect to the prefix they contain. It will then
selects its upstream neighbor (UN) by using the following algorithm :
Group neighbors according to their prefix
(a selection is always done within the
remaining groups of a previous selection)
For each group and among all entries within a group compute :
- MIN_DIST : the smallest distance value
- NB_NODES : the number of nodes in the group
- AVR_DIST : the average value for all advertised distances
Select group(s) with smallest MIN_DIST
If more than 1 group is selected
Select group(s) with highest NB_NODES
If more than 1 group is selected
Select group(s) with smallest AVR_DIST
If more than 1 group is selected
* Start a timer (2 seconds)
* Choose 1st group from which a node sends a GW_INFO msg.
* selects this node as UN
* STOP ALGORITHM
If timer expires, choose 1st sender of a GW_INFO msg. as UN
Endif
Endif
Endif
(within "winning group")
* Start a timer (2 seconds)
* Selects as UN the 1st node that sends a GW_INFO message
If timer expires, choose 1st sender of a GW_INFO message as UN
5.2 REFRESH algorithms for upstream neighbor selection
The REFRESH algorithms are used when a node already has an upstream
neighbor. If a node cannot cannot find an upstream neighbor when
using its REFRESH algorithm (i.e. the lifetime timer of its current
upstream neighbor has expired and a new upstream neighbor cannot be
selected with the REFRESH algorithm), it MUST follows the associated
BOOTSTRAP algorithm until a new upstream neighbor can be found. When
an upstream neighbor is found with the BOOTSTRAP algorithm, the node
Jelger, et al. Expires October 22, 2004 [Page 11]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
MUST follow the behavior its REFRESH algorithm. Note that a lifetime
timer is associated to the upstream neighbor as for any other
neighbors (see Section 4.3). If this timer expires, a new upstream
neighbor must be found.
The most simple REFRESH algorithm is F_DISTANCE. Its associated
BOOTSTRAP algorithm is B_DISTANCE. With F_DISTANCE, a node MUST try
to replace its current upstream neighbor if it receives a GW_INFO
message that contains a smaller "Distance" value than the one sent by
its current upstream neighbor. The sender of this GW_INFO becomes a
potential (new) upstream neighbor. If the link with this node is
validated as bi-directional, this node becomes the upstream neighbor.
With this algorithm, a node selects the prefix of one of its closest
gateways.
The second REFRESH algorithm is F_DISTANCE_STABILITY. Its associated
BOOTSTRAP algorithms are B_SLOWSTART and B_NOWAIT. This REFRESH
algorithm is similar to F_DISTANCE, with the following additional
restriction : for a given node, a potential upstream neighbor MUST
have the same prefix than the one in use by this node. With this
algorithm, the prefix of a node remains the same as long as this node
can find an upstream neighbor which uses the same prefix.
The third REFRESH algorithm is F_DELAY. Its associated BOOTSTRAP
algorithms are B_SLOWSTART and B_NOWAIT. F_DELAY has the same
restriction than F_DISTANCE_STABILITY : for a given node, a potential
upstream neighbor MUST have the same prefix than the current upstream
neighbor of this node. The difference is that a potential upstream
neighbor is selected as follows. If node A has an upstream neighbor
that sent a GW_INFO message with "Sequence number" N and "prefix" P,
it selects as a potential upstream neighbor, the first node than
sends a GW_INFO message with "prefix" P, and "Sequence number" equal
to (N+1) (or equal to 0 if N was equal to the maximum possible value
of the "Sequence number" field). If the link to the potential
upstream neighbor is validated as bi-directional, the potential
upstream neighbor becomes the new upstream neighbor.
5.3 Validating bi-directional links
The method described in this paragraph must be used if no other
mechanism is available for a node to check if it has a bi-directional
link with one of its neighbor. For example, if our proposal is
integrated in the operation of a proactive routing protocol which
maintains a view of its bi-directional neighbors, the following
method is not required. In all other cases, the proposed method MUST
be used.
When a node is about to select one of its neighbor as upstream
Jelger, et al. Expires October 22, 2004 [Page 12]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
neighbor, it must ensure it has a bi-directional link with this
neighbor. This condition must be checked at regular intervals. If a
node A has selected node B as a potential candidate to become its new
upstream neighbor, it must assign one of the bit of the "Neighborhood
connectivity" field to node B. We say that Node A assigns a "Neighbor
ID" to Node B by sending a Neighbor ID message to Node B. The format
of this message is shown in Figure 2. The 8-bit unsigned integer
"Neighbor ID" field must be set to a value not already assigned. The
maximum allowed value for this field is 15. The 8-bit unsigned
integer "ACK" field must be set to 0. A specific table is used by
each node to store the association Neighbor ID <--> Neighbor Address
when it has been validated. This table is called the CONNECT table.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID | ACK |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Neighbor ID message
Node B replies to this message by also assigning a Neighbor ID to
Node A. It must also acknowledge the reception of the previous
message by setting the ACK field to 1. This message must also be
acknowledged by Node A by sending a Neighbor ID message with the ACK
field set to 1 and the "Neighbor ID" field set to the value assigned
to B. Upon reception of the message sent by Node B, Node A creates an
entry in its CONNECT table for Node B with its assigned Neighbor ID.
This entry has a lifetime timer associated to it : it must be set to
CONNECT_LIFE. Upon expiration of the timer, the entry is removed.
Upon reception of the second message sent by Node A to Node B, Node B
creates an entry for Node A in its CONNECT table.
If Node A assigned a Neighbor ID equal to N to Node B, it will
indicate in its subsequent GW_INFO messages that Node B is in its
CONNECT table. To do so, Node A sets the Nth bit of the "Neighborhood
connectivity" field of its GW_INFO message to 1. Because Node B knows
it has been assigned the Nth bit, it can check if it is still in the
CONNECT table of Node A. Upon reception of this message, Node B also
reset to CONNECT_LIFE the timer associated to Node A in its CONNECT
table. A similar method is used by Node B to notify Node A that it is
still in its CONNECT table.
If an entry with ID Y in the CONNECT table of a node expires, the Yth
bit of the "Neighborhood connectivity" field of the subsequent
GW_INFO messages sent by this node must be set to 0. Furthermore, if
Jelger, et al. Expires October 22, 2004 [Page 13]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
a node C which has been assigned ID Z by Node D receives a GW_INFO
message sent by node D with the Zth bit of the "Neighborhood
connectivity" field set to 0, it must remove the entry associated to
Node D from its CONNECT table because the link has become
uni-directional.
When a node performs the B_SLOWSTART algorithm, it must carry on
sending GW_INFO messages otherwise its neighbors may think they have
lost their link with that node. However, the node must not be chosen
as upstream neighbor because it performs the B_SLOWSTART algorithm.
Therefore it must send specific GW_INFO messages with a NULL gateway
address (i.e. ::), a NULL prefix length and a distance value set to
255. The node must continue to use the Neighborhood Connectivity
field as usual.
Jelger, et al. Expires October 22, 2004 [Page 14]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
6. DNS considerations
As an extension to the proposed protocol, DNS information could also
be sent in GW_INFO messages. This would allow a node to select a
gateway that also permits to reach a DNS server. The GW_INFO
extension could be easily extended to include a field which contains
the IPv6 global address of a DNS server, as shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Length | Reserved | Neighborhood connectivity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Distance | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Global Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DNS server Global Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Extended GW_INFO message format
Jelger, et al. Expires October 22, 2004 [Page 15]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
7. Protocol parameters values
GW_INFO_REFRESH_PERIOD 2 seconds
NEIGH_LIFE LINK_LOST * GW_INFO_REFRESH_PERIOD seconds
LINK_LOST 3
ADDRESS_LIFE ADDR_LOST * GW_INFO_REFRESH_PERIOD seconds
ADDR_LOST 5
CONNECT_LOST 2.5
CONNECT_LIFE CONNECT_LOST * GW_INFO_REFRESH_PERIOD seconds
B_STAB_WAIT_TIME 1.5 * GW_INFO_REFRESH PERIOD seconds
Jelger, et al. Expires October 22, 2004 [Page 16]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
8. Acknowledgements
The authors wish to thank Prof. Jean-Jacques Pansiot for his helpful
comments and suggestions.
Jelger, et al. Expires October 22, 2004 [Page 17]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
References
[1] Perkins, C., Belding-Royer, E. and S. Das, "Ad hoc On-Demand
Distance Vector (AODV) Routing", RFC 3561, July 2003.
[2] Johnson, D., Maltz, D. and Y. Hu, "The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks (DSR)", I-D
draft-ietf-manet-dsr-09.txt, April 2003.
[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] Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A. and A.
Tuominen, "Internet Connectivity for Mobile Ad hoc networks",
I-D draft-wakikawa-manet-globalv6-02.txt, November 2002.
[6] Perkins, C., Belding-Royer, E. and I. Chakeres, "Internet
Connectivity for Mobile Ad hoc networks", I-D
draft-perkins-manet-aodvbis-00.txt, October 2003.
Authors' Addresses
Christophe Jelger
LSIIT - Université Louis Pasteur
Pôle API, bureau C429
Boulevard Sébastien Brant
Illkirch 67400
FRANCE
Phone: +33 390 24 45 90
EMail: jelger@dpt-info.u-strasbg.fr
Thomas Noel
LSIIT - Université Louis Pasteur
Pôle API, bureau C428
Boulevard Sébastien Brant
Illkirch 67400
FRANCE
Phone: +33 390 24 45 92
EMail: noel@dpt-info.u-strasbg.fr
Jelger, et al. Expires October 22, 2004 [Page 18]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
Arnaud Frey
LSIIT - Université Louis Pasteur
Pôle API, bureau C429
Boulevard Sébastien Brant
Illkirch 67400
FRANCE
Phone: +33 390 24 45 90
EMail: frey@clarinet.u-strasbg.fr
Jelger, et al. Expires October 22, 2004 [Page 19]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jelger, et al. Expires October 22, 2004 [Page 20]
Internet-Draft Adhoc gateway/prefix autoconf April 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jelger, et al. Expires October 22, 2004 [Page 21]