idnits 2.17.1 draft-ietf-autoconf-manetarch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 865. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2007) is 6237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'DWN03' is defined on line 749, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-10 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-03 == Outdated reference: A later version (-38) exists of draft-templin-autoconf-dhcp-06 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (AUTOCONF) I. Chakeres 3 Internet-Draft Boeing 4 Intended status: Informational J. Macker 5 Expires: September 3, 2007 Naval Research Laboratory 6 T. Clausen 7 LIX, Ecole Polytechnique 8 March 2, 2007 10 Mobile Ad hoc Network Architecture 11 draft-ietf-autoconf-manetarch-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 3, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document discusses Mobile Ad hoc NETworks (MANETs). It 45 introduces basic MANET terms, characteristics, and challenges. This 46 document also defines several MANET entities and architectural 47 concepts. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Borrowed Terminology . . . . . . . . . . . . . . . . . . . 3 54 2.2. MANET Terminology . . . . . . . . . . . . . . . . . . . . 5 55 3. MANET Motivation Discussion . . . . . . . . . . . . . . . . . 6 56 4. MANET Interface Characteristics . . . . . . . . . . . . . . . 7 57 4.1. Qualities - Wireless, Mobile, Ad hoc . . . . . . . . . . . 7 58 4.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.2.1. Semi-Broadcast Interface . . . . . . . . . . . . . . . 8 60 4.2.2. Fuzzy Neighbor Relationship & Extended Neighborhood . 9 61 4.2.3. MANET Membership . . . . . . . . . . . . . . . . . . . 9 62 5. Addressing, aka the MANET Prefix Model . . . . . . . . . . . . 10 63 6. MANETs' Place in the Network Stack . . . . . . . . . . . . . . 13 64 7. Cross Layering . . . . . . . . . . . . . . . . . . . . . . . . 14 65 8. Deployment Taxonomy . . . . . . . . . . . . . . . . . . . . . 15 66 8.1. Service Availability . . . . . . . . . . . . . . . . . . . 15 67 8.2. Number of Peer MANET Routers . . . . . . . . . . . . . . . 15 68 8.3. Example Deployments . . . . . . . . . . . . . . . . . . . 16 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 71 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 72 12. Informative References . . . . . . . . . . . . . . . . . . . . 17 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 74 Intellectual Property and Copyright Statements . . . . . . . . . . 20 76 1. Introduction 78 A Mobile Ad hoc NETwork (MANET) consists of a loosely connected set 79 of MANET nodes. Each MANET node embodies a MANET router and zero or 80 more hosts. These routers organize and maintain a routing structure 81 among themselves. These routers usually communicate over wireless 82 links and may be mobile. MANETs' characteristics create challenges 83 in several areas, and often require protocol extensions or new MANET 84 protocols altogether. 86 This document is focused on IP networking, though many of MANETs' 87 concepts and issues span the protocol stack. 89 This document is meant to complement [RFC2501] in describing and 90 defining MANET. 92 2. Terminology 94 2.1. Borrowed Terminology 96 Much of the terminology in this document was borrowed from existing 97 documents, to list a few [RFC1812], [RFC2328], [RFC2453], [RFC2460], 98 [RFC2461], [RFC3513], [RFC3753], [I-D.iab-multilink-subnet-issues], 99 [I-D.templin-autoconf-dhcp], and [I-D.ietf-ipv6-2461bis]. Note that 100 the original text for the terms is often modified, though we have 101 attempted to maintain the same meaning. In the future, terms defined 102 elsewhere will likely be cited instead of included. 104 This document employs the following definitions: 106 Node 107 any device (router or host) that implements IP. 109 Router (RT) 110 a node that forwards IP packets not explicitly addressed to 111 itself. 113 Host 114 any node that is not a router, i.e. it does not forward packets 115 addressed to others. 117 Link 118 A communications facility at a layer below IP, over which nodes 119 exchange IP packets directly without decrementing IP TTL (Hop 120 Limit). 122 Asymmetric Reachability 123 A link where non-reflexive and/or non-transitive reachability is 124 part of normal operation. Non-reflexive reachability means 125 packets from X reach Y but packets from Y don't reach X. Non- 126 transitive reachability means packets from X reach Y, and packets 127 from Y reach Z, but packets from X don't reach Z. Many radio/ 128 wireless interfaces exhibit these properties. 130 Neighbor 131 If node X can directly exchange IP packets with node Y, then node 132 Y is node X's neighbor. Packet reception characteristics are 133 often used to assist devices in determining the quality of 134 neighbors' communication. 136 Interface 137 A node's point of attachment to a communication link. 139 Broadcast Interface 140 An interface supporting many attached nodes, together with the 141 capability to address a single link layer message to all of the 142 attached nodes (broadcast). The set of nodes receiving a given 143 physical broadcast message are the neighbors of the node 144 originating the message. 146 Full-Broadcast Interface (FBI) 147 A broadcast interface with reflexive and transitive reachability. 148 All nodes on the interface can send and receive IP packets 149 directly, all nodes are symmetric neighbors. An Ethernet segment 150 is an example of a FBI. 152 Semi-Broadcast Interface (SBI) 153 A broadcast interface that may exhibit non-reflexive and/or non- 154 transitive reachability. A FBI is a special case of SBI. 155 Multiple access wireless radio interfaces are often SBI. 157 Site 158 a set of one or more links. 160 Flooding 161 The process of forwarding or distributing information to all 162 devices with in a bounded region. 164 Border Router (MBR) 165 a router that participates in multiple routing regions, and often 166 multiple routing protocols. A BR forms a border between its 167 multiple routing regions. A BR is responsible for presenting a 168 consistent picture of the nodes reachable through itself to each 169 routing region. A BR determines the routing information to 170 propagate between different routing regions. 172 2.2. MANET Terminology 174 In MANET there are two important entities. We define the following 175 entities: 177 MANET Node (MN) 178 a MANET node embodies a MANET router and zero or more hosts, as 179 illustrated in Figure 1. 181 MANET Router (MR) 182 an entity that has one or more MANET interfaces and that engages 183 in a MANET routing protocol. A MANET router may also have zero or 184 more classic IP interfaces to which hosts may connect. 186 <~~~~~~+~~~~~~> MANET 187 | INTERFACE 188 ''''''''''|'''''''''' 189 ' +-------|------+ ' 190 ' | MANET Router | ' 191 ' +-------+-+----+ ' 192 ' : : ' 193 ' MANET : +---+ ' 194 ' Node : | H | ' ============ 195 ' : +---+ ' = : = 196 '''''''''':'''''''''' =CLASSIC IP= 197 +......+......+ =INTERFACES= 198 : : ============ 199 +-+-+ +-+-+ 200 | H | * * * | H | 201 +---+ +---+ 203 Figure 1: MANET Node 205 In MANET there are several architectural scopes. We define the 206 following scopes: 208 MANET Neighbors 209 a set of MANET routers that is reachable in one hop over MANET 210 interface(s). 212 MANET N-Neighborhood 213 a set of MANET routers that is reachable in a N hops. These 214 routers usually have a large number of common neighbors and may 215 directly compete for the same shared wireless resources. 217 MANET 218 a set of MANET routers that is reachable via one or more hops. 220 If a link forms between two previously separated MANET routers or 221 MANETs, the two MANETs will merge to form a single larger MANET. 222 Similarly, if a critical link between two MANET routers is lost the 223 MANET will partition into two MANETs. 225 When discussing MANETs' connectivity to other networks, like the 226 Internet, a MANET is bounded by border routers (BR). That is, a 227 MANETs' BR form a border between a MANET and other routing regions. 229 3. MANET Motivation Discussion 231 The Internet Protocol (IP) core design tenets -- connectionless 232 networking and packet-based forwarding -- are ideally suited for use 233 in highly dynamic contexts, such as MANETs. Yet, some additional 234 functionality is required to meet the unique challenges and 235 opportunities present in MANETs. 237 The initial motivation for MANETs was called Packet Radio (PR) 238 networking [FL01]. In PR, each router is equipped with a single SBI. 239 This configuration is the simplest MANET router configuration. Each 240 router may be mobile, and the routers may be or may become spatially 241 distributed such that all routers cannot communicate directly. That 242 is, two routers might require one or more other intermediate routers 243 to forward (route) packets on their behalf. In the example shown in 244 Figure 2, for RT1 to send packets to RT3, the intermediary RT2 must 245 relay the packets. This implies that RT2 must receive the packet 246 from RT1 on its interface and determine that it must retransmit the 247 packet over the same interface as the one where the packet was 248 received, in order for the packet to reach RT3. This example also 249 illustrates how SBIs differ from FBIs: from the point of view of RT2, 250 both RT1 and RT3 are neighbors, whereas RT1 and RT3 are not 251 themselves neighbors with one another. 253 Communication 254 Range 255 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 256 Single | <~~~~~~+~~~~~~> | 257 SBI +-|-+ +-|-+ +-|-+ 258 |RT1| |RT2| |RT3| 259 +---+ +---+ +---+ 261 Figure 2: Basic MANET Network 263 In addition to addressing nodes' asymmetric reachability other 264 challenges exist. In PR networks, shared wireless resources result 265 in interdependence between nearby nodes, and these nodes often 266 communicate directly or indirectly. The dynamic wireless interface 267 characteristics and node mobility often manifest as frequent network 268 topology changes. 270 PR networks also lead to several other architecture related 271 challenges. One challenge was to attach these PR networks to other 272 networks, especially fixed networks like the ARPANET. Another 273 related challenge was how to deal with the large disparity between 274 different node and interface characteristics. 276 These PR network challenges helped stimulate the Internet Protocol; 277 an architecture based on connectionless networking and packet-based 278 forwarding that enables interconnection of heterogeneous devices over 279 heterogeneous interfaces. 281 4. MANET Interface Characteristics 283 Inheriting from Packet Radio as described above, a chief 284 particularity of MANETs are the characteristics and qualities of 285 MANET interfaces, and the challenges these entail for protocol design 286 and development. 288 4.1. Qualities - Wireless, Mobile, Ad hoc 290 In MANET several qualities impact protocol design. The most 291 fundamental qualities are wireless interface characteristics, 292 mobility, and ad hoc interaction. 294 Wireless interfaces exhibit challenging characteristics when compared 295 with wired interfaces. Many protocols (e.g. neighbor discovery) do 296 not operate in wireless networks with asymmetric reachability. 297 Wireless interfaces also exhibit time varying performance that can 298 significantly impact local communication. 300 Mobility can also exacerbates wireless networking issues, making it 301 more challenging to attain, establish, and maintain network neighbor 302 relationships between nodes. 304 Ad hoc networking further compounds problems by allowing nodes to 305 join and leave the network, or even form new networks, at will. 307 4.2. Challenges 309 MANETs characteristics result in many challenges. These challenges 310 reveal themselves in many forms, and MANET specific protocols must 311 often be developed. 313 4.2.1. Semi-Broadcast Interface 315 Given a wireless SBI (with non-transitive and non-reflexive 316 properties) and spatially distributed nodes, each node may have a 317 different unique partial view of the MANET. That is, each node may 318 have a different set of adjacent nodes. 320 Communication 321 Range 322 <~~~~~~+~~~~~~> <~~~~~~+~~~~~~> 323 Single | <~~~~~~+~~~~~~> | 324 SBI +-|-+ +-|-+ +-|-+ 325 |RT1| |RT2| |RT3| 326 +---+ +---+ +---+ 328 RT1 RT2 RT3 329 ------------------------- 330 Neighbors * RT2 RT1 RT2 331 * RT3 333 Figure 3: Semi-Broadcast Interface (SBI) Neighbors 335 The possibly unique set of adjacent nodes in each node often requires 336 nodes to forward packets out the same wireless interface as the one 337 over which they were received. Topologically, this act of forwarding 338 out the same interface causes a packet to reach a possibly different 339 set of nodes by traversing the wireless communication medium in a new 340 location. An example is provided in Figure 3, where each router is 341 capable of reaching a different set of routers. 343 The act of forwarding packets out of the same interface as the one 344 over which they were received often results in duplicate IP packets 345 being received at nodes with more than one neighbor, while also 346 reaching a new subset of nodes. 348 4.2.2. Fuzzy Neighbor Relationship & Extended Neighborhood 350 Defining the process of determining a neighbor's existence, continued 351 existence, and loss of existence is a fundamental challenge in 352 MANETs. Neighbors are hard to define due to the expected interface 353 characteristics: non-transitive, non-reflexive, time varying, and 354 other wireless properties. 356 Historically, two nodes are either neighbors or not neighbors and 357 several simple mechanisms have been used to determine a neighbor 358 relationship: single packet reception, acceptable loss rates, and 359 simple handshakes. In wireless networks the types of neighbor 360 relationships expand, as do the mechanisms to detect and maintain the 361 state of such relationships. 363 In wireless networks, nodes may often have non-reflexive (also often 364 seen called unidirectional or asymmetric) communication links. 365 Wireless networks also experience significant time varying packet 366 delivery, so simple loss rates may not be sufficient to define a 367 neighbor relationship. Similarly, as nodes move relatively to each 368 other, past loss rates may not reflect future communication 369 capabilities. 371 In wireless systems, nodes within the same small geographic region 372 are often densely connected with other nodes in the same region. 373 These nodes form a set of extended neighbor relationships that is 374 referred to as a neighborhood. A neighborhood is typically composed 375 of several nodes, with each node being densely connected to other 376 nodes. 378 These more dynamic neighbor relationships do not sit well with 379 certain Internet Protocols designed assuming an fixed Ethernet like 380 model to communication links (reflexive, transitive, and stable). 381 Given the unknown neighbor relationships, the addressing model often 382 associated with a Ethernet link is not valid. For example, in an 383 Ethernet network routers are often told that a particular range of 384 addresses are directly reachable. In MANETs' a node often cannot 385 make assumptions that a particular set of addressable nodes is always 386 reachable. Instead, nodes must detect and determine their neighbors, 387 and handle the changes to their neighbors over time. 389 4.2.3. MANET Membership 391 Given MANETs' characteristics (mobile, wireless, ad hoc), determining 392 a MANETs' membership is difficult, if not impossible in certain 393 scenarios. 395 /----------------------\ /----------------------\ 396 | MANET | | MANET | 397 | +---+ +---+ +---+ | | +---+ +---+ +---+ | 398 | |MN1+-+MN2+-+MN3| | | |MN1+-+MN2+-+MN3| | 399 | +-+-+ +---+ +---+ | | +---+ +---+ +-+-+ | 400 | | | | | | 401 | +-+-+ | Change | +-+-+ | 402 | |MN4+ | in | |MN7| | 403 | +---+\ | Time | +---+ | 404 | \+---+ | \----------------------/ 405 | +MN5+ | /----------------------\ 406 | /+---+\ | | MANET | 407 | +---+/ \+---+ | | +---+ +---+ +---+ | 408 | |MN6+ +MN7| | | |MN6+--+MN4+--+MN5| | 409 | +---+ +---+ | | +---+ +---+ +---+ | 410 \----------------------/ \----------------------/ 412 Figure 4: MANET(s) 414 At one moment a MANET might consist of a certain set of nodes, and 415 the next the MANET could partition into several MANETs. Later it 416 might re-merge or merge with a new set of nodes and form a larger 417 MANET. 419 To assist in coordinating among a loosely connected set of MANET 420 routers, a procedure called flooding is used. MANET flooding consist 421 of disseminating a packet to all connected MANET routers. 423 Certain routers in a MANET might connect to other routing regions. 424 These routers are called MANET Border Routers (MBR), and they often 425 run multiple routing protocol instances. The MBR are responsible for 426 choosing the routing information to share between the various 427 attached routing regions. The MBR should also present a consistent 428 picture of the nodes reachable through them. 430 As MANET membership changes, so does the connectivity of MBR within 431 the MANET. Therefore, a MBR may be challenged to present a 432 consistent set of reachable nodes. It may even choose not to share 433 routing information about the MANET topology to other routing 434 regions. 436 5. Addressing, aka the MANET Prefix Model 438 This section presents an architectural model for MANETs which 439 preserves the integrity of the IP architecture while allowing for the 440 particularities of MANETs. 442 This architectural model considers MANET nodes as routers with hosts 443 attached, as illustrated in Figure 5. These attached hosts may be 444 "external" (i.e. attached to the router via other network interfaces) 445 or "internal" - however the important observation to make is, that 446 the links between these hosts and the router are classic IP links. 447 This fact implies that, from the point of view of the hosts and the 448 applications running on these hosts, connectivity is via a classic IP 449 link. Hosts and their applications are not exposed to the specific 450 characteristics of the MANET interfaces and are connected to the 451 MANET via a router, which has one or more MANET interfaces. 453 <~~~~~~+~~~~~~> MANET <~~~~~~+~~~~~~> 454 | INTERFACE | 455 ''''''''''|'''''''''' ''''''''''|'''''''''' 456 ' +-|-+ MANET ' ' MANET +-|-+ ' 457 ' | R | Node ' ' Node | R | ' 458 ' +-+-+ ' ' +-+-+ ' 459 ' : : ' ' : : ' 460 ' : +---+ ' ' : +---+ ' 461 ' : | H | ' ============ ' : | H | ' 462 ' : +---+ ' = : = ' : +---+ ' 463 '''''''''':'''''''''' =CLASSIC IP= ' : ' 464 +......+......+ =INTERFACES= ' +......+......+ ' 465 : : ============ ' : : ' 466 +-+-+ +-+-+ '+-+-+ +-+-+' 467 | H | * * * | H | '| H | * * * | H |' 468 +---+ +---+ '+---+ +---+' 469 ''''''''''''''''''''' 471 Figure 5: MANET Addressing Model 473 If the MANET router is delegated a prefix p::, this prefix can be 474 assigned to the classic IP link(s), and hosts can be assigned 475 addresses from within this prefix, and configured with this prefix as 476 illustrated in Figure 6. Specifically, the MANET interface(s) of the 477 router are *not* configured with this prefix. The configuration of 478 MANET interfaces is detailed below. 480 MANET <~~~~~~+~~~~~~> 481 INTERFACE | ASSIGNED 482 ''''''''''|'''''''''' PREFIXES 483 ' MANET +-|-+ ' ========= 484 ' Node | R | ' <=== P:: = 485 ' +-+-+ ' ========= 486 ' : : ' 487 ' : +---+ ' ========= 488 ============ ' : | H | ' <=== P:1:: = 489 = : = ' : +---+ ' ========= 490 =CLASSIC IP= ' : ' 491 =INTERFACES= ' +......+......+ ' 492 ============ ' : : ' 493 '+-+-+ +-+-+' ========= 494 '| H | * * * | H |' <=== P:2:: = 495 '+---+ +---+' ========= 496 'P:2::1 P:2::N' 497 ''''''''''''''''''''' 499 Figure 6: MANET Node and Prefixes 501 MANET specific behaviors are exclusively exposed to the MANET 502 interface(s) of the routers. This includes MANET routing protocols 503 and interface and link characteristics (asymmetric neighborhoods, 504 semi-broadcast interfaces, fuzzy neighbor relationships, topology 505 dynamics, etc.). 507 The following characteristics deserve particular mention, since they 508 distinguish MANET interfaces and the MANET link model from the 509 classic IP link model: 511 Unique Prefixes 512 MANET interfaces must be configured with unique prefixes, that is 513 so that no two MANET interfaces are configured to appear within 514 the same IP prefix. Some common ways to achieve this are: 516 * unnumbered interfaces (IPv4) [RFC1812]; 518 * link-local addresses (IPv6); 520 * /128 (IPv6) or /32 (IPv4) prefixes. 522 However it is worth noting that prefix lengths shorter than /128 523 (IPv6) or /32 (IPv4) are possible on the MANET interfaces, as long 524 as the prefixes are unique to a single MANET interface. 526 Link-local Multicast/Broadcast Scope 527 On a MANET interface, a link-local multicast or broadcast reaches 528 MANET interfaces of neighboring nodes, regardless of their 529 configured addresses. A link-local multicast or broadcast on a 530 MANET interfaces is a "neighborcast" and is not forwarded, nor is 531 it assumed to be received by all nodes within a MANET. 533 The MANET addressing model presented in this section makes a clear 534 separation between the role of router and host in a MANET, 535 recognizing that: 537 o MANET interfaces are seen only by the router, assumed to be MANET 538 aware, and running appropriate protocols; 540 o MANET interfaces forming a multihop MANET area may use a site 541 prefix; 543 o hosts and subnets on a non-MANET interface assume a classic IP 544 link model; 546 o applications on hosts and protocols assuming classic IP interfaces 547 run unmodified. 549 MANET protocols are developed to work on MANET interfaces. The MANET 550 WG is chartered to develop routing protocols for MANET interfaces. 551 The Autoconf WG is chartered to develop autoconfiguration protocols 552 for MANET interfaces and MANET routers. 554 6. MANETs' Place in the Network Stack 556 While the MANET WG is focused upon network (L3) routing, that does 557 not imply that MANETs and their protocols are limited to L3. Several 558 previous and existing efforts are applying MANET protocols at various 559 layers. The challenges discussed above, exist independent of at 560 which layer MANET protocols are deployed. Of course, the protocols 561 themselves may need to be retooled slightly to accommodate the 562 information available to the deployed layer. 564 MANET MAC layer (L2) routing, more often called bridging, may work in 565 homogeneous wireless networks for delivering frames over multiple 566 hops. One example of L2 MANET is being developed in the IEEE 802.11s 567 effort. 569 L2 routing/bridging hides the multiple L2 hops from L3. This 570 behavior can be advantageous as this network can transparently mimic 571 an Ethernet, to some extent. The ability to mimic Ethernet allows 572 the L2 MANET to utilize existing L3 network protocols. 574 Alternatively, this transparency may lead to performance problems. 575 For example, if the L3 protocols make heavy use of broadcast 576 messaging or devices assume that high-speed wired bandwidth resources 577 are available. 579 L2 MANET does not enable heterogeneity. That is, L2 MANET is not 580 capable of bridging across heterogeneous interfaces. For example, L2 581 bridging cannot directly bridge two L2 technologies with different 582 addressing schemes. It can also be difficult if the frame sizes of 583 two L2 vary, as this could require breaking a single frame into 584 multiple frames of a different format. 586 L3 MANET enables heterogeneous networking, as IP was built with this 587 feature in mind. Forming a MANET at L3 implies that the L3 protocols 588 must handle the challenges presented in this document. 590 MANET like protocols can also be used at higher layers. One example 591 is peer-to-peer (P2P) networks. These networks have some of the same 592 challenges as MANET, e.g. variable neighbor relationships and 593 changing membership. 595 7. Cross Layering 597 In wireless networks, and especially in MANET, extended interfacing 598 among the network layers (physical, MAC, link, network, etc.) can be 599 extremely useful. Arguably, for MANET deployments to be successful, 600 some degree of cross layering should be considered. For example, 601 link layer feedback that a packet/frame was not able to be sent or 602 that it was not received could be used by the network layer to 603 indicate that a neighbor is no longer reachable. This information 604 and other extended interfacing could reduce, or eliminate, some upper 605 layer messaging. Further, it could significantly reduce the latency 606 in decision making. Note that though a certain lower layer 607 information is valuable, it likely needs to be extrapolated or 608 filtered before accurate assumptions about the network state can be 609 made. For example, failure to deliver a frame by itself may not be a 610 good indicator that a node is or is not reachable. 612 In networks with several different layers of MANET mechanism, the 613 sharing of information across different layers can be even more vital 614 to creating and maintaining the network. For example, if a P2P 615 network is run on top of a L3 MANET, the two networks can share 616 information to use a similar optimized topology. Similarly, they 617 could share neighbor state changes to reduce the messaging or latency 618 in making decisions. 620 8. Deployment Taxonomy 622 The present and future proliferation of inexpensive wireless 623 interfaces continues to stimulate technical interest and developments 624 in the area of MANET for a wide variety of deployment scenarios. In 625 this section, we present several characteristics for describing 626 expected MANET deployments. 628 8.1. Service Availability 630 Nodes often expect certain services/servers to be available. When 631 describing a deployment scenario, it is important to specify the 632 expected services available and the distance between the 633 participating devices. In MANET, nodes might assume a service is 634 available locally (within one IP hop) or within a particular scope 635 (one or more IP hops - MANET, site, global). Nodes might assume in 636 certain deployments that no special servers/services are available. 637 Finally, nodes might assume that servers are sometimes available, but 638 their availability is not guaranteed or ensured. 640 Different frameworks for autoconfiguration, network management, and 641 intra-AS routing can be developed based upon the expected constraints 642 and operating conditions. 644 8.2. Number of Peer MANET Routers 646 The number of peer MRs in a MANET is an important consideration. 647 This number is not the complete number of nodes in a MANET (since MRs 648 may support an arbitrary number of connected nodes) but a measure of 649 the number of MR participating as a cohesive flat routing area. That 650 is, the number of MR within a single routing region. 652 While the number of peer MRs does not define scalability of a MANET 653 protocol, it is often useful to discuss the number of peer MR to get 654 a feel for maturity of typical deployment solutions. For simplicity 655 we define the following network sizes to aid in discussion: 657 Small 658 2-30 MR peers 660 Moderate 661 30-100 MR peers 663 Large 664 100-1000 MR peers 666 Very large 667 Larger than 1000 MR peers 669 At the time of writing, small and moderate size peer MANET routing 670 scenarios have matured and have reasonable testing and deployment 671 experience. These sizes can perform reasonably well in many cases 672 without hierarchy. MANET architectures can, of course, support 673 routing hierarchies to improve scaling. Large and very large MANET 674 routing areas that are flat are still a topic of active research and 675 are not considered here. One can apply hierarchy to achieve scaling, 676 but again that is not being discussed here. Existing MANET routing 677 developments, such as SMF [I-D.ietf-manet-smf], have shown 678 significant performance improvements and capabilities even in small 679 peer router size deployments and experiments using classical routing 680 designs. 682 8.3. Example Deployments 684 Here we provide a short list of example deployment scenarios: 686 Home, office, campus, and community mesh networks 688 Disaster relief and first responder networks 690 Sensor networks 692 Range extension 694 Military communications 696 Automotive networks 698 9. Security Considerations 700 TBD 702 10. IANA Considerations 704 This is an informational document. IANA requirements for MANET 705 related protocols will be developed within the protocol 706 specifications for MANET protocols. 708 11. Acknowledgments 710 Discussions and developments concepts and architectural issues have 711 evolved over many years of discussion of related work within the 712 MANET WG. There are obviously many people that have contributed to 713 past discussions and related draft documents within the WG that have 714 influenced the development of these concepts that deserve 715 acknowledgment. The authors would like to thank all contributors to 716 the MANET and AUTOCONF WG efforts and those that have helped in the 717 review and content process. 719 While not entirely complete the authors would like to in 720 particular thank the following individuals for there discussions 721 and contributions: 723 Jari Akko 725 Emmanuel Baccelli 727 Justin Dean 729 Christopher Dearlove 731 Tom Henderson 733 Bob Hinden 735 Thomas Narten 737 Charles Perkins 739 Subhranshu Singh 741 Fred Templin 743 Dave Thaler 745 Seung Yi 747 12. Informative References 749 [DWN03] Macker, J. and S. Corson, "Mobile Ad hoc Networking: 750 Routing Technology for Dynamic, Wireless Networks", IEEE 751 Press, Mobile Ad hoc Networking, Chapter 9, 2003. 753 [FL01] Freebersyser, J. and B. Leiner, "A DoD perspective on 754 mobile ad hoc networks", Addison Wesley C. E. Perkin, Ed., 755 2001, pp. 29--51, July 2001. 757 [I-D.iab-multilink-subnet-issues] 758 Thaler, D., "Multilink Subnet Issues", 759 draft-iab-multilink-subnet-issues-03 (work in progress), 760 January 2007. 762 [I-D.ietf-ipv6-2461bis] 763 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 764 draft-ietf-ipv6-2461bis-10 (work in progress), 765 January 2007. 767 [I-D.ietf-manet-smf] 768 Macker, J., "Simplified Multicast Forwarding for MANET", 769 draft-ietf-manet-smf-03 (work in progress), October 2006. 771 [I-D.templin-autoconf-dhcp] 772 Templin, F., "MANET Autoconfiguration", 773 draft-templin-autoconf-dhcp-06 (work in progress), 774 February 2007. 776 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 777 RFC 1812, June 1995. 779 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 781 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 782 November 1998. 784 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 785 (IPv6) Specification", RFC 2460, December 1998. 787 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 788 Discovery for IP Version 6 (IPv6)", RFC 2461, 789 December 1998. 791 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 792 (MANET): Routing Protocol Performance Issues and 793 Evaluation Considerations", RFC 2501, January 1999. 795 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 796 (IPv6) Addressing Architecture", RFC 3513, April 2003. 798 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 799 RFC 3753, June 2004. 801 Authors' Addresses 803 Ian Chakeres 804 Boeing 805 The Boeing Company 806 P.O. Box 3707 Mailcode 7L-49 807 Seattle, WA 98124-2207 808 USA 810 Email: ian.chakeres@gmail.com 812 Joe Macker 813 Naval Research Laboratory 814 Washington, DC 20375 815 USA 817 Email: macker@itd.nrl.navy.mil 819 Thomas Heide Clausen 820 LIX, Ecole Polytechnique 821 91128 Palaiseau CEDEX 822 France 824 Email: T.Clausen@computer.org 825 URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/ 827 Full Copyright Statement 829 Copyright (C) The IETF Trust (2007). 831 This document is subject to the rights, licenses and restrictions 832 contained in BCP 78, and except as set forth therein, the authors 833 retain all their rights. 835 This document and the information contained herein are provided on an 836 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 837 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 838 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 839 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 840 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 841 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 843 Intellectual Property 845 The IETF takes no position regarding the validity or scope of any 846 Intellectual Property Rights or other rights that might be claimed to 847 pertain to the implementation or use of the technology described in 848 this document or the extent to which any license under such rights 849 might or might not be available; nor does it represent that it has 850 made any independent effort to identify any such rights. Information 851 on the procedures with respect to rights in RFC documents can be 852 found in BCP 78 and BCP 79. 854 Copies of IPR disclosures made to the IETF Secretariat and any 855 assurances of licenses to be made available, or the result of an 856 attempt made to obtain a general license or permission for the use of 857 such proprietary rights by implementers or users of this 858 specification can be obtained from the IETF on-line IPR repository at 859 http://www.ietf.org/ipr. 861 The IETF invites any interested party to bring to its attention any 862 copyrights, patents or patent applications, or other proprietary 863 rights that may cover technology that may be required to implement 864 this standard. Please address the information to the IETF at 865 ietf-ipr@ietf.org. 867 Acknowledgment 869 Funding for the RFC Editor function is provided by the IETF 870 Administrative Support Activity (IASA).