Mobile Networks BOF Timothy J. Kniveton Internet Draft Nokia Expires: August 2002 Alper E. Yegin Informational: February 2002 DoCoMo USA Labs Problem Scope and Requirements for Mobile Networks Working Group draft-kniveton-monet-requirements-00.txt Status of This Memo This document is a submission by the MONET Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the monet@nal.motlabs.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document suggests problem scope definitions and possible domain requirements for a proposed Mobile Networks working group. The recommendations made in this draft result from the discussions of the Mobile IP mailing list, the MONET mailing list, and an open meeting of interested parties which occured at IETF52 in Salt Lake City. Kniveton, Yegin Expires August 2002 [Page 1] Internet Draft MONET Scope and Requirements February 2002 Contents Status of This Memo 1 Abstract 1 1. Introduction 2 2. Terms 3 3. Goals and Problem Scope 4 4. Non-goals and Excluded Scope 4 5. Protocols 5 6. Network Architecture 6 7. Security Considerations 7 8. Intellectual Property Right Considerations 7 9. Acknowledgements 7 Authors' Addresses 8 Full Copyright Statement 9 1. Introduction This document describes problem scope boundaries and solution requirements for enabling subnet mobility within an IP network. This document is considered to be a contribution toward defining the potential work of a Mobile Networks (MONET) working group, based on the outcomes of discussions on the MONET mailing list, the Mobile IP mailing list, and at an open meeting of people interested in the mobile network problem domain which occurred in December 2001 at IETF52 in Salt Lake City. The ideas presented in this work may also be complimented by other efforts to define problem scope and solution requirements for this group, which have been described in MONET internet-drafts [9, 5]. Kniveton, Yegin Expires August 2002 [Page 2] Internet Draft MONET Scope and Requirements February 2002 2. Terms The terminology defined in Network Mobility Support in IPv6 [4], and that of IPv6 [2] and Mobile IPv6 [6] forms the basis for discussion about mobile networks (and the mobile routers which enable them). One change is noted in this terminology: for the purposes of discussing the mobile network problem domain, no distincion is made between Visiting or Local nodes within the mobile network. Visiting Mobile Nodes and Local Mobile Nodes are simply considered Mobile Nodes as defined in Mobile IP, and Local Fixed Nodes are simply considered Fixed Nodes, with their addresses allocated on the mobile network. The key words "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 [1]. In addition, this document uses the following terms: Fixed Host A host not capable moving from its home link to other links. A fixed node is capable of sending and receiving packets, that is, being a source or destination of traffic, but not a forwarder of it. Fixed Router A router not capable of moving from its home link to other links. A Fixed Router does not move with respect to the mobile network, but moves with respect to the fixed network, following the mobile network's movements, but mobility is taken care of by a mobile router in the same network as this fixed router. Mobile Host A host which communicates from the mobile network (which may or may not be its home link), but can also enter and leave the mobile network. Mobile Router A router which moves from its home link to other links. A mobile router is capable of forwarding packets between two or more interfaces, with one being the Internet, and the other link being the mobile network(s) that move with the mobile router. The mobile router must be aware of network mobility and must handle aspects of mobility management for the other nodes in the mobile network. Kniveton, Yegin Expires August 2002 [Page 3] Internet Draft MONET Scope and Requirements February 2002 Mobile Network A network whose point of attachment to the Internet can change. A mobile network is a collection of one or more mobile routers with possibly a number of fixed and mobile routers, and fixed and mobile nodes behind them. 3. Goals and Problem Scope The primary goal of the MONET work should be to support a technical solution which allows mobile network nodes (MNNs), to remain connected to the Internet and continuously reachable at all times while the mobile network they are attached to changes point of attachment. MNNs are both fixed (keeping the same address on the mobile network at all times), and mobile (entering and leaving the mobile network as they roam with respect to it). Support for both fixed and mobile MNNs is within the scope of this work. Secondary goals of the work can be to investigate the effects of network mobility on various aspects of internet communication such as routing protocol changes, implications of realtime traffic and fast handovers, optimizations. These should all support the primary goal of reachability for mobile network nodes. The MONET group is part of the IETF, and as such should be motivated by standardization work. Although mobile networks bring up many interesting research questions, these are only within the scope of this group insofar as they lead directly toward implementable solutions. Any further research topics should be offered to the IRTF Micromobility Design Team for additional review. Security is an important consideration, and efforts should be made to use existing solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges, such as securing route update information when a network changes points of attachment. These can be considered, as long as they do not conflict with the prior paragraph about research. 4. Non-goals and Excluded Scope The following goals are excluded: - host mobility. This is the problem domain of Mobile IP. - administration of the network - address assignment of hosts and links Kniveton, Yegin Expires August 2002 [Page 4] Internet Draft MONET Scope and Requirements February 2002 - network architectures - solutions for service discovery. These should be handled by traditional service discovery mechanisms 5. Protocols Internet Protocol The mobile networks we discuss are communicating using the Internet Protocol. Due to the advantages for mobility of IP version 6, it is desirable to spend most effort initially on an IPv6-based solution. However, it is also important to investigate how mobile networks can be enabled under IPv4 [8] conditions. To address this issue, it is desirable to either create a solution that could be utilized by both IPv6 and IPv4 with minimal (or no) changes, or subsequently undertake steps to adapt the solution to IPv4 or if that is not possible, create a new IPv4-based solution. Mobile IP The efforts of the Mobile IP working group have resulted in the Mobile IPv4 [7] and Mobile IPv6 [6] protocols, which have already solved the issue of host mobility. Since challenges to enabling mobile networks are vastly reduced by this work, it is proposed that the work in this group will adopt the methods for host mobility used in Mobile IP, and extend them in the simplest way possible to achieve its goals. MONET should be able to co-exist and not interfere with other mobility management protocols, such as Mobile IPv4, Mobile IPv6, Fast Handovers for Mobile IPv6 [3] and Mobile IPv4. Addressing and Configuration This topic is central to communication within a mobile network, so the changes to addressing models are a top concern for work within this group. Multicast There is some interest in discussing implications to multicast within the Monet scope. Service Discovery Kniveton, Yegin Expires August 2002 [Page 5] Internet Draft MONET Scope and Requirements February 2002 It may hold true that service discovery protocols need some modification in this type of environment, but at this point it is generally believed that existing solutions may be able to run on top of a mobile network without change. 6. Network Architecture Nesting It should be possible to create topologies within a mobile network of smaller subnetworks, and possibly attach other mobile networks in that topology. Although it is not fully clear how many layers of topology must be supported, or the complexity requirements of those nested networks, the goal is to support arbitrary levels of recursive networks, and only in the case where this is impractical and protocol concerns preclude this support should the solution impose restrictions on nesting. Transit Networks For the purposes of this work, we make a distinction between Transit Networks and Stub Networks. A transit network is one in which data would be forwarded between two endpoints outside of the network, so that the network itself simply serves as a transitional conduit for packet forwarding. A stub network, on the other hand, does not serve as a data forwarding path. Data on a stub network is destined for an endpoint located on that network. In order to keep minimal complexity, transit networks are outside of the scope of this group. Effort will be applied to solving communication for MNNs within a stub network only. Multi-homing Mobile network nodes can have multiple IP interfaces, therefore be multi-homed. On each interface they can have a different role within the scope of MONET. A multi-homed node might have a fixed interface which is always attached to the same network, and a mobile interface which changes its point of attachment. Such a node would be a fixed host on the former interface, and a mobile host on the latter interface. MONET protocol must be able to handle such multi-homing (multi-role) cases. Route Optimization Using overlay networks by using Mobile IP and MONET can create sub-optimal routing among communicating entities. Protocols can have route optimizations to remedy this problem by enabling entities Kniveton, Yegin Expires August 2002 [Page 6] Internet Draft MONET Scope and Requirements February 2002 to communicate their locations to each other for the shortest path. Such methods are defined for Mobile IPv4 and Mobile IPv6. Route optimization is an aspect of efficient communication that should be taken into consideration within MONET. Protocol End-points A MONET protocol should be used at least by home agents and mobile routers. This is the minimum set of entities that need to implement this protocol to enable mobile networks. MONET should be transparent to fixed routers and fixed hosts, therefore no implementation on these entities is needed. For optional route optimizations, mobile hosts and correspondent nodes can implement protocol extensions to utilize shortest paths in their communications. 7. Security Considerations The protocol signaling must be secured. The receiver of the protocol signaling must be able to verify the authenticity and the authorization of the sender to change routing information for the host(s)/network indicated. Unauthenticated and unauthorized nodes' request to change routing should not be permitted by the network. This is a very similar to the security requirement of Mobile IP. The difference is that when this requirement is not satisfied, the consequences would only effect a single mobile node in the case of Mobile IP, whereas a whole subnet, of possibly unlimited size, would be affected in the case of MONET. As such, stronger security mechanisms should be required by MONET. 8. Intellectual Property Right Considerations 9. Acknowledgements References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] R. Coltun, D. Ferguson, and J. Moy. OSPF for IPv6. Request for comments (proposed standard), Internet Engineering Task Force, December 1999. Kniveton, Yegin Expires August 2002 [Page 7] Internet Draft MONET Scope and Requirements February 2002 [3] et al. Dommety, G. Fast handovers for mobile ipv6. Internet Draft, Internet Engineering Task Force, July 2001. [4] et al. Ernst, T. Mobile networks support in mobile ipv6. Internet Draft, Internet Engineering Task Force, June 2001. [5] T. Ernst, L. Hong-Yon, and C. Castelluccia. Network mobility support in ipv6: Problem statement and requirements. Internet Draft, Internet Engineering Task Force, July 2001. [6] D. Johnson and C. Perkins. Mobility support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force, November 1998. [7] C. Perkins. IP Mobility Support. Request for Comments (Proposed Standard) 2002, Internet Engineering Task Force, October 1996. [8] J. Postel. Internet Protocol. Request for Comments (Standard) 791, Internet Engineering Task Force, September 1981. [9] H. Soliman and M. Pettersson. Mobile networks (monet) problem statement and scope. Internet Draft, Internet Engineering Task Force, February 2002. Authors' Addresses Timothy J. Kniveton Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1 650 625-2025 EMail: Timothy.Kniveton@Nokia.com Fax: +1 650 625-2502 Alper E. Yegin DoCoMo Communications Labs USA 101 Metro Drive, Suite 300 San Jose, California 95110 USA Phone: +1 408 451-4743 EMail: alper@docomolabs-usa.com Fax: +1 408 573-1090 Kniveton, Yegin Expires August 2002 [Page 8] Internet Draft MONET Scope and Requirements February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Kniveton, Yegin Expires August 2002 [Page 9]