No Working Group R. Wakikawa Internet-Draft Keio University Expires: August 9, 2007 P. Thubert Cisco T. Boot Infinity Networks J. Bound HP B. McCarthy Lancaster University February 5, 2007 MANEMO Problem Statement draft-wakikawa-manemo-problem-statement-00 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 August 9, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Wakikawa, et al. Expires August 9, 2007 [Page 1] Internet-Draft MANEMO Problem Statement February 2007 Abstract This document outlines the fundamental problems and approach rationale of MANEMO. When mobile nodes converge at the edge of the Internet using wireless interfaces, they can form a network in an ad- hoc fashion and are able to provide Internet connectivity to one another. This type of network is called a MANEMO Fringe Stub (MFS). Several issues exist in the MFS such as network loop, un-optimized path and multiple exit routers to the Internet. While fixed routers provide connectivity constantly, mobile routers can experience intermittent connectivity to the Internet due to their movement. When NEMO Basic Support is used in this context, network loops naturally occur. NEMO forces the packets to always travel through the home agent, which in turn causes an un-optimized path that can become a considerable problem when mobile routers form a nested topology. Multicast support introduces emphasized inefficiency. Different types of routers are able to provide Internet connectivity in the MFS, including both mobile routers and fixed access routers. Any node requiring Internet connectivity has to select the best exit router toward the Internet, therefore it is necessary for mobile nodes to maintain a local topology in the MFS and to utilise any available connectivity with a degree of Intelligence. Wakikawa, et al. Expires August 9, 2007 [Page 2] Internet-Draft MANEMO Problem Statement February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Layer 3 Mesh Network . . . . . . . . . . . . . . . . . . . 9 3.2. Layer 3 Sensor Network . . . . . . . . . . . . . . . . . . 9 3.3. Fleet at sea . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Crowd of Personal Mobile Router . . . . . . . . . . . . . 10 3.5. Deployable and Mobile networks . . . . . . . . . . . . . . 11 3.6. Disaster-Ready municipal network . . . . . . . . . . . . . 11 3.7. Various Access Points Discovery (beyond 802.21) . . . . . 12 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Network Loop . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Un-optimized Route . . . . . . . . . . . . . . . . . . . . 16 5.3. Multiple Exit Routers . . . . . . . . . . . . . . . . . . 18 6. Approach Rationale . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Layer 2 (mesh, spanning tree) based approach . . . . . . . 20 6.2. 802.21 based approach . . . . . . . . . . . . . . . . . . 20 6.3. MANET based approach . . . . . . . . . . . . . . . . . . . 21 6.4. Neighbor Discovery based approach . . . . . . . . . . . . 22 6.4.1. MANEMO ND and other MANET protocols . . . . . . . . . 23 6.4.2. MANEMO ND and AUTOCONF . . . . . . . . . . . . . . . . 23 7. Related Information . . . . . . . . . . . . . . . . . . . . . 25 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative reference . . . . . . . . . . . . . . . . . . . 28 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 29 Appendix A. Change Log From Previous Version . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Wakikawa, et al. Expires August 9, 2007 [Page 3] Internet-Draft MANEMO Problem Statement February 2007 1. Introduction With routers and access points now being priced as a commodity, a cloud of nodes connected by wireless technology is being created at the edge of the Internet. This cloud is called a MANEMO Fringe Stub (MFS) in this document. The definition of all the terms used in this document can be found in Section 2. Examples of these wireless technologies used within a MFS are wireless metropolitan and local area network protocols (WiMAX, WLAN, 802.20, etc), short distance wireless technology (bluetooth, irDA, UWB), and radio mesh networks (ex. 802.11s). As the MFS extends to the consumer market and into the homes, it's ease of use should become comparable to that of existing electrical appliances and extension cords, i.e. highly user friendly with little or no user interaction required. As a result, networking in the MFS will be highly unmanaged and ad-hoc, but at the same time will need to offer excellent service availability. In particular, NEMO basic support [1] could be used to provide global reachability for a mobile access network within the MFS. However, when Mobile Nodes attach randomly to one another in this model (to form what is termed a nested NEMO) the overall structure can become highly suboptimal and loops can also possibly occur. Therefore, there is a need for additional information to be made available to Mobile Nodes to help them select an interface and an attachment router over that interface in order to reach the Internet (possibly indirectly) in a fashion avoiding network loops. The aim of MANEMO is to enable this to happen in the MFS through the design of a specific MANET, tailored for the needs of nested NEMO that can form an optimized acyclic graph directed to the to the outside infrastructure and the Internet when it is reachable. MANEMO enables a Mobile Router to install one or more default route(s) towards the Internet and be globally reachable using NEMO. MANEMO may also be required to install backward routes towards prefixes owned by a Mobile Router in each of the intermediate routers from the selected Exit Router down to that Mobile Router. Finally, Internet connectivity in mobile scenarios can be costly, limited or unavailable, therefore there is a need to enable local routing between the Mobile Routers within a portion of the MFS. This form of local routing is useful for route optimization between Mobile Routers that are communicating directly in a portion of the MFS. This type of local communication is especially an efficiency improvement for multicast, as MANEMO multicast traffic could be distributed in the MFS without the overhead of nested tunnels and Wakikawa, et al. Expires August 9, 2007 [Page 4] Internet-Draft MANEMO Problem Statement February 2007 pseudo-broadcasting. Wakikawa, et al. Expires August 9, 2007 [Page 5] Internet-Draft MANEMO Problem Statement February 2007 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] Readers are expected to be familiar with all the terms defined in the RFC3753 [3] and the NEMO Terminology draft [4] Directed Graph A graph whose edges are ordered pairs of vertices. That is, each edge can be followed from one vertex to another vertex. Directed Acyclic Graph (DAG) Directed graph with no path that starts and ends at the same vertex - in other words, loopless. Capability, Innocuousness and Anonymity (CIA) Concepts which might replace the traditional AAA model in some circumstances in the MFS: Capability: Capability explores whether an Attachment Router can actually provide the requested services (reach back to Home, bandwidth...) Innocuousness: Innocuousness guarantees that giving a service to a peer (forwarding) or using a service from a peer (attaching) is harmless to itself. Anonymity: Anonymity ensures that peers are unable to identify one another. This concept might contradict that of rating peers which can be useful for peer to peer policing (tit for tat). Exit Router The Exit Router is a router which provides Internet connectivity and acts as a layer-3 sink for the MFS. The Exit Router can be a fixed Access Router supporting MANEMO or a mobile router (root-MR) connected directly to the Internet. Multiple Exit Routers may be available in an MFS. Exit Route An Exit Route is a next hop on a Mobile Router towards an Exit Router Local Communication Local Communication is communication between nodes in the same MFS without going through the Internet. Wakikawa, et al. Expires August 9, 2007 [Page 6] Internet-Draft MANEMO Problem Statement February 2007 Local Routing Local Routing is a routing scheme inside a MFS. MANEMO is used for arranging a tree structure towards the Internet. In addition, other MANET protocols can be used to optimise Local Communication. MANEMO MANET for NEMO. MANEMO provides the necessary additions to existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to find the most suited exit towards the infrastructure. MANEMO enables some internal connectivity within the nested NEMO whether the infrastructure is reachable or not. MANEMO is not MANET + NEMO. MANET + NEMO could suggest a MANET protocol reuse whereas MANET for NEMO suggests the development of a new protocol. MANEMO Fringe Stub (MFS) The MANEMO Fringe Stub is a cloud of Mobile Routers connected by wireless or wired links. Any type of link supporting IPv6 connectivity can be used, including partly meshed wireless topologies. An MFS is a stub at the edge of the Internet, interconnecting various types of devices which discover each other and form a network in an ad-hoc fashion to provide Internet connectivity to one another. Many disjunctive MFS can be connected to the Internet. An MFS can also be floating, which means the cloud is not connected to the Internet. MANEMO Link A MANEMO Link is a MANEMO enabled Mobile Router interface and the data link layer transmission medium connected to it. Via the link, other nodes can be reached, called the 1st hop neighbors. MANEMO Path A MANEMO Path is a network path between a Mobile Router and the root of the MANEMO Tree, the Exit Router. For Local Communication, an up-tree and down-tree path provides connectivity within a MANEMO tree. MANEMO Tree A MANEMO Tree is the simplest network topology connecting Mobile Routers within a MFS to a single Exit Router. The Exit Router is the root of the MANEMO Tree. In case of a floating MFS, a Mobile Router shall be elected as root of the MANEMO Tree. Wireless Node A Wireless Node is a node that has a wireless link to access the Internet. Example Wireless Nodes are a Mobile Node (Mobile Host or Mobile Router) and a normal IPv6 node [5] with a wireless link. Nested NEMO The Nested NEMO is a network configuration where one or more mobile routers are connected in nested formation. The detailed issues can be found in [13] and [14]. Wakikawa, et al. Expires August 9, 2007 [Page 7] Internet-Draft MANEMO Problem Statement February 2007 Self Optimizing A Self-Optimizing network is a self-forming, self- healing network that adapts its topology dynamically in order to optimize some metrics. Wakikawa, et al. Expires August 9, 2007 [Page 8] Internet-Draft MANEMO Problem Statement February 2007 3. Use cases 3.1. Layer 3 Mesh Network A layer 3 mesh network is a specific case of nested NEMO with very, very slow inner movements of Mobile Routers relative to one another. Change of attachment will be triggered by node additions and interference, rather than actual displacement. The mesh network is self-forming and self-healing. It forms a tree that is rooted at the nearest Exit Router (wire access). The tree will self-heal should a node fail, a radio link become unavailable (for a temporary interference), or a node or a wire access be added to the network. In order to deploy a mesh network easily, the inner addressing should be independent of the wire accesses. The MANEMO protocol should enable packets transmitted from Mobile Routers visiting the mesh to enter the Internet via an Exit Router with a topologically correct address even though the inner mesh addresses may be only unique local addresses. 3.2. Layer 3 Sensor Network A Sensor Network is an extreme form of a MANET in terms of the amount of devices and of their highly limited capabilities. Sensors can be low cost, mass produced devices operating for years on a pair of AAA batteries. A sensor dust can be spread over a monitored location, and from that moment on, the sensors are fixed and operate for the lifetime of their batteries, which are their most critical resource. Around a Sensor Network, sinks are deployed in order to collect the measurements from the sensors and relay the commands from the controllers. Thus, sensors automatically form a structure to forward unicast packets from the sensors to the sinks, and to propagate broadcast packets across the network from the sinks. The sensors act as a community, relaying packets for one another; but the model reaches its limits due in one hand to the operational cost on the batteries for listening to asynchronous packets from other sensors and for forwarding, and in the other hand to the complexity involved in forming an ad-hoc network over a large area. In order to establish a routing infrastructure and scale to a large geography, Mobile Routers can be deployed to form a mesh and act as default gateways to backhaul and aggregate the sensor data. In that case, most sensors could be either plain IPv6 hosts or at least be optimized to relay over a limited area towards the nearest Mobile Wakikawa, et al. Expires August 9, 2007 [Page 9] Internet-Draft MANEMO Problem Statement February 2007 Router. The Mobile Routers themselves might be actually fixed and well- distributed across the monitored location, with a few of them equipped with a backhaul capability to the Infrastructure. They could also be in fact mobile and appear, move and disappear, for instance as a drone passes over the sensor field to sweep a perimeter. The MANEMO protocol must ensure that the Exit Route(s) is found and maintained as quickly as possible. Finally, a possible flow in sensor networking is the polling of the sensors by an application. The application request is multicast to all sensors, and the sensors reply in a synchronized fashion. In that flow, the command might interfere with itself as it is repeated over the radios. Also, the sensor responses might interfere with one another. The MANEMO protocol should aim at minimizing interference with itself and could provide extensions to transport and aggregate sensor data. 3.3. Fleet at sea In the case of a fleet at sea, the MFS is moving together, with maybe temporary splits and merges. Also, when the fleet is at sea, the communications to the outside can be costly. In this use case, some ships may have well defined roles (like admiral ship, communications ships etc...) and therefore some additional engineering maybe required when considering the routing. For example, it may be desirable that certain specific ships be identified as preferred Exit Routers (root-MR) for the MANEMO. As opposed to the mesh networking and sensor networking cases, the fleet at sea involves inner movements within the fleet as demanded by the missions. As a result, some part of the fleet might split from the rest but still maintain local connectivity using MANEMO, as well as connectivity with the rest of the fleet using NEMO. In particular, it is possible that the comms ship may act as a Mobile Home for the fleet aggregation. 3.4. Crowd of Personal Mobile Router Another use case is a crowd of personal Mobile Routers. In this use case, people do not know each other but need to forward each others packets to the nearest Exit Router in order for the whole system to operate for everyone. Also, in this situation people may move quite rapidly relative to one another therefore the density of the crowd may be of significance. Wakikawa, et al. Expires August 9, 2007 [Page 10] Internet-Draft MANEMO Problem Statement February 2007 In this sort of unmanaged environment we cannot rely on a traditional (AAA, trust based) mechanism. Instead, the MANEMO protocol must enable MRs to obtain the required Capabilities in an Innocuous fashion. MANEMO has to enable and optimize the trade-off between ensuring some reciprocity (TIT for TAT) and maintaining a safe degree of Anonymity between the peer Mobile Routers. 3.5. Deployable and Mobile networks A task-group could perform activities in a planned matter in an area that lacks a capable data communication infrastructure. In such a case, the infrastructure would be embedded in the task-group itself. The used infrastructure would be heterogeneous; using whatever wireless or wired technology that is allowed, applicable, affordable and available. During their task, elements such as ships, vehicles, airborne elements and temporally used buildings, tents or other setups mostly have fixed locations, but elements can relocate in a planned or unplanned manner. During relocation, the data communication facilities can be shut down or kept active. Shut down data communication facilities would be classified as "on the hold" or "on the pause". Data communication facilities that are active during relocation are classified as "on the move". Networks with a high degree of stationary elements are called "Deployable networks"; relocation would normally be planned. Networks with a high degree of mobility are called "Mobile Networks" and planning activities would be minimal. Deployed Mobile Networks have both ingredients. Deployable and Mobile networks are being used by military forces, oil and mineral recovery undertakings and large scale events. They can also be added to Disaster-Ready municipal networks. 3.6. Disaster-Ready municipal network Several Groups like MetroNet6 in the US and U-2010 in Europe are considering solutions which would enable a quick restoration of communications after a disaster. This kind of problem has many facets, and MANEMO aims at solving implied the connectivity issues to provide a Disaster-Ready municipal network or a fast deployable mobile network. A municipal Network is Disaster Ready if the networking operations can be restored quickly during the normally chaotic phase that follows a disaster (earthquake, flood, tsunami, volcano). Though a large part of the municipal network might be utterly destroyed, the goal is to leverage whatever infrastructure is left to restore connectivity as soon as possible. Wakikawa, et al. Expires August 9, 2007 [Page 11] Internet-Draft MANEMO Problem Statement February 2007 This requires a municipal network with self-forming, self-healing characteristics. In addition, this requires the ability to support the dynamic reintroduction of additional/replacement materials that will recombine with the surviving infrastructure in an effort to complete it and further bolster the available coverage. In other words the municipal network must collaborate with the emergency Mobile Routers, which will be automatically supported if the mesh network technology is compatible with that of the Mobile Routers. For the MANEMO protocol, this means that Mobile Routers (in trucks, Personal Mobile Routers, etc...) can be deployed within the disaster area and restore connectivity in the part(s) of the city mesh that are still operational but isolated, and extend the connectivity in the areas that are not covered. 3.7. Various Access Points Discovery (beyond 802.21) IEEE 802.21 working group has been developing a mechanism to support optimized handover and interoperability between heterogeneous networks. The current set of 802.21 standards are not well designed to support mobile wireless access networks, though the 802.21 Working Group has not excluded supporting mobile access networks in the future. Once Mobile Routers are well deployed in vehicles, personal devices, etc., it is expected that we will begin to see access networks that are on the move. Within the current 802.21 standards, this moving access network is not considered. The 802.21 Information Service (IS) system cannot provide complete information of neighboring networks to users, because the IS basically deals with static types of information. Therefore, a user will obtain information of static neighboring networks from IS and acquire information about possible mobile access networks (Exit Routers) by using MANEMO. The best access network for users might depend on more than layer 2 and location knowledge. For instance, a passenger in a vehicle (i.e. bus/train) should stick to the access provided by that vehicle while a stationary passenger located in the station should get access from a fixed resource. Some of the required information to make the proper decision is available from layer 3 and above, as well as from the user himself. MANEMO should define and utilize means for discovering and selecting the best access network for users. Wakikawa, et al. Expires August 9, 2007 [Page 12] Internet-Draft MANEMO Problem Statement February 2007 4. Requirements MANEMO has the following requirements: R1: The MANEMO protocol must enable the discovery of multihop topologies at layer 3 from mere reachability and elaborate links for IPv6 usage, regardless of the wired or wireless media. R2: The MANEMO protocol must enable packets transmitted from Mobile Routers visiting the MFS to reach the Internet via an optimized path towards the nearest Exit Router, and back. R3: MANEMO must enable IP connectivity within the nested NEMO whether the infrastructure is reachable or not. R4: The MANEMO protocol must enable packets transmitted from Mobile Routers visiting the MFS to reach the Internet with a topologically correct address. R5: The MANEMO protocol should aim at minimizing radio interference with itself as the control messages get propagated in the MFS. R6: MANEMO protocol must enable inner movements within MFS to occur, and ensure details of this movement are not propagated beyond the MFS. R7: An MFS may split to become two separate MFSs, in this case MANEMO will continue to maintain local connectivity within the separate MFSs and connectivity between the MFSs will be restored once a NEMO connection becomes available. R8: The MANEMO protocol should enable and optimize the trade-off between ensuring some reciprocity between MFS peers and maintaining a safe degree of CIA (see Paragraph 3 in the terminology section (Section 2)) properties between the peer Mobile Routers. R9: The MANEMO protocol should enable that Mobile Routers be deployed to restore connectivity in parts of an MFS went isolated, or extend the connectivity in the areas that are not covered. 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. Wakikawa, et al. Expires August 9, 2007 [Page 13] Internet-Draft MANEMO Problem Statement February 2007 R11: The MANEMO protocol shall enable multicast communication, for nodes within the MFS and on the Internet. Translation of MANEMO multicast signaling and multicast signaling on the Internet shall take place on the Exit Router. R12: The MANEMO protocol shall optimize the path to the Internet using cross-layer metrics. Wakikawa, et al. Expires August 9, 2007 [Page 14] Internet-Draft MANEMO Problem Statement February 2007 5. Problem Statement Radio connectivity and movement have disrupted the concept of a link as we know it in the wired environment. Specific modes for specific radios are proposed to restore that concept, which is essential for IP operations, as single hop (802.11 infrastructure mode) or multihop (802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified solution to reconstruct a minimum topological abstraction at layer 3 for the use of NEMO. The MANEMO problem is already observed in several Working Groups and some are specified in [15][14]. The MANEMO is possibly related to following on-going work in IETF o Existing Routing Protocols (MANET, OSPF) o Network Mobility Support (NEMO) o Mobile Ad-hoc Network and Auto Configuration (AUTOCONF) o Mobile Ad-hoc Sensor Network (6LOWPAN) o Mobile Nodes and Multiple Interfaces in IPv6 (Monami6) The main problems are "Network Loop", "Un-optimized Route", and "Multiple Exit Routers" . 5.1. Network Loop A network loop can occur when multiple mobile routers are nested and suddenly the Exit Router (root-MR, i.e. MR1) looses connectivity to the Internet and connects to the mobile network of lower MR (i.e. MR2 in the figure) In this case, the loop is observed between MRs. Each mobile network is designed to have movement transparency by NEMO Basic Support Protocol. Any node connecting to a mobile network cannot know whether the access network is a mobile network or not. Moreover, it is impossible to know whether a connecting mobile router has managed Internet connectivity or not. The mobile router may loose Internet Connectivity, temporarily. Knowing the topology of MFS is highly important to prevent this network loop issue. Wakikawa, et al. Expires August 9, 2007 [Page 15] Internet-Draft MANEMO Problem Statement February 2007 +---+ +---+ |AR | |AR | +-+-+ +---+ | | +-+-+ +---+ |MR1| --> |MR1+--+ +-+-+ +-+-+ | | | | | | | +-+-+ +-+-+ | |MR2| |MR2|--+ +---+ +---+ Figure 1: Network Loop 5.2. Un-optimized Route This is well known issue of Nested NEMO. The problem is described in Section 2.3 of [13]. The NEMO Working Group suggests not to prevent support for nested NEMO. [6]. Figure 2 shows a typical example of nested NEMO. Even if the destination is in the same MFS, the packets are always traveled through multiple home agents. There are several proposal in the NEMO Working Group. Wakikawa, et al. Expires August 9, 2007 [Page 16] Internet-Draft MANEMO Problem Statement February 2007 +---+ +---+ +---+ +---+ |HA1| |HA2| |HA3| |HA4| +-+-+ +-+-+ +-+-+ +-+-+ | | | | | | | | +. . . . . . . . . . . . .+ : : : The Internet : : : +. . . . . . . . . . . . .+ | +-+-+ The Path From MR1 to MR4 | AR| [MR1->AR->HA1->HA4->HA2->HA1->AR-> +-+-+ MR1->MR2->MR4] | +-+-+ The Path From MR3 to MR4 |MR1| [MR3->MR2->MR1->AR->HA1->HA2->HA3-> +-+-+ HA4->HA2->HA1->AR->MR1->MR2->MR4] | +---+ +-+-+ +---+ |MR3|----+MR2+----+MR4| +---+ +---+ +---+ Figure 2: Nested NEMO Figure 3 shows the another example of un-optimized path. This redundant path is also occurred in no nested NEMO scenario. In this example, two mobile routers are not directly connected. Most of the nested solution proposed in NEMO working group cannot solve this case. MANEMO solution should be able to solve this case, too. Wakikawa, et al. Expires August 9, 2007 [Page 17] Internet-Draft MANEMO Problem Statement February 2007 +---+ +---+ +---+ +---+ |HA1| |HA2| |HA1| |HA2| +-+-+ ++--+ +-+-+ ++--+ | | | | | | | | +.+. . . . . . . . ..+.+ +.+. . . . . . . ..+.+ . . . . . The Internet . . The Internet . . . . . +. . . . . . . . . . . + +. . . . .+. . . .. . + | | +-+-+ +----R-----+ +---+ AR+---+ | | | +-+-+ | +-+-+ +-+-+ | | +---+AR1| |AR2+---+ | | | +---+ +---+ | +-+-+ +-+-+ +-+-+ +-+-+ |MR1| |MR2| |MR1| |MR2| +-+-+ +-+-+ +-+-+ +-+-+ MR1->AR->HA1->HA2->AR->MR2 MR1->AR1->R->HA1->HA2->R->AR2->MR2 Figure 3: Unoptimized Route 5.3. Multiple Exit Routers This problem occurs when a mobile node obtains multiple Exit Routers toward the Internet. In the illustrated case, the mobile node should attempt to obtain some information about each Exit Router in order to more efficiently utilize them. MANEMO may carry this information about each Exit Router and present it to the connected mobile node. Wakikawa, et al. Expires August 9, 2007 [Page 18] Internet-Draft MANEMO Problem Statement February 2007 . . . . . . . . . . . .. . . . The Internet . . . .. . . . . . . . . . . . | | | | +-+-+ +-+-+ |AR1| |AR2+--+ +-+-+ +-+-+ | | +---+ | | +-----|MR1|----+ | +-+-+ | | +-+-+ +--------+MR2| +---+ Figure 4: Multiple Exit Routers Wakikawa, et al. Expires August 9, 2007 [Page 19] Internet-Draft MANEMO Problem Statement February 2007 6. Approach Rationale MANEMO aims at extending IPv6 Neighbor Discovery [7] to form and maintain an optimized nested NEMO. This section covers the rationale behind this approach. 6.1. Layer 2 (mesh, spanning tree) based approach Arguably, an existing layer 2 technology such as a spanning tree of 802.11s could be used to establish a tree towards the nearest Exit Router. This falls short when the nodes are mobile routers for a number of reasons: In a L2 based solution, the MRs would end up bridging for the nested routers while routing for their own (attached) Mobile Network Prefixes. A L3 based solution could span over multiple radio types, such as: 802.16 or 11a for backhaul, 802.11a or 11b/g for edge and 802.11 b/g or 802.15.4 for access. It also could span wired links. In an L3 solution, you control the broadcast domain and limit the multicast troubles without snooping. In particular, you segment the ND broadcast operations. NEMO operation is better if the MANEMO operation is done in ND at L3, because NEMO already interfaces with ND. A L2 solution would require NEMO to understand L2/2.5 protocols such as like 802.11s or 802.21. There can be value in integration between the NEMO and the MANET aspects of the mobility problem. For instance, if the Reverse Routing Header technique [16] is used to solve the pinball routing problem, then the RRH can be compressed dynamically if routes down the tree (or the DAG) are installed by the MANEMO protocol in the intermediate routers. And then you get all the IP value that is not necessarily there or homogeneous at L2, like QoS, SNMP, RSVP, aggregation, etc... 6.2. 802.21 based approach In some scenarios, the information service approach may be taken. For example, trains are run on a regular schedule and a system can preempt the movement of mobile routers on each train. In such a case, the operator can dynamically update the information of routers in a train to the information service (IS). The mobile node can retrieve information about the neighboring access networks from IS in Wakikawa, et al. Expires August 9, 2007 [Page 20] Internet-Draft MANEMO Problem Statement February 2007 some scenarios. Unless the IS supports dynamic updates of access routers and provides certain topology of mobile access routers, it is difficult to solve all the problems of MANEMO. For instance, it does not enable us to structure the nested NEMO in an optimal fashion for reaching the infrastructure. 6.3. MANET based approach The Mobile Ad-hoc Network Architecture [17] provides an overview of the MANET problem and scope. MANEMO is about designing a specific MANET that is tailored for the needs of nested NEMO, with a strong focus on finding the way to the outside infrastructure when it is reachable. In that sense, MANEMO specializes on a specific area of MANET by adding a set of constraints that narrow the problem down. Arguably, an existing MANET protocol could be used to enable routing between the Mobile Router within a nested NEMO. But existing MANET are not optimized for the following requirements: Default Route: Because it is used by Mobile Routers to find a way out and bind to their Home Agent, the MANEMO protocol focuses on building, maintaining and optimizing a default path to the exit of the nested NEMO. With MANET, the default route is usually an addition, and in any case it is just another route, not the focus of the protocol. Prefix Routing: Subnet (prefix) routing is a secondary concern for the MANEMO protocol. Such routes are considered when conditions permit, but might be maintained in a Least Overhead Routing Approach (LORA) as opposed to an Optimized Routing Approach (ORA) which is used for the Default Route. Host Routes are not of concern since MANEMO deals with Mobile Routers. Note that DYMO and OLSR are capable of the prefix routing. Group Management: When forming a nested NEMO, the Mobile Routers need a selection of information that is not present in traditional MANET approaches. Notions such as group, depth, free bandwidth towards the exit, etc... impact the formation of the nested NEMO and the way it optimizes itself overtime. On the other hand, existing MANET protocols could be integrated or adapted for the following cases: Wakikawa, et al. Expires August 9, 2007 [Page 21] Internet-Draft MANEMO Problem Statement February 2007 On-demand Routing: When a node needs to discover Exit Routers, on- demand fashion may reduce the overhead of discovery procedure. Some MANET routing protocols such as AODV and DYMO has the on- demand mechanism to discover a route towards the destination. Neighborhood Routing: Because the MANEMO protocol provides only a minimized view of the local network, it might be missing a short path to a neighborhood destination over an alternate radio link. A collaboration with a MANET protocol would improve short-distance routing. As an example, internal connectivity between NEMOs within the local network may improve by Mobile Routers running a MANEMO routing protocol and discovering more optimal routes to the MNPs reachable within the local network. Mechanisms specific to MANEMO should also be developed to ensure this optimisation is safe. Global Reachability for a MANET In the MANET working group, an Internet Gateway is introduced to provide Internet connectivity to MANET. In this case, the gateway of a MANET network is also a NEMO Mobile Router. Using NEMO, The gateway registers the MANET prefix(es) to a Home Agent, enabling the MANET network to move as a whole. The Mobile Router can also act as a Mobile Home for the whole MANET, providing Home Agent services such as mobility and prefix delegation. In particular, the Mobile Home can maintain connectivity with Mobile IP6/NEMO enabled MANET Nodes that would stray away from the mobile MANET. For these reasons, MANET could contribute in optimizing a deployment, but a specific protocol has to be engineered to match the MANEMO requirements. 6.4. Neighbor Discovery based approach Neighbor Discovery (ND) [7] provides the means to discover neighbors and the prefix on a link, which are pervasive across IPv6 nodes and link types. Mobile IPv6 [8] and NEMO [1] rely heavily on ND for roaming and Home Link activities. Considering that NEMO already uses ND for Router Discovery, it makes sense to extend ND in MANEMO as opposed to providing a second peering mechanism. ND has already been extended to expose some layer 3 information, such as router selection hints [9]. ND is consistently being improved for mobility, in particular with Mobile IPv6 [8] and DNA, and for security with Secure ND [10]. ND operates on bidirectional links, whereas this is a restriction from the MANET standpoint, this condition enables simpler solutions for MANEMO. Neighbor Discovery is well suited for providing hints for composing a Wakikawa, et al. Expires August 9, 2007 [Page 22] Internet-Draft MANEMO Problem Statement February 2007 path to the Internet access router. The hits could include Layer 2 information as well as application layer information, needed for providing optimal and stable paths to Exit Routers. The Exit Routes connect the MANEMO Fringe Stub to the Internet. Path maintaining towards an Exit Router is suggested in a nested NEMO tree discovery protocol [18]. Multicast support could be provided by using the loop-free MANEMO Tree to forward packets to the Internet. Down-tree forwarding would use MLD-proxy[19], either with native MLD [11][12] / ICMP packets or send with the ND extensions to increase efficiency. Multicast forwarding rules should be validated, mechanisms like RPF-check and duplicate packet detection [20] would be used to eliminate multicast looped packets. Forwarding rules on the Exit Router is to be worked out. The MANEMO work will thus focus on an ND based solution that is required to provide multihop reachability while supporting inner movements in the nested NEMO. 6.4.1. MANEMO ND and other MANET protocols The MANEMO ND provided information can be used by other MANET protocols. Other MANET protocols could be used for optimize local connectivity or used for other reasons. MANEMO ND may provide IP link and address topology vectors to the nodes next hop neighbors. Then that topology information at each next hop neighbor would be propagated to an OLSRv2 [21] / NHDP [22] symmetric 2-hop neighborhood and Multipoint Relay, or OSPF-MANET [23] / [24] MANET Designated Router (most likely Parent and Routable characteristics) who then can flood that topology to other Multipoint Relays or MANET Designated Routers down to other neighbors. This also could be accomplished using NEMO/MANEMO Access Routers to the NEMO Clusterhead using the proposed tree discovery protocol [18]. The diameter of the topology would span a single ad hoc link. This would provide an IP layer 3 solution and the topology information could be placed in new ND options. 6.4.2. MANEMO ND and AUTOCONF The use of ND for IP link and address topology could also foster a discussion with IETF AUTOCONF Working Group to analyze if ND could be used as defined above to support ND stateless autoconfiguration. The design center for such a solution would be to place this ND link and IP topology enhancement below current MANET routing protocols and could reduce latency for ad hoc links whether within a MESH or Radio Network link. ND extensions could assist greatly below MANET routing Wakikawa, et al. Expires August 9, 2007 [Page 23] Internet-Draft MANEMO Problem Statement February 2007 protocols to discover neighbors, verify two way communications, exchange link state information, and provide update information between neighbors and ingress/egress point to MANET Mobile Routers. These extensions could also be applied as enhancements to the tree discovery protocol that would support MANEMO, thus adding these extensions to tree discovery protocol is a suggestion or it could be its own specification. Wakikawa, et al. Expires August 9, 2007 [Page 24] Internet-Draft MANEMO Problem Statement February 2007 7. Related Information Related Documents can be found in the Informative Reference section Solutions are already proposed at IETF such as [16] and [18]. The NEMO Working Group has the analysis document [25] for the nested NEMO issue. Wakikawa, et al. Expires August 9, 2007 [Page 25] Internet-Draft MANEMO Problem Statement February 2007 8. IANA considerations This document does not require any IANA action. Wakikawa, et al. Expires August 9, 2007 [Page 26] Internet-Draft MANEMO Problem Statement February 2007 9. Security Considerations This document is a problem statement and does not create any security threat. It discusses the concepts of Capability, Innocuousness and Anonymity in a nested NEMO. Wakikawa, et al. Expires August 9, 2007 [Page 27] Internet-Draft MANEMO Problem Statement February 2007 10. Acknowledgments We would like to thank all the people who have provided comments on this draft, and also co-authors of earlier documents in which authors of this present document have been engaged. As such, we would like to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham Soliman, Carlos Jesus Bernardos Cano and many others. 11. References 11.1. Normative reference [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [6] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-06 (work in progress), November 2006. [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [9] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. [10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. Wakikawa, et al. Expires August 9, 2007 [Page 28] Internet-Draft MANEMO Problem Statement February 2007 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 11.2. Informative Reference [13] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03 (work in progress), September 2006. [14] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route Optimisation Problem Statement", draft-clausen-nemo-ro-problem-statement-00 (work in progress), October 2004. [15] Ng, C., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-06 (work in progress), June 2006. [16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-06 (work in progress), September 2006. [17] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-chakeres-manet-arch-01 (work in progress), October 2006. [18] Thubert, P., "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-04 (work in progress), November 2006. [19] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD- Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in progress), April 2004. [20] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-03 (work in progress), October 2006. [21] Clausen, T., "The Optimized Link-State Routing Protocol version 2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006. [22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-00 (work in progress), June 2006. [23] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS Flooding", draft-ogier-manet-ospf-extension-08 (work in progress), October 2006. [24] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile Wakikawa, et al. Expires August 9, 2007 [Page 29] Internet-Draft MANEMO Problem Statement February 2007 Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in progress), January 2007. [25] Ng, C., "Network Mobility Route Optimization Solution Space Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in progress), September 2006. Wakikawa, et al. Expires August 9, 2007 [Page 30] Internet-Draft MANEMO Problem Statement February 2007 Appendix A. Change Log From Previous Version o Initial Documentation Authors' Addresses Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 JAPAN Email: ryuji@sfc.wide.ad.jp Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Teco Boot Infinity Networks B.V. Elperstraat 4 Schoonloo 9443TL Netherlands Phone: +31 592 50 12 66 Email: teco@inf-net.nl Jim Bound Hewlett-Packard PO BOX 570 Hollis, NH 03049 USA Phone: +603 465 3130 Email: jim.bound@hp.com Wakikawa, et al. Expires August 9, 2007 [Page 31] Internet-Draft MANEMO Problem Statement February 2007 McCarthy Ben Lancaster University Computing Department, Lancaster University. InfoLab 21, South Drive Lancaster, Lancashire LA1 4WA UK Phone: +44-1524-510-383 Fax: +44-1524-510-492 Email: b.mccarthy@lancaster.ac.uk URI: http://www.network-mobility.org/ Wakikawa, et al. Expires August 9, 2007 [Page 32] Internet-Draft MANEMO Problem Statement February 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). Wakikawa, et al. Expires August 9, 2007 [Page 33]