[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07                                       
MANET Autoconfiguration (AUTOCONF)                           I. Chakeres
Internet-Draft                                                    Boeing
Intended status: Informational                                 J. Macker
Expires: September 3, 2007                     Naval Research Laboratory
                                                              T. Clausen
                                                LIX, Ecole Polytechnique
                                                           March 2, 2007

                   Mobile Ad hoc Network Architecture

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 3, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   This document discusses Mobile Ad hoc NETworks (MANETs).  It
   introduces basic MANET terms, characteristics, and challenges.  This
   document also defines several MANET entities and architectural

Chakeres, et al.        Expires September 3, 2007               [Page 1]

Internet-Draft             MANET Architecture                 March 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
   4.  MANET Interface Characteristics  . . . . . . . . . . . . . . .  7
     4.1.  Qualities - Wireless, Mobile, Ad hoc . . . . . . . . . . .  7
     4.2.  Challenges . . . . . . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  Semi-Broadcast Interface . . . . . . . . . . . . . . .  8
       4.2.2.  Fuzzy Neighbor Relationship & Extended Neighborhood  .  9
       4.2.3.  MANET Membership . . . . . . . . . . . . . . . . . . .  9
   5.  Addressing, aka the MANET Prefix Model . . . . . . . . . . . . 10
   6.  MANETs' Place in the Network Stack . . . . . . . . . . . . . . 13
   7.  Cross Layering . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Deployment Taxonomy  . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Service Availability . . . . . . . . . . . . . . . . . . . 15
     8.2.  Number of Peer MANET Routers . . . . . . . . . . . . . . . 15
     8.3.  Example Deployments  . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   12. Informative References . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 20

Chakeres, et al.        Expires September 3, 2007               [Page 2]

Internet-Draft             MANET Architecture                 March 2007

1.  Introduction

   A Mobile Ad hoc NETwork (MANET) consists of a loosely connected set
   of MANET nodes.  Each MANET node embodies a MANET router and zero or
   more hosts.  These routers organize and maintain a routing structure
   among themselves.  These routers usually communicate over wireless
   links and may be mobile.  MANETs' characteristics create challenges
   in several areas, and often 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

2.1.  Borrowed Terminology

   Much of the terminology in this document was borrowed from existing
   documents, to list a few [RFC1812], [RFC2328], [RFC2453], [RFC2460],
   [RFC2461], [RFC3513], [RFC3753], [I-D.iab-multilink-subnet-issues],
   [I-D.templin-autoconf-dhcp], and [I-D.ietf-ipv6-2461bis].  Note that
   the original text for the terms is often modified, though we have
   attempted to maintain the same meaning.  In the future, terms defined
   elsewhere will likely be cited instead of included.

   This document employs the following definitions:

      any device (router or host) that implements IP.

   Router (RT)
      a node that forwards IP packets not explicitly addressed to

      any node that is not a router, i.e. it does not forward packets
      addressed to others.

      A communications facility at a layer below IP, over which nodes
      exchange IP packets directly without decrementing IP TTL (Hop

Chakeres, et al.        Expires September 3, 2007               [Page 3]

Internet-Draft             MANET Architecture                 March 2007

   Asymmetric Reachability
      A link where non-reflexive and/or non-transitive reachability is
      part of normal operation.  Non-reflexive reachability means
      packets from X reach Y but packets from Y don't reach X. Non-
      transitive reachability means packets from X reach Y, and packets
      from Y reach Z, but packets from X don't reach Z. Many radio/
      wireless interfaces exhibit these properties.

      If node X can directly exchange IP packets with node Y, then node
      Y is node X's neighbor.  Packet reception characteristics are
      often used to assist devices in determining the quality of
      neighbors' communication.

      A node's point of attachment to a communication link.

   Broadcast Interface
      An interface supporting many attached nodes, together with the
      capability to address a single link layer message to all of the
      attached nodes (broadcast).  The set of nodes receiving a given
      physical broadcast message are the neighbors of the node
      originating the message.

   Full-Broadcast Interface (FBI)
      A broadcast interface with reflexive and transitive reachability.
      All nodes on the interface can send and receive IP packets
      directly, all nodes are symmetric neighbors.  An Ethernet segment
      is an example of a FBI.

   Semi-Broadcast Interface (SBI)
      A broadcast interface that may exhibit non-reflexive and/or non-
      transitive reachability.  A FBI is a special case of SBI.
      Multiple access wireless radio interfaces are often SBI.

      a set of one or more links.

      The process of forwarding or distributing information to all
      devices with in a bounded region.

   Border Router (MBR)
      a router that participates in multiple routing regions, and often
      multiple routing protocols.  A BR forms a 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

Chakeres, et al.        Expires September 3, 2007               [Page 4]

Internet-Draft             MANET Architecture                 March 2007

      propagate between different routing regions.

2.2.  MANET Terminology

   In MANET there are two important entities.  We define the following

   MANET Node (MN)
      a MANET node embodies a MANET router and zero or more hosts, as
      illustrated in Figure 1.

   MANET Router (MR)
      an entity that has one or more MANET interfaces and that engages
      in a MANET routing protocol.  A MANET router may also have zero or
      more classic IP interfaces to which hosts may connect.

         <~~~~~~+~~~~~~>       MANET
                |            INTERFACE
      ' +-------|------+  '
      ' | MANET Router |  '
      ' +-------+-+----+  '
      '         :  :      '
      ' MANET   :   +---+ '
      ' Node    :   | H | ' ============
      '         :   +---+ ' =    :     =
      '''''''''':'''''''''' =CLASSIC IP=
         +......+......+    =INTERFACES=
         :             :    ============
       +-+-+         +-+-+
       | H |  * * *  | H |
       +---+         +---+

                           Figure 1: MANET Node

   In MANET there are several architectural scopes.  We define the
   following scopes:

   MANET Neighbors
      a set of MANET routers that is reachable in one hop over MANET

Chakeres, et al.        Expires September 3, 2007               [Page 5]

Internet-Draft             MANET Architecture                 March 2007

   MANET N-Neighborhood
      a set of MANET routers that is reachable in a N hops.  These
      routers usually have a large number of common neighbors and may
      directly compete for the same shared wireless resources.

      a set of MANET routers that is reachable via one or more hops.

   If a link forms between two previously separated MANET routers or
   MANETs, the two MANETs will merge to form a single larger MANET.
   Similarly, if a critical link between two MANET routers is lost the
   MANET will partition into two MANETs.

   When discussing MANETs' connectivity to other networks, like the
   Internet, a MANET is bounded by border routers (BR).  That is, a
   MANETs' 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
   functionality is required to meet the unique challenges and
   opportunities present in MANETs.

   The initial motivation for MANETs was called Packet Radio (PR)
   networking [FL01].  In PR, each router is equipped with a single SBI.
   This configuration is the simplest MANET router configuration.  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 other intermediate routers
   to forward (route) packets on their behalf.  In the example shown in
   Figure 2, for RT1 to send packets to RT3, the intermediary RT2 must
   relay the packets.  This implies that RT2 must receive the packet
   from RT1 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 RT3.  This example also
   illustrates how SBIs differ from FBIs: from the point of view of RT2,
   both RT1 and RT3 are neighbors, whereas RT1 and RT3 are not
   themselves neighbors with one another.

Chakeres, et al.        Expires September 3, 2007               [Page 6]

Internet-Draft             MANET Architecture                 March 2007

         <~~~~~~+~~~~~~>   <~~~~~~+~~~~~~>
   Single       | <~~~~~~+~~~~~~> |
   SBI        +-|-+    +-|-+    +-|-+
              |RT1|    |RT2|    |RT3|
              +---+    +---+    +---+

                       Figure 2: Basic MANET Network

   In addition to addressing nodes' asymmetric reachability other
   challenges exist.  In PR networks, shared wireless resources result
   in interdependence between nearby nodes, and these nodes often
   communicate directly or indirectly.  The dynamic wireless interface
   characteristics and node mobility often manifest as frequent network
   topology changes.

   PR networks also lead to several other architecture related
   challenges.  One challenge was to attach these PR networks to 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.

   These PR network challenges helped stimulate the Internet Protocol;
   an architecture based on connectionless networking and packet-based
   forwarding that enables interconnection of heterogeneous devices over
   heterogeneous interfaces.

4.  MANET Interface Characteristics

   Inheriting from Packet Radio as described above, a chief
   particularity of MANETs are the characteristics and qualities of
   MANET interfaces, and the challenges these entail for protocol design
   and development.

4.1.  Qualities - Wireless, Mobile, Ad hoc

   In MANET 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
   with wired interfaces.  Many protocols (e.g. neighbor discovery) do
   not operate in wireless networks with asymmetric reachability.
   Wireless interfaces also exhibit time varying performance that can
   significantly impact local communication.

Chakeres, et al.        Expires September 3, 2007               [Page 7]

Internet-Draft             MANET Architecture                 March 2007

   Mobility can also exacerbates wireless networking issues, making it
   more challenging to attain, establish, and maintain network neighbor
   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

   MANETs 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 (with non-transitive and non-reflexive
   properties) and spatially distributed nodes, each node may have a
   different unique partial view of the MANET.  That is, each node may
   have a different set of adjacent nodes.

         <~~~~~~+~~~~~~>   <~~~~~~+~~~~~~>
   Single       | <~~~~~~+~~~~~~> |
   SBI        +-|-+    +-|-+    +-|-+
              |RT1|    |RT2|    |RT3|
              +---+    +---+    +---+

               RT1      RT2      RT3
   Neighbors * RT2      RT1      RT2
             *          RT3

            Figure 3: Semi-Broadcast Interface (SBI) Neighbors

   The possibly unique set of adjacent nodes in each node often requires
   nodes 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 causes a packet to reach a possibly different
   set of nodes by traversing the wireless communication medium in a new
   location.  An example is provided in Figure 3, where each router is
   capable of reaching a different set of 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 nodes with more than one neighbor, while also

Chakeres, et al.        Expires September 3, 2007               [Page 8]

Internet-Draft             MANET Architecture                 March 2007

   reaching a new subset of nodes.

4.2.2.  Fuzzy Neighbor Relationship & Extended Neighborhood

   Defining the process of determining a neighbor's existence, continued
   existence, and loss of existence is a fundamental challenge in
   MANETs.  Neighbors are hard to define due to the expected interface
   characteristics: non-transitive, non-reflexive, time varying, and
   other wireless properties.

   Historically, two nodes are either neighbors or not neighbors and
   several simple mechanisms have been used to determine a neighbor
   relationship: single packet reception, acceptable loss rates, and
   simple handshakes.  In wireless networks the types of neighbor
   relationships expand, as do the mechanisms to detect and maintain the
   state of such relationships.

   In wireless networks, nodes may often have non-reflexive (also often
   seen called unidirectional or asymmetric) communication links.
   Wireless networks also experience significant time varying packet
   delivery, so simple loss rates may not be sufficient to define a
   neighbor relationship.  Similarly, as nodes move relatively to each
   other, past loss rates may not reflect future communication

   In wireless systems, nodes within the same small geographic region
   are often densely connected with other nodes in the same region.
   These nodes 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

   These more dynamic neighbor relationships do not sit well with
   certain Internet Protocols designed assuming an fixed Ethernet like
   model to communication links (reflexive, transitive, and stable).
   Given the unknown neighbor relationships, 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
   reachable.  Instead, nodes must detect and determine their neighbors,
   and handle the changes to their neighbors 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

Chakeres, et al.        Expires September 3, 2007               [Page 9]

Internet-Draft             MANET Architecture                 March 2007

      /----------------------\        /----------------------\
      |        MANET         |        |        MANET         |
      |  +---+ +---+ +---+   |        |  +---+ +---+ +---+   |
      |  |MN1+-+MN2+-+MN3|   |        |  |MN1+-+MN2+-+MN3|   |
      |  +-+-+ +---+ +---+   |        |  +---+ +---+ +-+-+   |
      |    |                 |        |                |     |
      |  +-+-+               | Change |              +-+-+   |
      |  |MN4+               |   in   |              |MN7|   |
      |  +---+\              |  Time  |              +---+   |
      |        \+---+        |        \----------------------/
      |         +MN5+        |        /----------------------\
      |        /+---+\       |        |         MANET        |
      |  +---+/       \+---+ |        |  +---+  +---+  +---+ |
      |  |MN6+         +MN7| |        |  |MN6+--+MN4+--+MN5| |
      |  +---+         +---+ |        |  +---+  +---+  +---+ |
      \----------------------/        \----------------------/

                            Figure 4: 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

   To assist in coordinating among a loosely connected set of MANET
   routers, a procedure called flooding is used.  MANET flooding consist
   of disseminating a packet to all connected MANET routers.

   Certain routers in a MANET might connect to other routing regions.
   These routers are called MANET Border Routers (MBR), and they often
   run multiple routing protocol instances.  The MBR are responsible for
   choosing the routing information to share between the various
   attached routing regions.  The MBR should also present a consistent
   picture of the nodes reachable through them.

   As MANET membership changes, so does the connectivity of MBR within
   the MANET.  Therefore, a MBR may be challenged to present a
   consistent set of reachable nodes.  It may even choose not to share
   routing information about the MANET topology to other routing

5.  Addressing, aka the MANET Prefix Model

   This section presents an architectural model for MANETs which
   preserves the integrity of the IP architecture while allowing for the
   particularities of MANETs.

Chakeres, et al.        Expires September 3, 2007              [Page 10]

Internet-Draft             MANET Architecture                 March 2007

   This architectural model considers MANET nodes as routers with hosts
   attached, as illustrated in Figure 5.  These attached hosts may be
   "external" (i.e. attached to the router via other network interfaces)
   or "internal" - however the important observation to make is, that
   the links between these hosts and the router are classic IP links.
   This fact implies that, from the point of view of the hosts and the
   applications running on these hosts, connectivity is via a classic IP
   link.  Hosts and their applications are not exposed to the specific
   characteristics of the MANET interfaces and are connected to the
   MANET via a router, which has one or more MANET interfaces.

         <~~~~~~+~~~~~~>       MANET        <~~~~~~+~~~~~~>
                |            INTERFACE             |
      ''''''''''|''''''''''              ''''''''''|''''''''''
      '       +-|-+ MANET '              ' MANET +-|-+       '
      '       | R | Node  '              ' Node  | R |       '
      '       +-+-+       '              '       +-+-+       '
      '         :  :      '              '         :  :      '
      '         :   +---+ '              '         :   +---+ '
      '         :   | H | ' ============ '         :   | H | '
      '         :   +---+ ' =    :     = '         :   +---+ '
      '''''''''':'''''''''' =CLASSIC IP= '         :         '
         +......+......+    =INTERFACES= '  +......+......+  '
         :             :    ============ '  :             :  '
       +-+-+         +-+-+               '+-+-+         +-+-+'
       | H |  * * *  | H |               '| H |  * * *  | H |'
       +---+         +---+               '+---+         +---+'

                     Figure 5: MANET Addressing Model

   If the MANET router is delegated a prefix p::, this prefix can be
   assigned to the classic IP link(s), and hosts can be assigned
   addresses from within this prefix, and configured with this prefix as
   illustrated in Figure 6.  Specifically, the MANET interface(s) of the
   router are *not* configured with this prefix.  The configuration of
   MANET interfaces is detailed below.

Chakeres, et al.        Expires September 3, 2007              [Page 11]

Internet-Draft             MANET Architecture                 March 2007

       MANET        <~~~~~~+~~~~~~>
     INTERFACE             |               ASSIGNED
                 ''''''''''|''''''''''     PREFIXES
                 ' MANET +-|-+       '    =========
                 ' Node  | R |       ' <=== P::   =
                 '       +-+-+       '    =========
                 '         :  :      '
                 '         :   +---+ '    =========
    ============ '         :   | H | ' <=== P:1:: =
    =    :     = '         :   +---+ '    =========
    =CLASSIC IP= '         :         '
    =INTERFACES= '  +......+......+  '
    ============ '  :             :  '
                 '+-+-+         +-+-+'    =========
                 '| H |  * * *  | H |' <=== P:2:: =
                 '+---+         +---+'    =========
                 'P:2::1       P:2::N'

                     Figure 6: MANET Node and Prefixes

   MANET specific behaviors are exclusively exposed to the MANET
   interface(s) of the routers.  This includes MANET routing protocols
   and interface and link characteristics (asymmetric neighborhoods,
   semi-broadcast interfaces, fuzzy neighbor relationships, topology
   dynamics, etc.).

   The following characteristics deserve particular mention, since they
   distinguish MANET interfaces and the MANET link model from the
   classic IP link model:

   Unique Prefixes
      MANET interfaces must be configured with unique prefixes, that is
      so that no two MANET interfaces are configured to appear within
      the same IP prefix.  Some common ways to achieve this are:

      *  unnumbered interfaces (IPv4) [RFC1812];

      *  link-local addresses (IPv6);

      *  /128 (IPv6) or /32 (IPv4) prefixes.

      However 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.

Chakeres, et al.        Expires September 3, 2007              [Page 12]

Internet-Draft             MANET Architecture                 March 2007

   Link-local Multicast/Broadcast Scope
      On a MANET interface, a link-local multicast or broadcast reaches
      MANET interfaces of neighboring nodes, regardless of their
      configured addresses.  A link-local multicast or broadcast on a
      MANET interfaces is a "neighborcast" and is not forwarded, nor is
      it assumed to be received by all nodes within 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 router, assumed to be MANET
      aware, and running appropriate protocols;

   o  MANET interfaces forming a multihop MANET area may use a site

   o  hosts and subnets on a non-MANET interface assume a classic IP
      link model;

   o  applications on hosts and protocols assuming classic IP interfaces
      run unmodified.

   MANET protocols are developed to work on MANET interfaces.  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.

6.  MANETs' Place in the Network Stack

   While the MANET WG is focused upon 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.

   MANET MAC layer (L2) routing, more often called bridging, may work in
   homogeneous wireless networks for delivering frames over multiple
   hops.  One example of L2 MANET is being developed in the IEEE 802.11s

   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.

Chakeres, et al.        Expires September 3, 2007              [Page 13]

Internet-Draft             MANET Architecture                 March 2007

   Alternatively, this transparency may lead to performance problems.
   For example, if the L3 protocols make heavy use of broadcast
   messaging or devices assume that high-speed wired bandwidth resources
   are available.

   L2 MANET does not enable heterogeneity.  That is, 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 MANET enables 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 higher layers.  One 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.

7.  Cross Layering

   In wireless networks, and especially in MANET, 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 neighbor 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 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 mechanism, 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.  Similarly, they
   could share neighbor state changes to reduce the messaging or latency
   in making decisions.

Chakeres, et al.        Expires September 3, 2007              [Page 14]

Internet-Draft             MANET Architecture                 March 2007

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 devices.  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
   intra-AS routing can be developed based upon the expected constraints
   and operating conditions.

8.2.  Number of Peer MANET Routers

   The number of peer MRs in a MANET is an important consideration.
   This number is not the complete number of nodes in a MANET (since MRs
   may support an arbitrary number of connected nodes) but a measure of
   the number of MR participating as a cohesive flat routing area.  That
   is, the number of MR within a single routing region.

   While the number of peer MRs does not define scalability of a MANET
   protocol, it is often useful to discuss the number of peer MR to get
   a feel for maturity of typical deployment solutions.  For simplicity
   we define the following network sizes to aid in discussion:

      2-30 MR peers

      30-100 MR peers

      100-1000 MR peers

Chakeres, et al.        Expires September 3, 2007              [Page 15]

Internet-Draft             MANET Architecture                 March 2007

   Very large
      Larger than 1000 MR peers

   At the time of writing, small and moderate size peer MANET routing
   scenarios have matured and have reasonable testing and deployment
   experience.  These sizes can perform reasonably well in many cases
   without hierarchy.  MANET architectures can, of course, support
   routing hierarchies to improve scaling.  Large and very large MANET
   routing areas that are flat are still a topic of active research and
   are not considered here.  One can apply hierarchy to achieve scaling,
   but again that is not being discussed here.  Existing MANET routing
   developments, such as SMF [I-D.ietf-manet-smf], have shown
   significant performance improvements and capabilities even in small
   peer router size deployments and experiments using classical routing

8.3.  Example Deployments

   Here we provide a short list of example deployment scenarios:

   Home, office, campus, and community mesh networks

   Disaster relief and first responder networks

   Sensor networks

   Range extension

   Military communications

   Automotive networks

9.  Security Considerations


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

Chakeres, et al.        Expires September 3, 2007              [Page 16]

Internet-Draft             MANET Architecture                 March 2007

   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 there discussions
      and contributions:

      Jari Akko

      Emmanuel Baccelli

      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.


Chakeres, et al.        Expires September 3, 2007              [Page 17]

Internet-Draft             MANET Architecture                 March 2007

              Thaler, D., "Multilink Subnet Issues",
              draft-iab-multilink-subnet-issues-03 (work in progress),
              January 2007.

              Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
              draft-ietf-ipv6-2461bis-10 (work in progress),
              January 2007.

              Macker, J., "Simplified Multicast Forwarding for MANET",
              draft-ietf-manet-smf-03 (work in progress), October 2006.

              Templin, F., "MANET Autoconfiguration",
              draft-templin-autoconf-dhcp-06 (work in progress),
              February 2007.

   [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,
              December 1998.

   [RFC2501]  Corson, M. and J. Macker, "Mobile Ad hoc Networking
              (MANET): Routing Protocol Performance Issues and
              Evaluation Considerations", RFC 2501, January 1999.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

Chakeres, et al.        Expires September 3, 2007              [Page 18]

Internet-Draft             MANET Architecture                 March 2007

Authors' Addresses

   Ian Chakeres
   The Boeing Company
   P.O. Box 3707 Mailcode 7L-49
   Seattle, WA  98124-2207

   Email: ian.chakeres@gmail.com

   Joe Macker
   Naval Research Laboratory
   Washington, DC  20375

   Email: macker@itd.nrl.navy.mil

   Thomas Heide Clausen
   LIX, Ecole Polytechnique
   91128 Palaiseau CEDEX

   Email: T.Clausen@computer.org
   URI:   http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/

Chakeres, et al.        Expires September 3, 2007              [Page 19]

Internet-Draft             MANET Architecture                 March 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Chakeres, et al.        Expires September 3, 2007              [Page 20]