MANET and NEMO Working Groups T. Boot Internet-Draft Infinity Networks Expires: August 30, 2007 February 26, 2007 Analysis of MANET and NEMO draft-boot-manet-nemo-analysis-00.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 August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Boot Expires August 30, 2007 [Page 1] Internet-Draft Analysis of MANET and NEMO February 2007 Abstract This document provides an overview of MANET and NEMO characteristics. It is claimed that MANET suits small mobile network topologies, providing optimal paths for communication within a MANET cloud. It is also claimed that NEMO suits small, mobile networks, providing sub-optimal paths to all Internet connected nodes. MANET and NEMO technology shortcoming are described, to be addressed in the MANET and NEMO workgroups or elsewhere within the IETF. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. MANET and NEMO Characteristics . . . . . . . . . . . . . . . . 6 3.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. HA dependency . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Route optimization . . . . . . . . . . . . . . . . . . . . 7 3.5. Interface type . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Multicast support . . . . . . . . . . . . . . . . . . . . 8 3.7. Worst Path First Syndrome . . . . . . . . . . . . . . . . 8 4. MANET for NEMO . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative reference . . . . . . . . . . . . . . . . . . . 14 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 15 Appendix A. Change Log From Previous Version . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Boot Expires August 30, 2007 [Page 2] Internet-Draft Analysis of MANET and NEMO February 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) 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 [1] is a proactive MANET protocol populating the routing table independent of any user traffic; DYMO [2] is a reactive protocol, providing path information for traffic flows and SMF [3] 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 August 30, 2007 [Page 3] Internet-Draft Analysis of MANET and NEMO 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 RFC2119 [4] Readers are expected to be familiar with all the terms defined in RFC3753: Mobility Related Terminology [5] and the NEMO Terminology draft [6] MANET Mobile Ad-hoc NETworks [5] NEMO NEtork MObility [6] NEMO BS Network Mobility Basic Support Protocol [7] NEMO RO NEMO Route Optimization [8] / [9] / [20] MIP Mobile IP [6] MIP4 IP Mobility Support for IPv4 [10] MIP6 Mobility Support in IPv6 [11] OLSR Optimized Link-State Routing Protocol [1] DYMO Dynamic MANET On-demand Routing [2] Boot Expires August 30, 2007 [Page 4] Internet-Draft Analysis of MANET and NEMO February 2007 SMF Simplified Multicast Forwarding for MANET [3] OSPF Open Shortest Path First [12][13] MONAMI6 Mobile Nodes and Multiple Interfaces in IPv6 MIPSHOP Mobility for IP: Performance, Signaling and Handoff Optimization HAHA Global HA to HA protocol [14]; [15] MR Mobile Router [5] [6]; also referenced as "MANET Router"[16] HA Home Agent [6] CN Correspondent Node [6] LFN Local Fixed Node [6] RA Router Advertisement [17] Boot Expires August 30, 2007 [Page 5] Internet-Draft Analysis of MANET and NEMO February 2007 3. MANET and NEMO Characteristics 3.1. Scalability MANET and NEMO have very different scalability characteristics. MANET can provide optimized paths within a limited topology, where NEMO provides Internet scale end-to-end connectivity. 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 [16]. Other technology must be used to provide Internet scale deployment. The OSPF MANET extension [21], [22] 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. 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. 3.2. Mobility With MANET, a MR can roam within an area where sufficient coverage is available. When the number of MRs increase, coverage will improve or the area will be enlarged. Scalability issues restrict the number of MRs, which implies restrictions on mobility. Zoned or hierarchical models are proposed, but world wide mobility would not be provided by MANET. With NEMO, scalability is not an issue and worldwide mobility can be provided for an almost unlimited number of MR, all having end-to-end connectivity. For both MANET and NEMO, mobility is related to radio coverage. No coverage implies no connectivity. Wireless Bandwidth is a scarce resource, so an ad-hoc dense crowd of MR requiring lots of bandwidth will overload available transmission means. Mobility is thus also restricted by available bandwidth. Boot Expires August 30, 2007 [Page 6] Internet-Draft Analysis of MANET and NEMO February 2007 3.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) [14] / [15]. 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. 3.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 [7] 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) [8] 3.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 [18]. In Mobility Related Terminology [5], The Ingress and Egress Interface types are introduced. Terms are related to the NEMO mobile Router model [7]. 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 August 30, 2007 [Page 7] Internet-Draft Analysis of MANET and NEMO February 2007 in MANET there is no need for special handling, and in MANEMO any MR interface could be MANET enabled. For policy reasons, a MANEMO interface could be defined as Ingress only. 3.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 [3]. SMF use 2-hop neighbor state provided by another protocol (currently NHDP [19]) 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 [23]. 3.7. 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[16]. NEMO / nested NEMO do 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 Boot Expires August 30, 2007 [Page 8] Internet-Draft Analysis of MANET and NEMO February 2007 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%. +-----+ | MR1 | +-----+ 11Mbps / | loss / | <1% / | 1Mbps +-+-+ | loss ~50% |MR2| | +-+-+ | 11Mbps \ | loss \ | <1% \ | +-+-+ |MR3| +---+ Figure 1: Worst Path First Syndrome Network Topology MR3 can select MR1 or MR2 as attachment router, router advertisements from both MR1 and MR2 are received. A MANET protocol, selecting a path based on hop-count, selects the direct path to MR1. NEMO would select MR1 or MR2, as it has no knowledge of the topology. Selecting the direct path to MR1 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 MR1 would require more retransmissions if reliable data transfer is supported. In a heterogeneous topology, the problem becomes totally unacceptable. Imagine that the three MRs are temporally "on the pause" and MR2 and MR3 are near to each other. Because MR3 has bad user experience, it can be serviced by using cabling to MR2 and the bandwidth is increased to 100Mbps and the packet loss is zero. Still, user experience is not enhanced at all, and MR1 would be selected. Finding solutions for this problem is out of scope of this document. But state of the art MANET protocols, including MANEMO if this work- Boot Expires August 30, 2007 [Page 9] Internet-Draft Analysis of MANET and NEMO February 2007 in-progress is continued, shall select optimized paths based on cross layer metrics. Boot Expires August 30, 2007 [Page 10] Internet-Draft Analysis of MANET and NEMO February 2007 4. MANET for NEMO A MANEMO design team is working on a MANET for NEMO. This MANET protocol is used as an enhancement on NEMO, solving problems with nested NEMO. It also introduces scalability in MANET as it introduces a new hierarchical layer by using Mobile IP / NEMO. MANEMO can be used where fixed infrastructures are partly available and where local communication between MRs is a basic requirement. Also multicast support and usage of cross-layer metrics is in scope for MANEMO. The MANEMO protocol is introduced in the MANEMO Problem Statement document [24]. Boot Expires August 30, 2007 [Page 11] Internet-Draft Analysis of MANET and NEMO February 2007 5. IANA considerations This document does not require any IANA action. Boot Expires August 30, 2007 [Page 12] Internet-Draft Analysis of MANET and NEMO February 2007 6. Security Considerations This document does not create any security threat. It discusses and analyses the concepts of MANET and NEMO. Boot Expires August 30, 2007 [Page 13] Internet-Draft Analysis of MANET and NEMO February 2007 7. Acknowledgments I would like to thank all the people involved in MANET and NEMO technology. 8. References 8.1. Normative reference [1] Clausen, T., "The Optimized Link-State Routing Protocol version 2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006. [2] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-06 (work in progress), October 2006. [3] Macker, J., "Simplified Multicast Forwarding for MANET", draft-ietf-manet-smf-03 (work in progress), October 2006. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [7] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [8] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03 (work in progress), September 2006. [9] Ng, C., "Network Mobility Route Optimization Solution Space Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in progress), September 2006. [10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Boot Expires August 30, 2007 [Page 14] Internet-Draft Analysis of MANET and NEMO February 2007 [12] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [13] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [14] Thubert, P., "Global HA to HA protocol", draft-thubert-nemo-global-haha-02 (work in progress), September 2006. [15] Devarapalli, V., "Local HA to HA protocol", draft-devarapalli-mip6-nemo-local-haha-01 (work in progress), March 2006. [16] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-chakeres-manet-arch-01 (work in progress), October 2006. [17] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [18] Templin, F., "Observations on "Link" in MANET/Autoconf and Other Contexts", draft-templin-manet-autoconf-link-00 (work in progress), August 2006. [19] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-00 (work in progress), June 2006. 8.2. Informative Reference [20] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route Optimisation Problem Statement", draft-clausen-nemo-ro-problem-statement-00 (work in progress), October 2004. [21] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS Flooding", draft-ogier-manet-ospf-extension-08 (work in progress), October 2006. [22] 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. [23] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD- Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in progress), April 2004. [24] Wakikawa, R. and P. Thubert, "MANEMO Problem Statement", draft-wakikawa-manemo-problem-statement-00 (work in progress), February 2007. Boot Expires August 30, 2007 [Page 15] Internet-Draft Analysis of MANET and NEMO February 2007 Appendix A. Change Log From Previous Version o Initial Documentation Author's Address Teco Boot Infinity Networks B.V. Elperstraat 4 Schoonloo 9443TL Netherlands Phone: +31 592 50 12 66 Email: teco@inf-net.nl Boot Expires August 30, 2007 [Page 16] Internet-Draft Analysis of MANET and NEMO 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). Boot Expires August 30, 2007 [Page 17]