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

Versions: 00

IETF INTERNET-DRAFT                        Thierry Ernst, WIDE and INRIA
                                                            October 2002

                "Network Mobility Support Requirements"
                  draft-ernst-nemo-requirements-00.txt



Status of This Memo

   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

   The purpose of traditional mobility support is to provide continuous
   Internet connectivity to mobile hosts only (host mobility support).
   In contrast, network mobility support (NEMO support) deals with
   situations where an entire network changes its point of attachment to
   the Internet and thus its reachability in the topology. In this
   situation, mobility support is to provide continuous Internet
   sessions not only to the router connecting the mobile network to the
   global Internet, but also to nodes behind the mobile router. This
   document tries to identify what constraints limit the implementation
   and the deployment of a potentially and ideally good solution, and
   what requirements solutions must comply with. Our main aim is to
   raise the discussion on the mailing list.









Ernst                       Expires May 2003                    [Page 1]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


                                 Contents

   Status of This Memo

   Abstract

   1. Introduction
   2. Overview
      2.1. Potential Configurations
      2.2. Observations and Constraints
           O1: Structure of the mobile network
           O2: Mobile Router is a transit point
           O3: Dog-leg Routing
           O4: Ad-Hoc Network
           O5: Scalability
           O6: Deployment and Backward Compatibility
           O7: Routers in the Mobile Network
           O8: Addressing Constraints
   3. High-Level Requirements
      3.1. Migration Transparency
      3.2. Operational Transparency
      3.3. Performance Transparency (Seamless Mobility)
      3.4. Layers Independence
      3.5. NEMO Support Transparency for MNNs
      3.7. Minimum Signaling Overload
      3.12. No impact on CNs or Internet routing
      3.13. Security
         3.13.1. Confidentiality
         3.13.2. Authentication
         3.13.3. Authorization
         3.13.4. Location Privacy
      3.14. Access Control
         3.14.1. Access Control for VMNs
         3.14.2. Access Control Architecture
         3.14.3. Access Control in the Fixed Network
      3.15. Internet-wide Mobility
      3.16. Unified Solution
      3.17. Mobile CNs
      3.18. Addressing Constraints
   4. Basic Support Requirements
   5. Extended Support Requirements

   Acknowledgments

   References

   Author's Addresses




Ernst                       Expires May 2003                    [Page 2]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


 1. Introduction

   Traditional work on mobility support is to provide continuous
   Internet connectivity to mobile hosts only (host mobility support).
   In contrast, network mobility support (NEMO support) deals with
   situations where an entire network changes its point of attachment to
   the Internet and thus its reachability in the topology. In this
   situation, mobility support is to provide continuous Internet
   sessions not only to the router connecting the mobile network to the
   global Internet, but also to nodes behind the mobile router.

   The purpose of the present document is to raise discussion in order
   to identify what constraints limit the implementation and the
   deployment of a potentially and ideally good solution, and what
   requirements solutions must comply to. Most constraints and
   requirements that we have listed are equally applicable to host
   mobility support and network mobility support. Some of them have been
   debated in the literature as far as host mobility support was
   concerned; we have extended this list to include those related to
   network mobility support. Other requirements are discussed in
   [REQUIREMENTS-1], [REQUIREMENTS-2}, [REQUIREMENTS-3] and
   [REQUIREMENTS-4].  All requirements may not be satisfied by a single
   solution. For the sake of modularity, we may decide to use separate
   solutions for different aspects of the problem space.  Note that most
   requirements discussed for host mobility support, like for instance
   in [Bhagwat96], [Myles93], [Castelluccia97], [Caceres96] or many
   other papers, are equally applicable to NEMO support. However, they
   must be extended and refined to meet the needs of NEMO support.

   We assume that the reader is familiar with the terminology defined in
   [TERMINOLOGY]. In order to understand the rationale that drives to
   the requirements, in section 2, we describe potential network
   mobility configurations and we make a number of observations that may
   constraint the forthcoming solutions. In section 3, we list some high
   level requirements. In section 4 and 5, the high-level requirements
   are refined in a more explicit manner for basic support and extended
   support. This list is not exhaustive and should be combined with the
   requirements found in the other drafts.













Ernst                       Expires May 2003                    [Page 3]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


 2. Overview

  2.1 Potential Configurations

      Network mobility support deals with entire networks of computers
      that change their point of attachment to the global Internet and
      need to maintain continuous Internet connectivity.

      Cases of mobile networks include networks attached to people
      (Personal Area Networks or PAN), and networks of sensors and
      access networks deployed in vehicles (aircrafts, boats, cars,
      trains, etc).

      A PAN may be connected to the Internet via a 802.11b WLAN (e.g.
      user in a shopping mall) and is likely to change its point of
      attachment very frequently, while an aircraft or a boat may be
      connected to the Internet via the same satellite link for a couple
      of hours. Some mobile networks may not move at all or may be kept
      in some sort of home network for a large amount of time

      In case mobile networks are access networks providing Internet
      access, IP devices carried by people (laptop, camera, mobile
      phone, etc) would get access to the Internet via the mobile
      network they are located in. In some cases, PANs may also be
      carried in the mobile network, in which case there are mobile
      networks visiting a larger mobile network. There is thus a need to
      achieve two levels of mobility: node mobility and network
      mobility.

      As people would by definition move from bus to train, thus from a
      mobile network to another, mobile nodes and mobile networks
      belonging to potentially different administrative domains would
      get attached to a mobile network.

      Since cases of mobile networks suck like trains, cars, aircrafts
      are themselves most likely to cross country boundaries, they are
      to move between topologically distant parts of the Internet thus
      between ISP boundaries.  A mobile network may attach to very
      distant parts of the Internet topology, provided it is granted
      access to it. In this situation, an Internet-wide mobility scheme,
      providing both intra-domain and inter-domain mobility, would be
      requested.

      The train example is particularly interesting because it shows we
      need to consider potentially large mobile networks containing
      hundreds of hosts and several routers. Since each mobile network
      node (MNN) may be communicating with a few correspondent nodes
      (CNs), the total number of CNs could be several times as large as



Ernst                       Expires May 2003                    [Page 4]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


      the number of MNNs and scale up to a few thousands. Not to say, a
      single server deployed in a vehicle may itself have thousands of
      CNs, or even more. Moreover, whatever the situation, CNs are also
      most likely to be sparsely distributed in the Internet.

      From the above scenarios, at least the following configurations of
      mobile networks seem to be desirable:

      - mobile networks of any size, ranging from a sole subnet with a
      few IP devices to a collection of subnets with hundreds of IP
      devices.

      - mobile networks with a potentially large number of correspondent
      nodes, sparsely distributed in different administrative domains,

      - simultaneous access to the Internet provided via distinct
      (likely wireless),

      - distinct cases of mobile networks moving with distinct mobility
      frequencies,

      - mobile networks displaced within a domain boundary (intra-domain
      mobility) or between domain boundaries (inter-domain mobility),

      - foreign mobile nodes that attach to the mobile network,

      - nodes that change their point of attachment within the mobile
      network,

      - nested mobile networks

  2.2. Observations and Constraints

      In order to drive the discussion on the requirements, this section
      lists a number of observations that may constraint or limit the
      deployment of a solution which looks potentially good on the
      paper.

  O1: Structure of the mobile network

      A MR changing its point of attachment does not **cause** the MNNs
      behind the MR to change their own physical point of attachment.
      MNNs MAY appear to move from the point of view of an observer in
      the Internet, but their point of attachment in the mobile network
      is not modified as a **result** of the mobile network changing its
      own point of attachment. In most cases, the internal structure of
      the mobile network will in effect be relatively stable (no dynamic
      change of the topology), but this is not a general assumption (see



Ernst                       Expires May 2003                    [Page 5]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


      section "Ad-hoc networks")

  O2: Mobile Router is a transit point

      All packets sent between MNNs and a CN outside the mobile network
      necessarily transit through one of the MRs of the mobile network.
      In the case of nested mobility, packets transit through the root-
      NEMO, thus through one of the TLMRs.

  O3: Dog-leg Routing

      As a result of mobility, routing between a CN in the global
      Internet and a mobile node may not be optimal. Packets usually
      transit via the home link of the mobile node if no routing
      optimization is explicitly performed. In network mobility,
      multiple dog-leg routing may be introduced by nested mobility. In
      this case, packets intended to a VMN may first transit by the
      VMN's home link, then being rerouted to the MR's home link.

      Non-optimal routing increases bandwidth consumption and
      transmission delays. The amount of traffic intended for the mobile
      network is understandably more significant than in the case of a
      single mobile node (see section "scalability"), then non-optimal
      routing is to be considered with more care than for host mobility
      support. However, efficient routing is usually performed at the
      expense of increased signaling.  Thus, the gain of optimal routing
      has to be balanced against the incurred signaling cost.

  O4: Ad-Hoc Network

      A mobile network as defined in the IETF NEMO Working Group is not
      to be confused with an Ad-hoc network as defined in the IETF MANET
      Working Group.

      In the MANET WG, an ad-hoc network is an autonomous system made of
      mobile nodes (i.e. routers) connected by wireless links. The
      routers are free to move randomly and to organize themselves
      arbitrary. Topologies are highly dynamic and there is no fixed
      infrastructure. Solutions produced by the MANET WG aim at
      maintaining routes between highly dynamic nodes. The MANET WG is
      also considering how to provide Internet access to the mobile
      nodes in the ad-hoc network, but the gateway between the ad-hoc
      network and the Internet does not change its point of attachment,
      so the MANET WG is not concerned with the mobility management of
      an entire network changing its point of attachment.

      In the NEMO WG, some routers may effectively move arbitrary, but
      this is not a common case. NEMO aims at providing Internet



Ernst                       Expires May 2003                    [Page 6]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


      reachability to nodes in the mobile network and at maintaining
      session continuity after the mobile network has changed its point
      of attachment in the topology.

      Thus, the NEMO WG and the MANET WG do not have the same
      objectives.  However, an Ad-hoc network which gateways to the
      Internet would change their point of attachment is likely to be
      considered as a special instance of a mobile network and would
      thus rely on NEMO solutions to manage the change of the point of
      attachment, while routing within the mobile network is only to be
      considered by MANET.

  O5: Scalability

      Scalability has always been considered in the design of new
      protocols. This particularly includes signaling load and memory
      consumption which must thus be minimized.

      For single hosts, host mobility support had to take into
      consideration a growing number of mobile hosts and should even
      assume that a major part of the nodes composing the Internet would
      be mobile in the near future. Thus, it has to scale to an
      important number of mobile nodes.

      The scalability parameters in NEMO support differ from host
      mobility. NEMO support has to scale to:

         o a large number of mobile networks (e.g. each vehicle, each
         person carrying a PAN)

         o a large mobile networks comprising several subnetworks and a
         large number of MNNs on each subnetwork (e.g. a train)

         o the number of CNs, which is somewhat a function of the size
         of the mobile network; the more MNNs a mobile network has, the
         more CNs the mobile network is most likely to have. (e.g. each
         MNN in a train communicating with a few CNs)

  O6: Deployment and Backward Compatibility

      In IPv4, minimizing the impact on the already deployed
      infrastructure was an important issue since it was not possible to
      require all hosts to implement new features. On the other hand, in
      IPv6, an important number of specifications has for sure already
      been defined, but IPv6 deployment is only dawning, so, it's
      theoretically still possible to impose new capabilities on all
      hosts.  However, it is not desirable. The rule of thumb for any
      new protocol is to make use of the existing ones whenever



Ernst                       Expires May 2003                    [Page 7]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


      possible, to require no changes on them, and to impose extensions
      only when necessary.

      The solution for NEMO support must thus be backward compatible
      with all existing IPv6 standards. If necessary, it will have to
      provide the necessary extensions to maintain backward
      compatibility with existing protocols. So, for instance:

         o Mobile IPv6: host mobility support in IPv6 is achieved by
         Mobile IPv6. NEMO support MUST not prevent the proper operation
         of Mobile IPv6.

         o IGMP (Mutlticast group membership): any IPv6 router is
         supposed to allow hosts on its attached subnetworks to
         participate in multicast sessions. Group membership is gathered
         by the IGMP protocol.

      It is also desirable to minimize infrastructure installation costs
      and complexity. So, the solution cannot be orthogonally different.

  O7: Routers in the Mobile Network

      All routers in the Internet are considered to run a number of
      protocols such as a routing protocol, Neighbor Discovery, ICMP,
      and others. This seems also to apply to routers deployed in mobile
      networks, but we have to figure out to what extend, and how.

  O8: Addressing Constraints

      The IP address is used for routing and to identify the subnetwork
      where an interface is attached to. Each interface on a subnetwork
      must therefore be configured with the network prefix of that
      subnetwork.


 3. High Level Requirements

   This section details a number of high level requirements that should
   be met by the solutions.

  3.1. Migration Transparency

      In order to provide migration transparency, a permanent and
      continuous Internet connectivity must be provided to all MNNs,
      without disruption of service. MNNs must always be reachable
      regardless of the point of attachment of the MR, and sessions must
      be maintained after the MR has changed its point of attachment.




Ernst                       Expires May 2003                    [Page 8]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


  3.2. Operational Transparency

      In order to be transparent to the applications and the users, NEMO
      support must be performed at the network layer.

  3.3. Performance Transparency (Seamless Mobility)

      NEMO support SHOULD exhibit low latency, incur little or no data
      loss, minimum delays, minimum signaling load, and minimum
      bandwidth consumption for packet delivery. It should be performed
      as seamlessly as host mobility is supported (no abrupt degradation
      of service).

  3.4. Layers Independence

      Handover of IP sessions is performed at the network layer. With
      respect to the layer separation of the Internet protocol suite,
      handover MUST be managed at the network layer only and
      transparently to upper layers, despite the migration of the mobile
      network in the network topology. Therefore, a change of
      topological location MUST not have an impact on layers above the
      network layer other than a transient loss of performance, as
      depicted in the above paragraph. If this is respected,
      compatibility with existing transport and application layers is
      maintained. In practice, the identifiers used at the transport
      layer should be independent from the physical IP addresses used at
      the network layer for routing. If upper layer protocols require a
      location independent and invariant identifier, the network layer
      MUST provide it with an identifier irrespective of the actual
      topological location.

  3.5. NEMO Support Transparency for MNNs

      In section "observation O1", we have seen that "MNNs don't change
      their own point of attachment as a result of the mobile network's
      displacement in the Internet topology. NEMO support SHOULD
      therefore be performed transparently to MNNs and keep them away
      from participating in NEMO support. Although MNNs may encounter
      variable delays of transmission and loss with their respective CNs
      as the network is moving. This is not considered a lack of
      transparency.  However, receiving movement information may be
      useful to hosts able to understand it, so this could be allowed as
      an option, and LMNs and VMNs, which are able to change their own
      point of attachment must manage their own mobility.

  3.7. Minimum Signaling Overload

      Mobility management is usually performed at the cost of control



Ernst                       Expires May 2003                    [Page 9]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


      traffic. In order to be scalable, NEMO support MUST minimize this
      control traffic.

  3.12. No impact on CN or Internet routing

      Session continuity between a MNN and arbitrary CNs anywhere in the
      Internet SHOULD NOT assume any changes to existing CNs or the
      Internet routing architecture. On the other hand, optimizations
      for performance enhancement MAY involve some changes to CNs,
      provided that such optimizations would not cause any disruption to
      ongoing sessions, if not supported by CNs (i.e. backward
      compatible).  [THIS IS TO BE DISCUSSED (in light of the
      observation made in section "Minimum Impact on the Existing
      Protocols and Infrastructure" here above) BECAUSE IT WOULD PREVENT
      POTENTIALLY INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED].

  3.13. Security

      NEMO support must comply with usual IPv6 security policies and
      standardized protocols. In addition, and unlike fixed nodes, MNNs
      are more exposed to security threats, particularly identity
      usurpation. NEMO support must provide MNNs and their CNs with at
      least as good security as for fixed nodes and mobile hosts. It
      particularly shouldn't leave more room for intruders to usurp an
      identify nor to perpetrate any kind of attack against the MNNs nor
      the CNs. In practice, all control messages required by NEMO
      support must be exchanged in a secure manner and must ensure the
      following:

   3.13.1. Confidentiality

         All control messages transmitted in the network MUST  ensure
         MNNs' confidentiality. Only the recipient of the control
         message may be able to decrypt the content of the datagram.

   3.13.2. Authentication

         All control messages MUST be authenticated by recipients in
         order to prevent intruders to usurp the identity of a MNN.

   3.13.3. Authorization

         The recipient of a control message MUST ensure that the sender
         is effectively authorized to perform the mobility support
         operation indicated in the control message.

   3.13.4. Location Privacy




Ernst                       Expires May 2003                   [Page 10]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


         NEMO support may provide means for MNNs to hide their location
         to any third party. It shouldn't be possible to determine the
         succession of topological location of a mobile network or a
         particular MNN by monitoring the exchange of control messages.
         In practice, MNNs may wish to hide their location to some or
         all of their CNs, or anyone else but the CNs. It may also be
         desirable to hide the location of the entire mobile network to
         all CNs without discrimination between MNNs.

  3.14. Access Control

   3.14.1. Access Control for VMNs

      Mobile Networks MUST be able to authenticate and authorize VMNs to
      gain access to the Internet via the mobile network infrastructure
      (MRs).

   3.14.2. Access Control Architecture

      To be able to comply with the current access control mechanisms
      and achieve a scalable solution, the final solution MUST NOT
      assume that the fixed network would authenticate VMNs. VMN
      authentication and authorization MUST be the responsibility of the
      mobile network.

   3.14.3. Access Control in the Fixed Network

      AAA solutions MUST allow for authenticating an entire network.
      This MAY simply be done by ensuring that the Authentication and
      Authorization is not necessarily performed for a single IP
      address. This is particularly important for IPv6 as each node may
      configure multiple addresses.

  3.15. Internet-wide mobility

      In order to ensure permanent and uninterrupted Internet-wide
      mobility, mobile network should be able to roam between access
      networks belonging to distinct ISPs and corporate networks
      (distinct administrative domains, i.e. inter-domain mobility) and
      via any available access technology (distinct technologies:802.11b
      WLAN, Bluetooth, satellite link, GSM, i.e. heterogeneous
      mobility). Indeed, nothing but administrative and security
      policies should prevent a mobile network to attach anywhere in the
      Internet topology. So, the solution must technically allow this
      kind of scenario. In addition, NEMO support must also accommodate
      to CNs deployed in distinct administrative domains.

  3.16. Unified Solution



Ernst                       Expires May 2003                   [Page 11]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


      Should different schemes be proposed, a unified mobility support
      scheme is required. A situation where distinct NEMO support
      schemes are deployed and unable to inter-operate with each other
      must be avoided.

  3.17. Mobile CNs

      NEMO support MUST be optimized to handle the case where the CN is
      MIPv6-enabled and/or itself located in a mobile network
      (particularly if it is a VMN). It must perform efficiently in both
      cases.

 4. Requirements for Basic Support

   In this section, the high-level requirements are refined in a more
   explicit manner for basic support. This list is not exhaustive and
   should be combined with the requirements found in the other drafts.
   Requirements follow from our observations and high-level requirements
   in section 2 and 3.

   Basic support is to maintain session continuity between nodes in the
   mobile network and nodes in the global Internet. The solution will
   have to meet the following requirements [TO BE DISCUSSED ON THE LIST
   - THIS IS A PROPOSITION - AT THAT POINT DON'T TAKE THINGS FOR
   GRANTED]:

   R1: The solution MUST provide permanent Internet connectivity and
       reachability to all nodes behind the MR

   R2: The solution MUST maintain continuous sessions between nodes
       behind the MR and arbitrary CNs after IP handover of the MR

   R3: All the potential configurations MUST be treated the same way
       (any number of subnets and MNN, nested mobile networks,
   multihomed
       mobile networks)

   R4: The solution MUST support LFNs, VMNs, and LMNs.

   R5: CNs and MNNs must comply with the requirements for IPv6 nodes
       defined in [IPv6-NODE]

   R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to
       MNNs)

   R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs)

   R8: A VMN that gets attached to a link within the mobile network



Ernst                       Expires May 2003                   [Page 12]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


       obtains an address on that link.

   R9: The solution MUST support nested mobile networks with any number
       of mobility levels

   R10: The solution MUST support multi-homed mobile network
        R10.1 : The solution MUST support mobile networks with multiple
        MRs

        R10.2:  The solution MUST support MR with multiple interfaces


   R11: The solution MUST NOT prevent the use of existing protocols

        R11.1: The solution MUST allow MNNs to operate the "CN
        functionality" of Mobile IPv6

        R11.2: The solution MUST support MIPv6-enabled VMNs and LMNs

        R11:3: The solution will ensure that mechanisms related to
        multi-homing
              (defined within other WGs in IETF) will be useful for
        NEMO"


   R12: The solution MUST support a large number of mobile networks

   R12: The solution MUST support a large number of CNs

   R13: The solution MUST support vertical handoff

   R14: The solution MUST support horizontal handoff

   R15: The solution SHOULD support fast handoff

   R16: The solution MUST support inter-domain mobility

   R17: The solution MUST support heterogeneous mobility

   R18: The solution MUST minimize control traffic


 5. Requirements for Extended Support

   In this section, the high-level requirements are refined in a more
   explicit manner for extended support. This list is not exhaustive and
   should be combined with the requirements found in the other drafts.




Ernst                       Expires May 2003                   [Page 13]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


   Extended support is to optimize routing between CNs and arbitrary
   MNNs and must support the following requirements (non exhaustive
   list, to be completed later)

   R1: The solution for Extended support must seat on top of Basic
   support.
       This means it must comply with the requirements defined under
       "Basic support" and co-exist with it without disturbing it or any
       of the nodes that do not need/understand it.

   R2: MNNs and CNs MAY be NEMO-enabled as a means to improve routing.
   As
       such be notified and take action upon the change of point of
       attachment of the MR.

   R3: The solution must preserve route aggregation in the Internet

   R4: The solution must minimize control traffic.

   RXXXX: To be continued. Many more to be added later.































Ernst                       Expires May 2003                   [Page 14]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


Acknowledgments

   The material presented in this document takes most of the text from
   our former internet-drafts submitted to MobileIP WG and to the former
   MONET BOF, co-authored with Hong-Yon Lach, which where themselves
   based on original text from [Ernst01]. The author would therefore
   like to thank both Motorola Labs Paris and INRIA (PLANETE team,
   Grenoble, France), for the opportunity to bring this topic to the
   IETF since 2000, and particularly Hong-Yon Lach (Motorola) and Claude
   Castelluccia (INRIA) for their advices, suggestions, and direction.
   We also acknowledge the contribution from Alexandru Petrescu
   (Motorola), Christophe Janneteau (Motorola), Hesham Soliman
   (Ericsson), Mattias Petterson (Ericsson) and Keisuke Uehara (Keio
   University). We are grateful to people in the InternetCAR team (Keio
   University) and all the people on the NEMO (formerly MONET) mailing
   list for their comments and suggestions on the NEMO ML which helped
   to improve this draft (Greg Daley, Pascal Thubert, James Kempf, TJ
   Kniveton, and other we may have forgot to include here)

References

   [Bhagwat96]      P. Bhagwat, S. Tripathi, and C. Perkins.
                    "Network Layer Mobility: an Architecture and Survey"
                    IEEE Personal Communications, 3(3):54, June 1996.

   [Caceres96]      R. Caceres and V.N. Padmanabhan.
                   "Fast and scalable handoffs for wireles
                    internetworks"
                    In Proc. of the Second ACM/IEEE MOBICOM,
                    New-York, USA, November 1996.

   [Castelluccia98] Claude Castelluccia.
                    "A Hierarchical Mobility Management Scheme for IPv6.
                    Third Symposium on Computers and Communications
   (ISCC'98),
                    Athens, Greece, June 1998.
                    http://www.inrialpes.fr/planete

   [Ernst01]        Thierry Ernst
                    "Network Mobility Support in IPv6", PhD Thesis,
                    University Joseph Fourier Grenoble, France.
                    October 2001. http://www.inria.fr/rrrt/tu-0714.html

   [IPv6-NODE]      John Loughney
                    "IPv6 Node Requirements"
                    draft-ietf-ipv6-node-requirements-01.txt
                    July 2002, Work in progress.




Ernst                       Expires May 2003                   [Page 15]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


   [MIPv6]          David B. Johnson and C. Perkins.
                    "Mobility Support in IPv6"
                    draft-ietf-mobileip-ipv6-18.txt,
                    July 2002. Work in progress.

   [Myles93]        Andrew Myles and David Skellern.
                   "Comparing Four IP Based Mobile Host Protocols"
                    In Joint- European Networking Conference.
                    Macquarie University, Sydney, Australia, May 1993.

   [PSBU]           T. Ernst et al.
                    "Mobile Networks Support in Mobile IPv6
                    (Prefix Scope Binding Updates)"
                    draft-ernst-mobileip-v6-network-03.txt,
                    March 2002. Work in progress

   [RFC1122]        R. Braden (editor).
                    "Requirements for Internet Hosts - Communication
                    Layers".  IETF RFC 1122, October 1989.

   [RFC2460]        S. Deering and R. Hinden.
                    "Internet Protocol Version 6 (IPv6) Specification"
                    IETF RFC 2460, December 1998.

   [REQUIREMENTS-1] Hesham Soliman
                    "Problem Scope",
                    Internet-Draft draft-soliman-monet-scope-00.txt,
                    February 2002. Expired

   [REQUIREMENTS-2] H.-Y. Lach, C. Janneteau, A. Petrescu
                    "Mobile Network Scenarios, Scope and Requirements",
                    draft-lach-nemo-requirements-00.txt,
                    October 2002.

   [REQUIREMENTS-3] T.J. Kniveton, A. Yegin
                    "Problem Scope and Requirements for Mobile Networks
                    Working Group"
                    draft-kniveton-monet-requirements.txt,
                    February 2002.  Expired

   [REQUIREMENTS-4] C. W. Ng, and T. Tanaka
              "Usage Scenario and Requirements for AAA in Network
              Mobility Support"
                    draft-ng-nemo-aaa-use-00.txt            October
   2002. Work in progress

   [TERMINOLOGY]    Thierry Ernst and Hong-Yon Lach
                    "Terminology for Network Mobility Support",



Ernst                       Expires May 2003                   [Page 16]


INTERNET-DRAFT    Network Mobility Support Requirements    February 2002


                    draft-ernst-nemo-terminology-00.txt,
                    October 2002. Work in progress.

Author's Addresses

    Questions about this document can be directed to the authors:


      Thierry Ernst,
      WIDE Project and INRIA
      Jun Murai lab. Faculty of Environmental Information,
      Keio University.
      5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan.
      Phone : +81-466-49-1100
      Fax   : +81-466-49-1395
      E-mail: ernst@sfc.wide.ad.jp
      Web: http://www.sfc.wide.ad.jp/~ernst/


































Ernst                       Expires May 2003                   [Page 17]


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