MANET and NEMO Working Groups T. Boot Internet-Draft Infinity Networks Expires: December 28, 2007 June 26, 2007 Analysis of MANET and NEMO draft-boot-manet-nemo-analysis-01.txt 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 December 28, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides an overview of models for MANET and NEMO. It descibes the MANET and the NEMO characteristics. It also also lists problems using the MANET and NEMO technology, when problems are not described in other documents. It is claimed that MANET suits small mobile network topologies, providing optimal paths for communication within a MANET cloud and towards the outside. It is also claimed that NEMO suits small mobile subnets, providing sub-optimal paths for to Internet connected nodes. This document is used for evaluating a need for a MANET for NEMO, called MANEMO. Boot Expires December 28, 2007 [Page 1] Internet-Draft Analysis of MANET and NEMO June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. MANET classification and models for hierarchy . . . . . . . . 8 3.1. Sub-IP MANET . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Isolated MANET . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Interconnected MANETs . . . . . . . . . . . . . . . . . . 9 3.4. Stub MANET . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Layered MANETs . . . . . . . . . . . . . . . . . . . . . . 10 4. Fringe Stub models . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Layer-2 Access . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Layer-2 Meshing . . . . . . . . . . . . . . . . . . . . . 12 4.3. Node Mobility . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Network Mobility . . . . . . . . . . . . . . . . . . . . . 14 4.5. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. MANEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. MANET and NEMO Characteristics . . . . . . . . . . . . . . . . 17 5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. HA dependency . . . . . . . . . . . . . . . . . . . . . . 18 5.4. Route optimization . . . . . . . . . . . . . . . . . . . . 18 5.5. Interface type . . . . . . . . . . . . . . . . . . . . . . 18 5.6. Multicast support . . . . . . . . . . . . . . . . . . . . 19 6. Problems found in MANET and NEMO . . . . . . . . . . . . . . . 20 6.1. Worst Path First Syndrome . . . . . . . . . . . . . . . . 20 6.2. Break Before Make problem . . . . . . . . . . . . . . . . 21 6.3. Routing loops in proactive routing protocols . . . . . . . 22 6.4. Congested link avoidance . . . . . . . . . . . . . . . . . 23 6.5. MANET and NEMO at home problem . . . . . . . . . . . . . . 25 6.6. MANET scale to infinity problem when peering to strangers . . . . . . . . . . . . . . . . . . . . . . . . 27 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative reference . . . . . . . . . . . . . . . . . . . 29 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 29 Boot Expires December 28, 2007 [Page 2] Internet-Draft Analysis of MANET and NEMO June 2007 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 32 A.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Boot Expires December 28, 2007 [Page 3] Internet-Draft Analysis of MANET and NEMO June 2007 1. Introduction IP technology is increasingly being used in mobile networks. Many issues arise with mobility, for example wireless bandwidth and link quality are typically low related to fixed, wired infrastructures. Also routing protocols for mobile environments are faced with new challenges; connectivity comes and goes when nodes move and link quality increases and decreases instead of flapping between an OK and an NOT-OK state. Two IETF mobility technologies are available, that is Mobile Ad-hoc NETworks (MANET) [1], [2] and Mobile IP (MIP). The MANET workgroup is working on routing protocols, running on mobile or fixed routers; either in small isolated topologies or at edges of large IP infrastructures. Multiple types of MANET protocols exist; OLSR [3] is a proactive MANET protocol populating the routing table independent of any user traffic; DYMO [4] is a reactive protocol, providing path information for traffic flows and SMF [5] is a multicast flooding protocol. The MIP4 and MIP6 workgroups are working on mobility support for hosts, enabling session continuity while moving. Other workgroups are working on improvements on MIP, for example MONAMI6 and MIPSHOP are working on using multiple interfaces towards the IP infrastructure. The NEMO workgroup extends MIP using the Mobile Router concept, providing MIP services for MR attached nodes. With NEMO, nesting can occur, introducing new challenges. Currently, a number of communities are working on network architectures for mobile domains. Different communities work on different domains, all having their specific requirements. Work within the IETF would comply with all those requirements. Sample domains are military, public safety / emergency response networks, mobile networks used by enterprises and non-governmental organizations, provider based Internet access, license-free wireless networks and networks for intelligent transport systems / vehicle communication systems. Also combinations of multiple domains can be used, for example a mobile network for a disaster relief organization could use own licensed transmission means, provider based Internet access and license-free wireless networks; all used in cars also equipped with an inter-vehicle communication system / intelligent transport system. Boot Expires December 28, 2007 [Page 4] Internet-Draft Analysis of MANET and NEMO June 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 RFC2119 [6] Readers are expected to be familiar with all the terms defined in RFC3753: Mobility Related Terminology [7] and the NEMO Terminology draft [8] MANET Mobile Ad-hoc NETworks [7] NEMO NEtork MObility [8] NEMO BS Network Mobility Basic Support Protocol [9] NEMO RO NEMO Route Optimization [10] / [11] / [12] MIP Mobile IP [8] MIP4 IP Mobility Support for IPv4 [13] MIP6 Mobility Support in IPv6 [14] OLSR Optimized Link-State Routing Protocol [3] DYMO Dynamic MANET On-demand Routing [4] Boot Expires December 28, 2007 [Page 5] Internet-Draft Analysis of MANET and NEMO June 2007 SMF Simplified Multicast Forwarding for MANET [5] OSPF Open Shortest Path First [15][16] MONAMI6 Mobile Nodes and Multiple Interfaces in IPv6 MIPSHOP Mobility for IP: Performance, Signaling and Handoff Optimization HAHA Global HA to HA protocol [17]; [18] MNR MANET Router [2] MR Mobile Router [7] [8] MH Mobile Host [7] HA Home Agent [8] CN Correspondent Node [8] LFN Local Fixed Node [8] RA Boot Expires December 28, 2007 [Page 6] Internet-Draft Analysis of MANET and NEMO June 2007 Router Advertisement [19] Boot Expires December 28, 2007 [Page 7] Internet-Draft Analysis of MANET and NEMO June 2007 3. MANET classification and models for hierarchy MANETs can be classified based on different deployment scenarios. The classical MANET approach focused on a single, contiguous MANET region. Now MANET technology is getting mature, focus is shifting towards interfacing between different MANETs and MANETs connected to the Internet. This section provides a classification of MANETs and models for MANET hierarchy. Deployed MANETs can inherit characteristics of different models. 3.1. Sub-IP MANET MANET technology can be used below the IP layer. The MANET forms a single IP subnet, where nodes can reach each other transparently. The subnetwork provides full connectivity for unicast and multicast / broadcast. RFC3819 [20] provides advice on subnetworks. +-----------------------+ | | | Sub-IP MANET | | | +-----------------------+ : : : : : = Classic IP Interface +-+-+ +-+-+ | N | * * * * * | N | +---+ +---+ Figure 1: Sub-IP MANET Sub-IP MANETs are transparent for the IP layer and do not introduce special requirements. 3.2. Isolated MANET An Isolated MANET is a single, contiguous MANET region. MANET routers within the MANET region provide connectivity to attached hosts. No Routers are attached to an Isolated MANET. Boot Expires December 28, 2007 [Page 8] Internet-Draft Analysis of MANET and NEMO June 2007 +-------------------------+ | Isolated MANET | | | | ~MNR1 | ~ = MANET IP Interface | ~ ~ ~MNR2 | | MNR3 ~ ~ ~ | | ~ ~~~MNR4 ~ | | MNR5~~~~~ ~~~MNR6 | +-:------------------:----+ : : : : +-+-+ +-+-+ | H | * * * * * * | H | +---+ +---+ Figure 2: Isolated MANET 3.3. Interconnected MANETs MANETs can be connected to each other, forming a single network infrastructure. +-------------------------+ +-----------------------+ | MANET1 | | MANET2 | | | | | | ~MNR1 | | | | ~ ~ ~MNR2#############MNR7~~~~~~~~~~MNR8 | | MNR3 ~ ~ ~ | | ~ ~~~ ~ | | ~ ~~~~~~MNR4 ~ | | ~ ~~~ ~ | | MNR5 ~~~MNR6 | | MNR9 ~~MNR10 | +-:------------------:----+ +--:---------------:----+ : : : : : : : +-+-+ +-+-+ +-+-+ | H | * * * * * * | H | | H | # = MANET Border +---+ +---+ +---+ Interface Figure 3: Interconnected MANETs The MANET Border Interface connects the two routing regions. Route filtering and summarization can be configured. Border Interfaces are typically not formed ad-hoc. Boot Expires December 28, 2007 [Page 9] Internet-Draft Analysis of MANET and NEMO June 2007 3.4. Stub MANET Stub MANETs are connected to a Fixed Infrastructure or the Internet. Connectivity to the Fixed Infrastructure is provided with default routes. Connectivity to the Stub MANET can be provided with an aggregated prefix. +-------------------------------+ | | | Fixed Infrastructure | | | | R | +-----------------------#-------+ # # +--------------------#----+ | Stub MANET # | | # | | ~MNR1 # | | ~ ~ ~MNR2 | | MNR3 ~ ~ ~ | | ~ ~~~MNR4 ~ | | MNR5~~~~~ ~~~MNR6 | +-:------------------:----+ : : : : +-+-+ +-+-+ | H | * * * * * * | H | +---+ +---+ Figure 4: Stub MANET A Stub MANET could have redundant MANET Border Interfaces. The Stub MANET will not act as transit region. 3.5. Layered MANETs MANETs can have a layered structure. Connection to the top level is similar to a Fixed Infrastructure connection. The lowest level can be configured as Stub MANETs. MANETs in the middle layers provide transit services. Boot Expires December 28, 2007 [Page 10] Internet-Draft Analysis of MANET and NEMO June 2007 +---------------------------------------+ | Top-level MANET | | | | :::::::R::::::::: | | R R | +----------------#---------------#------+ # # # # +--------------------#----+ +---#---------------------+ | Stub MANET2 # | | # MANET3 | | # | | # (transit) | | ~MNR1 # | | # | | ~ ~ ~MNR2 | | MNR7~~~~~~~~~~~MNR8 | | MNR3 ~ ~ ~ | | ~ ~~~ ~ | | ~ ~~~~~~MNR4 ~ | | ~ ~~~~ ~ | | MNR5 ~~~MNR6 | | MNR9 ~~MNR10 | +-:------------------:----+ +--:---------------#------+ : : : # : : : # +-+-+ +-+-+ +-+-+ +------#------+ | H | * * * * * * | H | | H | | Stub MANET4 | +---+ +---+ +---+ +-------------+ Figure 5: Layered MANETs Layered MANETs have a fixed structure. Mobility within the MANET is supported. Dynamic border router formation between the MANETs is currently not foreseen. Boot Expires December 28, 2007 [Page 11] Internet-Draft Analysis of MANET and NEMO June 2007 4. Fringe Stub models In the (Wireless) Fringe Stub, an almost infinite wireless ad-hoc topology is connected to a Fixed Infrastructure. The Fringe Stub is not required to be continuous, the Fixed Infrastructure is used to interconnect isolated segments. Mobile Routers can roam between isolated segments without any reconfiguration. In the Fringe Stub models, Layer-2 Access, Layer-2 Meshing, Mobile IP, NEMO and MANET technologies are used. Deployed Fringe Stubs can inherit characteristics of different models. 4.1. Layer-2 Access Mobile nodes can use a layer-2 Access service provided by telecommunication providers. Classical IP interfacing is used, so special requirements are introduced. Depending on the provider or the technology used, micro mobility or macro mobility is provided. <--------------------------------------------------> < > < Fixed Infrastructure > < > < ::::::::::R:::::::::::::::::R:::::: > < R R R > <------BS----------------BS-------------BS---------> : : : : : : BS = Base Station : : : +-+-+ +-+-+ | N | * * * * * * * * * * * * * | N | +---+ +---+ Figure 6: Layer-2 Access 4.2. Layer-2 Meshing For reducing costs of the infrastructure or to extend area of reach, Relay Stations can be used to enhance the Layer-2 Access model. This provide also some kind of redundancy. When the Base Station is isolated from the backbone, an alternative path via another Base Station can be used. Boot Expires December 28, 2007 [Page 12] Internet-Draft Analysis of MANET and NEMO June 2007 <--------------------------------------------------> < > < Fixed Infrastructure > < > < ::::::::::R:::::::::::::::::R:::::: > < R R R > <------BS----------------BS-------------BS---------> : : : RN.. : : RN = Relay Node : : : : : ......RN : : : +-+-+ +-+-+ +-+-+ | N | * * | N | * * * * * * * | N | +---+ +---+ +---+ Figure 7: Layer-2 Meshing 4.3. Node Mobility MIP (MIP4 [13] and MIP6 [14]) provide mobility and handover functionalities to mobile nodes. Mobile IP is targeted for providing "macro mobility". It provides session continuity over different heterogeneous network types and provides global roaming. "Micro mobility" using link-layer mobility services would provide better handover performance [13]. Optimizing handover using IP technology is work-in-progress. <--------------------------------------------------> < > < Fixed Infrastructure HA > < CN > < ::::::::::R:::::::::::::::::R:::::: > < R R R > <------:-----------------:--------------:----------> : : : : : : : : : +--+-+ +--+-+ | MN | * * * * * * * * * * * * | MN | +----+ +----+ Figure 8: Node Mobility The Home Agent (HA) takes care of reachability for served Mobile Boot Expires December 28, 2007 [Page 13] Internet-Draft Analysis of MANET and NEMO June 2007 Nodes. The Corresponding Nodes (CN) find the path to Mobile Nodes via the HA. 4.4. Network Mobility Network Mobility (NEMO basic, [9]) extends Mobile IP for roaming subnets. Local Fixed Nodes (LFN) connected to the Mobile Router (MR) benefit form the MR MIP service. <--------------------------------------------------> < > < Fixed Infrastructure HA > < CN > < ::::::::::R:::::::::::::::::R:::::: > < R R R > <------:-----------------:--------------:----------> : : : : : : e: Egress Interface : : : i: Ingress Interface +--e-+ +----e----+ | MR | * * * * * * * * | MR(s) | +--i-+ +----i----+ : : ........... ................ : : : : +-+-+ +-+-+ +-+-+ +-+-+ | H | | H | * | H | | R | +---+ +---+ +---+ +-+-+ : +-+-+ | H | +---+ Figure 9: Network Mobility The MR serves local connected hosts and local connected routers, called Local Fixed Nodes (LFN). The "Egress Interface" is used for reaching the HA, either directly when at home or via the MIP tunnel when the MR is at a foreign network. Mobility service is provided via the "Ingress Interface" for a Mobile Subnet. 4.5. Nested NEMO With NEMO, visiting mobile nodes are supported, this is because MRs are able to connect to the Ingress interface of other MRs and configure their CoAs/receive connectivity via the MR they are Boot Expires December 28, 2007 [Page 14] Internet-Draft Analysis of MANET and NEMO June 2007 temporarily attached to. Mobile Hosts are stubs, as they do not provide forwarding. Nested Mobile Routers can form an arbitrary level of nested HA tunnels. <--------------------------------------------------> < > < Fixed Infrastructure HA > < CN > < ::::::::::R:::::::::::::::::R:::::: > < R R R > <------:-----------------:--------------:----------> : : : : : : : : : +--e-+ +----e----+ | MR | * * * * * * * * | MR(s) | +--i-+ +----i----+ : : ........... ................ : : : : +--+-+ +--e-+ +--e-+ +--+-+ | MH | | MR | | MR | * * * * | MH | +----+ +--i-+ +--i-+ +----+ : : +--+-+ ........ | MH | : : +----+ v v <-- Deeper nesting of MRs Figure 10: Nested NEMO Nested Mobile Routers form tree topologies. Pin-ball routing is introduced, discussed in a section on Route Optimization below. 4.6. MANEMO With MANEMO [21], [22], MANET technology is introduced in Nested NEMO. The main goals are implementing NEMO Route Optimizing, supporting floating Nested NEMO topologies and providing optimized paths within the MANEMO Fringe Stub without using NEMO tunneling. A suggested solution is using a tree discovery protocol [23]. The tree structure is used for optimizing packet forwarding between Mobile Nodes and the Exit Router [24], [25]. The tree can also be used for inner-tree communication and multicast support. Another suggested solution is to use direct communication between Boot Expires December 28, 2007 [Page 15] Internet-Draft Analysis of MANET and NEMO June 2007 1-hop neighbors by advertising the mobile subnet prefix using IPv6 Neighbor Discovery [25], [26]. Also using MANET technology is suggested [22], [27]. <-----------------------------------------------------> < > < Fixed Infrastructure HA > < CN > < ::::::::::R:::::::::::::::::::R:::::: > < R ER R > <------#--------------------#--------------#----------> # # # # # # <-----#--------------------#--------------#----------> < # MANEMO # # > < # Fringe Stub # ER7 > < ER1~ # ~ > < ~ ~~ ~~~~~~MR2 ~ > < MR3 ~ ~~~ ~~ MR8 > < ~ ~~~MR4 ~~ ~ ~~ > < MR5~~~~~ ~~~~MR6 MR9 MR10 > <----:-----------------:--------------:--------:-----> : : : : : : : : +-+-+ +-+-+ | N | * * * * * * * * * * * * * * * * * | N | +---+ +---+ Figure 11: MANEMO In MANEMO, the interface types Ingress, Egress and MANET could be logical roles. Physical interfaces could have any role and policies on MRs can limit the roles on particular interfaces. This relax the definition of a NEMO MR [9]. Exit Routers are Fixed Access routers running MANEMO protocols or top level Mobile Routers. MANEMO Fringe Stub is work in progress. MANET proactive, reactive and source-routing technology is used in addition to Nested NEMO. Boot Expires December 28, 2007 [Page 16] Internet-Draft Analysis of MANET and NEMO June 2007 5. MANET and NEMO Characteristics 5.1. Scalability MANET and NEMO have very different goals. MANET can provide optimized paths within a limited topology, where NEMO provides Internet scale end-to-end connectivity. Therefore, scalability characteristics for MANET and NEMO are very different. MANET scalability is researched and many improvements are proposed. But still MANET networks have their limits, a large number (100 or more) of Mobile Routers in a flat area is a topic for active research [2]. Other technology must be used to provide Internet scale deployment. The OSPF MANET extension [28], [29] is applicable for a limited number of routers interconnected with radio interfaces. Such a MANET subnetwork would be part of an OSPF area, and OSPF (and BGP) routing state flooding reduction mechanisms enable large scale deployment. Many independent OSPF MANET subnetworks can de deployed, similar to for example Ethernet segment scalability. Other MANET protocols could use the same approach. A MANET domain can be connected to a fixed infrastructure and route aggregation hides routing state flooding. NEMO makes use of the MIP tunnel overlay, hiding mobility on the fixed Internet infrastructure. The number of mobile networks scales with the number of home agents, and address aggregation enables huge scale NEMO deployment. 5.2. Mobility With MANET, a MNR can roam within an area where sufficient coverage is available. When the number of MANs increase, coverage will improve or the area will be enlarged. Scalability issues restrict the number of MANs, which implies restrictions on mobility. Zoned or hierarchical models are proposed, but world wide mobility would not be provided by MANET. With NEMO, "macro mobility" is inherited from Mobile IP. Worldwide mobility can be provided for an almost unlimited number of MRs, all having end-to-end connectivity. For both MANET and NEMO, mobility is also related to radio coverage. No coverage implies no connectivity. Boot Expires December 28, 2007 [Page 17] Internet-Draft Analysis of MANET and NEMO June 2007 5.3. HA dependency MANET does not depend on Mobile IP and doesn't need a home agent. NEMO extends Mobile IP using a Mobile Router. The Mobile Router maintains a tunnel to its home agent. Traffic between LFN and CN flows through the tunnel and thus the home agent is a critical element for communication. HA dependency can be relaxed by HA redundancy or new protocols, like Global HA to HA protocol (HAHA) [17] / [18]. MIP and NEMO Route Optimization could also relax the HA dependency. For communication from a NEMO LFN to a far away CN, the HA dependency may not be a problem. But for local communication, this could be unacceptable, especially in military and public safety / emergency response networks, where local communication availability is a primary concern. 5.4. Route optimization MANET protocols would select a shortest path (fewest hops, lowest metric) or an optimized path based on cross-layer metrics. Problems with optimized path selection based on fewest hop count are described below in section Worst Path First Syndrome. Currently, nested NEMO based on NEMO BS [9] lacks intelligent path selection. RA sent by MR are equivalent to RA sent by a fixed Access Router. Selecting an Attachement Router without any knowledge on path metrics would select non-optimal paths. Nested NEMO has high tunnel header overhead and a pinball route problem. Also route loops can occur (NEMO RO) [10]. 5.5. Interface type In the MANET architecture, a MANET-Interface is an interface with a MANET protocol enabled. Typical behavior is the relay function, incoming traffic on this interface can be relayed to serve other nodes increasing connectivity in the MANET topology [30]. In Mobility Related Terminology [7], The Ingress and Egress Interface types are introduced. Terms are related to the NEMO mobile Router model [9]. The Ingress Interface is the interface with the Mobile Network Nodes connected to. The Egress Interface is the interface the Mobile Router uses to attach to the fixed infrastructure. When discussions started about integrating MANET and NEMO, the difference between the MANET and Egress interface faded. Also a discussion about the need for a MANEMO Ingress Interfaces started, as Boot Expires December 28, 2007 [Page 18] Internet-Draft Analysis of MANET and NEMO June 2007 in MANET there is no need for special handling, and in MANEMO any router interface could be MANET enabled. For policy reasons, a MANEMO router interface could be defined as Ingress only. 5.6. Multicast support In MANET environment, classical multicast forwarding using a Reverse Path Forwarding Check cannot be used. The MANET interface is used for relaying IP packets, and a basic forwarding rule is broken, specifying that an IP multicast packet is never sent back over the incoming interface. Multiple MANET multicast protocols are proposed, but many of them showed large overhead for keeping state information. Currently the MANET workgroup is working on SMF [5]. SMF use 2-hop neighbor state provided by another protocol (currently NHDP [31]) for efficient flooding combined with duplicate packet detection. In NEMO, multicast service can be provided. Within the Mobile Network itself, basic multicasting is used. Global multicast supported can also be provided; the MR relays the multicast to the HA, where the multicast flow is injected in the fixed infrastructure. Receiving multicast from the fixed infrastructure is also supported, the HA relays the multicast flow via the tunnel to the MR and the FLNs. Multicasting between nearby NEMO MRs would have large overhead, as the multicast is lead over the HAs. Also multicast from the fixed infrastructure to multiple nearby NEMO MRs is inefficient, as the multicast flow is pseudo-broadcasted over multiple tunnels to these MRs. Options for improved NEMO multicast support are proposed, e.g. using MLD-proxy [32]. Boot Expires December 28, 2007 [Page 19] Internet-Draft Analysis of MANET and NEMO June 2007 6. Problems found in MANET and NEMO This section is used as placeholder for problems in MANET or NEMO, which are not maintained in separate IETF Problem Statement documents. 6.1. Worst Path First Syndrome Classic routing protocols use the hop-count as metric for best path selecting. Hop-count is still used in modern MANET routing protocols. For homogeneous topologies, where all links have similar capabilities, this could be seen as sufficient. But when different link types are used or link characteristics vary in time and on a neighbor by neighbor basis, problems are introduced. Using cross- layer information is seen as helpful for MANET environments[2]. NEMO / nested NEMO do currently not select a path based on metrics. The Worst Path First Syndrome is a name given to a behavior of a path selection algorithm, selecting the path to a destination using the fewest hops, but also the worst quality links. Using ad-hoc networks with broadcast radios, link quality and data rate would be a function of distance and influenced by obstacles. In the example below, a high quality radio link uses a data rate of 11Mbps and has a packet loss below 1%. A bad quality radio link uses a data rate of 1Mbps and has a packet loss around 50%. +----+ | R1 | +----+ 11Mbps / | loss / | <1% / | 1Mbps +----+ | loss ~50% | R2 | | +----+ | 11Mbps \ | loss \ | <1% \ | +----+ | R3 | +----+ Figure 12: Worst Path First Syndrome Network Topology R3 can select R1 or R2 as attachment router, router advertisements Boot Expires December 28, 2007 [Page 20] Internet-Draft Analysis of MANET and NEMO June 2007 from both R1 and R2 are received. A MANET protocol, selecting a path based on hop-count, selects the direct path to R1. NEMO would select R1 or R2, as it has no knowledge of the topology. Selecting the direct path to R1 is the worst in terms of bandwidth (1Mbps where 11Mbps is available), packet loss (50% where less than 2% is available) and used spectrum (single transmission over 1Mbps takes more time for sending a packet than 2 times over 11Mbps). The direct path to R1 would require more retransmissions if reliable data transfer is supported. In a heterogeneous topology, the problem becomes totally unacceptable. Imagine that the three Rs are temporally "on the pause" and R2 and R3 are near to each other. Because R3 has bad user experience, it can be serviced by using cabling to R2 and the bandwidth is increased to 100Mbps and the packet loss is zero. Still, user experience is not enhanced at all, and R1 would be selected. Defining solutions for this problem is out of scope of this document. A suggested approach is using path metrics based on cross layer metrics. 6.2. Break Before Make problem The Break Before Make (BBM) [7], problem occurs when links suddenly fail and there is no pre-warning mechanism. Classic routing protocols suffer from BBM, as problems in fixed infrastructures are mostly caused by equipment failures and these problems are hard to predict. Modern protocols have support for L2-triggers, speeding up connection repair time. Graceful shutdown is a mechanism that is for predicted outages. Before the outage, neighbors are signaled the node or link is taken out of service and an alternative path is selected, if available. In a wireless infrastructure, especially when elements are moving, link quality is varying and getting out-of-reach can be detected by layer-2 mechanisms or by detecting packet loss, e.g. provided by a hello protocol. The decreased link quality can be signaled to the neighbors, and alternative paths can be selected before the link breaks. Such concepts are called Make Before Break (MBB) [7]. When hop count metrics are used, varying link quality is not taken into account and links are used until the become really out of reach. This is similar to the WPF syndrome described above. Defining solutions for this problem is out of scope of this document. A suggested approach is using path metrics based on cross layer link Boot Expires December 28, 2007 [Page 21] Internet-Draft Analysis of MANET and NEMO June 2007 metrics. 6.3. Routing loops in proactive routing protocols Loops in classical unicast routing could take place when an interface state changes. When an interface goes down, the routing table is adjusted quickly for removing entries with a next hop via this interface. Alternative routes could be used quickly also. Other router routing tables are updated after routing protocol activity; this could take milliseconds up to minutes, depending on protocol and timer settings. During this convergence, routing loops can occur and packet starvation is handled by TTL mechanism. On wireless media, using TTL for starvation could have a high impact on radio resources and spectrum utilization. In the following scenario, a hop-count based metric is used. Routers are located around an obstacle and a ring topology is formed due to radio propagation. In the scenario, R5 is moving away from R4. +----+ +----+ +----+ | R1 |--------| R2 |--------| R3 | +----+ +----+ +----+ | | | =+=+= obstacle =+=+ | | | +----+ +----+ | R4 |----------------------| R5 | R5 moves this way ---> +----+ +----+ Figure 13: MANET routing loop scenario When R5 is moved, the neighbor state for R4 and R5 goes down. +----+ +----+ +----+ | R1 |--------| R2 |--------| R3 | +----+ +----+ +----+ | \ | =+=+= obstacle =+=+ \ | \ +----+ +----+ | R4 | | R5 | R5 moves this way ---> +----+ +----+ Boot Expires December 28, 2007 [Page 22] Internet-Draft Analysis of MANET and NEMO June 2007 Figure 14: Neighbor down detected R4 and R5 detect the change due to the hello mechanism or L2 triggers. After R4 is aware of the failure, it immediately adjusts its routing table. It uses R1 as next hop for traffic to R5. However, R1 is still not aware of the topology change and still uses R4 as next hop for traffic towards R5. Now the routing loop occurs: +----+ +----+ +----+ | R1 |--------| R2 |--------| R3 | +----+ +----+ +----+ ^ | \ Loop: | | =+=+= obstacle =+=+ \ | v \ +----+ +----+ | R4 | | R5 | R5 moved +----+ +----+ Figure 15: Transit during MANET convergence The loop is solved as soon as R1 is aware of the new topology. Time for convergence is caused by routing protocol packet transfer, timers and processing time. Protocol timers that slow down packet transfer or introduce jitter in SPF calculation increase convergence time and thus loop duration. So jitter introduced by draft-clausen-manet-jitter emphasizes the routing loop problem. Defining solutions for this problem is out of scope of this document. A suggested approach is using a) path metrics based on cross layer metrics; b) implementing a reverse path check on the previous forwarder address, when this address is available and c) implementing a duplicate packet detection mechanism. 6.4. Congested link avoidance In MANET environment, the shortest path mechanism can select a link connecting two MANET islands for relaying all traffic flows between these islands. This is also the case when many exit routers to a high speed backbone are available. Boot Expires December 28, 2007 [Page 23] Internet-Draft Analysis of MANET and NEMO June 2007 <---------------------------------------------------> < > < Fixed Infrastructure > < > < ::::::::::R:::::::::::::::::::R:::::: > < R ER R > <------#--------------------#--------------#--------> # # # # # # +-----#--------------------#--------------#--------+ | # MANET # # | | # # ER7 | | ER1~ # ~ | | ~ ~~ ~~~~~~MR2,,,, ~ | | MR3 ~ ~~~ ~~ ,,,,,,,,MR8 | | ~ ~~~MR4 ~~ ~ ~~ | | MR5~~~~~ ~~~~MR6 MR9 MR10 | , = Congested +----:-----------------:--------------:-------:----+ MANET Link : : : : : : : : +-+-+ +-+-+ | H | * * * * * * * * * * * * * * * * | H | +---+ +---+ Figure 16: Congested link in MANET In (Nested) NEMO, low bandwidth paths to scarce exit routers can become congested, also caused by local traffic. Unoptimized tree topologies can also introduce congestion. Boot Expires December 28, 2007 [Page 24] Internet-Draft Analysis of MANET and NEMO June 2007 <----------------------------------------------------> < > < Fixed Infrastructure HA > < CN > < ::::::::::R:::::::::::::::::::R:::::: > < R ER R > <------#--------------------#--------------#---------> # # # ; # # <-----;--------------------#--------------#--------> < ; Nested # # > < ; NEMO # ER7 > < ER1. # : > < : .. MR2 : > < MR3 : MR8 > < : ...MR4 : :. > < MR5 :....MR6 MR9 MR10 > ; = Congested <----:-----------------:--------------:--------:---> Nested NEMO : : : : Link : : : : +-+-+ +-+-+ | H | * * * * * * * * * * * * * * * * | H | +---+ +---+ Figure 17: Congested link in Nested NEMO In wireless infrastructures, using bandwidth efficiently is a primary concern. Advanced QoS mechanisms are needed, utilizing radio interface characteristics. Call admission control mechanisms like RSVP should be considered, especially for real-time traffic. Attention is required for bridging layer-2 devices, where the router and the layer-2 device are linked with a high speed interface. Flow control and layer-2 metric transfer between router and the layer-2 device as described in "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics" [33] can solve introduced problems. Also attention is required for an ad-hoc dense crowd of nodes requiring lots of bandwidth. In such a scenario, available transmission means will be overloaded. 6.5. MANET and NEMO at home problem In MIP, a Mobile Node is at home when it is connected to the Home Link. For wireless nodes in the home region, a MANET protocol could be used for extending the home link, using the HA as exit router. Boot Expires December 28, 2007 [Page 25] Internet-Draft Analysis of MANET and NEMO June 2007 This introduces a problem, the node could be classified as "at home" because it can reach any CN using the MANET and its own HA as exit router, but it is also "far form home" because it is not on the home link, in the meaning that it does not receive HA RA with the Home Agent Information Option. <---------------------------------------> < CN > < Fixed Infrastructure > < > < HA > <------------------#----|---------------> # | ~ | +---------------~----|-------+ | MANET ~ | | | and ~ | HAIO received by MR1, not by MR2 | Nested MR1 V | | NEMO ~ | | ~ | | MR2 | +----------------------------+ Figure 18: MANET and NEMO at home detection MR1 receives the HA RA with HAIO, thus MR1 is at home. MR2 is not receiving the HAIO and is thus far from home. But MR2 is able to communicate with the fixed infrastructure using MANET routing and the HA acting as MANET Border Router. Another problem is introduced when the MANET protocol is used on the NEMO tunnel. This introduces a routing shortcut, the native MANET route is in parallel with the MANET route via the NEMO tunnel. The next hop to the HA and thus to the NEMO tunnel endpoint could be learned through the tunnel, this introduces tunnel interface instability. Boot Expires December 28, 2007 [Page 26] Internet-Draft Analysis of MANET and NEMO June 2007 <---------------------------------------> < CN > < Fixed Infrastructure > < > < ^ ^ HA > <-----------------|--|---#--------------> | | # n t ~ +--------------a--u---~----------+ | MANET t n ~ | | and i n ~ | | Nested v e MR1 | | NEMO e l ~ | | | | ~ | | v v MR2 | +--------------------------------+ Figure 19: MANET and NEMO at home routing shortcut The impact of the MANET and NEMO at home routing shortcut problem is to be analyzed. Problem areas are tunnel instability and multicast packets sent to HA via MANET and the tunnel. 6.6. MANET scale to infinity problem when peering to strangers In a dense deployment of MANET routers, all configured for roaming in a large area and peering to all other routers, the MANET will melt down due to flooding topology information from any to all. A sample scenario is car to car communication in a metropolis with say a million cars. Current IETF MANET protocols provide a flat routing domain, where reachability is provided between ALL MANET routers. In a chain of MANET routers, where each router has two neighbors (or one neighbor on the end routers), there is no problem with neighbor discovery or 2-hop neighbor state maintenance. But prefix flooding (proactive routing) or route requests (reactive routing) are flooded over all routers in the MANET. This problem occurs independent of the existence of a fixed backbone infrastructure. +------+ +------+ +------+ +------+ +------+ +------+ | MNR1 |~~~| MNR2 |~~~| MNR3 |~~<> ~| MNRx |~~~| MNRy |~~~| MNRz | +------+ +------+ +------+ +------+ +------+ +------+ Boot Expires December 28, 2007 [Page 27] Internet-Draft Analysis of MANET and NEMO June 2007 Figure 20: Infinite chain of MANET routers Some would suggest MANETs can be designed for using hierarchy. Current IETF MANET protocols do not support such. Others would suggest automatic hierarchy can be added in future extensions on the basic protocol. There is no evidence that options for such are realistic. Boot Expires December 28, 2007 [Page 28] Internet-Draft Analysis of MANET and NEMO June 2007 7. IANA considerations This document does not require any IANA action. 8. Security Considerations This document does not create any security threat. It discusses and analyses the concepts of MANET and NEMO. 9. Acknowledgments I would like to thank all the people involved in MANET and NEMO technology. I would particularly like to thank (in alphabetical order) people involved in MANEMO: Jari Arkko, Thomas Clausen, Ian Chakeres, Ben McCarthy, Alexandru Petrescu, Pascal Thubert, Ryuji Wakikawa and all that I forgot. 10. References 10.1. Normative reference 10.2. Informative Reference [1] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [2] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-chakeres-manet-arch-01 (work in progress), October 2006. [3] Clausen, T., "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. [4] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-09 (work in progress), May 2007. [5] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-04 (work in progress), March 2007. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. Boot Expires December 28, 2007 [Page 29] Internet-Draft Analysis of MANET and NEMO June 2007 [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [9] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [10] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03 (work in progress), September 2006. [11] Ng, C., "Network Mobility Route Optimization Solution Space Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in progress), September 2006. [12] Clausen, T., "NEMO Route Optimisation Problem Statement", draft-clausen-nemo-ro-problem-statement-01 (work in progress), March 2007. [13] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [14] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [15] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [16] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [17] Thubert, P., "Global HA to HA protocol", draft-thubert-nemo-global-haha-02 (work in progress), September 2006. [18] Devarapalli, V., "Local HA to HA protocol", draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), March 2006. [19] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [20] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. [21] Wakikawa, R., "MANEMO Problem Statement", Boot Expires December 28, 2007 [Page 30] Internet-Draft Analysis of MANET and NEMO June 2007 draft-wakikawa-manemo-problem-statement-00 (work in progress), February 2007. [22] Wakikawa, R., "MANEMO Architecture", draft-wakikawa-manemoarch-00 (work in progress), June 2007. [23] Thubert, P., "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-05 (work in progress), April 2007. [24] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-07 (work in progress), February 2007. [25] Thubert, P., "Network In Node Advertisement", draft-thubert-nina-00 (work in progress), February 2007. [26] Petrescu, A. and C. Janneteau, "The NANO Draft (Scene Scenario for Mobile Routers and MNP in RA)", draft-petrescu-manemo-nano-00 (work in progress), March 2007. [27] Clausen, T., "A MANET Architecture Model", Rapport de Recherche, Technical Report, INRIA Institut National de Recherche en Informatique et en Automatique, ISSN 0249- 6399 RR_MANET_Architectural_Model.pdf, March 2007. [28] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS Flooding", draft-ogier-manet-ospf-extension-09 (work in progress), March 2007. [29] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in progress), January 2007. [30] Templin, F., "Observations on "Link" in MANET/Autoconf and Other Contexts", draft-templin-manet-autoconf-link-00 (work in progress), August 2006. [31] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-03 (work in progress), May 2007. [32] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD- Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in progress), April 2004. [33] Berry, B. and H. Holgate, "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", draft-bberry-pppoe-credit-06 (work in progress), November 2006. Boot Expires December 28, 2007 [Page 31] Internet-Draft Analysis of MANET and NEMO June 2007 Appendix A. Change Log A.1. Changes from version 00 to 01 Added MANET and Fringe Stub models sections. Added Routing Loop problem in proactive protocols. Added Break Before Make problem. Added Congested Link problem. Added MANET and NEMO at home problem. Added MANET scale to infinity problem when peering to strangers. Author's Address Teco Boot Infinity Networks B.V. Elperstraat 4 Schoonloo 9443TL Netherlands Email: teco@inf-net.nl Boot Expires December 28, 2007 [Page 32] Internet-Draft Analysis of MANET and NEMO June 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). Boot Expires December 28, 2007 [Page 33]