Internet DRAFT - draft-ruffino-manet-autoconf-multigw
draft-ruffino-manet-autoconf-multigw
AUTOCONF S. Ruffino
Internet-Draft P. Stupar
Expires: December 28, 2006 Telecom Italia
June 26, 2006
Automatic configuration of IPv6 addresses for MANET with multiple
gateways (AMG)
draft-ruffino-manet-autoconf-multigw-03
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 December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes AMG, a mechanism for stateless
autoconfiguration of IPv6 addresses for Mobile Ad-hoc Networks
(MANETs), connected to the Internet by means of one or more gateways.
Network prefixes are disseminated by Internet gateways and are used
by nodes to configure a set of global IPv6 addresses. An algorithm
is specified, by which nodes can choose the optimal address for data
traffic. Configured global addresses are also advertised to other
Ruffino & Stupar Expires December 28, 2006 [Page 1]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
MANET nodes, to minimize latencies in case of gateway failures, MANET
partitions and mergers. The specified mechanism aims to be
independent from any particular MANET routing protocol and to
effectively exploit multiple gateways.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Scenarios . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement and assumptions . . . . . . . . . . . . . . 5
3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
4. AMG Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Logical data structures . . . . . . . . . . . . . . . . . . . 10
5.1 Prefix Information Base . . . . . . . . . . . . . . . . . 10
5.2 Global Addresses Information Base (GAIB) . . . . . . . . . 10
5.2.1 Global Addresses Information Base Management . . . . . 11
6. Prefix Advertisement . . . . . . . . . . . . . . . . . . . . . 13
6.1 Prefix Advertisement (PA) messages format . . . . . . . . 13
6.2 PA message generation . . . . . . . . . . . . . . . . . . 15
6.3 PA message processing and PIB management . . . . . . . . . 15
7. Address configuration mechanism . . . . . . . . . . . . . . . 17
7.1 MANET-local Address configuration . . . . . . . . . . . . 17
7.2 Global addresses configuration . . . . . . . . . . . . . . 17
7.2.1 Best Prefix Selection Algorithm . . . . . . . . . . . 17
7.3 Global addresses broadcasting . . . . . . . . . . . . . . 19
7.3.1 OLSRv1 operations . . . . . . . . . . . . . . . . . . 19
7.3.2 OLSRv2 operations . . . . . . . . . . . . . . . . . . 20
7.3.3 DYMO operations . . . . . . . . . . . . . . . . . . . 20
7.4 Gateway operations . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1 Normative references . . . . . . . . . . . . . . . . . . . 24
10.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 26
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
B. Considerations on address changes . . . . . . . . . . . . . . 28
C. Prefix Advertisement Examples . . . . . . . . . . . . . . . . 29
D. OLSRv1 operations . . . . . . . . . . . . . . . . . . . . . . 31
D.1 Data structures: MID Information Base . . . . . . . . . . 31
D.2 MID messages . . . . . . . . . . . . . . . . . . . . . . . 32
D.2.1 MID message generation . . . . . . . . . . . . . . . . 32
D.2.2 MID message forwarding . . . . . . . . . . . . . . . . 32
D.2.3 MID message processing . . . . . . . . . . . . . . . . 33
E. Proposed Values for Constants . . . . . . . . . . . . . . . . 34
E.1 Emission Intervals . . . . . . . . . . . . . . . . . . . . 34
E.2 Holding Time . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 35
Ruffino & Stupar Expires December 28, 2006 [Page 2]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
1. Introduction
This document specifies AMG, a general-purpose stateless mechanism
for automatic configuration of topologically correct, globally valid
IPv6 addresses on nodes in a MANET connected to the Internet through
one or more Internet gateways (see [I-D.singh-autoconf-adp]).
An overview of AMG can be given as follows: gateways periodically
disseminate their IPv6 prefixes in the MANET; when nodes receive such
prefixes, they build a set of global addresses, rank them with a
best-prefix selection algorithm, start using one or more of them for
data traffic and concurrently advertise them back to other MANET
nodes.
An important feature of AMG is the use of a best-prefix selection
algorithm, which enables MANET nodes to continuosly choose the best
address to use, according to the MANET topology. In fact, a node can
change the global address in use e.g. after the failure of the
gateway announcing the prefix from which it derived its used global
address or for performance reasons, e.g. to optimize downstream data
traffic path. A second important feature is address advertisement:
it enables nodes and gateways, to know all the addresses configured
on each other nodes and to build routes towards them: in particular,
packets arriving at the gateways from the Internet directed to any
addresses of MANET nodes, can be routed with no delay, even after
partitioning occur and many nodes may be forced to change addresses
in use.
AMG aims to be independent from any particular MANET routing
protocol; nevertheless we specify detailed operations in case the
Optimized Link State Routing (OLSR) [RFC3626] is used. AMG uses the
Generalized MANET Packet/Message Format [I-D.packetbb] for Prefix
Advertisement messages.
This document is organized as follows: Section 2 describes the
applicability scenarios; Section 3 exposes the problem of global
address configuration in case of multiple gateways; Section 4
outlines the proposed solution. Logical data structures are detailed
in Section 5 and operations are described in Section 6 and Section 7.
Finally, Appendix B contains some considerations on using AMG with
Mobile IPv6.
Ruffino & Stupar Expires December 28, 2006 [Page 3]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
2. Applicability Scenarios
AMG can be used to configure valid IPv6 addresses on MANET nodes in
different scenarios, both when the MANET is interconnected to the
Internet and when it is standalone. The reference scenario is shown
in Figure 1 (see also [I-D.ruffino-conn-scenarios]). In this
scenario, MANETs are connected to the Internet by means of one or
more gateways (GW1,GW2,GW3). Nodes (N1...N6), that are not directly
linked to the external network, can use multi-hop paths to reach the
gateways and forward outbound traffic to Internet hosts (H1).
H1
|
|
+---------------+
| Internet |**
+---------------+ *
* * *
* * *
* * *
GW1** * GW3
| +--GW2 |
| | | |
---N1--------+ | |
/ \ | N5----N6
N4 \ N2
N3-----/
Figure 1: MANET interconnected to an external network
An Internet gateway is a MANET node, equipped with a MANET interface,
and a second interface, connected to the external network. Multiple
gateways can improve reliability and fault tolerance, as there is no
single point of failure in the network, and enable load balancing of
traffic directed/coming to/from the Internet. Gateways, as well as
nodes, can also be mobile devices, and, as such, can join and depart
to/from the MANET at any time: the number of available gateways can
therefore vary in time.
AMG can also be applied to scenarios where Internet connection is
unavailable, i.e. when MANET is isolated or temporarly disconnected
(see [I-D.ruffino-conn-scenarios] for a description of isolated MANET
scenarios and applications).
Ruffino & Stupar Expires December 28, 2006 [Page 4]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
3. Problem Statement and assumptions
Standard configuration methods for IPv6, i.e. stateful ([RFC3315])
and stateless ([RFC2462]) IPv6 autoconfiguration, cannot be applied
to multi-link networks such as MANETs, as outlined by previous work
([I-D.singh-autoconf-adp], [I-D.perkins-manet-autoconf],
[I-D.wakikawa-globalv6], [I-D.wakikawa-v6-support]). Standard
methods have been designed for single-hop link (e.g. a single LAN
segment), where all hosts and routers share the same link and don't
address MANET intrinsic characteristics, such as multi-hop
connections, partitions and mergers.
This specification aims at solving the problems described in AUTOCONF
Problem Statement [I-D.singh-autoconf-adp]. In particular, it is
focused on global connectivity, i.e. its goals are to enable MANET
nodes to build topologically correct global IPv6 addresses and to
discover and exploit multiple Internet gateways, if present. It is
designed to cope with partitions of the MANET and mergers of two or
more MANETs.
It is worth noting that in the reference scenario (Section 2),
different design choices imply different technical issues and
requirements:
1. In case of multiple GWs announcing *one* network prefix,
partitioning of the MANET may invalid routes in the Internet
towards MANET nodes, compromising end-to-end reachability. E.g.,
if a MANET cloud breaks into two separate parts, each one
containing a gateway, routers in the Internet cannot choose the
correct gateway to deliver traffic for a MANET node. Recovery
could be possible, e.g. using host routes, or using a signalling
path through the Internet (if available), between partitioned
gateways, but, currently, there is no consolidated way (i.e.
IETF standard) to solve the problem. Moreover, the implications
should be carefully studied, because it is quite likely such a
mechanism would require additional protocols/mechanism to run on
Internet routers, gateways and MANET nodes. This might limit the
applicability of single-prefix autoconf to scenarios with no
partitioning at all, e.g. small controlled ad-hoc networks, with
very limited mobility, or static sensor networks.
2. In case of multiple gateways advertising *multiple* network
prefixes, no coordination among gateways is needed, to preserve
Internet routing consistency, even after partitions/mergers,
since traffic is univocally routed towards the gateway owning one
particular prefix. Using all the available prefixes, MANET nodes
can build a "pool" of valid global IPv6 addresses. However,
other problems may arise within the MANET itself.
Ruffino & Stupar Expires December 28, 2006 [Page 5]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
In fact, traffic coming from the Internet is routed through the
gateway which owns the prefix, used by nodes to build source
address for data packets. Nodes' choice of which global address
(and gateway) to use is critical, since it also directly affects
the path followed by downstream data within the MANET: a node
could choose a prefix announced by a very "far" gateway (in terms
of routing metrics), while a "closer" one could exist. In this
case, traffic could flow through a non-optimal path within the
MANET. Therefore, MANET nodes should be able to choose, both at
bootstrap and after major topological changes, the best gateway
(e.g. the "closest" one in terms of routing metrics) to configure
their address(es), in order to minimize latency and delay
variation, maximize throughput and efficiently use radio
resources. This can be summarized as the "best prefix selection"
problem. Note that this problem is separate from the selection
of a default gateway, which defines the default route for traffic
directed to the Internet.
3. MANET nodes could reconfigure (frequently) their global
address(es), due to partitioning, merging, movement and gateway
failure. Following current version of [I-D.rfc2461bis], every
unicast IPv6 address should be checked for uniqueness, prior to
configuration. In a multiple-gateway/multiple-prefixes MANET,
this could bring to a large amount of control signalling,
especially if the ad-hoc network is very dynamic.
4. If nodes, involved in communications with Internet hosts, use
only global addresses for route calculation (e.g. in OLSR, use of
global address as originator address), existing MANET routes must
be recomputed when connectivity to the gateway that assigned the
prefix is lost. This, because nodes could choose to reestablish
communications after the outage is detected, by exploiting
another available gateway and therefore configuring a new global
address.
3.1 Assumptions
It is therefore assumed that each gateway owns one or more
topologically correct IPv6 network prefixes, which can be announced
within the MANET. The mechanism by which gateways retreive this
information is out of scope of this specification: it can be manually
configured or dynamically set up, during link establishment towards
the Internet, e.g. using DHCP with Prefix Delegation Option
([RFC3633]).
It is also assumed that different gateways advertise different
prefixes, in order not to require special configuration both on
Ruffino & Stupar Expires December 28, 2006 [Page 6]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
gateways themselves and on Internet routers. Moreover, as discussed
above, use of MANET-local addresses to build in-MANET routes could be
more efficient than use of global addresses, in case of frequent
global address reconfiguration, especially if proactive protocols are
used.
This specification explicitly does not address the problem of
verifying uniqueness of a newly configured address. It is authors'
belief that, due to the very low probability of an address conflict
in IPv6 address space, an active Duplicate Address Detection
mechanism may not be needed. A lightweight passive address conflict
detection and repair mechanism could be used, instead of an try-and-
wait approach (e.g. the model used in [RFC2462]), which can bring to
signalling overhead and long latencies.
The specified autoconfiguration mechanism performs gateway discovery,
but it is assumed that default route calculation is performed by
routing protocol running on MANET nodes. This, because routing
protocol is the only process responsible for calculating optimal
routes in the MANET.
Ruffino & Stupar Expires December 28, 2006 [Page 7]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
4. AMG Overview
AMG operates in 4 phases.
1) MANET-local address configuration
At bootstrap, nodes configure a permanent MANET-local address and
use it as identifier in routing protocol messages (e.g. as main
address in OLSR). This specification recommends the use of IPv6
Unique Local Addresses [RFC4193] to configure MANET-local
addresses. As explained in Section 3, such addresses are not
verified for uniqueness prior to configuration; instead, an
address conflict detection mechanism may be started, that monitors
routing packets and other events, reacting only when a conflict is
detected (out of scope of this specification). When this step
completes, MANET nodes (highly likely) own an unique IPv6 address,
which can be used for communications within the MANET.
2) Prefix Advertisement
Internet gateways periodically advertise global network prefixes
by means of a message, named Prefix Advertisement (PA). It is
assumed that a forwarding engine is available in the MANET. The
current version of this specification assumes the use of SMF
([I-D.SMF]); future versions may define a specialized forwarding
procedure for PAs;
3) Best prefix selection and global address configuration
MANET nodes receive Prefix Advertisement (PA) messages from the
gateways. They use the prefixes stored in PAs to configure a set
of global IPv6 addresses, built according to [RFC4291]: at least,
they build an address from each received prefix. Nodes apply an
algorithm, named Best Prefix Selection (see Section 7.2.1), using
routing metrics of Internet gateways, if available, to rank the
received prefixes. Nodes can use the ranking to select
appropriate source address for Internet traffic.
4) Advertisement of global addresses
Nodes start broadcasting the configured global addresses (in step
3.) to other MANET nodes: this operation enables all nodes to bind
MANET-local addresses, used by routing protocol for path
calculations, to global addresses. As a result, they can use
existing routes to deliver data traffic coming from the Internet
and directed to any global address in the MANET. Routing
protocols can be used for address advertisement: OLSRv1 (with HNA
or MID messages), OLSRv2 (with TC messages) and DYMO already have
the capability to advertise multiple addresses along with the main
address of each node.
Nodes periodically reapply Best Prefix Selection algorithm (step 3.
Ruffino & Stupar Expires December 28, 2006 [Page 8]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
above), inspecting the routing table. The selection can also
reactively triggered, to re-order prefixes after a significant event
occurs, for example:
o one ore more gateways, which advertises prefixes used by the node,
become unreachable.
o node detects a significant topological change, after which the
prefix, previously ranked as the best one, corresponds to an non-
optimal path (see Section 3).
The main advantages of the proposed solution are the following:
o in case of gateway failure or MANET partitioning, nodes can
immediately use another valid global address to start data
communications with other nodes and Internet hosts: no significant
delay due to routing protocol operations is experienced. This,
because the local topological information is bound to a MANET-
local address and is independent from the global address currently
used. As described above (step 4.), all other MANET nodes already
know the correct path to reach the node by this address.
o the path followed by downstream traffic coming from the Internet
can be optimized, with respect to the routing metric. This can be
achieved, using a Best Prefix Selection algorithm (Default Gateway
method, described in Section 7.2.1) that assigns the highest rank
to the address derived from a prefix announced by the default
gateway (i.e., the best one routing protocol chooses).
o a gateway which becomes a node, e.g. as the result of losing
connectivity towards the external network, can immediately receive
downlink traffic by using another active gateway.
Ruffino & Stupar Expires December 28, 2006 [Page 9]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
5. Logical data structures
In this section, two data structures used by AMG are defined: the
Prefix Information Base (PIB), which stores the received prefixes,
and the Global Addresses Information Base (GAIB), which stores global
addresses built by the node. Best prefix Selection algorithm is
applied on GAIB entries.
5.1 Prefix Information Base
The Prefix Information Base (PIB) contains the delegated prefixes
announced by gateways within the MANET and it is filled processing
Prefix Advertisements. It is maintained by each node and gateway.
If a gateway advertises multiple prefixes, PIB MUST be filled with an
entry for each advertised prefix.
Entries of the PIB have the following structure (length of each field
is expressed in octets):
+--------------+----------------------------------------------------+
| Field | Data |
+--------------+----------------------------------------------------+
| P_address | MANET-local address of the gateway which sent the |
| (16) | PA |
| | |
| P_network | A prefix owned by the gateway whose MANET-local |
| (16) | address is P_address |
| | |
| P_prefix_len | Length of the prefix contained in P_network field |
| gth (1) | |
| | |
| P_time (1) | Validity time |
+--------------+----------------------------------------------------+
Table 1: Prefix Information Base (PIB)
5.2 Global Addresses Information Base (GAIB)
The Global Addresses Information Base (GAIB) stores the set of the
global addresses built by a node, after processing Prefix
Advertisements carrying global prefixes, i.e. using global prefixes
contained into PIB. It is maintained on each node and gateway. The
refresh of GAIB entries tightly depends on the state of the entries
of PIB, as the validity of a global Address is bound to the validity
of the global prefix from which the global Address has been derived.
Best Prefix Selection algorithm is applied on entries of GAIB, which
Ruffino & Stupar Expires December 28, 2006 [Page 10]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
are re-ordered accordingly.
Entries of the Global Addresses Information Base have the following
structure:
+--------------+----------------------------------------------------+
| Field | Data |
+--------------+----------------------------------------------------+
| G_address | A valid global IPv6 address, owned by the node |
| (16) | |
| | |
| G_prefix_len | Length of the prefix in G_address |
| gth (1) | |
| | |
| G_metric (1) | Routing metric of the gateway, owner of the prefix |
| | used to build G_address. |
+--------------+----------------------------------------------------+
Table 2: Global Addresses Information Base
Entries in GAIB are used to fill routing protocol messages,
responsible for advertising global addresses of each node to other
MANET nodes (e.g. HNA and MID in OLSRv1), as explained in
Section 7.3. Optimisations, such as advertising only a subset of the
GAIB, to decrease overhead in the network, may be specified in future
versions of this specification.
5.2.1 Global Addresses Information Base Management
For each (valid) prefix contained into Prefix Information Base, a
node creates a new entry as follows:
1. it creates a IPv6 global address as described in [RFC4291] and
stores it in the G_address field. It stores the prefix length in
G_prefix_length.
2. it looks-up the routing table and retreives the metric of the
gateway that advertised the network prefix used to build
G_address, if available. It stores the metric in G_metric field.
It can retreive MANET-local address of the gateway inspecting the
PIB: the node performs a search using network prefix as key. If
the look-up fails, G_metric is left blank.
GAIB maintanance is periodically executed: i.e. routing table look-up
is periodically looked-up, to update values in G_metric field of all
entries.
If an entry stored into Prefix Information Base is removed, e.g.
Ruffino & Stupar Expires December 28, 2006 [Page 11]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
after P_time expiration, all the addresses derived from the expired
prefix must be removed from GAIB as well.
Ruffino & Stupar Expires December 28, 2006 [Page 12]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
6. Prefix Advertisement
This section details format and processing of Prefix Advertisement
(PA) messages in AMG. PAs conform to the generalized message format,
as specified in [I-D.packetbb].
6.1 Prefix Advertisement (PA) messages format
The general PA message structure is shown in Figure 2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | RSRV |1|0|1|0| msg-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| originator-address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-seq-number | msg-tlv-block-length=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| head-length | head :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: head | num-tails |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tail :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tail :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail | tlv-block-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tlv-type-1 | tlv-semantics | length | value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | value | tlv-type-2 | tlv-semantics |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | value | ... | value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ruffino & Stupar Expires December 28, 2006 [Page 13]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Figure 2: Format of Prefix Advertisement messages
Where each field of the message has the following meaning:
o <msg-type> = Prefix Advertisement (T.B.D.)
o <msg-semantics>:
* <originator-address> and <msg-seq-number> are included by
setting bit 1
* bit 3 indicates that the message should be intended for
forwarding even if the message type is unknown to the recipient
o <msg-header-info>
* <originator-address> is filled with the main address of the
gateway sending PA messages
* PA contains <msg-seq-number>
o <addr-block> contains the delegated prefixes owned by the gateway,
which generated the message.
o <tlv-block>
* <tlv-type-1> = VALIDITY_TIME
+ <tlv-semantics>: bit 2 and bit 3 (noindex e multivalue) can
be set to support multiple addresses with different values
+ <value>: validity time of the information stored in the PA
message. It is set to PA_HOLD_TIME. Validity times are
expressed in mantissa and exponent format
* <tlv-type-2> = PREFIX_LENGTH
+ <tlv-semantics>: bit 2 and bit 3 (noindex e multivalue) can
be set to support multiple addresses with different values
+ <value>: prefix length, expressed in octets, of the network
prefix carried in PA message.
o final padding to 32 bit boundary is optional, and is not included
in message length.
This specification assumes use of SMF [I-D.SMF] to broadcast PAs
within the MANET. Using SMF, "hop-count" field, commonly used in
Ruffino & Stupar Expires December 28, 2006 [Page 14]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
MANET protocols, cannot be incremented by nodes, upon forwarding the
message and therefore it is not included in PAs. However, in a
MANET, hop-count between two nodes in a MANET can be generally
different from the metric associated with the route between the same
two nodes, as calculated by routing protocol. Thus, AMG retreives
gateways' metric from the routing table, both to fill GAIB
(Section 5.2.1) and to apply Best Prefix Selection algorithm
(Section 7.2.1).
6.2 PA message generation
PAs are originated by gateways every PA_INTERVAL seconds. Every PA
contains all the prefixes owned by the gateway, along with associated
validity time. The list of prefixes can be partial in each PA
message (e.g., due to message size limitations, imposed by the
network, or other policies), but parsing of all PA messages
describing the interface set from a node MUST be complete within a
certain refreshing period (PA_INTERVAL). The information contained
in the PA messages is used by the nodes to build their Global
Addresses.
6.3 PA message processing and PIB management
PAs are received by all MANET nodes and gateways, which MUST process
every received PA according to this Section. Upon processing a PA
message, the P_time MUST be computed from the VALIDITY_TIME tlv of
the message header (see [RFC3626]). The PIB SHOULD then be updated
as follows; for each network prefix (Network Address, Prefix Length)
in the message:
1. if an entry in the association set already exists, where:
P_addr == Originator Address
P_network_addr == Network Address
P_prefix_length == Prefix Length
then the holding time for that entry MUST be set to:
P_time = current time + validity time
2. otherwise, a new entry MUST be recorded with:
P_gateway_addr = Originator Address
Ruffino & Stupar Expires December 28, 2006 [Page 15]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
P_network_addr = Network Address
P_prefix_length = Prefix Length
P_time = current time + validity time
Ruffino & Stupar Expires December 28, 2006 [Page 16]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
7. Address configuration mechanism
This section describes the configuration operations for MANET nodes
and gateways.
7.1 MANET-local Address configuration
At bootstrap, each node and gateway builds one address following
[RFC4193] and configures it on one of its interface partecipating to
MANET routing. ULA addresses MAY be used for multi-hop transmissions
local to the MANET (e.g. [I-D.jelger-mla]). Other MANET interfaces
can be configured with ULA as well, but nodes must choose one of its
MANET-local addresses as main address and activate the SMF process.
MANET-local address SHOULD be used as originator address in routing
protocol messages. A passive address conflict detection mechanism,
such as [I-D.laouiti], MAY be started after configuration, as
explained in Section 3.1.
7.2 Global addresses configuration
As a configuring node joins the appropriate multicast group and
activates SMF, it starts receiving PAs from available Internet
gateways. It processes PAs and updates PIB accordingly, as described
in Section 6.3. It concurrently fills GAIB, as described in
Section 5.2.1, building a set of valid global IPv6 addresses. The
node can configure one or more of the global addresses on its
interfaces and start using them as source addresses in data packets.
To choose the optimal source address to use, the nodes executes the
Best Prefix Selection algorithm on entries of GAIB. Two situations
can arise:
o node configures only one global address: in this case, the
selection algorithm can help the node to choose the best address
to use;
o node configures multiple global addresses: in this case, [RFC3484]
controls the source address selection. The Best Prefix Selection
algorithm could nevertheless be use as an aid to RFC3484, in order
to select the most convenient address to use.
7.2.1 Best Prefix Selection Algorithm
This section features two Best Prefix Selection algorithms. In the
current version of this document only algorithm traces are included.
The best prefix selection algorithm must take into account aspects
Ruffino & Stupar Expires December 28, 2006 [Page 17]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
related to MANET topology, e.g. the routing metrics of the gateways
and external aspects, e.g. the number and type of active data
sessions. It is assumed that a node, inspecting the routing table,
monitors the current metric value of every reachable gateway
generating PA messages and always knows which is the current default
gateway, chosen by routing protocol. In this section two alternative
algorithms are proposed.
1. Default Gateway Method: nodes always rank the prefix announced by
the current Default Gateway as the highest possible and sort the
remaining prefixes by descending value of routing metrics (i.e.
worse metric means lower ranking).
In case of OLSR and DYMO, the default gateway is the closest
gateway in terms of number of hops. This algorithm solves the
downlink path optimization problem described in Section 3. In
fact, if the node uses a global IPv6 address derived from the
prefix announced by the default gateway, traffic to and from the
external network flows through the same gateway. As a drawback,
if MANET topology frequently changes, nodes which configured only
one global address on MANET interface, may experience frequent
address changes, which can cause disruption of data sessions.
2. Threshold Method: nodes calculate the difference 'D' between the
metric of the gateway announcing the prefix currently in use and
the metric of each other known gateway. Then, they discard
gateways whose D value is below a predefined threshold. Finally,
if the result is not an empty set, they re-sort the prefixes of
the non-discarded gateways by descending value of routing
metrics.
Threshold method accounts for situations when, although nodes use
non-optimal prefixes (and traffic flows on non-optimal paths),
they prefer to keep current address preferences unchanged,
because the benefits provided by a prefix change are not worth
the overhead required by the change itself. E.g. when a node has
one single configured address and many active data sessions, a
prefix change may bring to severe loss of data. Choosing one
single value of the threshold for many deployment environments
can be difficult: it highly depends on the metric and other
factors, which do not strictly depend on routing, e.g. Quality
of Service required by applications and number of active data
sessions.
The selection algorithm SHOULD be executed at bootstrap time, after a
node receives the first set of global prefixes. Nevertheless, this
Ruffino & Stupar Expires December 28, 2006 [Page 18]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
operation SHOULD also be executed when particular events trigger a
topological change in the MANET. Such events have been cited in
Section 4 and can be further detailed as follows:
1. Failure of the gateway owning the chosen prefix;
2. A partition, after which the node and the gateway, owning the
chosen prefix, belong to two different MANETs;
3. The gateway, which announces the chosen prefix, becomes a node,
e.g. after shutting down the interface connecting it to the
external network, and stops announcing prefixes;
4. After a movement of one or more MANET devices, a gateway has a
better metric than the gateway announcing the chosen prefix;
5. A merging occurs, after which a gateway previously not connected
to the MANET may have the best metric value.
In case of events 1., 2. and 3. PIB entries expire, because the
global prefix, which the global addresses in use are derived from, is
no more listed into PA messages: the node MUST also change its global
address, choosing one of the prefixes announced by active gateways.
In case of 4. and 5., the node determines that its global addresses
in use are derived from a non-optimal prefix, according to the the
topological information it owns: in this cases, the node MAY use
other valid global addresses, derived from optimal gateways.
Appendix B elaborates on address changes on MANET nodes.
7.3 Global addresses broadcasting
After nodes have built and configured one or more global addresses,
they advertise them within the MANET. Doing this, other MANET nodes
bind each other node's MANET-local address with the global addresses
owned by each node. Since DYMO, OLSRv1 and OLSRv2 can already
support advertisement of multiple addresses, belonging to a single
node, this specification does not define any new transport mechanism.
In the following sections, implementation guidelines are given for
the mentioned protocols.
7.3.1 OLSRv1 operations
OLSRv1 operations are detailed in Appendix D. Here, MID messages are
used to disseminate global addresses. HNAs messages can be used as
well.
Ruffino & Stupar Expires December 28, 2006 [Page 19]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
7.3.2 OLSRv2 operations
In the current version of OLSRv2, HNA and MID functionalities have
been incorporated in TC messages. Procedures defined for OLSRv1 can
be modified to work with v2 processing.
7.3.3 DYMO operations
Every DYMO node may insert its addresses in the routing messages
(RREP, RREQ, RERR) it forwards to other nodes. Thus, when a node
generates a RREQ to create a route to a destination, every node in
the path will have information (in particular, the metric, i.e. the
hop-count, and a valid route) about IP addresses owned by other nodes
in the path. AMG can exploit this feature to advertise configured
global addresses to other MANET nodes, and in particular, to the
gateways.
In order to apply Best Prefix Selection algorithm, AMG needs to know
metrics associated with gateways. In DYMO, this could be
accomplished by having the gateways periodically generating a special
gratuitous RREQ message with IPDestinationAddress = MANETcastAddress
and Target.Address = ALL_ZERO. Nodes receiving this RREQ MUST NOT
generate a RREP to gateways, but must create or update routes and
metrics towards them and intermediate nodes.
7.4 Gateway operations
Internet gateways have at least one global IPv6 address, belonging to
the external network and used on the external interface. While the
mechanism, by which such address is acquired, is out of scope of this
specification, the configuration of the global address used on the
MANET interface is described in this section.
Gateways MUST configure the global IPv6 address of their MANET
interface using the mechanism specified in Section 5 and Section 7: a
gateway MUST execute the operations described in these sections for
MANET nodes. Gateways MUST always select the prefix they own, to
configure global address they will use on MANET interface. Finally,
gateways MUST process PAs received from other gateways, build global
addresses and disseminate them as described in Section 7.3.
As described in Section 4, a gateway can change its mode of
operations, becoming a node, for a number of reasons, e.g. because it
has lost connectivity with the external network or because of its
Internet interface failure. When a gateway is active, but it has
indications that the Internet is unreachable, it stops generating PA
messages and executes the operations described in Section 7.2 and
Section 7.3.
Ruffino & Stupar Expires December 28, 2006 [Page 20]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Since the gateway has already disseminated its new global address
(after it first received prefixes from other gateways), it can start
communicating with the hosts located outside the MANET with
negligible latency.
Ruffino & Stupar Expires December 28, 2006 [Page 21]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
8. Security Considerations
T.B.D.
Ruffino & Stupar Expires December 28, 2006 [Page 22]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
9. IANA Considerations
This document has no actions for IANA.
Ruffino & Stupar Expires December 28, 2006 [Page 23]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
10. References
10.1 Normative references
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 4291, February 2006.
10.2 Informative References
[I-D.DYMO]
Chakeres, I., Belding-Royer, E., and C. Perkins, "Dynamic
MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-04
(work in progress), October 2005.
[I-D.OLSRv2]
Clausen, T. and C. Dearlove, "The Optimized Link-State
Routing Protocol version 2", draft-ietf-manet-olsrv2-01
(work in progress), March 2006.
[I-D.SMF] Macker, J., "Simplified Multicast Forwarding for MANET",
draft-ietf-manet-smf-02 (work in progress), March 2006.
[I-D.jelger-mla]
Jelger, C., "MANET Local IPv6 Addresses",
draft-jelger-autoconf-mla-00 (work in progress),
April 2006.
[I-D.laouiti]
Adjih, C., Laouiti, A., and K. Mase, "Address
autoconfiguration in Optimized Link State Routing
Protocol", draft-laouiti-manet-olsr-address-autoconf-01
Ruffino & Stupar Expires December 28, 2006 [Page 24]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
(work in progress), July 2005.
[I-D.packetbb]
Clausen, T., Dearlove, C., and J. Dean, "Generalized MANET
Packet/Message Format", draft-ietf-manet-packetbb-00 (work
in progress), February 2006.
[I-D.perkins-manet-autoconf]
Perkins, C., Malinen, J., Wakikawa, R., and E. Belding-
Royer, "IP Address Autoconfiguration for Ad Hoc Networks",
I-D draft-perkins-manet-autoconf-01.txt, November 2001.
[I-D.rfc2461bis]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-06 (work in progress),
October 2005.
[I-D.ruffino-conn-scenarios]
Ruffino, S., Stupar, P., Clausen, T., and S. Singh,
"Connectivity Scenarios for MANET",
draft-ruffino-conn-scenarios-00 (work in progress),
January 2006.
[I-D.singh-autoconf-adp]
Singh, S., Clausen, T., Perkins, C., and P. Ruiz, "Ad hoc
network autoconfiguration: definition and problem
statement", draft-singh-autoconf-adp-03 (work in
progress), October 2005.
[I-D.wakikawa-globalv6]
Wakikawa, R., Malinen, J., Perkins, C., Nilsson, A., and
A. Tuominen, "Global connectivity for IPv6 Mobile Ad Hoc
Networks", I-D draft-wakikawa-manet-globalv6-04.txt,
October 2003.
[I-D.wakikawa-v6-support]
Wakikawa, R., "IPv6 Support on Mobile Ad-hoc Network",
draft-wakikawa-manet-ipv6-support-00 (work in progress),
February 2005.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
Ruffino & Stupar Expires December 28, 2006 [Page 25]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Authors' Addresses
Simone Ruffino
Telecom Italia
Via G.Reiss Romoli 274
Torino 10148
Italy
Phone: +39 011 228 7566
Email: simone.ruffino@telecomitalia.it
Patrick Stupar
Telecom Italia
Via G.Reiss Romoli 274
Torino 10148
Italy
Phone: +39 011 228 5727
Email: patrick.stupar@telecomitalia.it
Ruffino & Stupar Expires December 28, 2006 [Page 26]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Appendix A. Acknowledgments
The authors would like to thank Ivano Guardini and Ivano Verzola for
their valuable comments.
Ruffino & Stupar Expires December 28, 2006 [Page 27]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Appendix B. Considerations on address changes
As explained in Section 7.2, nodes and gateways can configure
multiple addresses on their MANET interfaces, if multiple gateways
and/or prefixes are available. [RFC3484]is used to choose among
configured global addresses the source addresses for data
communications. The output of Best Prefix Selection algorithm, i.e.
prefix ranking, can be used as an hint, to enable nodes to choose
always the optimal prefix and address.
Configuring multiple addresses enable nodes to effectively exploit
multiple egress points in the MANET and to smoothly change source
addresses for data traffic, following MANET topological changes. If
a MANET is very dynamic, the best gateway for a node can change very
quickly: if multiple address are available, node can simply choose
one of them as source address to set-up new data communications.
If only one address is configured on MANET interface (e.g. due to
user preferences, configuration or other policies), then, according
AMG (Section 7.2.1), node could experience frequent address changes,
e.g. in order to optimize downlink traffic coming from external
hosts. Generally, such address changes imply active data sessions
interruption.
In order to cope with this, Mobile IPv6 [RFC3775] can be used. It is
worth noting that AMG, in particular using mechanism explained in
Section 7.3, reduces (ideally to zero) the latency introduced by a
global address change, granting better performances when MANET nodes
use MIPv6. In fact, if a node experiments a change from a first
gateway to a second gateway, then it chooses a new global address,
associated to the second gateway, and it sends a Binding Update
message, registering the new chosen address as the new Care-of
Address. When the Binding Acknowledge message from the Home Agent
arrives at the gateway, immediately a route to the node will be
available, because the new Care-of Address was announced in the MANET
(as described in Section 7.3). Therefore handover latency is reduced
to the time needed to send a Binding Update message and receive the
correspondent Binding Acknowledge message routing latency is
negligible.
Ruffino & Stupar Expires December 28, 2006 [Page 28]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Appendix C. Prefix Advertisement Examples
Figure 3 and Figure 3 depict two example of PA messages.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |0|0|0|0|1|0|1|0| msg-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| |
| originator-address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-seq-number |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| head-length | head :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: head |0|0|0|0|0|0|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tail 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail 1 | tail 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tail 2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: tail 2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|0|0|0|0|1|0|1|0| VALIDITY_TIME |0|0|0|0|1|1|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|1|0| value_1 | value_2 | PREFIX_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|1|1|0|0|0|0|0|0|0|0|1|0| length_1 | length_2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PA containing two different prefixes, with different
validity times and prefix lengths
Ruffino & Stupar Expires December 28, 2006 [Page 29]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |0|0|0|0|1|0|1|0| msg-size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ |
| |
+ originator-address |
| |
+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-seq-number |0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| head-length | |
+-+-+-+-+-+-+-+-+ +
| |
+ head +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|0|1|0|0|0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALIDITY_TIME |0|0|0|0|0|1|0|0|0|0|0|0|0|0|0|1| value_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PREFIX_LENGTH |0|0|0|0|0|1|0|0|0|0|0|0|0|0|0|1| length_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PA containing one single prefix
Ruffino & Stupar Expires December 28, 2006 [Page 30]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Appendix D. OLSRv1 operations
This section details the global address advertising procedure,
described in Section 7.3, using OLSRv1 MID messages.
D.1 Data structures: MID Information Base
The Multiple Interface Association Information Base, is defined in
[RFC3626]: the present specification modifies the semantics of one of
its fields. Multiple Interface Association Information Base is
defined in [RFC3626] and is filled processing MID messages.
[RFC3626] mandates that these messages are generated by a MANET node
only when it is equipped with multiple physical interfaces, through
which it is connected to the MANET and participates to OLSR. MIDs
contain the addresses configured on the node's physical interfaces.
The node is identified by multiple valid IPv6 addresses, one for each
interface connected to the MANET: Multiple Interface Association
Information Base contains bindings between such addresses and the
main address of the node. Using this table, MANET nodes can set-up
routes not only towards main address of other nodes, but also towards
multiple interface addresses associated to main address. Following
[RFC3626], a node connected to the MANET by means of a single
interface MUST NOT generate MIDs.
In this specification, as described in Appendix D.2, MID messages
generated by a node contain the list of the Global Addresses, i.e.
the list of all the global addresses the node may configure on its
MANET interface. The Multiple Interface Association Information Base
is maintained by each node and gateway and is used to store the
bindings between the Global Addresses and MANET-local Addresses of
other nodes.
It is worth noting that the semantics of the entries in Multiple
Interface Association Information Base, as well as of MID messages,
is changed by this specification, since multiple Global Addresses can
be configured on a single interface. This semantic change has no
effect on the processing of MID messages and it is completely
backward-compatible: in fact, from a node's perspective, addresses
announced in MID messages can be single addresses configured on
multiple interfaces, or multiple addresses configured on a single
interface. Routing table construction rules are not changed: nodes
build necessary routes to both primary and secondary addresses
following [RFC3626].
Ruffino & Stupar Expires December 28, 2006 [Page 31]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Hence, Multiple Interface Association Information Base entries have
the following semantics (same as specified in [RFC3626]):
+--------------+----------------------------------------------------+
| Field | Data |
+--------------+----------------------------------------------------+
| I_iface_addr | a Global Address built (and possibly configured) |
| | by a node |
| | |
| I_main_addr | the main address of the node which has built the |
| | Global Address contained into I_iface_addr field |
| | |
| I_time | Validity time |
+--------------+----------------------------------------------------+
Table 3: Multiple Interface Association Information Base
D.2 MID messages
By means of standard MID messages processing, when OLSR eventually
converges, the node is reachable at any of its Global Addresses :
MANET nodes' routing tables contain a route for each secondary
address listed into MID messages. A packet whose destination is one
of the secondary addresses of a node (e.g. traffic from external
hosts to MANET nodes) can therefore be routed within the MANET.
Return traffic will be destined to such secondary address and will be
routed within the MANET by means of the topological information
inserted into MID messages.
D.2.1 MID message generation
A MID message is sent by a node in the network to announce its Global
Addresses. I.e., the MID message contains the list of the Global
Addresses which have been built by it and inserted into GAIB. The
list of Addresses can be partial in each MID message (e.g., due to
message size limitations, imposed by the network), but parsing of all
MID messages describing the Global Information Base of a node MUST be
complete within a certain refreshing period (MID_INTERVAL). The
information contained in the MID messages is used by the nodes to
route packets, which may be destined to one (or more) of the Global
Addresses, chosen by a node to communicate with hosts located outside
the MANET.
D.2.2 MID message forwarding
Upon receiving a MID message, following the rules of section 3 of
[RFC3626], the message MUST be forwarded according to section 3.4 of
Ruffino & Stupar Expires December 28, 2006 [Page 32]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
[RFC3626].
D.2.3 MID message processing
MID messages are processed as described in [RFC3626]. The tuples in
the multiple interface association set are recorded with the
information that is exchanged through MID messages. Upon receiving a
MID message, the "validity time" MUST be computed from the Vtime
field of the message header (as described in Section 3.3.2 of
[RFC3626]). The Multiple Interface Association Information Base
SHOULD then be updated as follows:
1. If the sender interface (note: not the originator) of this
message is not in the symmetric 1-hop neighborhood of this node,
the message MUST be discarded.
2. For each Global Address listed in the MID message:
1. If there exist some tuple in the interface association set
where:
I_iface_addr == Global Address, AND
I_main_addr == Originator Address,
then the holding time of that tuple is set to:
I_time = current time + validity time.
2. Otherwise, a new tuple is recorded in the interface
association set where:
I_iface_addr = Global Address,
I_main_addr = Originator Address,
I_time = current time + validity time.
Ruffino & Stupar Expires December 28, 2006 [Page 33]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 2006
Appendix E. Proposed Values for Constants
E.1 Emission Intervals
PA_INTERVAL = 5 seconds
MID_INTERVAL = 5 seconds
E.2 Holding Time
PA_HOLD_TIME = 3 x PA_INTERVAL
MID_HOLD_TIME = 3 x MID_INTERVAL
Ruffino & Stupar Expires December 28, 2006 [Page 34]
Internet-Draft Autoconf for Multi-GW MANET (AMG) June 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.
Ruffino & Stupar Expires December 28, 2006 [Page 35]
