draft-ietf-seamoby-mm-problem-00.txt   draft-ietf-seamoby-mm-problem-01.txt 
skipping to change at page 1, line 18 skipping to change at page 1, line 18
G. Tardy G. Tardy
Nortel Nortel
O. H. Levkowetz O. H. Levkowetz
ABNW ABNW
J. Manner J. Manner
University of Helsinki University of Helsinki
P. Neumiller P. Neumiller
3Com Corporation 3Com Corporation
R. Ramjee R. Ramjee
Lucent Lucent
Issued: February 19, 2001 Issued: February 23, 2001
Expires: August 19, 2001 Expires: August 23, 2001
SeaMoby Micro Mobility Problem Statement SeaMoby Micro Mobility Problem Statement
<draft-ietf-seamoby-mm-problem-00.txt> <draft-ietf-seamoby-mm-problem-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
Seamless mobility requires preserving the capability, security, and Seamless mobility requires preserving the capability, security, and
quality of service offered to a mobile node during handoffs. To quality of service offered to a mobile node during handovers. To
achieve seamlessness, low (ideally no) latency and low (ideally achieve seamlessness, low (ideally no) latency and low (ideally
zero) packet loss handoff protocols are needed. Limiting the effect zero) packet loss handover protocols are needed. Limiting the effect
of handoffs has the potential to improve handoff performance in of handovers has the potential to improve handover performance in
terms of latency and packet loss. This draft identifies the problem terms of latency and packet loss. This draft identifies the problem
area for seamless mobility and defines the scope of the work for the area for seamless mobility and defines the scope of the work for the
SeaMoby work group. SeaMoby work group.
Abstract..............................................................1 Abstract..............................................................1
1 Introduction........................................................3 1 Introduction........................................................3
1.1 Scope ...........................................................3 1.1 Scope ...........................................................3
1.2 Problem Statement ...............................................3 1.2 Problem Statement ...............................................4
1.3 Terminology .....................................................4 1.3 Terminology .....................................................4
1.4 Architectural Diagram.............................................6 1.4 Architectural Diagram.............................................6
2 Overview............................................................7 2 Overview............................................................7
2.1 Goals ...........................................................7 2.1 Goals ...........................................................8
3 Interaction / Comparison With Other Protocols.......................7 3 Interaction / Comparison With Other Protocols.......................8
3.1 Comparison with Mobile IP .......................................8 3.1 Comparison with Mobile IP .......................................8
3.1.1 Scalability Issues ...........................................8 3.1.1 Scalability & Performance Related Issues .....................9
3.2 MANET / Ad-Hoc Networking Comparison ...........................8 3.2 MANET / Ad-Hoc Networking Comparison ...........................10
4 Scenarios...........................................................9 4 Scenarios..........................................................10
4.1 Intra-domain mobility.............................................9 4.1 Intra-domain mobility ..........................................10
4.1.1 Handoff Within a Subnet ......................................9 4.1.1 Handover Within a Subnet ....................................10
4.1.2 Seamless Intra-domain Mobility With Optimized Routing. ......10 4.1.2 Seamless Intra-domain Mobility With Optimized Routing. ......11
4.1.3 Confidentiality and Optimal Path When Roaming ...............10 4.1.3 Confidentiality and Optimal Path When Roaming ...............11
4.1.4 Mobile Network and Route Aggregation ........................10 4.1.4 Mobile Network and Route Aggregation ........................11
4.2 Inter-domain mobility ..........................................10 4.2 Inter-domain mobility ..........................................11
4.2.1 Local Mobility Spanning Multiple Domains ....................10 4.2.1 Local Mobility Spanning Multiple Domains ....................11
4.2.2 Local mobility restricted to a single domain ................11 4.2.2 Local mobility restricted to a single domain ................12
4.3 Local-mobility protocol deployment scenarios ...................11 4.3 Local-mobility protocol deployment scenarios ...................12
4.3.1 Options to Deploy Local-mobility Protocol in Routers ........11 4.3.1 Options to Deploy Local-mobility Protocol in Routers ........12
4.3.2 Ease of Deployment by Allowing Plug and Play Capability .....11 4.3.2 Ease of Deployment by Allowing Plug and Play Capability .....12
4.3.3 Local-mobility Protocol in Different ADs ....................11 4.3.3 Local-mobility Protocol in Different ADs ....................12
4.4 Summary ........................................................12 4.4 Summary ........................................................13
5 Security Considerations............................................12 5 Next Steps.........................................................13
6 IANA Considerations................................................12 6 Security Considerations............................................13
7 Acknowledgments....................................................12 7 IANA Considerations................................................14
8 Author's Addresses.................................................13 8 Acknowledgments....................................................14
9 References.........................................................14 9 Author's Addresses.................................................14
Full Copyright Statement.............................................14 10 References........................................................15
Full Copyright Statement.............................................16
1 Introduction 1 Introduction
The convergence of wireless networking and IP networking requires The convergence of wireless networking and IP networking requires
solutions for transporting realtime application data to IP enabled solutions for transporting realtime application data to IP enabled
mobile devices and mobile networks. Current IP mobility solutions mobile devices and mobile networks. Current IP mobility solutions
tend to focus primarily on best effort data transport to and from a tend to focus primarily on best effort data transport to and from a
mobile device where the routable IP address (for example, Mobile IP mobile device where the routable IP address (for example, Mobile IP
Care-of Address) of the Mobile Device changes during handoff. Care-of Address) of the Mobile Device changes during handover.
Seamless handover for realtime applications imposes strict Seamless handover for realtime applications imposes strict
requirements on latency and packet loss. Packet drops should be requirements on latency and packet loss. Packet drops should be
minimized when moving from one access router to another. Latency minimized when moving from one access router to another. Latency
due to the handoff from one access router to another should be due to the handover from one access router to another should be
minimized so as not to impact the applications running on a mobile minimized so as not to impact the applications running on a mobile
device or mobile network. device or mobile network.
The assumption is that a local protocol can address these goals The assumption is that a local protocol can address these goals by
better by limiting its applicability to a smaller domain (such as an limiting its applicability to a smaller domain thus reducing the
intranet - e.g. warehouse, and not the entire internet as in the amount of signaling needed that should improve performance. This
case of Mobile IP) and reverting to Mobile IP for the general case assumption may require that the scope of a local mobility protocol
of internet mobility support. This assumption may require that the be restricted to the case of mobility support of a mobile host whose
scope of a local mobility protocol be restricted to the case of routable IP address does not change.
mobility support of a mobile host whose routable IP address does not
change. In this draft, the term 'local mobility' is used in place of
micromobility.
1.1 Scope 1.1 Scope
The scope of mobility will be developed as part of the solution The scope of mobility will be developed as part of the solution
space. Possibilities include: space. Possibilities include:
Mobility where the User's routable IP address does not change Mobility where the User's routable IP address does not change
Where the mobility may be: Where the mobility may be:
Within a subnet. Within a subnet.
Within an administrative domain. Within an administrative domain.
Between administrative domains. Between administrative domains.
Within a limited number of hops Within a limited number of hops
This is not meant to be an exhaustive survey, but to point in the
direction for further analysis. For example, source-based routing
[DSR] and tunneling [2002] are two possible solutions for mobility.
Some source routing schemes [DSR] allow:
"... packet routing to be trivially loop-free, avoids the need for
up-to-date routing information in the intermediate nodes through
which packets are forwarded, and allows nodes forwarding or
overhearing packets to cache the routing information in them for
their own future use."
Tunnel-based approaches [2002][MIPv6] may have better scaling
properties, but this may not be an issue with local mobility
domains.
1.2 Problem Statement 1.2 Problem Statement
There are many proposals for adding and enhancing mobility in IP
networks, for example Mobile IP [2002][MIPv6]. There are a number
of proposals to optimize Mobile IP signaling to allow fast handovers
[FAST MIPv6]. However, none of these completely address the complex
interaction of parameters and protocols needed for Seamless
Handovers.
A local mobility mechanism, which localizes processing and A local mobility mechanism, which localizes processing and
signaling, thus enabling less latency, should allow better signaling, thus enabling less latency, should allow better
scalability, performance and reliability resulting in seamless scalability, performance and reliability resulting in seamless
handoffs. Moreover, a lightweight approach, customized to the exact handovers. Moreover, a lightweight approach, customized to the exact
requirements of local mobility while interoperable with a more requirements of local mobility while interoperable with a more
general mobility mechanism (e.g. Mobile-IP), would allow an easier general mobility mechanism (e.g. vanilla Mobile-IP [2002]), would
deployment in situations where local mobility is sufficient, or allow an easier deployment in situations where local mobility is
several general mobility mechanisms are involved. sufficient, or several general mobility mechanisms are involved.
Seamless handoffs, while maintaining the same routable IP address of Applicability of the above might be useful for networks with
a Mobile Node or Mobile Network should be a work item for the multiple layer 3 access points with unreliable connectivity between
SEAMOBY Working Group. the mobile and those access points, for example.
While studying solutions for Seamless handoffs using the same While studying solutions for seamless handovers, the SEAMOBY Working
routable IP address handoff, the SEAMOBY Working Group should Group should include the following considerations:
include the following considerations:
* Handoff between heterogeneous networks. For example, 802.11, * Mobility maintaining the same routable IP address of a mobile
node or mobile network.
* Handover between heterogeneous networks. For example, 802.11,
Bluetooth and 3G cellular. Bluetooth and 3G cellular.
* How to discover a new Access Link and the Access Router serving * How to discover a new Access Link and the Access Router serving
the new Access Link. the new Access Link.
* How to discover the bandwidth, cost, error rate (and other * How to discover the bandwidth, cost, error rate (and other
properties) of candidate Access Links. properties) of candidate Access Links.
* Involving QoS characteristics as part of the handoff process. * Involving QoS characteristics as part of the handover process.
* Optimize the path for mobile-to-mobile communications. * Optimize the path for mobile-to-mobile communications.
* Enable plug and play capabilities for Mobile Devices, Access * Enable plug and play capabilities for Mobile Devices, Access
Routers/Access Links. Routers/Access Links.
* Support for mobility of mobile hosts and mobile networks * Support for mobility of mobile hosts and mobile networks
Prioritization of, additions to, and details of the above items will Prioritization of, additions to, and details of the above items will
be worked out during the requirements phase. be worked out during the requirements phase.
1.3 Terminology 1.3 Terminology
See [SM Terms] for additional terminology. See [SM Terms] for additional terminology.
Local Mobility The movement of an IP device without requiring Local Mobility The movement of an IP device without requiring
a change to its routable IP address. Although a change to its routable IP address. Although
its point of attachment may change during the its point of attachment may change during the
move, the IP address used to reach the device move, the IP address used to reach the device
(both its home and IP subnet routable IP (both its home and IP subnet routable IP
address) do not change. address) do not change.
Seamless Handoff A handoff procedure which does not result in Seamless Handover A handover procedure which does not result in
any change in service capability, security, or any change in service capability, security, or
quality. This procedure has strict timing quality. This procedure has strict timing
requirement for the execution and low (zero) requirement for the execution and low (zero)
packet loss. packet loss.
Subnet A range of IP address designated by a common Subnet A range of IP address designated by a common
prefix constitutes a subnet. A subnet exists prefix constitutes a subnet. A subnet exists
when no IP routing is required to reach the when no IP routing is required to reach the
intended host. Examples: For IPv4: 10.1.1.0/24 intended host. Examples: For IPv4: 10.1.1.0/24
(subnet mask is 255.255.255.0), for IPv6: (subnet mask is 255.255.255.0), for IPv6:
skipping to change at page 1, line 305 skipping to change at page 1, line 330
2 Overview 2 Overview
Local Mobility should also consider if the new access router (ARn+1) Local Mobility should also consider if the new access router (ARn+1)
provides the same 'services' (QoS, etc.) as expected by the user. A provides the same 'services' (QoS, etc.) as expected by the user. A
local mobility solution should (a) ensure that ARn+1 provides the local mobility solution should (a) ensure that ARn+1 provides the
same QoS as ARn or (b) alert applications that QoS is changing or same QoS as ARn or (b) alert applications that QoS is changing or
has changed. has changed.
2.1 Goals 2.1 Goals
Mandatory Below are listed a number of issues, which any local mobility
solution should address. The exact nature shall be detailed in a
requirements for micromobility document.
* Mobility without changing the routable IP address * Mobility without changing the routable IP address
* Use Mobile IP WG protocols for mobility between local mobility * Use Mobile IP WG protocols for mobility between local mobility
domains domains
* The solution is IP version neutral, although implementation * The solution is IP version neutral, although implementation
details may differ for IPv4 and IPv6 details may differ for IPv4 and IPv6
* Handover to new AR that can provide the same quality and * Handover to new AR that can provide the same quality and
security of service as the old AR or alert the application if security of service as the old AR or alert the application if
change occurs change occurs
* Scale well with the size of the local mobility domain * Scale well with the size of the local mobility domain
* Inter-technology/heterogeneous mobility support * Inter-technology/heterogeneous mobility support
* Mobility support for mobile hosts and mobile networks * Mobility support for mobile hosts and mobile networks
Desirable
* Use MIP for signaling from the MN. * Use MIP for signaling from the MN.
* Enable optimized routing for MN to MN communications. * Enable optimized routing for MN to MN communications.
* Inter-operate with existing QoS protocols (i.e. RSVP) * Inter-operate with existing QoS protocols (i.e. RSVP)
* Plug and play (automatic setup and recovery, handle failures * Plug and play (automatic setup and recovery, handle failures
gracefully) gracefully)
* Allow a progressive deployment * Allow a progressive deployment
* Bandwidth optimization, maximizing throughput e.g. with a smart * Bandwidth optimization, maximizing throughput e.g. with a smart
handoff algorithm handover algorithm
* User location confidentiality * User location confidentiality
* Support connectivity to multiple Access Routers simultaneously * Support connectivity to multiple Access Routers simultaneously
(IP diversity / load balancing) (IP diversity / load balancing)
* Allow simple ad-hoc networking * Allow simple ad-hoc networking
These goals should serve as input to local mobility requirements.
3 Interaction / Comparison With Other Protocols 3 Interaction / Comparison With Other Protocols
Local Mobility will interwork with Context Transfer. Local Mobility will interwork with Context Transfer.
This work will define the areas of intersection (and non- This work will define the areas of intersection (and non-
intersection) between SeaMoby and the following: intersection) between SeaMoby and the following:
* Mobile IP [2002], [MIPv6] * Mobile IP [2002], [MIPv6]
* Fast Handoffs [Fast IP6] * Fast Handovers [Fast IP6]
* Regional Registration for IPv4, IPv6 * Hierarchical MIPv4 / MIPv6
* Regional Registrations for IPv6
* Mobility management in other networks * Mobility management in other networks
3.1 Comparison with Mobile IP 3.1 Comparison with Mobile IP
Goals Solution based on Mobile IP Goals Solution based on Mobile IP
1) Seamlessness: Fast/Proactive Handover work
1) Seamlessness: Fast/Proactive Handoff work
2) Scalability: Hierarchical Mobile IP work 2) Scalability: Hierarchical Mobile IP work
3) Efficiency: Requires tunneling; Route Optimization 3) Efficiency: Requires tunneling; Route Optimization
work; For localized updates, Hierarchical work; For localized updates, Hierarchical
Mobile IP Mobile IP
4) Configurability: Plug & Play of routers/base stations not 4) Configurability: Plug & Play of ARs/APs not addressed.
addressed - need to configure HA/FA/GFA's Autoconfiguration is addressed in IPv6,
etc. but capabilities of the APs is not
5) Reliability: HA/GFA needs redundancy, failover addressed by Mobile IP.
capability 5) Reliability: HA/GFA (MIPv4); MAPs (MIPv6) need
redundancy, failover capability
6) QoS: controversial; tunneling complicates QoS 6) QoS: controversial; tunneling complicates QoS
support support.
7) Paging: controversial; not addressed 7) Paging: controversial; not addressed
8) AAA/Registration: controversial; speed of 8) AAA/Registration: controversial; speed of
(re)authentication and/or (re)authentication and/or
(re)registration during cross-AD handoff (re)registration during cross-AD handover
may require expedited techniques or may require expedited techniques or
credential development. credential development.
9) Security/Message controversial; speed of message (e.g., 9) Security/Message controversial; speed of message (e.g.,
Authentication: context transfer) authentication during Authentication: context transfer) authentication during
cross-AD handoff may require expedited cross-AD handover may require expedited
techniques (e.g., key or ticket techniques (e.g., key or ticket
infrastructure). infrastructure).
10) Mobile Network controversial. 10) Mobile Network Optimized Routing in IPv4 does not
Support: Support: support mobile routing; nor does MIPv6
sufficiently define interoperable support
for mobile networks.
Thus, while Mobile IP WG has some work in the pipeline to address Thus, Mobile IP WG does not completely cover the solution space
some of these goals (1-3 & 9), it does not comprehensively address for Seamless mobility. More detailed analysis should be done to
all these goals. Likewise, the AAA WG has work in development that determine the applicability of Mobile IP to local mobility and to
may or may not satisfy goal 8 concurrently with the other goals. identify Mobile IP's shortcomings.
3.1.1 Scalability Issues 3.1.1 Scalability & Performance Related Issues
1) There is a concern that A GFA/FA in every AR may not scale or For MIPv4, there is a concern that a GFA/FA in every AR may not
even be desirable in extremely inexpensive AR devices. scale or even be desirable in extremely inexpensive AR devices.
Also, there is a concern that putting an FA essentially everywhere
would add complication to what could be a relatively simple micro-
mobility handover.
2) There is a concern that putting an FA essentially everywhere Interactions between Mobile IP and QoS mechanisms (for example RSVP)
would add a lot of complication to what could be a relatively are complex and may not work fast enough. [MIP RSVP] They introduce
simple micro-mobility handoff. additional signaling.
3) There are some thoughts that micro-mobility could possibly be It has been suggested that in order to scale MIP, Hierarchical /
handled completely by MNs. Regional FAs, GFAs, MAPs and other such "in the middle of the
network boxes" are needed. This may be considered a limitation of
MIP. This begins to chip away at some fundamental philosphies of the
internet, such as making the network robust against single points of
failures; that intelligence exists at the edge and so on.
3.2 MANET / Ad-Hoc Networking Comparison 3.2 MANET / Ad-Hoc Networking Comparison
The MANET WG in the IETF has an important charter to create a The MANET WG in the IETF has an important charter to create a
protocol for mobiles arranged in arbitrary and highly dynamic protocol for mobiles arranged in arbitrary and highly dynamic
associations. This work is striving for robust and highly scalable associations. This work is striving for robust and highly scalable
routing solutions. Currently, MANET is not considering fast or routing solutions. Currently, MANET is not considering fast or
seamless handoff. seamless handover.
In many instances, for example small residential networks found in In many instances, for example small residential networks found in
the home, the network may be relatively small and has far less the home, the network may be relatively small and has far less
dynamics. The network may still have a requirement for fast and/or dynamics. The network may still have a requirement for fast and/or
seamless handoffs. For this reason there may be some overlap between seamless handovers. For this reason there may be some overlap
SeaMoby and ad-hoc networking solutions. Therefore, SeaMoby MUST be between SeaMoby and ad-hoc networking solutions. Therefore, SeaMoby
able to co-exist gracefully with any MANET solutions algorithm that MUST be able to co-exist gracefully with any MANET solutions
does become standardized. algorithm that does become standardized.
4 Scenarios 4 Scenarios
This section is intended as to provide some simple, descriptive This section is intended as to provide some simple, descriptive
examples of the problem. The network is based on Figure 1, in 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, section 1.4. In the scenarios, the term mobile node (MN) is used,
but the node could be a mobile host, mobile router, etc. 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 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. 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 the city, I can be reached through ISP Y's cellular network, AD2
in Figure 1. in Figure 1.
4.1 Intra-domain mobility 4.1 Intra-domain mobility
Company X provides mobility service to its employees within the Company X provides mobility service to its employees within the
intra-net AD1. The IP address of a mobile host remains fixed intra-net AD1. The IP address of a mobile host remains fixed
regardless of its attachment point within the administrative domain. regardless of its attachment point within the administrative domain.
4.1.1 Handoff Within a Subnet 4.1.1 Handover Within a Subnet
The MN moves out of AP3 (802.11) coverage area, and can select AP2 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 (802.11) or AP1 (Bluetooth), which are all connected on the same
subnet (e.g. - Ethernet) to AR1. One characteristic of Bluetooth is subnet (e.g. - Ethernet) to AR1.
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 On each handover, the new access point must ensure sufficient
capacity to support traffic related to the mobile node aside of pre- capacity to support traffic related to the mobile node aside of pre-
existing connections. In this example, the Bluetooth access point existing connections. In this example, the Bluetooth access point
AP1 experiences temporary environmental noise (e.g. - an oven), and AP1 experiences temporary environmental noise (e.g. - an oven), and
the corresponding loss of available capacity. Therefore, a handoff the corresponding loss of available capacity. Therefore, a handover
to AP2 is selected. This is an intra-AR handoff between APs of the to AP2 is selected. This is an intra-AR handover between APs of the
same technology. In this case Inter-AP protocol (e.g. - 802.11 IAPP) same technology. In this case Inter-AP protocol (e.g. - 802.11 IAPP)
will be used to do handoff. will be used to do handover.
Later, the MN moves to an area that is only covered by AP1 Later, the MN moves to an area that is only covered by AP1
(Bluetooth), so an inter-technology handoff occurs between AP2 (Bluetooth), so an inter-technology handover occurs between AP2
(802.11) to AP1 (Bluetooth) (802.11) to AP1 (Bluetooth)
4.1.2 Seamless Intra-domain Mobility With Optimized Routing. 4.1.2 Seamless Intra-domain Mobility With Optimized Routing.
A user establishes a video phone call with a colleague. During the A user establishes a video phone call with a colleague. During the
call both parties move around the building; their Mobile Nodes hop call both parties move around the building; their Mobile Nodes hop
between subnets while changing their attachment point. However, between subnets while changing their attachment point. However,
there is no degradation in the quality of the video phone call. The there is no degradation in the quality of the video phone call. The
network continuously maintains an optimized communication path network continuously maintains an optimized communication path
between the two mobile nodes. More precisely, the path for a session between the two mobile nodes. More precisely, the path for a session
skipping to change at page 1, line 500 skipping to change at page 1, line 534
domain with the same IP address that I used to roam within X domain. 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 The ISP Y provides under this agreement best effort connectivity to
me (using the IP address assigned by X) for some time, before it 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 requires me to perform Mobile-IP, e.g. for negotiating new IP
address, issuing BUs, doing AAA, etc. As a result of Mobile-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 processing, I will get a new IP address for roaming within Y's
domain, and other contracted services, such as QoS. The ISP Y domain, and other contracted services, such as QoS. The ISP Y
provides best effort connectivity for the transitory period, because provides best effort connectivity for the transitory period, because
it must perform authentication and authorization, and retrieve it must perform authentication and authorization, and retrieve
user's service (QoS) profile, before providing QoS and other user's service (QoS) profile, before providing QoS and other
contracted services. This is an instance of fast handoff handled by contracted services. This is an instance of fast handover handled by
local mobility protocol first, then an inter-domain mechanism (e.g. local mobility protocol first, then an inter-domain mechanism (e.g.
Mobile-IP)is invoked for AAA and contracted services. Mobile-IP)is invoked for AAA and contracted services.
4.2.2 Local mobility restricted to a single domain 4.2.2 Local mobility restricted to a single domain
When I drive to the supermarket, I enter Y's domain. My company X 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 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 network and receive my contracted services. The ISP Y first assigns
me a new IP address before providing me connectivity. Hence, as soon 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 as I discover that I am in Y's domain, I must initiate Mobile-IP
skipping to change at page 1, line 543 skipping to change at page 1, line 577
a location, or the service provider want to expand its wireless a location, or the service provider want to expand its wireless
service to a new area. When the new equipment connected to the service to a new area. When the new equipment connected to the
network, the new routers/agents can learn how to forward data network, the new routers/agents can learn how to forward data
packets by automatically learning from neighbors or other sources. A packets by automatically learning from neighbors or other sources. A
new access point should learn the capability of its neighboring APs. new access point should learn the capability of its neighboring APs.
This automatic learning process enables plug and play capability This automatic learning process enables plug and play capability
4.3.3 Local-mobility Protocol in Different ADs 4.3.3 Local-mobility Protocol in Different ADs
The local mobility domain can have one-to-one mapping to the The local mobility domain can have one-to-one mapping to the
administrative domain. In this deployment case, a handoff between administrative domain. In this deployment case, a handover between
two ADs requires change of the routable IP address of the mobile 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 node. In this case a macro-mobility protocol, such as Mobile IP, is
needed inter-domain handoff. needed inter-domain handover.
A local mobility domain can span multiple ADs if a trust A local mobility domain can span multiple ADs if a trust
relationship exists between them allowing the use of the same relationship exists between them allowing the use of the same
routable IP address across ADs. routable IP address across ADs.
4.4 Summary 4.4 Summary
AD Administrative Domain AD Administrative Domain
MD Mobility Domain MD Mobility Domain
SN Subnet SN Subnet
skipping to change at page 1, line 583 skipping to change at page 1, line 617
Plug & Play | X | X | Plug & Play | X | X |
(1)except for those participating in the inter-AP protocol in the (1)except for those participating in the inter-AP protocol in the
same subnet same subnet
(2)transparent at least to anyone outside of the MD (2)transparent at least to anyone outside of the MD
(3)transparent to the CN, and only if reverse tunneling is used (3)transparent to the CN, and only if reverse tunneling is used
(4) proprietary at the moment (4) proprietary at the moment
(5) may be redundant in some cases where the L2 provides similar/same (5) may be redundant in some cases where the L2 provides similar/same
mechanisms. mechanisms.
5 Security Considerations 5 Next Steps
It is proposed that the next steps be:
* Setting of requirements for local mobility
* Proposal of solutions
* Analysis of solutions
* Recommendation of micromobility solution
In the analysis, a critical piece will be to identify the
shortcomings of Mobile IP.
6 Security Considerations
This type of non-protocol document does not directly affect the This type of non-protocol document does not directly affect the
security of the Internet. security of the Internet.
6 IANA Considerations 7 IANA Considerations
This document does not directly affect IANA. This document does not directly affect IANA.
7 Acknowledgments 8 Acknowledgments
The authors would like to thank Kulwinder Atwal, Peter Lei, Charlie The authors would like to thank Kulwinder Atwal, Peter Lei, Charlie
Perkins, Michael A. Ramalho, Luca Salgarelli, Hesham Soliman, Perkins, Michael A. Ramalho, Philip Roberts, Luca Salgarelli, Hesham
Michael Thomas and Mika Ylianttila for their comments and Soliman, Michael Thomas, George Tsirtsis, and Mika Ylianttila for
contributions to this document. their comments and contributions to this document.
8 Author's Addresses 9 Author's Addresses
John Loughney (editor) John Loughney (editor)
Nokia Research Center Nokia Research Center
PO Box 407 PO Box 407
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
john.loughney@nokia.com john.loughney@nokia.com
Dana Blair Dana Blair
Cisco Cisco
skipping to change at page 1, line 676 skipping to change at page 1, line 720
Guilhem Tardy Guilhem Tardy
Nortel Networks Nortel Networks
100 Constellation Crescent 100 Constellation Crescent
Nepean, ON K2G 6J8 Nepean, ON K2G 6J8
Canada Canada
Phone: 1-613-763-1953 Phone: 1-613-763-1953
guilhem.tardy@nortelnetworks.com guilhem.tardy@nortelnetworks.com
9 References 10 References
[2002] Perkins, C., "IP Mobility Support". Internet [2002] Perkins, C., "IP Mobility Support". Internet
Engineering Task Force, Request for Comments (RFC) Engineering Task Force, Request for Comments (RFC)
2002, October 1996. 2002, October 1996.
[2460] Deering, S., and Hinden, R. (Editors); "Internet [2460] Deering, S., and Hinden, R. (Editors); "Internet
Protocol, Version 6 (IPv6) Specification"; RFC 2460, Protocol, Version 6 (IPv6) Specification"; RFC 2460,
December 1998. December 1998.
[2753] Yavatkar, R., Pendarakis, D., Guerin, R.; "A [2753] Yavatkar, R., Pendarakis, D., Guerin, R.; "A
skipping to change at page 1, line 698 skipping to change at page 1, line 742
2753; January 2000. 2753; January 2000.
[MIPv6] David B. Johnson, Charles Perkins, "Mobility Support [MIPv6] David B. Johnson, Charles Perkins, "Mobility Support
in IPv6", draft-ietf-mobileip-ipv6-12.txt, April in IPv6", draft-ietf-mobileip-ipv6-12.txt, April
2000. 2000.
[SM Terms] Manner, J. et al; "Mobility Related Terminology"; [SM Terms] Manner, J. et al; "Mobility Related Terminology";
<draft-manner-seamoby-terms-00.txt>; Work In <draft-manner-seamoby-terms-00.txt>; Work In
Progress; January 12, 2001. Progress; January 12, 2001.
[Fast MIP6] Perkins, C., Editor, "Fast Handoffs for Mobile IPv6", [Fast MIP6] Tsirtsis, G. (Editor), "Fast Handovers for Mobile
draft-perkins-mobileip-handoff-01.txt, a work in IPv6", draft-ietf-mobileip-fast-mipv6-00.txt, a work
progress; February 2001. in progress; February 2001.
[DSR] Johnson, D. et al. "The Dynamic Source Routing
Protocol for Mobile Ad Hoc Networks"; <draft-ietf-
manet-dsr-04.txt>; Work in Progress; November 17,
2000.
[TORA] Park, V. et al. "Temporally-Ordered Routing Algorithm
(TORA) Version 1 Functional Specification"; <draft-
ietf-manet-tora-spec-03.txt>; Work in Progress;
November 24, 2000.
[2501] Corson, S.; Macker, J.; "Mobile Ad hoc Networking
(MANET): Routing Protocol Performance Issues and
Evaluation Considerations"; RFC 2501; January 1999.
[MIP RSVP] Thomas, M.; "Analysis of Mobile IP and RSVP
Interactions"; <draft-thomas-seamoby-rsvp-analysis-
00.txt>; work in progress; February 12, 2001.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/