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]