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

Versions: 00 01

INTERNET-DRAFT                                     J. Loughney (Editor)
Internet Engineering Task Force                                   Nokia
                                                               D. Blair
                                                                  Cisco
                                           P. Hazy/H. Li/M. Jaseemuddin
                                                               G. Tardy
                                                                 Nortel
                                                        O. H. Levkowetz
                                                                   ABNW
                                                              J. Manner
                                                 University of Helsinki
                                                           P. Neumiller
                                                       3Com Corporation
                                                              R. Ramjee
                                                                 Lucent
Issued:  February 19, 2001
Expires: August 19, 2001

                SeaMoby Micro Mobility Problem Statement
                 <draft-ietf-seamoby-mm-problem-00.txt>

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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

   Seamless mobility requires preserving the capability, security, and
   quality of service offered to a mobile node during handoffs. To
   achieve seamlessness, low (ideally no) latency and low (ideally
   zero) packet loss handoff protocols are needed. Limiting the effect
   of handoffs has the potential to improve handoff performance in
   terms of latency and packet loss. This draft identifies the problem
   area for seamless mobility and defines the scope of the work for the
   SeaMoby work group.


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001


Abstract..............................................................1
1 Introduction........................................................3
 1.1 Scope ...........................................................3
 1.2 Problem Statement ...............................................3
 1.3 Terminology .....................................................4
1.4 Architectural Diagram.............................................6
2 Overview............................................................7
 2.1 Goals ...........................................................7
3 Interaction / Comparison With Other Protocols.......................7
 3.1 Comparison with Mobile IP .......................................8
  3.1.1 Scalability Issues ...........................................8
  3.2 MANET / Ad-Hoc Networking Comparison ...........................8
4 Scenarios...........................................................9
4.1 Intra-domain mobility.............................................9
  4.1.1 Handoff Within a Subnet ......................................9
  4.1.2 Seamless Intra-domain Mobility With Optimized Routing. ......10
  4.1.3 Confidentiality and Optimal Path When Roaming ...............10
  4.1.4 Mobile Network and Route Aggregation ........................10
 4.2 Inter-domain mobility ..........................................10
  4.2.1 Local Mobility Spanning Multiple Domains ....................10
  4.2.2 Local mobility restricted to a single domain ................11
 4.3 Local-mobility protocol deployment scenarios ...................11
  4.3.1 Options to Deploy Local-mobility Protocol in Routers ........11
  4.3.2 Ease of Deployment by Allowing Plug and Play Capability .....11
  4.3.3 Local-mobility Protocol in Different ADs ....................11
 4.4 Summary ........................................................12
5 Security Considerations............................................12
6 IANA Considerations................................................12
7 Acknowledgments....................................................12
8 Author's Addresses.................................................13
9 References.........................................................14
Full Copyright Statement.............................................14




















Loughney (editor)                                              [Page 2


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

1 Introduction

   The convergence of wireless networking and IP networking requires
   solutions for transporting realtime application data to IP enabled
   mobile devices and mobile networks. Current IP mobility solutions
   tend to focus primarily on best effort data transport to and from a
   mobile device where the routable IP address (for example, Mobile IP
   Care-of Address) of the Mobile Device changes during handoff.

   Seamless handover for realtime applications imposes strict
   requirements on latency and packet loss. Packet drops should be
   minimized when moving from one access router to another.  Latency
   due to the handoff from one access router to another should be
   minimized so as not to impact the applications running on a mobile
   device or mobile network.

   The assumption is that a local protocol can address these goals
   better by limiting its applicability to a smaller domain (such as an
   intranet - e.g. warehouse, and not the entire internet as in the
   case of Mobile IP) and reverting to Mobile IP for the general case
   of internet mobility support. This assumption may require that the
   scope of a local mobility  protocol be restricted to the case of
   mobility support of a mobile host whose routable IP address does not
   change.

1.1 Scope

   The scope of mobility will be developed as part of the solution
   space.  Possibilities include:

     Mobility where the User's routable IP address does not change

   Where the mobility may be:

     Within a subnet.
     Within an administrative domain.
     Between administrative domains.
     Within a limited number of hops

1.2 Problem Statement

   A local mobility mechanism, which localizes processing and
   signaling, thus enabling less latency, should allow better
   scalability, performance and reliability resulting in seamless
   handoffs. Moreover, a lightweight approach, customized to the exact
   requirements of local mobility while interoperable with a more
   general mobility  mechanism (e.g. Mobile-IP), would allow an easier
   deployment in situations  where local mobility is sufficient, or
   several general mobility mechanisms are involved.




Loughney (editor)                                              [Page 3


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   Seamless handoffs, while maintaining the same routable IP address of
   a Mobile Node or Mobile Network should be a work item for the
   SEAMOBY Working Group.

   While studying solutions for Seamless handoffs using the same
   routable IP address handoff, the SEAMOBY Working Group should
   include the following considerations:

    *  Handoff between heterogeneous networks.  For example, 802.11,
       Bluetooth and 3G cellular.
    *  How to discover a new Access Link and the Access Router serving
       the new Access Link.
    *  How to discover the bandwidth, cost, error rate (and other
       properties) of candidate Access Links.
    *  Involving QoS characteristics as part of the handoff process.
    *  Optimize the path for mobile-to-mobile communications.
    *  Enable plug and play capabilities for Mobile Devices, Access
       Routers/Access Links.
    *  Support for mobility of mobile hosts and mobile networks

   Prioritization of, additions to, and details of the above items will
   be worked out during the requirements phase.

1.3 Terminology

   See [SM Terms] for additional terminology.

   Local Mobility        The movement of an IP device without requiring
                         a change to its routable IP address. Although
                         its point of attachment may change during the
                         move, the IP address used to reach the device
                         (both its home and IP subnet routable IP
                         address) do not change.

   Seamless Handoff      A handoff procedure which does not result in
                         any change in service capability, security, or
                         quality. This procedure has strict timing
                         requirement for the execution and low (zero)
                         packet loss.

   Subnet                A range of IP address designated by a common
                         prefix constitutes a subnet. A subnet exists
                         when no IP routing is required to reach the
                         intended host. Examples: For IPv4: 10.1.1.0/24
                         (subnet mask is 255.255.255.0), for IPv6:
                         1234:5678:90AB:CDEF::/64

   Network               A Network is characterized by a range of IP
                         address designated by a common prefix and may
                         contain one or more adjacent subnets
                         interconnected by IP routers.


Loughney (editor)                                              [Page 4


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   Administrative Domain A collection of networks under the same
                         administrative control and grouped together
                         for administrative purposes. [2753]

   Local Mobility Domain A Local Mobility Domain contains one or more
                         IP subnets, networks, or Administrative
                         Domains.  Within the Local Mobility Domain,
                         the routable IP address assigned to a Mobile
                         Host or Mobile Router serving a Mobile Network
                         does not change.

   Mobile Node (MN)      An IP node capable of changing its point of
                         attachment to the network. The MN can be
                         either a mobile end-node or a mobile router
                         serving an arbitrarily complex mobile network.

   Mobile Host (MH)      An IP node capable of changing its point of
                         attachment to the network. The MH only refers
                         to an end-node without further routing
                         support.

   Mobile Router (MR)    An IP Router that may change its point of
                         attachment to an IP network.

   Mobile Network        An IP network where one or more Mobile Routers
                         are used to access a larger IP network.


   Access Point (AP)     A layer 2 device, which is connected to one or
                         more Access Routers and offers the wireless
                         link connection to the MH. Access Points are
                         sometimes called 'base stations'. Note that
                         this usage differs from that used by some
                         Access Router vendors, who call their boxes
                         'Access Points'.

   Access Router (AR)    An IP router residing in an Access Network and
                         connected to one or more access points. An AR
                         offers connectivity to MNs. The router may
                         include intelligence beyond simple forwarding
                         service offered by ordinary IP routers. An AR
                         communicates with one or more Access Points.

   Access Network Gateway (ANG) An IP gateway that separates the Access
                         Network from a third party network.

   Access Network (AN)   An IP network that includes one or more ARs
                         and ANGs.

   Radio Cell            An area associated with each AP, where there
                         is radio coverage, i.e. where radio


Loughney (editor)                                              [Page 5


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

                         communication between a MN and the specific AP
                         is possible.

1.4 Architectural Diagram

   The following diagram proposes an example architecture, for
   reference.  It is not meant to impose any restriction upon mobility,
   but for use to better visualize the problem space.

                       +-+
                       | | ---+
                       +-+    |
                       AP1    |
                              |
                       +-+    |   +-----+                   +-----+  |
               |<-->   | | ---+---| AR1 |-------------------|     |  |
              []       +-+    |   +-----+          \       /| ANG |--|
              MN       AP2    |                     \     / |     |  |
                              |                      \   /  +-----+  |
                       +-+    |                       \ /            |
                       | |----+                        X             |
                       +-+                            / \            |
                       AP3                           /   \           |
                                                    /     \ +-----+  |
                       +-+       +-----+           /       \|     |  |
               |<-->   | |-------| AR2 |--------------------| ANG |--|
              []       +-+       +-----+                    |     |  |
              MR       AP4                                  +-----+  |
                                                                     |
                        Administrative Domain (AD) 1                 |
            - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|-
                        Administrative Domain (AD) 2                 |
                                                                     |
                                                                     |
                       +-+        +-----+                   +-----+  |
               |<-->   | | -------| AR3 |-------------------|     |  |
              []       +-+       /+-----+                  /| ANG |--|
              MH       AP5      /                         / |     |  |
                               /                         /  +-----+  |
                       +-+    /                         /            |
                       | |----                         /             |
                       +-+                            /              |
                       AP6                           /               |
                                                    /                |
                       +-+       +-----+           /                 |
                       | |-------| AR4 |-----------                  |
                       +-+ \     +-----+         /                   |
                       AP7  \                   /                    |
                             \                 /                     |
                              \  +-----+      /                      |
                               --| AR5 |------                       |
                                 +-----+                             |

Loughney (editor)                                              [Page 6


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001



            Figure 1: Architectural Diagram for Local Mobility

2 Overview

   Local Mobility should also consider if the new access router (ARn+1)
   provides the same 'services' (QoS, etc.) as expected by the user. A
   local mobility solution should (a) ensure that ARn+1 provides the
   same QoS as ARn or (b) alert applications that QoS is changing or
   has changed.

2.1 Goals

   Mandatory

     * Mobility without changing the routable IP address
     * Use Mobile IP WG protocols for mobility between local mobility
       domains
     * The solution is IP version neutral, although implementation
       details may differ for IPv4 and IPv6
     * Handover to new AR that can provide the same quality and
       security of service as the old AR or alert the application if
       change occurs
     * Scale well with the size of the local mobility domain
     * Inter-technology/heterogeneous mobility support
     * Mobility support for mobile hosts and mobile networks

   Desirable

     * Use MIP for signaling from the MN.
     * Enable optimized routing for MN to MN communications.
     * Inter-operate with existing QoS protocols (i.e. RSVP)
     * Plug and play (automatic setup and recovery, handle failures
       gracefully)
     * Allow a progressive deployment
     * Bandwidth optimization, maximizing throughput e.g. with a smart
       handoff algorithm
     * User location confidentiality
     * Support connectivity to multiple Access Routers simultaneously
       (IP diversity / load balancing)
     * Allow simple ad-hoc networking

3 Interaction / Comparison With Other Protocols

   Local Mobility will interwork with Context Transfer.

   This work will define the areas of intersection (and non-
   intersection) between SeaMoby and the following:

    * Mobile IP [2002], [MIPv6]
    * Fast Handoffs [Fast IP6]

Loughney (editor)                                              [Page 7


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

    * Regional Registration for IPv4, IPv6
    * Mobility management in other networks

3.1 Comparison with Mobile IP

     Goals                    Solution based on Mobile IP

     1)   Seamlessness:       Fast/Proactive Handoff work
     2)   Scalability:        Hierarchical Mobile IP work
     3)   Efficiency:         Requires tunneling; Route Optimization
                              work; For localized updates, Hierarchical
                              Mobile IP
     4)   Configurability:    Plug & Play of routers/base stations not
                              addressed - need to configure HA/FA/GFA's
                              etc.
     5)   Reliability:        HA/GFA needs redundancy, failover
                              capability
     6)   QoS:                controversial; tunneling complicates QoS
                              support
     7)   Paging:             controversial; not addressed
     8)   AAA/Registration:   controversial; speed of
                              (re)authentication and/or
                              (re)registration during cross-AD handoff
                              may require expedited techniques or
                              credential development.
     9)   Security/Message    controversial; speed of message (e.g.,
          Authentication:     context transfer) authentication during
                              cross-AD handoff may require expedited
                              techniques (e.g., key or ticket
                              infrastructure).
     10)  Mobile Network      controversial.
          Support:

     Thus, while Mobile IP WG has some work in the pipeline to address
     some of these goals (1-3 & 9), it does not comprehensively address
     all these goals. Likewise, the AAA WG has work in development that
     may or may not satisfy goal 8 concurrently with the other goals.

3.1.1 Scalability Issues

   1)   There is a concern that A GFA/FA in every AR may not scale or
        even be desirable in extremely inexpensive AR devices.

   2)  There is a concern that putting an FA essentially everywhere
       would add a lot of complication to what could be a relatively
       simple micro-mobility handoff.

   3)  There are some thoughts that micro-mobility could possibly be
       handled completely by MNs.

3.2 MANET / Ad-Hoc Networking Comparison


Loughney (editor)                                              [Page 8


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   The MANET WG in the IETF has an important charter to create a
   protocol for mobiles arranged in arbitrary and highly dynamic
   associations.  This work is striving for robust and highly scalable
   routing solutions.  Currently, MANET is not considering fast or
   seamless handoff.

   In many instances, for example small residential networks found in
   the home, the network may be relatively small and has far less
   dynamics.  The network may still have a requirement for fast and/or
   seamless handoffs. For this reason there may be some overlap between
   SeaMoby and ad-hoc networking solutions.  Therefore, SeaMoby MUST be
   able to co-exist gracefully with any MANET solutions algorithm that
   does become standardized.

4 Scenarios

   This section is intended as to provide some simple, descriptive
   examples of the problem.  The network is based on Figure 1, in
   section 1.4.  In the scenarios, the term mobile node (MN) is used,
   but the node could be a mobile host, mobile router, etc.

   I work for company X that controls and manages its intra-net AD1 in
   Figure 1. Employees at my work use mobile hosts to roam within AD1.
   In the city, I can be reached through ISP Y's cellular network, AD2
   in Figure 1.

4.1 Intra-domain mobility

   Company X provides mobility service to its employees within the
   intra-net AD1. The IP address of a mobile host remains fixed
   regardless of its attachment point within the administrative domain.

4.1.1 Handoff Within a Subnet

   The MN moves out of AP3 (802.11) coverage area, and can select AP2
   (802.11) or AP1 (Bluetooth), which are all connected on the same
   subnet (e.g. - Ethernet) to AR1. One characteristic of Bluetooth is
   that an unassisted search for and re-association with a new access
   point may take as much as 11 seconds, while detailed knowledge of
   the target access point may reduce this to less than 100 ms.

   On each handoff, the new access point must ensure sufficient
   capacity to support traffic related to the mobile node aside of pre-
   existing connections. In this example, the Bluetooth access point
   AP1 experiences temporary environmental noise (e.g. - an oven), and
   the corresponding loss of available capacity. Therefore, a handoff
   to AP2 is selected. This is an intra-AR handoff between APs of the
   same technology. In this case Inter-AP protocol (e.g. - 802.11 IAPP)
   will be used to do handoff.




Loughney (editor)                                              [Page 9


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   Later, the MN moves to an area that is only covered by AP1
   (Bluetooth), so an inter-technology handoff occurs between AP2
   (802.11) to AP1 (Bluetooth)

4.1.2 Seamless Intra-domain Mobility With Optimized Routing.

   A user establishes a video phone call with a colleague. During the
   call both parties move around the building; their Mobile Nodes hop
   between subnets while changing their attachment point. However,
   there is no degradation in the quality of the video phone call. The
   network continuously maintains an optimized communication path
   between the two mobile nodes. More precisely, the path for a session
   between two mobile hosts should be ideally the same as the path
   selected if the mobile nodes were fixed devices. This is an instance
   of seamless intra-domain mobility with optimized routing.

4.1.3 Confidentiality and Optimal Path When Roaming

   An IETF member wants to download drafts while moving between several
   work group meetings.  The IETF Member would like to maintain
   confidentiality, while doing so.  Binding Updates (BU) will reveal
   location, and home agent (HA) produce triangular routing. Therefore,
   it would be very useful to have a local-mobility solution supporting
   location confidentiality within the administrative domain while
   providing optimal communication path.

4.1.4 Mobile Network and Route Aggregation

   An ISP provides wireless service for users travelling on the city
   train. The trains have an IP network installed to provide Internet
   access to the users on the train. There might be one or more mobile
   routers that have radio interfaces to communicate with the AP's of
   the ISP. To reach the hosts on the moving train, it is desirable to
   have an aggregate route for all the hosts in the train. This is an
   instance where an ISP provides local mobility for route aggregates.

4.2 Inter-domain mobility

   Service providers may make agreements allowing local mobility to
   span different administrative districts, or may simply provide
   roaming between these ADs. This can produce the following scenarios.

4.2.1 Local Mobility Spanning Multiple Domains

   When I drive to the supermarket, I enter Y's domain. My company X
   has an agreement with Y that allows me to make fast hand-off to Y's
   domain with the same IP address that I used to roam within X domain.
   The ISP Y provides under this agreement best effort connectivity to
   me (using the IP address assigned by X) for some time, before it
   requires me to perform Mobile-IP, e.g. for negotiating new IP
   address, issuing BUs, doing AAA, etc. As a result of Mobile-IP
   processing, I will get a new IP address for roaming within Y's

Loughney (editor)                                              [Page 10


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   domain, and other contracted services, such as QoS. The ISP Y
   provides best effort connectivity for the transitory period, because
   it must perform authentication and authorization, and retrieve
   user's service (QoS) profile, before providing QoS and other
   contracted services. This is an instance of fast handoff handled by
   local mobility protocol first, then an inter-domain mechanism (e.g.
   Mobile-IP)is invoked for AAA and contracted services.

4.2.2 Local mobility restricted to a single domain

   When I drive to the supermarket, I enter Y's domain. My company X
   has an agreement with Y that allows me to roam within Y's cellular
   network and receive my contracted services. The ISP Y first assigns
   me a new IP address before providing me connectivity. Hence, as soon
   as I discover that I am in Y's domain, I must initiate Mobile-IP
   processing to perform inter-domain hand-off.

4.3 Local-mobility protocol deployment scenarios

4.3.1 Options to Deploy Local-mobility Protocol in Routers

   The local mobility protocol may be deployed in all the nodes or a
   selected set of the nodes in a network. The network nodes with
   local-mobility routing capability can be named as Mobile Location
   Aware Nodes (MLAN). If all the nodes in a network are MLAN, each
   node knows how to forward the data packets towards a mobile device.
   If only a subset of the network nodes are MLAN, tunnels can be used
   to connect the MLANs so that the data packets can be tunneled
   through the non-MLANs between a pair of MLANs. Therefore, we can
   think that the local-mobility protocol is applicable among the MLANs
   for local-mobility routing in the network. Conceptually, there
   should be no difference for the protocol whether it is used in the
   network routers or mobile agents.

4.3.2 Ease of Deployment by Allowing Plug and Play Capability

   A service provider may want to temporally setup wireless service in
   a location, or the service provider want to expand its wireless
   service to a new area. When the new equipment connected to the
   network, the new routers/agents can learn how to forward data
   packets by automatically learning from neighbors or other sources. A
   new access point should learn the capability of its neighboring APs.
   This automatic learning process enables plug and play capability

4.3.3 Local-mobility Protocol in Different ADs

   The local mobility domain can have one-to-one mapping to the
   administrative domain. In this deployment case, a handoff between
   two ADs requires change of the routable IP address of the mobile
   node. In this case a macro-mobility protocol, such as Mobile IP, is
   needed inter-domain handoff.


Loughney (editor)                                              [Page 11


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   A local mobility domain can span multiple ADs if a trust
   relationship exists between them allowing the use of the same
   routable IP address across ADs.

4.4 Summary

   AD     Administrative Domain
   MD     Mobility Domain
   SN     Subnet

   X -> Applicable
                      |       intra-SN      |     inter-AD    |inter-AD
                      |intra-tech|inter-tech|inter-SN|intra-MD|inter-MD
   -------------------+----------+----------+--------+--------+--------
   inter-AP prot      |     X    |          |        |        |
   local mobility prot|     X    |    X     |    X   |    X   |
   Mobile-IP          |     X    |    X     |    X   |    X   |   X

                           |Inter-AP prot | local mob. Prot |    MIP
   ------------------------+--------------+-----------------+----------
   optimized route         |    X         |        X        |
   location confidentiality|    X (1)     |        X (2)    |   X (3)
   QoS Support             |    x (5)     |        X        |
   Context Transfer        |    x (5)     |        X        |   X (4)
   Transparent             |    L3+       |        L4+      |   L4+
   Plug & Play             |    X         |        X        |

   (1)except for those participating in the inter-AP protocol in the
      same subnet
   (2)transparent at least to anyone outside of the MD
   (3)transparent to the CN, and only if reverse tunneling is used
   (4)       proprietary at the moment
   (5)       may be redundant in some cases where the L2 provides similar/same
      mechanisms.

5 Security Considerations

   This type of non-protocol document does not directly affect the
   security of the Internet.

6 IANA Considerations

   This document does not directly affect IANA.

7 Acknowledgments

   The authors would like to thank Kulwinder Atwal, Peter Lei, Charlie
   Perkins, Michael A. Ramalho, Luca Salgarelli, Hesham Soliman,
   Michael Thomas and Mika Ylianttila for their comments and
   contributions to this document.



Loughney (editor)                                              [Page 12


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

8 Author's Addresses

   John Loughney (editor)
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group
   Finland
   john.loughney@nokia.com

   Dana Blair
   Cisco
                                                         dblair@cisco.com

   Peter Hazy
   Nortel Networks
   100 Constellation Crescent
   Nepean, ON K2G 6J8
   Canada
   Phone:  1-613-768-2969

   Muhammad Jaseemuddin
   Nortel Networks
   100 Constellation Crescent
   Nepean, ON K2G 6J8
   Canada
   Phone: 1-613-765-7520
   jaseem@nortelnetworks.com

   O. Henrik Levkowetz
   A Brand New World
   Osterogatan 1
   S-164 28 Kista
   Sweden

henrik.levkowetz@abrandnewworld.se

   Hongyi Li
   Nortel Networks
   100 Constellation Crescent
   Nepean, ON K2G 6J8
   Canada
   Phone:  1-613-763-5966

hyli@nortelnetworks.com

   Jukka Manner
   Department of Computer Science, University of Helsinki
   P.O. Box 26 (Teollisuuskatu 23)
   FIN-00014 Helsinki
   FINLAND
   jmanner@cs.Helsinki.fi

   Phillip Neumiller
   3Com Corporation

Loughney (editor)                                              [Page 13


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   1800 W. Central Road
   Mount Prospect  IL 60056
   USA
   phil_neumiller@3com.com

   Ram Ramjee,
   Bell Labs, Lucent Technologies,
   101 Crawfords Corner Road,
   Holmdel, NJ 07733
   USA
   Phone: 1-732-949-3306
   Fax:   1-732-949-4513
   ramjee@bell-labs.com

   Guilhem Tardy
   Nortel Networks
   100 Constellation Crescent
   Nepean, ON K2G 6J8
   Canada
   Phone:  1-613-763-1953

guilhem.tardy@nortelnetworks.com

9 References

   [2002]         Perkins, C., "IP Mobility Support". Internet
                  Engineering Task Force, Request for Comments (RFC)
                  2002, October 1996.

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

   [2753]         Yavatkar, R., Pendarakis, D., Guerin, R.; "A
                  Framework for Policy-based Admission Control"; RFC
                  2753; January 2000.

   [MIPv6]        David B. Johnson, Charles Perkins, "Mobility Support
                  in IPv6", draft-ietf-mobileip-ipv6-12.txt, April
                  2000.

   [SM Terms]     Manner, J. et al; "Mobility Related Terminology";
                  <draft-manner-seamoby-terms-00.txt>; Work In
                  Progress; January 12, 2001.

   [Fast MIP6]    Perkins, C., Editor, "Fast Handoffs for Mobile IPv6",
                  draft-perkins-mobileip-handoff-01.txt, a work in
                  progress; February 2001.

Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.


Loughney (editor)                                              [Page 14


Internet Draft     SeaMoby MM Problem Statement       February 19, 2001

   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.






























Loughney (editor)                                              [Page 15]


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