MANET Autoconfiguration (AUTOCONF) I. Chakeres
Internet-Draft Motorola
Intended status: Informational J. Macker
Expires: February 28, 2008 Naval Research Laboratory
T. Clausen
LIX, Ecole Polytechnique
August 27, 2007
Mobile Ad hoc Network Architecture
draft-ietf-autoconf-manetarch-05
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 February 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document discusses Mobile Ad hoc NETworks (MANETs). It
introduces basic MANET terms, characteristics, and challenges and
defines fundamental MANET entities and architectural concepts.
Chakeres, et al. Expires February 28, 2008 [Page 1]
Internet-Draft MANET Architecture August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Borrowed Terminology . . . . . . . . . . . . . . . . . . . 3
2.2. MANET Terminology . . . . . . . . . . . . . . . . . . . . 5
3. MANET Motivation Discussion . . . . . . . . . . . . . . . . . 6
3.1. Packet Radio Networks . . . . . . . . . . . . . . . . . . 7
3.2. Packet Radio Networks and the Internet . . . . . . . . . . 7
3.3. Packet Radio Networks and MANETs . . . . . . . . . . . . . 8
4. MANET Interface Characteristics . . . . . . . . . . . . . . . 8
4.1. Qualities - Wireless, Mobile, Ad hoc . . . . . . . . . . . 9
4.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Semi-Broadcast Interface . . . . . . . . . . . . . . . 9
4.2.2. Fuzzy Relationships Between Nearby MANET
Routers & MANET Routers Extended Neighborhood . . . . 10
4.2.3. MANET Membership . . . . . . . . . . . . . . . . . . . 11
5. Addressing & the MANET Prefix Model . . . . . . . . . . . . . 12
5.1. General Address Architecture . . . . . . . . . . . . . . . 12
5.2. MANET Interface Configuration . . . . . . . . . . . . . . 13
5.3. Routers and Hosts in a MANET . . . . . . . . . . . . . . . 14
6. MANETs' Place in the Network Stack . . . . . . . . . . . . . . 15
7. Cross Layering . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Deployment Taxonomy . . . . . . . . . . . . . . . . . . . . . 16
8.1. Service Availability . . . . . . . . . . . . . . . . . . . 16
8.2. Number of MANET Routers in a MANET . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Chakeres, et al. Expires February 28, 2008 [Page 2]
Internet-Draft MANET Architecture August 2007
1. Introduction
A Mobile Ad hoc NETwork (MANET) consists of a loosely connected set
of MANET routers. Each MANET router embodies routing/forwarding
functionality and may also incorporate host functionality. These
routers organize and maintain a routing structure among themselves.
These routers may communicate over dynamic wireless channels with
asymmetric reachability, may be mobile, and may join and leave the
network at any time. MANETs' characteristics create challenges in
several areas, and may require protocol extensions or new MANET
protocols altogether.
This document is focused on IP networking, though many of MANETs'
concepts and issues span the protocol stack.
This document is meant to complement [RFC2501] in describing and
defining MANET.
2. Terminology
Owing to the fact that a MANET, as described in this document, is an
instance of an IP network, much of the terminology employed in this
document is borrowed from existing documents. Some of the documents
that contain relevant terminology are [RFC1812], [RFC2328],
[RFC2453], [RFC2460], [RFC2461], [RFC4291], [RFC3753], and [RFC4903].
In some cases the terminology is slightly abbreviated or rephrased;
although, every effort made to retain the meanings. Borrowed
terminology is provided in Section 2.1 with the intent of providing a
complete discussion of MANETs using coherent terminology. MANET
specific terminology is provided in Section 2.2.
2.1. Borrowed Terminology
This document employs the following definitions:
Node (N)
any device (router or host) that implements IP.
Router (R)
a node that forwards IP packets not explicitly addressed to
itself.
Host (H)
any node that is not a router, i.e. a host does not forward
packets addressed to others.
Chakeres, et al. Expires February 28, 2008 [Page 3]
Internet-Draft MANET Architecture August 2007
Link
a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below
IP. Examples are Ethernets (simple or bridged), PPP links, X.25,
Frame Relay, or ATM networks as well as internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself.
Asymmetric Reachability
Asymmetric reachability describes two properties of certain
interface types' underlying communication facilities. First, non-
transitive communication means packets from X can reach Y, and
packets from Y can reach Z, but packets from X may not reach Z.
Second, non-bidirectional communication means that packets from X
can reach Y but packets from Y may not reach X. Many radio/
wireless interfaces exhibit these properties.
Neighbor
If node X can directly send or receive IP packets to/from node Y,
then node Y is node X's neighbor.
Interface
A node's point of attachment to a communication link.
Broadcast Interface
An interface with the known capability to address a single link
layer transmission to all of the attached nodes (broadcast). The
set of nodes receiving a given physical broadcast message are
neighbors of the node originating the message.
Full-Broadcast Interface (FBI)
A broadcast interface known to have both transitive and
bidirectional communication, i.e. it does not exhibit asymmetric
reachability. Nodes which are connected to the same link via
Full-Broadcast Interfaces can all send and receive IP packets
directly to each other -- all nodes are thus bi-directional
neighbors. Ethernet interfaces connected via a single Ethernet
segment is an example of a FBI.
Semi-Broadcast Interface (SBI)
A broadcast interface that may exhibit asymmetric reachability.
Multiple access wireless radio interfaces are often SBI. Note
that since a SBI *may* exhibit asymmetric reachability, it also
may not. Thus, a FBI can be said to be a special case of SBI, or
rather, a protocol which is capable of operating under the
constraints of an SBI will ALSO be able to operate with an FBI.
Chakeres, et al. Expires February 28, 2008 [Page 4]
Internet-Draft MANET Architecture August 2007
Classic IP Interface
A classic IP interface has both transitive and bidirectional
properties, i.e. is an FBI. A classic IP interface furthermore
assumes that a particular set of addresses, specifically those
within the same prefix as the IP address of the classic IP
interface, are reachable within one IP hop. Put another way, a
classic IP interface, configured with an address p::i and a prefix
p::, assumes that all other addresses within the prefix p:: are
either assigned other to classic IP interfaces which are reachable
within one IP hop -- or are not used/present in the network at
all.
Border Router (BR)
a router that participates in multiple routing regions, and often
multiple routing protocols. A BR defines the border between its
multiple routing regions. A BR is responsible for presenting a
consistent picture of the nodes reachable through itself to each
routing region. A BR determines the routing information to
propagate between different routing regions.
2.2. MANET Terminology
The following terminology is proper to MANETs:
MANET Interface
A MANET interface may demonstrate asymmetric reachability (e.g.,
SBI) and/or neighboring nodes' addresses may not be a priori
known. Note: according to the definition of a classic IP
interface, such an interface satisfies the characteristics of a
MANET interface -- with the additional nice properties that it
does not exhibit asymmetric reachability and a set of neighboring
nodes' addresses are known a priori. Thus, a classic IP interface
can be said to be a special case of a MANET interface, or rather,
a protocol which is capable of operating under the constraints of
a MANET interface will ALSO be able to operate with a classic IP
interface. A more detailed discussion of MANET interface
characteristics is provided in Section 4.
MANET Router (MNR)
a MANET router embodies router functionality and may also include
host functionality, reachable via its loopback interface(s). A
MANET router has one or more MANET interfaces. A MANET router may
also have zero or more classic IP interfaces to which itself (via
loopback), hosts, routers, or networks may connect; i.e. the
router may be responsible for several IP prefixes. A MANET router
is expected to participate in routing on behalf of one or more of
its interfaces. A MANET router is illustrated in Figure 1.
Chakeres, et al. Expires February 28, 2008 [Page 5]
Internet-Draft MANET Architecture August 2007
<~~~~~~+~~~~~~> MANET
| Interface(s)
'''''''''''''
' MANET '
' Router '
'''''''''''''
: Classic IP
: Interface(s)
+----+------+
|Loopback(s)|
|Node(s) |
|Router(s) |
|Network(s) |
+-----------+
Figure 1: MANET Router
MANETs can be described by several topological scopes, as defined in
the following:
MANET Neighborhood
a set of MANET routers that is within one IP hop, receives
messages sent via link-local [RFC4007] messaging.
MANET
a routing region consisting of a set of MANET routers that is
within one or more MANET router hops. If a MANET connects to
other routing regions, its border is defined by Border Routers.
Dependent upon the deployment and management strategy, coalescing and
fragmentation of MANETs may be a supported feature. In other words,
if a communication path between two previously separated MANET
routers or MANETs becomes available, the two MANETs may merge to form
a single larger MANET. Similarly, if a communication path between
two MANET routers is disappears and no alternative path between the
routers exists, then the MANET may be partitioned into two separate
MANETs.
When discussing MANETs' connectivity to other networks, such as the
Internet, a MANET is bounded by border routers (BR). That is, a
MANET's BR form a border between a MANET and other routing regions.
3. MANET Motivation Discussion
The Internet Protocol (IP) core design tenets -- connectionless
networking and packet-based forwarding -- are ideally suited for use
in highly dynamic contexts, such as MANETs. Yet, some additional
Chakeres, et al. Expires February 28, 2008 [Page 6]
Internet-Draft MANET Architecture August 2007
functionality is required to meet the unique challenges and
opportunities present in MANETs.
3.1. Packet Radio Networks
The initial motivation for MANETs was called Packet Radio (PR)
networking [FL01]. In PR, each router is equipped with a single
wireless interface. Each router may be mobile, and the routers may
be or may become spatially distributed such that all routers cannot
communicate directly. That is, two routers might require one or more
intermediate routers to forward (route) packets on their behalf. In
the example shown in Figure 2: for PR1 to send packets to PR3, the
intermediary PR2 must relay the packets. This implies that PR2 must
receive the packet from PR1 on its interface and determine that it
must retransmit the packet over the same interface as the one where
the packet was received, in order for the packet to reach PR3. From
the point of view of PR2, both PR1 and PR3 are neighboring routers,
whereas PR1 and PR3 are not themselves neighboring routers of one
another.
Communication
Range
<~~~~~~+~~~~~~> <~~~~~~+~~~~~~>
Single | <~~~~~~+~~~~~~> |
MANET +-|-+ +-|-+ +-|-+
Interface |PR1| |PR2| |PR3|
+---+ +---+ +---+
Figure 2: Basic Packet Radio Network
3.2. Packet Radio Networks and the Internet
Packet Radio networks inspired several architecture related
challenges, including how to interconnect Packet Radio networks and
other networks, especially fixed networks like the ARPANET. Another
related challenge was how to deal with the large disparity between
different node and interface characteristics present in different
networks.
These aspects of Packet Radio networks helped stimulate the early
development of the Internet Protocol; an architecture based on
connectionless networking and packet-based forwarding that enables
interconnection of heterogeneous devices over heterogeneous
communication technologies.
Chakeres, et al. Expires February 28, 2008 [Page 7]
Internet-Draft MANET Architecture August 2007
3.3. Packet Radio Networks and MANETs
The router configuration in Figure 2 is the simplest MANET router
configuration: a single interface exhibiting MANET interface
characteristics (asymmetric reachability, non pre-determined
neighborhood). Many other challenges exist, in MANETs and in Packet
Radio Networks both: wireless interfaces imply shared communication
resources which result in interdependence between nearby nodes, and
these nodes often communicate directly or indirectly. Wireless
channel statistical dynamics and node mobility may result in frequent
packet channel losses and network topology changes.
Figure 3 shows a general schematic of a MANET: each MANET Router
(MNR) has one or more MANET Interfaces, over which MANET interface
aware protocols operate to ensure MANET communication, and zero or
more non-MANET interfaces, either towards hosts or other networks.
Over these non-MANET interfaces, protocols need not be aware of MANET
interface characteristics, thus classic IP interfaces can be assumed.
+---+
|MNR|
+-|-+
+-+ +---+ / /|\ \ +---+ +-+
| |...MNR--- .-. ---MNR|..| |
+-+ +---+ \ ,-( _)-. / +---+ +-+
.-(_ MANET )-.
Other ( Communication )
Nodes `-(______)-'
and \|/ \|/
Networks +-|-+ +-|-+
|MNR| \|/ |MNR|
+-:-+ +-|-+ +-:-+
: |MNR| :
+-+ +-:-+ +-+
+-+ : +-+
+-+
+-+
Figure 3: Mobile Ad Hoc NETwork Example
4. MANET Interface Characteristics
Inheriting from Packet Radio as described above, primary
particularities of MANETs are the characteristics and qualities of
MANET interfaces, and the challenges these entail for protocol design
Chakeres, et al. Expires February 28, 2008 [Page 8]
Internet-Draft MANET Architecture August 2007
and development.
4.1. Qualities - Wireless, Mobile, Ad hoc
In MANETs several qualities impact protocol design. The most
fundamental qualities are wireless interface characteristics,
mobility, and ad hoc interaction.
Wireless interfaces exhibit challenging characteristics when compared
to wired interfaces. Many protocols (e.g. IPv6 neighbor discovery
[RFC2461]) do not operate in wireless networks with asymmetric
reachability. Wireless interfaces also exhibit dynamic time varying
performance (e.g. packet loss, data rate) that can significantly
impact local communication.
Mobility can also exacerbate wireless networking issues, making it
more challenging to attain, establish, and maintain network
relationships between nodes.
Ad hoc networking further compounds problems by allowing nodes to
join and leave the network, or even form new networks, at will.
4.2. Challenges
MANET characteristics result in many challenges. These challenges
reveal themselves in many forms, and MANET specific protocols must
often be developed.
4.2.1. Semi-Broadcast Interface
Given a wireless SBI that exhibits asymmetric reachability and
spatially distributed MANET Routers, each MANET Router may have a
different unique partial view of the MANET. That is, each node may
see a different set of adjacent MANET Routers.
Communication
Range
<~~~~~~+~~~~~~> <~~~~~~~~+~~~~~~~>
Single |<~~~~~~~~+~~~~~~~~>|
SBI +--|-+ +--|-+ +--|-+
|MNR1| |MNR2| |MNR3|
+----+ +----+ +----+
MNR1 MNR2 MNR3
-------------------------
Neighboring MNR2 MNR1 MNR2
Routers MNR3
Chakeres, et al. Expires February 28, 2008 [Page 9]
Internet-Draft MANET Architecture August 2007
Figure 4: Semi-Broadcast Interface (SBI) Neighboring Routers
The possibly unique set of adjacent MANET Routers perceived by each
MANET Router often requires MANET Routers to forward packets out the
same wireless interface as the one over which they were received.
Topologically, this act of forwarding out the same interface may
cause a packet to reach a different set of MANET Routers by
traversing the wireless communication medium in a new location. An
example is provided in Figure 4, where each MANET Router is capable
of reaching a different set of MANET Routers.
The act of forwarding packets out of the same interface as the one
over which they were received often results in duplicate IP packets
being received at MANET Routers with more than one neighboring MANET
Router, while also reaching a new subset of MANET Routers. Thus,
duplicate packet detection is often an inherent part of MANET
protocol designs.
4.2.2. Fuzzy Relationships Between Nearby MANET
Routers & MANET Routers Extended Neighborhood
Defining the process of determining neighboring MANET Routers'
existence, continued existence, and loss of existence is a
fundamental challenge in MANETs. Relationships with neighboring
MANET routers are hard to define due to the MANET interface
characteristics: potential asymmetric reachability, potential time
variation, and potentially other wireless properties.
Historically, two nodes are either neighbors or not neighbors and
several simple mechanisms have been used to determine neighbor
relationships: single packet reception, acceptable loss rates, and
simple handshakes. [RFC2461], for example, employs an initial
exchange of messages to determine neighborship, after which
neighborship (or absence thereof) is assumed permanent. In dynamic
wireless networks the types of neighbor relationships expand, as do
the mechanisms to detect and maintain the state of such
relationships.
Wireless network interfaces may exhibit unidirectional communication.
Dynamic wireless networks may also experience significant time
varying packet delivery between the same pair of wireless network
interfaces, so simple loss rates may not be sufficient to define a
neighbor relationship. Similarly, as nodes (and, hence, interfaces)
move relatively to each other, past loss rates may not reflect future
communication capabilities.
In wireless systems, nodes within the same small geographic region
are often densely connected with other nearby nodes. These nodes
Chakeres, et al. Expires February 28, 2008 [Page 10]
Internet-Draft MANET Architecture August 2007
form a set of extended neighbor relationships that is referred to as
a neighborhood. A neighborhood is typically composed of several
nodes, with each node being densely connected to other nodes.
These more dynamic neighbor relationships do not sit well with
certain Internet Protocols designed assuming a fixed Ethernet like
model to communication links (bidirectional, transitive, and stable).
Given the fuzzy neighbor relationships between MANET routers, the
addressing model often associated with a Ethernet link is not valid.
For example, in an Ethernet network routers are often told that a
particular range of addresses are directly reachable. In MANETs' a
node often cannot make assumptions that a particular set of
addressable nodes is always (directly) reachable. Instead, nodes
must detect and determine neighboring nodes, and handle changes to
this set over time.
4.2.3. MANET Membership
Given MANETs' characteristics (mobile, wireless, ad hoc), determining
a MANETs' membership is difficult, if not impossible in certain
scenarios.
/----------------------\ /----------------------\
| MANET | | MANET |
| +----+ +----+ +----+ | | +----+ +----+ +----+ |
| |MNR1+-+MNR2+-+MNR3| | | |MNR1+-+MNR2+-+MNR3| |
| +-+--+ +----+ +----+ | | +----+ +----+ +-+--+ |
| | | | | |
| +-+--+ | Change | +-+--+ |
| |MNR4| | in | |MNR7| |
| +----+ | Time | +----+ |
| \ | \----------------------/
| +----+ |
| |MNR5| |
| +----+ | /----------------------\
| / \ | | MANET |
| +----+ +----+ | | +----+ +----+ +----+ |
| |MNR6| |MNR7| | | |MNR6+-+MNR4+-+MNR5| |
| +----+ +----+ | | +----+ +----+ +----+ |
\----------------------/ \----------------------/
Figure 5: MANET(s)
At one moment a MANET might consist of a certain set of nodes, and
the next the MANET could partition into several MANETs. Later it
might re-merge or merge with a new set of nodes and form a larger
Chakeres, et al. Expires February 28, 2008 [Page 11]
Internet-Draft MANET Architecture August 2007
MANET.
Certain routers in a MANET might connect to other routing regions.
These routers are called Border Routers (BRs), and they often run
multiple routing protocol instances. BRs are responsible for
choosing the routing information to share between the various
attached routing regions. BRs should also present a consistent
picture of the nodes reachable through them.
As MANET membership changes, so does the connectivity of BR within
the MANET. Therefore, a BR may be challenged to present a consistent
set of reachable nodes. It may even choose not to share detailed
routing information about the MANET topology to other routing
regions.
5. Addressing & the MANET Prefix Model
This section presents an architectural model for MANETs which
preserves the integrity of the conventional IP addressing
architecture while allowing for the particularities of MANETs.
5.1. General Address Architecture
This architectural model considers MANET routers as simply routers
with addressable nodes attached, as illustrated in Figure 1. The
attached nodes may be "external" (i.e. attached to the router via
other network interfaces) or "internal". This implies that, from the
point of view of these entities and the applications running on them,
connectivity is via a classic IP interface. Therefore applications
are not exposed to the specific characteristics of MANET interfaces,
e.g. asymmetric reachability or fuzzy neighbor relationships.
A MANET router can be delegated zero or more prefixes. If a MANET
router is delegated a prefix p::, then prefixes derived from this
prefix (p:1::, p:2::, ...) may be assigned to the MANET routers
classic IP interfaces(s), and nodes on these classic IP interfaces
may be assigned addresses from within this prefix, and configured
with this prefix according to the address autoconfiguration
mechanisms governing these interfaces [RFC2461] and [RFC2462]. This
concept is illustrated in Figure 6.
MANET interface(s) that exhibit asymmetric reachability or unknown/
indeterministic membership attached to the router are specifically
*NOT* configured with this prefix. The configuration of these MANET
interfaces is detailed in Section 5.2.
If a MANET router is connected via a classic IP interface, on which
Chakeres, et al. Expires February 28, 2008 [Page 12]
Internet-Draft MANET Architecture August 2007
an existing prefix and address allocation entity is present, then
this interface may be configured with addresses and prefixes from
that classic IP link. This information may be in addition to or
instead of configuring the MANET routers interface towards that
classic IP link with a prefix derived from the prefix delegated to
the MANET router. A MANET routing protocol running on the MANET
routers' MANET interface(s) may or may not include addresses and
prefixes acquired on that MANET routers' interfaces and assigned to
classic IP links in its routing messages. The routing protocol
configuration is administratively determined when deploying a MANET.
MANET <~~~~~~+~~~~~~>
Interface | Delegated
| Prefix
''''''''''''''''''''' =========
' MANET ' <=== P:: =
' Router ' =========
''''''''' : ' Assigned
: ' : ' Prefix
: ' +--------+' =========
============ : ' |Loopback|' <=== P:1:: =
= : = : ' +--------+' =========
=Classic IP= : ''''''''''''' Assigned
=Interfaces= : Prefix
============ : =========
+......+......+ <=== P:2:: =
: : =========
+-+-+ +-+-+
| N | * * * | N |
+---+ +---+
P:2::1 P:2::K
Figure 6: MANET Router and Prefixes
5.2. MANET Interface Configuration
MANET specific behaviors are exclusively exposed to the MANET
interface(s) of the routers. This behaviors may include asymmetric
reachability, semi-broadcast interfaces, fuzzy MANET router neighbor
relationships, unknown/indeterministic MANET membership, rapid
topology dynamics, etc.
The following characteristics deserve particular mention, since they
distinguish the configuration and behavior of MANET interface(s)
classic IP interfaces:
Chakeres, et al. Expires February 28, 2008 [Page 13]
Internet-Draft MANET Architecture August 2007
Unique Prefixes
MANET interfaces that are known to exhibit the above mentioned
properties must be configured with unique prefixes. The reason
for this requirements is so that no two MANET interfaces are
configured to appear within the same IP prefix. Common ways to
achieve this are:
* unnumbered interfaces (IPv4);
* link-local addresses (IPv6);
* /128 (IPv6) or /32 (IPv4) prefixes.
It is worth noting that prefix lengths shorter than /128 (IPv6) or
/32 (IPv4) are possible on the MANET interfaces, as long as the
prefixes are unique to a single MANET interface. Note that the
above statement is not an exception, but simply a clarification
that MANET are no different from other networks in this respect.
Link-local Multicast/Broadcast Scope
On a MANET interface, a packet sent to a link-local multicast or
broadcast addresses reaches the MANET interfaces of neighboring
MANET routers, regardless of their configured addresses. Link-
local packets are never forwarded and since a MANET may span
several hops, nodes cannot assume that a packet sent to a link-
local address will reach all MANET routers within a MANET.
5.3. Routers and Hosts in a MANET
The MANET addressing model presented in this section makes a clear
separation between the role of router and host in a MANET,
recognizing that:
o MANET interfaces are seen only by the MANET aware router, assumed
to be MANET aware, and running appropriate protocols;
o nodes and networks/subnets on non-MANET interface(s) assume a
classic IP link model;
o applications on hosts and protocols assuming classic IP interfaces
run unmodified.
MANET protocols are protocols developed to work on MANET interfaces
and to be MANET-aware. The MANET WG is chartered to develop routing
protocols for MANET interfaces. The Autoconf WG is chartered to
develop autoconfiguration protocols for MANET interfaces and MANET
routers.
Chakeres, et al. Expires February 28, 2008 [Page 14]
Internet-Draft MANET Architecture August 2007
Note that this addressing framework is similar to how routing in the
existing Internet is structured. Routers run their routing protocol
over router interconnects with various characteristics to which only
the routing protocols are privy. On the other hand, hosts connect to
the routers over classic IP interfaces with well-known
characteristics.
6. MANETs' Place in the Network Stack
While the MANET WG is focused on network (L3) routing, that does not
imply that MANETs and their protocols are limited to L3. Several
previous and existing efforts are applying MANET protocols at various
layers. The challenges discussed above, exist independent of at
which layer MANET protocols are deployed. Of course, the protocols
themselves may need to be retooled slightly to accommodate the
information available to the deployed layer.
One example of sub-IP MANET routing is MANET MAC layer (L2) routing.
This type of routing is often called bridging, and may work in
homogeneous wireless networks for delivering frames over multiple
hops.
L2 routing/bridging hides the multiple L2 hops from L3. This
behavior can be advantageous as this network can transparently mimic
an Ethernet, to some extent. The ability to mimic Ethernet allows
the L2 MANET to utilize existing L3 network protocols. On the other
hand, this transparency may lead to performance problems. For
example, if the L3 protocols make heavy use of broadcast messaging or
if devices assume that high-speed wired bandwidth resources are
available.
L2 MANETs do not enable heterogeneity. That is, a L2 MANET is not
capable of bridging across heterogeneous interfaces. For example, L2
bridging cannot directly bridge two L2 technologies with different
addressing schemes. It can also be difficult if the frame sizes of
two L2 vary, as this could require breaking a single frame into
multiple frames of a different format.
L3 MANETs enable heterogeneous networking, as IP was built with this
feature in mind. Forming a MANET at L3 implies that the L3 protocols
must handle the challenges presented in this document.
MANET like protocols can also be used at other layers, both above and
below L3. Another example is peer-to-peer (P2P) networks. These
networks have some of the same challenges as MANET, e.g. variable
neighbor relationships and changing membership.
Chakeres, et al. Expires February 28, 2008 [Page 15]
Internet-Draft MANET Architecture August 2007
7. Cross Layering
In wireless networks, and especially in MANETs, extended interfacing
among the network layers (physical, MAC, link, network, etc.) can be
extremely useful. Arguably, for MANET deployments to be successful,
some degree of cross layering should be considered. For example,
link layer feedback that a packet/frame was not able to be sent or
that it was not received could be used by the network layer to
indicate that a neighboring MANET router is no longer reachable.
This information and other extended interfacing could reduce, or
eliminate, some upper layer messaging. Further, it could
significantly reduce the latency in decision making. Note that
though a certain lower layer information is valuable, it likely needs
to be extrapolated or filtered before accurate assumptions about the
network state can be made. For example, failure to deliver a single
frame by itself may not be a good indicator that a node is or is not
reachable.
In networks with several different layers of MANET mechanisms, the
sharing of information across different layers can be even more vital
to creating and maintaining the network. For example, if a P2P
network is run on top of a L3 MANET, the two networks can share
information to use a similar optimized topology, and neighboring
MANET router state changes to reduce the messaging or the latency in
making decisions.
8. Deployment Taxonomy
The present and future proliferation of inexpensive wireless
interfaces continues to stimulate technical interest and developments
in the area of MANET for a wide variety of deployment scenarios. In
this section, we present several characteristics for describing
expected MANET deployments.
8.1. Service Availability
Nodes often expect certain services/servers to be available. When
describing a deployment scenario, it is important to specify the
expected services available and the distance between the
participating nodes. In MANET, nodes might assume a service is
available locally (within one IP hop) or within a particular scope
(one or more IP hops - MANET, site, global). Nodes might assume in
certain deployments that no special servers/services are available.
Finally, nodes might assume that servers are sometimes available, but
their availability is not guaranteed or ensured.
Different frameworks for autoconfiguration, network management, and
Chakeres, et al. Expires February 28, 2008 [Page 16]
Internet-Draft MANET Architecture August 2007
intra-AS routing can be developed based upon the expected constraints
and operating conditions.
8.2. Number of MANET Routers in a MANET
The number of peer MANET routers in a MANET is an important
consideration. This number is not the complete number of nodes in a
MANET (since MANET routers may support an arbitrary number of
connected nodes) but a measure of the number of MANET routers
participating as a cohesive flat routing region. That is, the number
of MANET routers within a single routing region.
While the number of peer MANET routers does not define scalability of
a MANET protocol, it is often useful to discuss the number of peer
MANET router to get a feel for maturity of typical deployment
solutions. For simplicity we define the following network sizes to
aid in discussion:
Small
2-30 peer MANET routers
Moderate
30-100 peer MANET routers
Large
100-1000 peer MANET routers
Very large
Larger than 1000 peer MANET routers
As of 2007, small and moderate size peer MANET routing scenarios have
matured and have undergone reasonable test and deployment experience.
MANETs of those sizes can perform reasonably well in many cases
without hierarchy. For scaling up to large and very large MANET
networks, routing hierarchies, a standard technique for wired
Internet routing, is a possibility. While scaling design extensions
exist, large and very large MANET flat routing regions are still a
topic of ongoing active research and are not discussed further here.
9. Security Considerations
Each MANET router may not know its neighborhood a priori
(Section 2.2), but it should determine its neighborhood dynamically
and track changes as the network evolves. Similarly for MANET
network membership (Section 4.2.3), MANET routers may leave or join a
MANET, and the MANET may partition or merge with others. In addition
to these issues, many MANET routers are expected to communicate over
Chakeres, et al. Expires February 28, 2008 [Page 17]
Internet-Draft MANET Architecture August 2007
wireless interfaces; and the "open" nature of wireless communication
means that nearby nodes will often be capable of sending and
receiving MANET protocol packets.
Without any security measures MANET routers operating under these
characteristics will often expose protocol information to and accept
information from nearby nodes. Protecting MANET routers from
disruptive nearby nodes can be performed by using CONFIDENTIALITY,
DATA INTEGRITY, and PEER ENTITY AUTHENTICATION.
Different deployments of MANETs may have very different security
requirements. For example, if a MANET is deployed for a military
purpose, exposing the network topology to any outside party may be
not be acceptable -- whereas for a civilian deployment exposure of
topology information may be of little or no importance. Furthermore,
different deployments may require different mechanisms to address
security issues (e.g. pre-sharing of keys or certificates), and the
MANET routers themselves may have various additional constraints
(e.g. computational power for generating or verifying cryptographic
attributes). Therefore, due to the large diversity of MANET routers
and their deployments, MANET protocols should allow for appropriate,
and possibly multiple or various, security mechanisms.
10. IANA Considerations
This is an informational document. IANA requirements for MANET
related protocols will be developed within the protocol
specifications for MANET protocols.
11. Acknowledgments
Discussions and developments concepts and architectural issues have
evolved over many years of discussion of related work within the
MANET WG. There are obviously many people that have contributed to
past discussions and related draft documents within the WG that have
influenced the development of these concepts that deserve
acknowledgment. The authors would like to thank all contributors to
the MANET and AUTOCONF WG efforts and those that have helped in the
review and content process.
While not entirely complete the authors would like to in
particular thank the following individuals for exhaustive
discussions and valuable contributions:
Jari Akko
Chakeres, et al. Expires February 28, 2008 [Page 18]
Internet-Draft MANET Architecture August 2007
Emmanuel Baccelli
Alan Cullen
Justin Dean
Christopher Dearlove
Tom Henderson
Bob Hinden
Thomas Narten
Charles Perkins
Subhranshu Singh
Fred Templin
Dave Thaler
Seung Yi
12. Informative References
[DWN03] Macker, J. and S. Corson, "Mobile Ad hoc Networking:
Routing Technology for Dynamic, Wireless Networks", IEEE
Press, Mobile Ad hoc Networking, Chapter 9, 2003.
[FL01] Freebersyser, J. and B. Leiner, "A DoD perspective on
mobile ad hoc networks", Addison Wesley C. E. Perkin, Ed.,
2001, pp. 29--51, July 2001.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
Chakeres, et al. Expires February 28, 2008 [Page 19]
Internet-Draft MANET Architecture August 2007
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations", RFC 2501, January 1999.
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.
Authors' Addresses
Ian D Chakeres
Motorola
Bagmane Tech Park
66/1, Plot 5, CV Raman Nagar
Bangalore, Karnataka 560093
India
Email: ian.chakeres@gmail.com
URI: http://www.ianchak.com/
Joe Macker
Naval Research Laboratory
Washington, DC 20375
USA
Email: macker@itd.nrl.navy.mil
Chakeres, et al. Expires February 28, 2008 [Page 20]
Internet-Draft MANET Architecture August 2007
Thomas Heide Clausen
LIX, Ecole Polytechnique
91128 Palaiseau CEDEX
France
Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org/
Chakeres, et al. Expires February 28, 2008 [Page 21]
Internet-Draft MANET Architecture August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chakeres, et al. Expires February 28, 2008 [Page 22]