[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Mobile Networks BOF                                       T. J. Kniveton
Internet Draft                                                     Nokia
Expires:  May 1, 2003                                     Alper E. Yegin
Informational:  November 1, 2002                         DoCoMo USA Labs
   Problem Scope and Requirements for Network Mobility Working Group
                draft-kniveton-monet-requirements-01.txt


   Status of This Memo

   This document is a submission by the NEMO Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the nemo@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 proposed solutions which describe how to connect
   mobile routers within the scope of the Network Mobility working
   group.  The recommendations made in this draft result from the
   discussions of the Mobile IP mailing list, the NEMO mailing list, and
   past meetings of MONET and NEMO BOF sessions.














Kniveton, Yegin               Expires May 1, 2003               [Page 1]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 requirements specification work of the Network Mobility
   (NEMO) working group, based on the outcomes of discussions on the
   MONET/NEMO mailing list, the Mobile IP mailing list, and at past BOF
   meetings of this group which occurred IETF52, IETF53, and IETF54
   conferences.

   The ideas presented in this work are expected to be complimented by
   other efforts to define problem scope and solution requirements for
   this group, which have been described in NEMO internet-drafts [9, 5].






Kniveton, Yegin               Expires May 1, 2003               [Page 2]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 May 1, 2003               [Page 3]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 NEMO 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 NEMO 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 May 1, 2003               [Page 4]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 May 1, 2003               [Page 5]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 network mobility.  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.  A NEMO protocol must be able to handle such
   multi-homing (multi-role) cases.

   Route Optimization

   Using overlay networks by using Mobile IP and NEMO can create
   sub-optimal routing among communicating entities.  Protocols can
   have route optimizations to remedy this problem by enabling entities



Kniveton, Yegin               Expires May 1, 2003               [Page 6]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 NEMO.

   Protocol End-points

   A NEMO 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.

   NEMO 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 NEMO. As such, stronger security
   mechanisms should be required by NEMO.


   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 May 1, 2003               [Page 7]


Internet Draft Network Mobility Scope and Requirements  November 1, 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


        T. 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 May 1, 2003               [Page 8]


Internet Draft Network Mobility Scope and Requirements  November 1, 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 May 1, 2003               [Page 9]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/