autoconf P. Hofmann
Internet-Draft DoCoMo Euro-Labs
Expires: September 2, 2006 March 1, 2006
Multihop Radio Access Network (MRAN) Protocol Specification
draft-hofmann-autoconf-mran-00
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.
This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into
languages other than English.
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 September 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents an IPv6-based protocol for the interconnection
of ad hoc networks and the Internet. The protocol enables mobile
nodes in ad hoc networks to communicate with correspondent nodes in
the Internet.
Hofmann Expires September 2, 2006 [Page 1]
Internet-Draft MRAN March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Message and Table Formats . . . . . . . . . . . . . . . . . . 8
3.1. Internet Gateway Advertisement (GW_ADV) . . . . . . . . . 8
3.2. Internet Gateway Solicitation (GW_SOL) . . . . . . . . . . 9
3.3. Solicited Internet Gateway Advertisement (SOL_GW_ADV) . . 9
3.4. Mobile Node Registration (MN_REG) . . . . . . . . . . . . 10
3.5. Mobile Node Registration Acknowledgement (MN_REG_ACK) . . 10
3.6. Gateway Table . . . . . . . . . . . . . . . . . . . . . . 11
3.7. Mobile Node Table . . . . . . . . . . . . . . . . . . . . 11
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Internet Gateway Discovery . . . . . . . . . . . . . . . . 12
4.1.1. Proactive Discovery Mode . . . . . . . . . . . . . . . 12
4.1.2. Reactive Discovery Mode . . . . . . . . . . . . . . . 12
4.1.3. Hybrid Discovery Mode . . . . . . . . . . . . . . . . 13
4.1.4. Gateway Table Maintenance . . . . . . . . . . . . . . 13
4.1.5. Applicability of Gateway Discovery Modes . . . . . . . 13
4.2. Internet Gateway Selection . . . . . . . . . . . . . . . . 14
4.3. Address Autoconfiguration . . . . . . . . . . . . . . . . 14
4.4. Mobile Node Registration . . . . . . . . . . . . . . . . . 14
4.5. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 15
4.6. Multihop Handovers . . . . . . . . . . . . . . . . . . . . 16
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Hofmann Expires September 2, 2006 [Page 2]
Internet-Draft MRAN March 2006
1. Introduction
Connecting mobile ad hoc networks (MANET) with the Internet is useful
for several application scenarios. It enables mobile nodes (MN) in
ad hoc networks to access services in the Internet or to communicate
with correspondent nodes (CN) outside of their ad hoc network. The
connection of MANETs and the Internet is provided by an entity that
is part of both networks, e.g., a router that has a wireless
interface for communication with MNs and a wired interface for
connection to a fixed IP-based network. This entity is referred to
as Internet gateway (GW). An Internet GW is able to communicate with
MNs by running the same MANET routing protocol as the MNs. An
example of a MANET with Internet connection is shown in Figure 1.
------
| CN |
------
|
|
----------------------
| Internet |
----------------------
| |
| |
------ ------
| GW | | GW |
------ ------
| |
| |
------ ------
| MN | | MN |
------ ------
| |
| |
------ ------ ------
| MN |--| MN |--| MN |
------ ------ ------
Figure 1
The connection of a MN in a MANET with a CN in the Internet comprises
three major steps: Internet GW discovery, address autoconfiguration,
and packet forwarding. In case a MN discovers more than one GW, it
selects the most appropriate one based on certain rules. Next, the
MN obtains a topologically correct prefix or address from it's
preferred GW for communication with the CN. This is necessary as
MANETs usually employ a flat addressing scheme that allows MNs to use
any arbitrary address for communication with other MNs. Finally, the
Hofmann Expires September 2, 2006 [Page 3]
Internet-Draft MRAN March 2006
communication can start and packets are forwarded from the MN through
the MANET via the GW to the CN and vice versa.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.1. Requirements
The MANET routing protocol and the Internet connection protocol
should be able to operate independently. On the one hand, the
Internet connection protocol should be able to run on top of any
routing protocol. This allows to use the Internet connection
protocol in application scenarios with different MANET routing
protocols. On the other hand, the operation of the Internet
connection protocol should not affect the MANET routing protocol.
For instance, a change of a MN's global address should not
necessitate an update of routes in the ad hoc network, resulting in
high routing overhead. This is of particular importance if nodes are
highly mobile and change their Internet GW frequently.
The connection of MANET and Internet via multiple GWs should be
supported. MNs should be able to detect if multiple GWs are
available. If this is the case, MNs should be able to select the
most appropriate GW. Furthermore, MNs should be able to maintain a
connection with a particular GW, i.e., packets sent by this MN should
not be forwarded to a different GW. This can be important for
authentication, authorization, and accounting (AAA) reasons or if
selected GWs provide certain services or quality thereof.
The Internet connection protocol should provide different GW
discovery modes to enable an adaptation to different application
scenarios (i.e., number of MNs and GWs, mobility pattern, MANET
routing protocol type) to limit signaling overhead.
The connection between a MN and the Internet should be maintained
while the MN is moving. If the connection between the MN and its
current GW is lost (e.g., due to a route failure) the Internet
connection protocol should initiate the reestablishment of the
connection with the Internet via an alternative GW ("multihop
handover"). Again, this is important if nodes are highly mobile.
Finally, the Internet connection protocol should support partitioning
and merging of MANETs.
Based on these requirements we propose the Multihop Radio Access
Network (MRAN) protocol.
Hofmann Expires September 2, 2006 [Page 4]
Internet-Draft MRAN March 2006
1.2. Assumptions
MNs and GWs use local addresses for communication within the MANET.
The local address may be autoconfigured as described in, e.g.,
[I-D.jeong-adhoc-ip-addr-autoconf].
Routing is performed by a MANET routing protocol, e.g., [I-D.clausen-
manet-olsrv2] or [I-D.ietf-manet-dymo].
A flooding protocol (e.g., [I-D.perkins-manet-bcast]) is used for
broadcasting certain MRAN control messages. Alternatively, the
flooding funtionality may be provided by the MANET routing protocol.
1.3. Terminology
Internet gateway
An Internet gateway (GW) connects a MANET with the Internet.
Therefore, GWs must be able to communicate with nodes of the MANET
and with nodes in the Internet.
Mobile node
All other nodes of the MANET are mobile nodes (MN).
Correspondent node
A node in the Internet that communicates with a MN in the MANET is
a correspondent node (CN).
Local address
MNs and GWs use local addresses to communicate within the MANET.
Global address
MNs use a global address to communicate with their CN.
Hofmann Expires September 2, 2006 [Page 5]
Internet-Draft MRAN March 2006
2. Overview
The operation of the MRAN protocol is composed of several functions:
Internet GW discovery, GW selection, address autoconfiguration,
registration, packet forwarding, and multihop handovers.
The MRAN protocol provides three different modes of Internet GW
discovery. This ensures that the protocol can be efficiently used in
various different application scenarios. In proactive mode, all GWs
periodically broadcast advertisement messages. MNs in proactive mode
that require Internet access have to wait until they receive such a
message. In reactive discovery mode, MNs only attempt to discover
available GWs if required (e.g., if a DNS request is supposed to be
sent to the Internet). If a MN requires access to the Internet and
has no information about available GWs, it broadcasts a GW
solicitation message. If a GW receives such a message from a MN, it
returns a solicited GW advertisement message per unicast. Finally,
hybrid Internet GW discovery is a combination of proactive and
reactive discovery. The GW is in proactive mode and the MN is in
reactive mode. All GW advertisement messages contain the GW's
globally valid prefix of length 64 bit.
If a MN wants to connect to the Internet and has information about
multiple GWs, it selects the closest GW with respect to number of
hops. However, other or additional metrics may be used for the GW
selection as well.
If a MN has selected a GW, it uses the selected GW's prefix and its
own EUI-64 to autoconfigure a global address. It may subsequently
perform a duplicate address detection (DAD).
A registration of MNs with GWs is required to enable GWs to
appropriately forward packets from the Internet to the MNs. If a MN
has created a global address, it registers with the selected GW.
Therefore, it sends a registration request message to the GW. When
receiving such a message, a GW returns a registration acknowledgment
message to the MN. If the MN receives this message, the registration
was successful and the MN repeats the registration periodically. MNs
in reactive GW discovery mode queue payload packets during the GW
discovery and registration process. The registration may be used for
other purposes as well, e.g., AAA.
Payload packets are tunneled between MNs and GWs in both directions.
On the one hand, using tunnels for sending packets from the MNs to
the GWs enables MNs to explicitly select their preferred GW. On the
other hand, using tunnels for sending packets from GWs to MNs allows
using only local addresses instead of global addresses for intra-
MANET communication. This approach "decouples" the operation of
Hofmann Expires September 2, 2006 [Page 6]
Internet-Draft MRAN March 2006
MANET routing and MRAN protocol as no rerouting needs to be performed
if any MN changes its global address after having connected to a new
GW. This helps limiting the routing overhead particularly in highly
mobile networks.
If a MN is disconnected from its current GW (e.g., because the route
to the GW has failed) while communicating with a CN in the Internet,
it has to discover, select, and register with another GW. This is a
"forced" multihop handover. However, a MN may also select a new GW
for optimization reasons, e.g., if it knows another GW that is closer
than the current one. The MN then performs the registration with the
new GW while it is still connected to the old one. This is an
"optimizing" multihop handover. Optimizing handovers are much faster
than forced handovers. Furthermore, optimizing handovers increase
the reliability of the route between MN and GW. This reduces the
frequency of forced handovers. Hence, optimizing handovers increase
the system performance, particularly by reducing the packet loss.
Hofmann Expires September 2, 2006 [Page 7]
Internet-Draft MRAN March 2006
3. Message and Table Formats
This Section defines the format of the MRAN control messages and the
tables required for the protocol operation.
3.1. Internet Gateway Advertisement (GW_ADV)
All GWs in proactive mode periodically broadcast this message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type | Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| GW's local address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message type: 1
Reserved: Filled with zeros, ignored by receiver
Lifetime: The lifetime of this advertisement
Sequence number: Initialized to zero for the first and increased
by one for each new advertisement by the GW
Prefix: Advertised prefix of GW with length 64 bit
Hofmann Expires September 2, 2006 [Page 8]
Internet-Draft MRAN March 2006
3.2. Internet Gateway Solicitation (GW_SOL)
MNs in reactive mode broadcast this message to discover available
GWs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MN's local address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message type: 2
Reserved: Filled with zeros, ignored by receiver
Sequence number: Initialized to zero for the first and increased
by one for each new solicitation by the MN
3.3. Solicited Internet Gateway Advertisement (SOL_GW_ADV)
GWs return this message on reception of a MN's GW_SOL message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message type: 3
Reserved: Filled with zeros, ignored by receiver
Prefix: Advertised prefix of GW with length 64 bit
Hofmann Expires September 2, 2006 [Page 9]
Internet-Draft MRAN March 2006
3.4. Mobile Node Registration (MN_REG)
MNs send this message to register with their selected GW.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type | Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MN's global address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message type: 4
Reserved: Filled with zeros, ignored by receiver
Lifetime: The time in seconds for how long the mobile node
wants to register with the Internet GW
3.5. Mobile Node Registration Acknowledgement (MN_REG_ACK)
GWs return this message to the MN if the registration was successful.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message type | Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message type: 5
Reserved: Filled with zeros, ignored by receiver
Lifetime: The time in seconds specifying for how long the
registration is valid
Hofmann Expires September 2, 2006 [Page 10]
Internet-Draft MRAN March 2006
3.6. Gateway Table
MNs maintain a gateway (GW) table to store information about
available GWs. An entry of the GW table contains the following
information.
+------------------------------+
| GW's local address |
+------------------------------+
| GW's prefix |
+------------------------------+
| GW expiration time |
+------------------------------+
| Registration expiration time |
+------------------------------+
MNs also need to keep track of their current status, i.e., whether
they are connected (i.e., registered) to any GW and, if so, to which
GW they are connected.
3.7. Mobile Node Table
GWs maintain a mobile node (MN) table to store information about MNs
that have a valid registration. An entry of the MN table contains
the following information.
+------------------------------+
| MN's local address |
+------------------------------+
| MN's global address |
+------------------------------+
| Registration expiration time |
+------------------------------+
Hofmann Expires September 2, 2006 [Page 11]
Internet-Draft MRAN March 2006
4. Protocol Operation
The operation of the MRAN protocol is composed of several functions:
Internet GW discovery, GW selection, address autoconfiguration,
registration, packet forwarding, and multihop handovers. The details
of the protocol operation are described in the following.
4.1. Internet Gateway Discovery
The MRAN protocol provides three different modes of Internet GW
discovery.
4.1.1. Proactive Discovery Mode
In proactive mode, all GWs MUST periodically broadcast advertisement
(GW_ADV) messages advertising their service in a certain time
interval (GW_ADV_INTERVAL). The hop limit of the messages SHOULD be
set to NET_DIAMETER. MNs that require Internet access have to wait
until they receive a GW_ADV message.
4.1.2. Reactive Discovery Mode
In reactive discovery mode, MNs only attempt to discover available
GWs if required (e.g., if a DNS request is supposed to be sent to the
Internet). If a MN requires access to the Internet and has no
information about available GWs, it MUST broadcast a GW solicitation
(GW_SOL) message. The hop limit of this messages SHOULD be set to
NET_DIAMETER. If the MN does not receive a SOL_GW_ADV message within
a certain time period (GW_SOL_TIMEOUT), it SHOULD resend a limited
number (GW_SOL_RETRIES) of GW_SOL messages until it receives a
SOL_GW_ADV message. The timeout for the second solicitation message
is 2 x GW_SOL_TIMEOUT, for the third 3 x GW_SOL_TIMEOUT, etc. This
backoff algorithm reduces the flooding overhead in the MANET. The MN
MAY additionally employ the expanding ring search technique (as
described in [RFC3561]) to further reduce the flooding overhead. If
the MN does not receive any SOL_GW_ADV message, the GW discovery has
failed.
GWs in reactive mode MUST NOT send any packets unless they receive a
GW_SOL message. If a GW receives a GW_SOL message from a MN, it MUST
return a solicited GW advertisement (SOL_GW_ADV) message per unicast,
using the MN's local address. The hop limit of this message SHOULD
be set to NET_DIAMETER.
Payload packets that are supposed to be sent to the CN in the
Internet SHOULD be queued during the reactive GW discovery for a
maximum duration of PKT_QUEUE_LIFETIME to limit packet loss.
Hofmann Expires September 2, 2006 [Page 12]
Internet-Draft MRAN March 2006
4.1.3. Hybrid Discovery Mode
Hybrid Internet GW discovery is a combination of proactive and
reactive discovery. The GW is in proactive mode and the MN is in
reactive mode. Hence, the MN only initiates the GW discovery if it
requires Internet access and has not received any GW_ADV messages
recently.
To reduce the signaling overhead in hybrid GW discovery mode, either
the hop limit of GW_ADV messages SHOULD be set to a value lower than
NET_DIAMETER or the interval of GW_ADV messages SHOULD be set to a
value higher than GW_ADV_INTERVAL, or both.
4.1.4. Gateway Table Maintenance
MNs MUST maintain a table listing all valid GWs. A table entry is
created when a MN receives a GW_ADV or SOL_GW_ADV message. An entry
contains the GW's local address, prefix, the GW expiration time, and
the registration expiration time (registration is described in
Section 4.4). The GW expiration time is the reception time of the
last GW_ADV message plus the advertised GW_ADV_LIFETIME. It is
updated each time a new advertisement from the same GW is received.
Entries created on reception of a SOL_GW_ADV message do not expire,
hence the GW expiration time is set to infinity (represented by an
integer of maximum value).
A GW table entry MUST be removed if it has expired or if the
registration with the respective GW has failed. If a MN is currently
connected to a GW and the route between MN and this GW fails, the
respective GW table entry SHOULD be removed. If a MN is currently
connected to a GW and the registration with this GW expires, the
respective GW table entry MAY be removed.
If a MN is in reactive GW discovery mode and currently connected to a
GW, it SHOULD remove all entries in the GW table with GW expiration
time set to infinity except the entry of the current GW. This
ensures removing stale information.
4.1.5. Applicability of Gateway Discovery Modes
The preferred GW discovery mechanism should be carefully selected
depending on the actual application scenario. The first important
aspect is that the GW discovery mode should be consistent with the
MANET routing protocol type, i.e., proactive GW discovery should be
used together with a proactive routing protocol [I-D.clausen-manet-
olsrv2] and reactive GW discovery together with a reactive MANET
routing protocol [I-D.ietf-manet-dymo].
Hofmann Expires September 2, 2006 [Page 13]
Internet-Draft MRAN March 2006
Another important aspect is the control overhead generated by the
MRAN protocol. It is well known that flooding of messages generates
the largest amount of control overhead, while overhead caused by
unicast control messages is negligible. MRAN control messages are
flooded by either GWs in proactive mode or MNs in reactive mode that
need to discover a GW. The suitability of the different GW discovery
modes hence depends on the ratio of GWs to MNs that require Internet
access, and on the node mobility. For instance, if a large and
highly mobile MANET is connected to a few GWs, the proactive GW
discovery is advantageous.
The hybrid GW discovery mode might be a good tradeoff for large
networks or for networks whose characteristics are not known a
priori.
The last aspect is the targeted user application. Real-time
applications can hardly cope with high packet delay or jitter.
Hence, it does not make sense to employ reactive GW discovery with
packet queuing in this case.
4.2. Internet Gateway Selection
If a MN needs to connect to the Internet and has information about
multiple GWs in its GW table, it SHOULD select the closest GW with
respect to number of hops. However, other or additional metrics may
be used for the GW selection as well. If a MN in proactive GW
discovery needs Internet connection and does not have any GW table
entry, it MUST select the first GW it receives a GW_SOL message from.
If a MN in reactive GW discovery mode needs an Internet connection
and does not have information about available GWs, it MUST originate
a GW_SOL message. The MN SHOULD select the first GW it receives a
SOL_GW_ADV from, but it MAY wait a short time (GW_SELECT_DEFER)
before selecting a GW to consider the case that a SOL_GW_ADV from a
better suited GW is received later.
4.3. Address Autoconfiguration
If a MN has selected a GW, it MUST use the selected GW's prefix and
its own EUI-64 [RFC3513] to autoconfigure a global address. It MAY
subsequently perform a duplicate address detection (DAD).
4.4. Mobile Node Registration
A registration of MNs with GWs is required to enable GWs to
appropriately forward packets from the Internet to the MNs (see
Section 4.5). It may however be used for other purposes as well,
e.g., authentication, authorization, and accounting (AAA).
Hofmann Expires September 2, 2006 [Page 14]
Internet-Draft MRAN March 2006
If a MN has created a global address, it registers with the selected
GW. Therefore, it sends a registration request (MN_REG) message to
the GW, containing the MN's global address and a lifetime field
specifying for how long the MN wants to register with the GW. The
lifetime SHOULD be set to MN_REG_LIFETIME.
If the MN does not receive an acknowledgment within a certain time
(MN_REG_TIMEOUT), it SHOULD resend a limited number (MN_REG_RETRIES)
of registration request messages until it receives a MN_REG_ACK
message. If the MN does not receive any MN_REG_ACK message after
MN_REG_DURATION, the registration has failed and the MN MUST remove
the respective GW table entry. It SHOULD subsequently select a new
GW or perform GW discovery if required.
When receiving a MN_REG message, a GW MUST return a registration
acknowledgment (MN_REG_ACK) message to the MN including the granted
lifetime of the registration. The granted lifetime SHOULD be the
lifetime requested by the MN.
GWs MUST maintain a table listing all MNs that currently have a valid
registration. An entry of the MN table is created on reception of a
MN_REG message and contains the respective MN's local address, global
address, and the registration expiration time. The registration
expiration time is the reception time of the last MN_REG message plus
the granted lifetime of the registration. An entry is updated each
time a MN_REG message from the same MN is received. A MN table entry
MUST be removed by GWs if the registration of the respective MN has
expired.
If the MN eventually receives the MN_REG_ACK message, the
registration was successful and the MN SHOULD repeat the registration
periodically with an interval of MN_REG_INTERVAL. The periodical
registration with the current GW MUST be stopped if either the MN
selects a new GW or the GW table entry of the respective GW has been
removed.
If the MN is in reactive GW discovery mode, it SHOULD queue payload
packets during the registration process. If the MN is in proactive
GW discovery mode, it SHOULD always maintain a registration with a GW
even if Internet connection currently is not required. This avoids
unnecessary delays in case a payload packet needs to be sent to a CN
in the Internet.
4.5. Packet Forwarding
Payload packets are tunneled between MNs and GWs in both directions,
achieved by either IP-in-IP encapsulation [RFC2473] or using a
routing extension header [RFC2460]. On the one hand, using tunnels
Hofmann Expires September 2, 2006 [Page 15]
Internet-Draft MRAN March 2006
for sending packets from the MNs to the GWs enables MNs to explicitly
select their preferred GW, e.g., a GW that provides a certain service
quality. On the other hand, using tunnels for sending packets from
GWs to MNs allows using only local addresses instead of global
addresses for intra-MANET communication. This approach "decouples"
the operation of MANET routing and MRAN protocol as no rerouting
needs to be performed if any MN changes its global address after
having connected to a new GW. This helps limiting the routing
overhead particularly in highly mobile networks.
GWs must maintain tunnels to each MN with a valid registration. The
destination address of the inner IP header is the global address of
the MN. The destination address of the outer header is the local
address of the MN. A GW MUST establish a tunnel to a MN after
reception of a MN_REG message and MUST remove it when the respective
MN table entry has expired.
Simultaneously, MNs must maintain a tunnel to their current GW. The
destination address of the inner IP header is the global address of
the CN, whereas the destination address of the outer header is the
local address of the GW. A MN MUST establish a tunnel to a GW after
reception of a MN_REG_ACK message. If the MN is in reactive GW
discovery mode and has any payload packets in its queue, it MUST
subsequently forward them to the Internet. The tunnel MUST be
removed if either a new GW is selected or the respective GW table
entry has been removed.
4.6. Multihop Handovers
If a MN is disconnected from its current GW (i.e., the GW table entry
or registration has expired or route to GW has failed) while
communicating with a CN in the Internet, it SHOULD discover, select
and register with another GW. This is a "forced" multihop handover.
The delay of the forced handover is mainly composed of the delays of
GW discovery (if necessary) and registration process.
However, a MN MAY also decide to select a new GW for optimization
reasons, e.g., if it knows another GW that is closer than the current
one. The MN SHOULD then perform the registration with the new GW
while it is still connected to the old one. This is an "optimizing"
multihop handover. The delay of optimizing handovers is composed of
the delay of changing the global address and the tunnel only. Thus,
optimizing handovers are much faster than forced handovers.
Furthermore, optimizing handovers increase the reliability of the
route between MN and GW. This reduces the frequency of forced
handovers. Hence, optimizing handovers increase the system
performance, particularly by reducing the packet loss [HBP06].
However, optimizing handovers are only possible with proactive (or
Hofmann Expires September 2, 2006 [Page 16]
Internet-Draft MRAN March 2006
hybrid) GW discovery.
MNs SHOULD stay connected to their current GW for a minimum duration
(OPT_HO_DEFER) before performing an optimizing handover to another
GW. This reduces the impact of handovers on IP mobility protocols
(e.g., Mobile IPv6 [RFC3775]) that might run on top.
Hofmann Expires September 2, 2006 [Page 17]
Internet-Draft MRAN March 2006
5. Protocol Parameters
The recommended values for the protocol parameters are listed below.
Parameter Value
--------- -----
NET_DIAMETER 35
NODE_TRAVERSAL_TIME 40 ms
NET_TRAVERSAL_TIME 3 * NODE_TRAVERSAL_TIME * NET_DIAMETER / 2
GW_ADV_LIFETIME 3,000 ms
GW_ADV_INTERVAL GW_ADV_LIFETIME * 0.9
GW_SOL_TIMEOUT 2 * NET_TRAVERSAL_TIME
GW_SOL_RETRIES 2
GW_SOL_DURATION (GW_SOL_RETRIES + 1) * (GW_SOL_RETRIES + 2) *
GW_SOL_TIMEOUT / 2
GW_SELECT_DEFER NODE_TRAVERSAL_TIME * NET_DIAMETER
MN_REG_LIFETIME 30,000 ms
MN_REG_TIMEOUT 2 * NET_TRAVERSAL_TIME
MN_REG_RETRIES 5
MN_REG_DURATION (MN_REG_RETRIES + 1) * MN_REG_TIMEOUT
PKT_QUEUE_LIFETIME GW_SOL_DURATION + MN_REG_DURATION
OPT_HO_DEFER 10,000 ms
The parameter NET_DIAMETER MAY be adapted to the actual network size.
Hofmann Expires September 2, 2006 [Page 18]
Internet-Draft MRAN March 2006
6. Security Considerations
Possible security threats imposed by the proposed protocol are not
addressed.
7. IANA Considerations
There are no IANA considerations.
8. Acknowledgments
The author would like to thank Christian Prehofer and Christian
Bettstetter for their valuable comments on the design and evaluation
of the MRAN protocol and for the support in composing this document.
Hofmann Expires September 2, 2006 [Page 19]
Internet-Draft MRAN March 2006
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
9.2. Informative References
[HBP06] Hofmann, P., Bettstetter, C., and C. Prehofer,
"Performance Impact of Multihop Handovers in an IP-based
Multihop Radio Access Network", accepted for ACM SIGMOBILE
Mobile Computing and Communications Review (MC2R) 2006.
[I-D.clausen-manet-olsrv2]
Clausen, T., "The Optimized Link-State Routing Protocol
version 2", draft-clausen-manet-olsrv2-01 (work in
progress), September 2005.
[I-D.ietf-manet-dymo]
Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing",
draft-ietf-manet-dymo-03 (work in progress), October 2005.
[I-D.jeong-adhoc-ip-addr-autoconf]
Jeong, J., "Ad Hoc IP Address Autoconfiguration",
draft-jeong-adhoc-ip-addr-autoconf-06 (work in progress),
January 2006.
[I-D.perkins-manet-bcast]
Perkins, C., "IP Flooding in Ad hoc Mobile Networks",
draft-perkins-manet-bcast-02 (work in progress),
June 2005.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Hofmann Expires September 2, 2006 [Page 20]
Internet-Draft MRAN March 2006
Author's Address
Philipp Hofmann
DoCoMo Communications Laboratories Europe GmbH
Landsberger Str. 312
Munich 80687
Germany
Phone: +49-89-56824-218
Email: hofmann@docomolab-euro.com
URI: www.docomoeurolabs.de
Hofmann Expires September 2, 2006 [Page 21]
Internet-Draft MRAN March 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.
Hofmann Expires September 2, 2006 [Page 22]