idnits 2.17.1 draft-wakikawa-manemo-problem-statement-00.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1047. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1071. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R10: The solution MUST not require modifications to any node other than nodes that participates to the MFS. It must support fixed nodes, mobile hosts and mobile routers in the NEMOs that form the MFS, and ensure backward compatibility with other standards defined by the IETF. -- 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 (February 5, 2007) is 6261 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '3') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '6') ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3775 (ref. '8') (Obsoleted by RFC 6275) == Outdated reference: A later version (-01) exists of draft-clausen-nemo-ro-problem-statement-00 == Outdated reference: A later version (-07) exists of draft-ietf-nemo-multihoming-issues-06 == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-06 == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-04 == Outdated reference: A later version (-14) exists of draft-ietf-manet-smf-03 == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-02 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-00 == Outdated reference: A later version (-10) exists of draft-ogier-manet-ospf-extension-08 == Outdated reference: A later version (-05) exists of draft-chandra-ospf-manet-ext-04 Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Expires: August 9, 2007 P. Thubert 5 Cisco 6 T. Boot 7 Infinity Networks 8 J. Bound 9 HP 10 B. McCarthy 11 Lancaster University 12 February 5, 2007 14 MANEMO Problem Statement 15 draft-wakikawa-manemo-problem-statement-00 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 9, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document outlines the fundamental problems and approach 49 rationale of MANEMO. When mobile nodes converge at the edge of the 50 Internet using wireless interfaces, they can form a network in an ad- 51 hoc fashion and are able to provide Internet connectivity to one 52 another. This type of network is called a MANEMO Fringe Stub (MFS). 53 Several issues exist in the MFS such as network loop, un-optimized 54 path and multiple exit routers to the Internet. While fixed routers 55 provide connectivity constantly, mobile routers can experience 56 intermittent connectivity to the Internet due to their movement. 57 When NEMO Basic Support is used in this context, network loops 58 naturally occur. NEMO forces the packets to always travel through 59 the home agent, which in turn causes an un-optimized path that can 60 become a considerable problem when mobile routers form a nested 61 topology. Multicast support introduces emphasized inefficiency. 62 Different types of routers are able to provide Internet connectivity 63 in the MFS, including both mobile routers and fixed access routers. 64 Any node requiring Internet connectivity has to select the best exit 65 router toward the Internet, therefore it is necessary for mobile 66 nodes to maintain a local topology in the MFS and to utilise any 67 available connectivity with a degree of Intelligence. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.1. Layer 3 Mesh Network . . . . . . . . . . . . . . . . . . . 9 77 3.2. Layer 3 Sensor Network . . . . . . . . . . . . . . . . . . 9 78 3.3. Fleet at sea . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4. Crowd of Personal Mobile Router . . . . . . . . . . . . . 10 80 3.5. Deployable and Mobile networks . . . . . . . . . . . . . . 11 81 3.6. Disaster-Ready municipal network . . . . . . . . . . . . . 11 82 3.7. Various Access Points Discovery (beyond 802.21) . . . . . 12 84 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 87 5.1. Network Loop . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.2. Un-optimized Route . . . . . . . . . . . . . . . . . . . . 16 89 5.3. Multiple Exit Routers . . . . . . . . . . . . . . . . . . 18 91 6. Approach Rationale . . . . . . . . . . . . . . . . . . . . . . 20 92 6.1. Layer 2 (mesh, spanning tree) based approach . . . . . . . 20 93 6.2. 802.21 based approach . . . . . . . . . . . . . . . . . . 20 94 6.3. MANET based approach . . . . . . . . . . . . . . . . . . . 21 95 6.4. Neighbor Discovery based approach . . . . . . . . . . . . 22 96 6.4.1. MANEMO ND and other MANET protocols . . . . . . . . . 23 97 6.4.2. MANEMO ND and AUTOCONF . . . . . . . . . . . . . . . . 23 99 7. Related Information . . . . . . . . . . . . . . . . . . . . . 25 101 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 11.1. Normative reference . . . . . . . . . . . . . . . . . . . 28 109 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 29 111 Appendix A. Change Log From Previous Version . . . . . . . . . . 31 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 114 Intellectual Property and Copyright Statements . . . . . . . . . . 33 116 1. Introduction 118 With routers and access points now being priced as a commodity, a 119 cloud of nodes connected by wireless technology is being created at 120 the edge of the Internet. This cloud is called a MANEMO Fringe Stub 121 (MFS) in this document. The definition of all the terms used in this 122 document can be found in Section 2. Examples of these wireless 123 technologies used within a MFS are wireless metropolitan and local 124 area network protocols (WiMAX, WLAN, 802.20, etc), short distance 125 wireless technology (bluetooth, irDA, UWB), and radio mesh networks 126 (ex. 802.11s). As the MFS extends to the consumer market and into 127 the homes, it's ease of use should become comparable to that of 128 existing electrical appliances and extension cords, i.e. highly user 129 friendly with little or no user interaction required. As a result, 130 networking in the MFS will be highly unmanaged and ad-hoc, but at the 131 same time will need to offer excellent service availability. 133 In particular, NEMO basic support [1] could be used to provide global 134 reachability for a mobile access network within the MFS. However, 135 when Mobile Nodes attach randomly to one another in this model (to 136 form what is termed a nested NEMO) the overall structure can become 137 highly suboptimal and loops can also possibly occur. 139 Therefore, there is a need for additional information to be made 140 available to Mobile Nodes to help them select an interface and an 141 attachment router over that interface in order to reach the Internet 142 (possibly indirectly) in a fashion avoiding network loops. The aim 143 of MANEMO is to enable this to happen in the MFS through the design 144 of a specific MANET, tailored for the needs of nested NEMO that can 145 form an optimized acyclic graph directed to the to the outside 146 infrastructure and the Internet when it is reachable. 148 MANEMO enables a Mobile Router to install one or more default 149 route(s) towards the Internet and be globally reachable using NEMO. 151 MANEMO may also be required to install backward routes towards 152 prefixes owned by a Mobile Router in each of the intermediate routers 153 from the selected Exit Router down to that Mobile Router. 155 Finally, Internet connectivity in mobile scenarios can be costly, 156 limited or unavailable, therefore there is a need to enable local 157 routing between the Mobile Routers within a portion of the MFS. This 158 form of local routing is useful for route optimization between Mobile 159 Routers that are communicating directly in a portion of the MFS. 161 This type of local communication is especially an efficiency 162 improvement for multicast, as MANEMO multicast traffic could be 163 distributed in the MFS without the overhead of nested tunnels and 164 pseudo-broadcasting. 166 2. Terminology 168 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [2] 172 Readers are expected to be familiar with all the terms defined in the 173 RFC3753 [3] and the NEMO Terminology draft [4] 175 Directed Graph A graph whose edges are ordered pairs of vertices. 176 That is, each edge can be followed from one vertex to another 177 vertex. 179 Directed Acyclic Graph (DAG) Directed graph with no path that starts 180 and ends at the same vertex - in other words, loopless. 182 Capability, Innocuousness and Anonymity (CIA) Concepts which might 183 replace the traditional AAA model in some circumstances in the 184 MFS: 186 Capability: Capability explores whether an Attachment Router can 187 actually provide the requested services (reach back to Home, 188 bandwidth...) 190 Innocuousness: Innocuousness guarantees that giving a service to 191 a peer (forwarding) or using a service from a peer (attaching) 192 is harmless to itself. 194 Anonymity: Anonymity ensures that peers are unable to identify 195 one another. This concept might contradict that of rating 196 peers which can be useful for peer to peer policing (tit for 197 tat). 199 Exit Router The Exit Router is a router which provides Internet 200 connectivity and acts as a layer-3 sink for the MFS. The Exit 201 Router can be a fixed Access Router supporting MANEMO or a mobile 202 router (root-MR) connected directly to the Internet. Multiple 203 Exit Routers may be available in an MFS. 205 Exit Route An Exit Route is a next hop on a Mobile Router towards an 206 Exit Router 208 Local Communication Local Communication is communication between 209 nodes in the same MFS without going through the Internet. 211 Local Routing Local Routing is a routing scheme inside a MFS. 212 MANEMO is used for arranging a tree structure towards the 213 Internet. In addition, other MANET protocols can be used to 214 optimise Local Communication. 216 MANEMO MANET for NEMO. MANEMO provides the necessary additions to 217 existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to 218 find the most suited exit towards the infrastructure. MANEMO 219 enables some internal connectivity within the nested NEMO whether 220 the infrastructure is reachable or not. MANEMO is not MANET + 221 NEMO. MANET + NEMO could suggest a MANET protocol reuse whereas 222 MANET for NEMO suggests the development of a new protocol. 224 MANEMO Fringe Stub (MFS) The MANEMO Fringe Stub is a cloud of Mobile 225 Routers connected by wireless or wired links. Any type of link 226 supporting IPv6 connectivity can be used, including partly meshed 227 wireless topologies. An MFS is a stub at the edge of the 228 Internet, interconnecting various types of devices which discover 229 each other and form a network in an ad-hoc fashion to provide 230 Internet connectivity to one another. Many disjunctive MFS can be 231 connected to the Internet. An MFS can also be floating, which 232 means the cloud is not connected to the Internet. 234 MANEMO Link A MANEMO Link is a MANEMO enabled Mobile Router 235 interface and the data link layer transmission medium connected to 236 it. Via the link, other nodes can be reached, called the 1st hop 237 neighbors. 239 MANEMO Path A MANEMO Path is a network path between a Mobile Router 240 and the root of the MANEMO Tree, the Exit Router. For Local 241 Communication, an up-tree and down-tree path provides connectivity 242 within a MANEMO tree. 244 MANEMO Tree A MANEMO Tree is the simplest network topology 245 connecting Mobile Routers within a MFS to a single Exit Router. 246 The Exit Router is the root of the MANEMO Tree. In case of a 247 floating MFS, a Mobile Router shall be elected as root of the 248 MANEMO Tree. 250 Wireless Node A Wireless Node is a node that has a wireless link to 251 access the Internet. Example Wireless Nodes are a Mobile Node 252 (Mobile Host or Mobile Router) and a normal IPv6 node [5] with a 253 wireless link. 255 Nested NEMO The Nested NEMO is a network configuration where one or 256 more mobile routers are connected in nested formation. The 257 detailed issues can be found in [13] and [14]. 259 Self Optimizing A Self-Optimizing network is a self-forming, self- 260 healing network that adapts its topology dynamically in order to 261 optimize some metrics. 263 3. Use cases 265 3.1. Layer 3 Mesh Network 267 A layer 3 mesh network is a specific case of nested NEMO with very, 268 very slow inner movements of Mobile Routers relative to one another. 269 Change of attachment will be triggered by node additions and 270 interference, rather than actual displacement. 272 The mesh network is self-forming and self-healing. It forms a tree 273 that is rooted at the nearest Exit Router (wire access). The tree 274 will self-heal should a node fail, a radio link become unavailable 275 (for a temporary interference), or a node or a wire access be added 276 to the network. 278 In order to deploy a mesh network easily, the inner addressing should 279 be independent of the wire accesses. The MANEMO protocol should 280 enable packets transmitted from Mobile Routers visiting the mesh to 281 enter the Internet via an Exit Router with a topologically correct 282 address even though the inner mesh addresses may be only unique local 283 addresses. 285 3.2. Layer 3 Sensor Network 287 A Sensor Network is an extreme form of a MANET in terms of the amount 288 of devices and of their highly limited capabilities. Sensors can be 289 low cost, mass produced devices operating for years on a pair of AAA 290 batteries. A sensor dust can be spread over a monitored location, 291 and from that moment on, the sensors are fixed and operate for the 292 lifetime of their batteries, which are their most critical resource. 294 Around a Sensor Network, sinks are deployed in order to collect the 295 measurements from the sensors and relay the commands from the 296 controllers. Thus, sensors automatically form a structure to forward 297 unicast packets from the sensors to the sinks, and to propagate 298 broadcast packets across the network from the sinks. 300 The sensors act as a community, relaying packets for one another; but 301 the model reaches its limits due in one hand to the operational cost 302 on the batteries for listening to asynchronous packets from other 303 sensors and for forwarding, and in the other hand to the complexity 304 involved in forming an ad-hoc network over a large area. 306 In order to establish a routing infrastructure and scale to a large 307 geography, Mobile Routers can be deployed to form a mesh and act as 308 default gateways to backhaul and aggregate the sensor data. In that 309 case, most sensors could be either plain IPv6 hosts or at least be 310 optimized to relay over a limited area towards the nearest Mobile 311 Router. 313 The Mobile Routers themselves might be actually fixed and well- 314 distributed across the monitored location, with a few of them 315 equipped with a backhaul capability to the Infrastructure. They 316 could also be in fact mobile and appear, move and disappear, for 317 instance as a drone passes over the sensor field to sweep a 318 perimeter. The MANEMO protocol must ensure that the Exit Route(s) is 319 found and maintained as quickly as possible. 321 Finally, a possible flow in sensor networking is the polling of the 322 sensors by an application. The application request is multicast to 323 all sensors, and the sensors reply in a synchronized fashion. In 324 that flow, the command might interfere with itself as it is repeated 325 over the radios. Also, the sensor responses might interfere with one 326 another. The MANEMO protocol should aim at minimizing interference 327 with itself and could provide extensions to transport and aggregate 328 sensor data. 330 3.3. Fleet at sea 332 In the case of a fleet at sea, the MFS is moving together, with maybe 333 temporary splits and merges. Also, when the fleet is at sea, the 334 communications to the outside can be costly. 336 In this use case, some ships may have well defined roles (like 337 admiral ship, communications ships etc...) and therefore some 338 additional engineering maybe required when considering the routing. 339 For example, it may be desirable that certain specific ships be 340 identified as preferred Exit Routers (root-MR) for the MANEMO. 342 As opposed to the mesh networking and sensor networking cases, the 343 fleet at sea involves inner movements within the fleet as demanded by 344 the missions. As a result, some part of the fleet might split from 345 the rest but still maintain local connectivity using MANEMO, as well 346 as connectivity with the rest of the fleet using NEMO. In 347 particular, it is possible that the comms ship may act as a Mobile 348 Home for the fleet aggregation. 350 3.4. Crowd of Personal Mobile Router 352 Another use case is a crowd of personal Mobile Routers. In this use 353 case, people do not know each other but need to forward each others 354 packets to the nearest Exit Router in order for the whole system to 355 operate for everyone. Also, in this situation people may move quite 356 rapidly relative to one another therefore the density of the crowd 357 may be of significance. 359 In this sort of unmanaged environment we cannot rely on a traditional 360 (AAA, trust based) mechanism. Instead, the MANEMO protocol must 361 enable MRs to obtain the required Capabilities in an Innocuous 362 fashion. MANEMO has to enable and optimize the trade-off between 363 ensuring some reciprocity (TIT for TAT) and maintaining a safe degree 364 of Anonymity between the peer Mobile Routers. 366 3.5. Deployable and Mobile networks 368 A task-group could perform activities in a planned matter in an area 369 that lacks a capable data communication infrastructure. In such a 370 case, the infrastructure would be embedded in the task-group itself. 371 The used infrastructure would be heterogeneous; using whatever 372 wireless or wired technology that is allowed, applicable, affordable 373 and available. 375 During their task, elements such as ships, vehicles, airborne 376 elements and temporally used buildings, tents or other setups mostly 377 have fixed locations, but elements can relocate in a planned or 378 unplanned manner. During relocation, the data communication 379 facilities can be shut down or kept active. Shut down data 380 communication facilities would be classified as "on the hold" or "on 381 the pause". Data communication facilities that are active during 382 relocation are classified as "on the move". Networks with a high 383 degree of stationary elements are called "Deployable networks"; 384 relocation would normally be planned. Networks with a high degree of 385 mobility are called "Mobile Networks" and planning activities would 386 be minimal. Deployed Mobile Networks have both ingredients. 388 Deployable and Mobile networks are being used by military forces, oil 389 and mineral recovery undertakings and large scale events. They can 390 also be added to Disaster-Ready municipal networks. 392 3.6. Disaster-Ready municipal network 394 Several Groups like MetroNet6 in the US and U-2010 in Europe are 395 considering solutions which would enable a quick restoration of 396 communications after a disaster. This kind of problem has many 397 facets, and MANEMO aims at solving implied the connectivity issues to 398 provide a Disaster-Ready municipal network or a fast deployable 399 mobile network. 401 A municipal Network is Disaster Ready if the networking operations 402 can be restored quickly during the normally chaotic phase that 403 follows a disaster (earthquake, flood, tsunami, volcano). Though a 404 large part of the municipal network might be utterly destroyed, the 405 goal is to leverage whatever infrastructure is left to restore 406 connectivity as soon as possible. 408 This requires a municipal network with self-forming, self-healing 409 characteristics. In addition, this requires the ability to support 410 the dynamic reintroduction of additional/replacement materials that 411 will recombine with the surviving infrastructure in an effort to 412 complete it and further bolster the available coverage. In other 413 words the municipal network must collaborate with the emergency 414 Mobile Routers, which will be automatically supported if the mesh 415 network technology is compatible with that of the Mobile Routers. 417 For the MANEMO protocol, this means that Mobile Routers (in trucks, 418 Personal Mobile Routers, etc...) can be deployed within the disaster 419 area and restore connectivity in the part(s) of the city mesh that 420 are still operational but isolated, and extend the connectivity in 421 the areas that are not covered. 423 3.7. Various Access Points Discovery (beyond 802.21) 425 IEEE 802.21 working group has been developing a mechanism to support 426 optimized handover and interoperability between heterogeneous 427 networks. The current set of 802.21 standards are not well designed 428 to support mobile wireless access networks, though the 802.21 Working 429 Group has not excluded supporting mobile access networks in the 430 future. 432 Once Mobile Routers are well deployed in vehicles, personal devices, 433 etc., it is expected that we will begin to see access networks that 434 are on the move. Within the current 802.21 standards, this moving 435 access network is not considered. The 802.21 Information Service 436 (IS) system cannot provide complete information of neighboring 437 networks to users, because the IS basically deals with static types 438 of information. Therefore, a user will obtain information of static 439 neighboring networks from IS and acquire information about possible 440 mobile access networks (Exit Routers) by using MANEMO. 442 The best access network for users might depend on more than layer 2 443 and location knowledge. For instance, a passenger in a vehicle (i.e. 444 bus/train) should stick to the access provided by that vehicle while 445 a stationary passenger located in the station should get access from 446 a fixed resource. Some of the required information to make the 447 proper decision is available from layer 3 and above, as well as from 448 the user himself. 450 MANEMO should define and utilize means for discovering and selecting 451 the best access network for users. 453 4. Requirements 455 MANEMO has the following requirements: 457 R1: The MANEMO protocol must enable the discovery of multihop 458 topologies at layer 3 from mere reachability and elaborate links 459 for IPv6 usage, regardless of the wired or wireless media. 461 R2: The MANEMO protocol must enable packets transmitted from Mobile 462 Routers visiting the MFS to reach the Internet via an optimized 463 path towards the nearest Exit Router, and back. 465 R3: MANEMO must enable IP connectivity within the nested NEMO 466 whether the infrastructure is reachable or not. 468 R4: The MANEMO protocol must enable packets transmitted from Mobile 469 Routers visiting the MFS to reach the Internet with a 470 topologically correct address. 472 R5: The MANEMO protocol should aim at minimizing radio interference 473 with itself as the control messages get propagated in the MFS. 475 R6: MANEMO protocol must enable inner movements within MFS to occur, 476 and ensure details of this movement are not propagated beyond the 477 MFS. 479 R7: An MFS may split to become two separate MFSs, in this case 480 MANEMO will continue to maintain local connectivity within the 481 separate MFSs and connectivity between the MFSs will be restored 482 once a NEMO connection becomes available. 484 R8: The MANEMO protocol should enable and optimize the trade-off 485 between ensuring some reciprocity between MFS peers and 486 maintaining a safe degree of CIA (see Paragraph 3 in the 487 terminology section (Section 2)) properties between the peer 488 Mobile Routers. 490 R9: The MANEMO protocol should enable that Mobile Routers be 491 deployed to restore connectivity in parts of an MFS went isolated, 492 or extend the connectivity in the areas that are not covered. 494 R10: The solution MUST not require modifications to any node other 495 than nodes that participates to the MFS. It must support fixed 496 nodes, mobile hosts and mobile routers in the NEMOs that form the 497 MFS, and ensure backward compatibility with other standards 498 defined by the IETF. 500 R11: The MANEMO protocol shall enable multicast communication, for 501 nodes within the MFS and on the Internet. Translation of MANEMO 502 multicast signaling and multicast signaling on the Internet shall 503 take place on the Exit Router. 505 R12: The MANEMO protocol shall optimize the path to the Internet 506 using cross-layer metrics. 508 5. Problem Statement 510 Radio connectivity and movement have disrupted the concept of a link 511 as we know it in the wired environment. Specific modes for specific 512 radios are proposed to restore that concept, which is essential for 513 IP operations, as single hop (802.11 infrastructure mode) or multihop 514 (802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified 515 solution to reconstruct a minimum topological abstraction at layer 3 516 for the use of NEMO. 518 The MANEMO problem is already observed in several Working Groups and 519 some are specified in [15][14]. 521 The MANEMO is possibly related to following on-going work in IETF 523 o Existing Routing Protocols (MANET, OSPF) 525 o Network Mobility Support (NEMO) 527 o Mobile Ad-hoc Network and Auto Configuration (AUTOCONF) 529 o Mobile Ad-hoc Sensor Network (6LOWPAN) 531 o Mobile Nodes and Multiple Interfaces in IPv6 (Monami6) 533 The main problems are "Network Loop", "Un-optimized Route", and 534 "Multiple Exit Routers" . 536 5.1. Network Loop 538 A network loop can occur when multiple mobile routers are nested and 539 suddenly the Exit Router (root-MR, i.e. MR1) looses connectivity to 540 the Internet and connects to the mobile network of lower MR (i.e. 541 MR2 in the figure) 543 In this case, the loop is observed between MRs. Each mobile network 544 is designed to have movement transparency by NEMO Basic Support 545 Protocol. Any node connecting to a mobile network cannot know 546 whether the access network is a mobile network or not. Moreover, it 547 is impossible to know whether a connecting mobile router has managed 548 Internet connectivity or not. The mobile router may loose Internet 549 Connectivity, temporarily. 551 Knowing the topology of MFS is highly important to prevent this 552 network loop issue. 554 +---+ +---+ 555 |AR | |AR | 556 +-+-+ +---+ 557 | 558 | 559 +-+-+ +---+ 560 |MR1| --> |MR1+--+ 561 +-+-+ +-+-+ | 562 | | | 563 | | | 564 +-+-+ +-+-+ | 565 |MR2| |MR2|--+ 566 +---+ +---+ 568 Figure 1: Network Loop 570 5.2. Un-optimized Route 572 This is well known issue of Nested NEMO. The problem is described in 573 Section 2.3 of [13]. The NEMO Working Group suggests not to prevent 574 support for nested NEMO. [6]. Figure 2 shows a typical example of 575 nested NEMO. Even if the destination is in the same MFS, the packets 576 are always traveled through multiple home agents. There are several 577 proposal in the NEMO Working Group. 579 +---+ +---+ +---+ +---+ 580 |HA1| |HA2| |HA3| |HA4| 581 +-+-+ +-+-+ +-+-+ +-+-+ 582 | | | | 583 | | | | 584 +. . . . . . . . . . . . .+ 585 : : 586 : The Internet : 587 : : 588 +. . . . . . . . . . . . .+ 589 | 590 +-+-+ The Path From MR1 to MR4 591 | AR| [MR1->AR->HA1->HA4->HA2->HA1->AR-> 592 +-+-+ MR1->MR2->MR4] 593 | 594 +-+-+ The Path From MR3 to MR4 595 |MR1| [MR3->MR2->MR1->AR->HA1->HA2->HA3-> 596 +-+-+ HA4->HA2->HA1->AR->MR1->MR2->MR4] 597 | 598 +---+ +-+-+ +---+ 599 |MR3|----+MR2+----+MR4| 600 +---+ +---+ +---+ 602 Figure 2: Nested NEMO 604 Figure 3 shows the another example of un-optimized path. This 605 redundant path is also occurred in no nested NEMO scenario. In this 606 example, two mobile routers are not directly connected. Most of the 607 nested solution proposed in NEMO working group cannot solve this 608 case. MANEMO solution should be able to solve this case, too. 610 +---+ +---+ +---+ +---+ 611 |HA1| |HA2| |HA1| |HA2| 612 +-+-+ ++--+ +-+-+ ++--+ 613 | | | | 614 | | | | 615 +.+. . . . . . . . ..+.+ +.+. . . . . . . ..+.+ 616 . . . . 617 . The Internet . . The Internet . 618 . . . . 619 +. . . . . . . . . . . + +. . . . .+. . . .. . + 620 | | 621 +-+-+ +----R-----+ 622 +---+ AR+---+ | | 623 | +-+-+ | +-+-+ +-+-+ 624 | | +---+AR1| |AR2+---+ 625 | | | +---+ +---+ | 626 +-+-+ +-+-+ +-+-+ +-+-+ 627 |MR1| |MR2| |MR1| |MR2| 628 +-+-+ +-+-+ +-+-+ +-+-+ 630 MR1->AR->HA1->HA2->AR->MR2 MR1->AR1->R->HA1->HA2->R->AR2->MR2 632 Figure 3: Unoptimized Route 634 5.3. Multiple Exit Routers 636 This problem occurs when a mobile node obtains multiple Exit Routers 637 toward the Internet. In the illustrated case, the mobile node should 638 attempt to obtain some information about each Exit Router in order to 639 more efficiently utilize them. MANEMO may carry this information 640 about each Exit Router and present it to the connected mobile node. 642 . . . . . . . . . . . .. 643 . . 644 . The Internet . 645 . . 646 .. . . . . . . . . . . . 647 | | 648 | | 649 +-+-+ +-+-+ 650 |AR1| |AR2+--+ 651 +-+-+ +-+-+ | 652 | +---+ | | 653 +-----|MR1|----+ | 654 +-+-+ | 655 | +-+-+ 656 +--------+MR2| 657 +---+ 659 Figure 4: Multiple Exit Routers 661 6. Approach Rationale 663 MANEMO aims at extending IPv6 Neighbor Discovery [7] to form and 664 maintain an optimized nested NEMO. This section covers the rationale 665 behind this approach. 667 6.1. Layer 2 (mesh, spanning tree) based approach 669 Arguably, an existing layer 2 technology such as a spanning tree of 670 802.11s could be used to establish a tree towards the nearest Exit 671 Router. This falls short when the nodes are mobile routers for a 672 number of reasons: 674 In a L2 based solution, the MRs would end up bridging for the 675 nested routers while routing for their own (attached) Mobile 676 Network Prefixes. 678 A L3 based solution could span over multiple radio types, such as: 679 802.16 or 11a for backhaul, 802.11a or 11b/g for edge and 802.11 680 b/g or 802.15.4 for access. It also could span wired links. 682 In an L3 solution, you control the broadcast domain and limit the 683 multicast troubles without snooping. In particular, you segment 684 the ND broadcast operations. 686 NEMO operation is better if the MANEMO operation is done in ND at 687 L3, because NEMO already interfaces with ND. A L2 solution would 688 require NEMO to understand L2/2.5 protocols such as like 802.11s 689 or 802.21. 691 There can be value in integration between the NEMO and the MANET 692 aspects of the mobility problem. For instance, if the Reverse 693 Routing Header technique [16] is used to solve the pinball routing 694 problem, then the RRH can be compressed dynamically if routes down 695 the tree (or the DAG) are installed by the MANEMO protocol in the 696 intermediate routers. 698 And then you get all the IP value that is not necessarily there or 699 homogeneous at L2, like QoS, SNMP, RSVP, aggregation, etc... 701 6.2. 802.21 based approach 703 In some scenarios, the information service approach may be taken. 704 For example, trains are run on a regular schedule and a system can 705 preempt the movement of mobile routers on each train. In such a 706 case, the operator can dynamically update the information of routers 707 in a train to the information service (IS). The mobile node can 708 retrieve information about the neighboring access networks from IS in 709 some scenarios. Unless the IS supports dynamic updates of access 710 routers and provides certain topology of mobile access routers, it is 711 difficult to solve all the problems of MANEMO. For instance, it does 712 not enable us to structure the nested NEMO in an optimal fashion for 713 reaching the infrastructure. 715 6.3. MANET based approach 717 The Mobile Ad-hoc Network Architecture [17] provides an overview of 718 the MANET problem and scope. 720 MANEMO is about designing a specific MANET that is tailored for the 721 needs of nested NEMO, with a strong focus on finding the way to the 722 outside infrastructure when it is reachable. In that sense, MANEMO 723 specializes on a specific area of MANET by adding a set of 724 constraints that narrow the problem down. 726 Arguably, an existing MANET protocol could be used to enable routing 727 between the Mobile Router within a nested NEMO. But existing MANET 728 are not optimized for the following requirements: 730 Default Route: Because it is used by Mobile Routers to find a way 731 out and bind to their Home Agent, the MANEMO protocol focuses on 732 building, maintaining and optimizing a default path to the exit of 733 the nested NEMO. With MANET, the default route is usually an 734 addition, and in any case it is just another route, not the focus 735 of the protocol. 737 Prefix Routing: Subnet (prefix) routing is a secondary concern for 738 the MANEMO protocol. Such routes are considered when conditions 739 permit, but might be maintained in a Least Overhead Routing 740 Approach (LORA) as opposed to an Optimized Routing Approach (ORA) 741 which is used for the Default Route. Host Routes are not of 742 concern since MANEMO deals with Mobile Routers. Note that DYMO 743 and OLSR are capable of the prefix routing. 745 Group Management: When forming a nested NEMO, the Mobile Routers 746 need a selection of information that is not present in traditional 747 MANET approaches. Notions such as group, depth, free bandwidth 748 towards the exit, etc... impact the formation of the nested NEMO 749 and the way it optimizes itself overtime. 751 On the other hand, existing MANET protocols could be integrated or 752 adapted for the following cases: 754 On-demand Routing: When a node needs to discover Exit Routers, on- 755 demand fashion may reduce the overhead of discovery procedure. 756 Some MANET routing protocols such as AODV and DYMO has the on- 757 demand mechanism to discover a route towards the destination. 759 Neighborhood Routing: Because the MANEMO protocol provides only a 760 minimized view of the local network, it might be missing a short 761 path to a neighborhood destination over an alternate radio link. 762 A collaboration with a MANET protocol would improve short-distance 763 routing. As an example, internal connectivity between NEMOs 764 within the local network may improve by Mobile Routers running a 765 MANEMO routing protocol and discovering more optimal routes to the 766 MNPs reachable within the local network. Mechanisms specific to 767 MANEMO should also be developed to ensure this optimisation is 768 safe. 770 Global Reachability for a MANET In the MANET working group, an 771 Internet Gateway is introduced to provide Internet connectivity to 772 MANET. In this case, the gateway of a MANET network is also a 773 NEMO Mobile Router. Using NEMO, The gateway registers the MANET 774 prefix(es) to a Home Agent, enabling the MANET network to move as 775 a whole. The Mobile Router can also act as a Mobile Home for the 776 whole MANET, providing Home Agent services such as mobility and 777 prefix delegation. In particular, the Mobile Home can maintain 778 connectivity with Mobile IP6/NEMO enabled MANET Nodes that would 779 stray away from the mobile MANET. 781 For these reasons, MANET could contribute in optimizing a deployment, 782 but a specific protocol has to be engineered to match the MANEMO 783 requirements. 785 6.4. Neighbor Discovery based approach 787 Neighbor Discovery (ND) [7] provides the means to discover neighbors 788 and the prefix on a link, which are pervasive across IPv6 nodes and 789 link types. Mobile IPv6 [8] and NEMO [1] rely heavily on ND for 790 roaming and Home Link activities. Considering that NEMO already uses 791 ND for Router Discovery, it makes sense to extend ND in MANEMO as 792 opposed to providing a second peering mechanism. 794 ND has already been extended to expose some layer 3 information, such 795 as router selection hints [9]. ND is consistently being improved for 796 mobility, in particular with Mobile IPv6 [8] and DNA, and for 797 security with Secure ND [10]. ND operates on bidirectional links, 798 whereas this is a restriction from the MANET standpoint, this 799 condition enables simpler solutions for MANEMO. 801 Neighbor Discovery is well suited for providing hints for composing a 802 path to the Internet access router. The hits could include Layer 2 803 information as well as application layer information, needed for 804 providing optimal and stable paths to Exit Routers. The Exit Routes 805 connect the MANEMO Fringe Stub to the Internet. Path maintaining 806 towards an Exit Router is suggested in a nested NEMO tree discovery 807 protocol [18]. 809 Multicast support could be provided by using the loop-free MANEMO 810 Tree to forward packets to the Internet. Down-tree forwarding would 811 use MLD-proxy[19], either with native MLD [11][12] / ICMP packets or 812 send with the ND extensions to increase efficiency. Multicast 813 forwarding rules should be validated, mechanisms like RPF-check and 814 duplicate packet detection [20] would be used to eliminate multicast 815 looped packets. Forwarding rules on the Exit Router is to be worked 816 out. 818 The MANEMO work will thus focus on an ND based solution that is 819 required to provide multihop reachability while supporting inner 820 movements in the nested NEMO. 822 6.4.1. MANEMO ND and other MANET protocols 824 The MANEMO ND provided information can be used by other MANET 825 protocols. Other MANET protocols could be used for optimize local 826 connectivity or used for other reasons. 828 MANEMO ND may provide IP link and address topology vectors to the 829 nodes next hop neighbors. Then that topology information at each 830 next hop neighbor would be propagated to an OLSRv2 [21] / NHDP [22] 831 symmetric 2-hop neighborhood and Multipoint Relay, or OSPF-MANET [23] 832 / [24] MANET Designated Router (most likely Parent and Routable 833 characteristics) who then can flood that topology to other Multipoint 834 Relays or MANET Designated Routers down to other neighbors. This 835 also could be accomplished using NEMO/MANEMO Access Routers to the 836 NEMO Clusterhead using the proposed tree discovery protocol [18]. 837 The diameter of the topology would span a single ad hoc link. This 838 would provide an IP layer 3 solution and the topology information 839 could be placed in new ND options. 841 6.4.2. MANEMO ND and AUTOCONF 843 The use of ND for IP link and address topology could also foster a 844 discussion with IETF AUTOCONF Working Group to analyze if ND could be 845 used as defined above to support ND stateless autoconfiguration. The 846 design center for such a solution would be to place this ND link and 847 IP topology enhancement below current MANET routing protocols and 848 could reduce latency for ad hoc links whether within a MESH or Radio 849 Network link. ND extensions could assist greatly below MANET routing 850 protocols to discover neighbors, verify two way communications, 851 exchange link state information, and provide update information 852 between neighbors and ingress/egress point to MANET Mobile Routers. 853 These extensions could also be applied as enhancements to the tree 854 discovery protocol that would support MANEMO, thus adding these 855 extensions to tree discovery protocol is a suggestion or it could be 856 its own specification. 858 7. Related Information 860 Related Documents can be found in the Informative Reference section 862 Solutions are already proposed at IETF such as [16] and [18]. The 863 NEMO Working Group has the analysis document [25] for the nested NEMO 864 issue. 866 8. IANA considerations 868 This document does not require any IANA action. 870 9. Security Considerations 872 This document is a problem statement and does not create any security 873 threat. It discusses the concepts of Capability, Innocuousness and 874 Anonymity in a nested NEMO. 876 10. Acknowledgments 878 We would like to thank all the people who have provided comments on 879 this draft, and also co-authors of earlier documents in which authors 880 of this present document have been engaged. As such, we would like 881 to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham 882 Soliman, Carlos Jesus Bernardos Cano and many others. 884 11. References 886 11.1. Normative reference 888 [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 889 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 890 January 2005. 892 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 893 Levels", BCP 14, RFC 2119, March 1997. 895 [3] Manner, J. and M. Kojo, "Mobility Related Terminology", 896 RFC 3753, June 2004. 898 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 899 draft-ietf-nemo-terminology-06 (work in progress), 900 November 2006. 902 [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 903 Specification", RFC 2460, December 1998. 905 [6] Ernst, T., "Network Mobility Support Goals and Requirements", 906 draft-ietf-nemo-requirements-06 (work in progress), 907 November 2006. 909 [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 910 for IP Version 6 (IPv6)", RFC 2461, December 1998. 912 [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 913 IPv6", RFC 3775, June 2004. 915 [9] Draves, R. and D. Thaler, "Default Router Preferences and More- 916 Specific Routes", RFC 4191, November 2005. 918 [10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 919 Neighbor Discovery (SEND)", RFC 3971, March 2005. 921 [11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 922 Discovery (MLD) for IPv6", RFC 2710, October 1999. 924 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 925 (MLDv2) for IPv6", RFC 3810, June 2004. 927 11.2. Informative Reference 929 [13] Ng, C., "Network Mobility Route Optimization Problem 930 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 931 progress), September 2006. 933 [14] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route 934 Optimisation Problem Statement", 935 draft-clausen-nemo-ro-problem-statement-00 (work in progress), 936 October 2004. 938 [15] Ng, C., "Analysis of Multihoming in Network Mobility Support", 939 draft-ietf-nemo-multihoming-issues-06 (work in progress), 940 June 2006. 942 [16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 943 its application to Mobile Networks", 944 draft-thubert-nemo-reverse-routing-header-06 (work in 945 progress), September 2006. 947 [17] Chakeres, I., "Mobile Ad hoc Network Architecture", 948 draft-chakeres-manet-arch-01 (work in progress), October 2006. 950 [18] Thubert, P., "Nested Nemo Tree Discovery", 951 draft-thubert-tree-discovery-04 (work in progress), 952 November 2006. 954 [19] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD- 955 Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in 956 progress), April 2004. 958 [20] Macker, J., "Simplified Multicast Forwarding for MANET", 959 draft-ietf-manet-smf-03 (work in progress), October 2006. 961 [21] Clausen, T., "The Optimized Link-State Routing Protocol version 962 2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006. 964 [22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", 965 draft-ietf-manet-nhdp-00 (work in progress), June 2006. 967 [23] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS 968 Flooding", draft-ogier-manet-ospf-extension-08 (work in 969 progress), October 2006. 971 [24] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile 972 Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in 973 progress), January 2007. 975 [25] Ng, C., "Network Mobility Route Optimization Solution Space 976 Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in 977 progress), September 2006. 979 Appendix A. Change Log From Previous Version 981 o Initial Documentation 983 Authors' Addresses 985 Ryuji Wakikawa 986 Keio University and WIDE 987 5322 Endo Fujisawa Kanagawa 988 252-8520 989 JAPAN 991 Email: ryuji@sfc.wide.ad.jp 993 Pascal Thubert 994 Cisco Systems 995 Village d'Entreprises Green Side 996 400, Avenue de Roumanille 997 Batiment T3 998 Biot - Sophia Antipolis 06410 999 FRANCE 1001 Phone: +33 4 97 23 26 34 1002 Email: pthubert@cisco.com 1004 Teco Boot 1005 Infinity Networks B.V. 1006 Elperstraat 4 1007 Schoonloo 9443TL 1008 Netherlands 1010 Phone: +31 592 50 12 66 1011 Email: teco@inf-net.nl 1013 Jim Bound 1014 Hewlett-Packard 1015 PO BOX 570 1016 Hollis, NH 03049 1017 USA 1019 Phone: +603 465 3130 1020 Email: jim.bound@hp.com 1021 McCarthy Ben 1022 Lancaster University 1023 Computing Department, Lancaster University. 1024 InfoLab 21, South Drive 1025 Lancaster, Lancashire LA1 4WA 1026 UK 1028 Phone: +44-1524-510-383 1029 Fax: +44-1524-510-492 1030 Email: b.mccarthy@lancaster.ac.uk 1031 URI: http://www.network-mobility.org/ 1033 Full Copyright Statement 1035 Copyright (C) The IETF Trust (2007). 1037 This document is subject to the rights, licenses and restrictions 1038 contained in BCP 78, and except as set forth therein, the authors 1039 retain all their rights. 1041 This document and the information contained herein are provided on an 1042 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1043 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1044 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1045 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1046 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1047 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1049 Intellectual Property 1051 The IETF takes no position regarding the validity or scope of any 1052 Intellectual Property Rights or other rights that might be claimed to 1053 pertain to the implementation or use of the technology described in 1054 this document or the extent to which any license under such rights 1055 might or might not be available; nor does it represent that it has 1056 made any independent effort to identify any such rights. Information 1057 on the procedures with respect to rights in RFC documents can be 1058 found in BCP 78 and BCP 79. 1060 Copies of IPR disclosures made to the IETF Secretariat and any 1061 assurances of licenses to be made available, or the result of an 1062 attempt made to obtain a general license or permission for the use of 1063 such proprietary rights by implementers or users of this 1064 specification can be obtained from the IETF on-line IPR repository at 1065 http://www.ietf.org/ipr. 1067 The IETF invites any interested party to bring to its attention any 1068 copyrights, patents or patent applications, or other proprietary 1069 rights that may cover technology that may be required to implement 1070 this standard. Please address the information to the IETF at 1071 ietf-ipr@ietf.org. 1073 Acknowledgment 1075 Funding for the RFC Editor function is provided by the IETF 1076 Administrative Support Activity (IASA).