draft-ietf-mipshop-lmm-requirements-00.txt draft-nikander-mipshop-lmm-goals-00-pre-Nov06.txt
mipship C. Williams Network Working Group C. Williams
Internet-Draft MCSR Labs Internet-Draft MCSR Labs
Expires: May 6, 2004 November 6, 2003 Expires: May 6, 2004 P. Nikander
Ericsson Research Nomadiclab
November 6, 2003
Localized Mobility Management Requirements Localized Mobility Management Goals
draft-ietf-mipshop-lmm-requirements-00 draft-nikander-mipshop-lmm-goals-00
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 RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
  Skipping to change at page 1, line 38:
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 6, 2004. This Internet-Draft will expire on May 6, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document describes requirements for Localized Mobility This document describes goals for Localized Mobility Management (LMM)
Management (LMM) for Mobile IP and Mobile IPv6 protocols. These for IP layer mobility, such Mobile IP and Mobile IPv6. These goals
requirements are intended to guide the design of a protocol are intended to guide the design of a protocol specification for LMM.
specification for LMM. Localized Mobility Management, in general, Localized Mobility Management, in general, introduces enhancements to
introduces enhancements to Mobile IPv4 and Mobile IPv6 to reduce the IP layer mobility protocols to reduce the amount of latency in IP
amount of latency in binding updates sent to the Home Agent and, for layer mobility management messages exchanged between a Mobile Node
route-optimization, Correspondent Nodes, upon Care of Address change. (MN) and its peer entities. In addition, LMM seeks to reduce the
In addition, LMM seeks to reduce the amount of signaling over the amount of signaling over the global Internet when a mobile node
global Internet when a mobile node traverses within a defined local traverses within a defined local domain. The identified goals are
domain. The identified requirements are essential for localized essential for localized mobility management functionality. They are
mobility management functionality. They are intended to be used as a intended to be used as a guide for analysis on the observed benefits
guide for analysis on the observed benefits over the identified over the identified goals for architecting and deploying LMM schemes.
requirements for architecting and deploying LMM schemes.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Intra-domain mobility . . . . . . . . . . . . . . . . . . 6 3.1 Intra-domain mobility . . . . . . . . . . . . . . . . . . 6
3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Security provisioning . . . . . . . . . . . . . . . . . . 6 3.2.1 Security provisioning . . . . . . . . . . . . . . . . . . 6
3.2.2 Non-interference with HA-MN . . . . . . . . . . . . . . . 6 3.2.2 Non-interference with peer entities . . . . . . . . . . . 6
3.2.3 Non-interference with CN-MN . . . . . . . . . . . . . . . 6 3.2.3 No new vulnerabilities . . . . . . . . . . . . . . . . . . 6
3.2.4 No new vulnerabilities . . . . . . . . . . . . . . . . . . 6
3.3 Induced LMM functional requirements . . . . . . . . . . . 6 3.3 Induced LMM functional requirements . . . . . . . . . . . 6
3.3.1 No additional functionality at HA or CN . . . . . . . . . 7 3.3.1 No additional functionality at peer entities . . . . . . . 6
3.3.2 No changes to existing components . . . . . . . . . . . . 7 3.3.2 No changes to existing components . . . . . . . . . . . . 7
3.3.3 No additional messages to CN or HA . . . . . . . . . . . . 7 3.3.3 No additional messages to peer entities . . . . . . . . . 7
3.4 Scalability, Reliability, and Performance . . . . . . . . 7 3.4 Scalability, Reliability, and Performance . . . . . . . . 7
3.4.1 Linear complexity . . . . . . . . . . . . . . . . . . . . 7 3.4.1 Linear complexity . . . . . . . . . . . . . . . . . . . . 7
3.4.2 Linear routing state growth . . . . . . . . . . . . . . . 7 3.4.2 Linear routing state growth . . . . . . . . . . . . . . . 7
3.4.3 No additional points of failure . . . . . . . . . . . . . 7 3.4.3 No additional points of failure . . . . . . . . . . . . . 7
3.4.4 No worse performance . . . . . . . . . . . . . . . . . . . 8 3.4.4 No worse performance . . . . . . . . . . . . . . . . . . . 7
3.4.5 Scalable expansion of the network . . . . . . . . . . . . 8 3.4.5 Scalable expansion of the network . . . . . . . . . . . . 8
3.4.6 Resilience to topological changes . . . . . . . . . . . . 8 3.4.6 Resilience to topological changes . . . . . . . . . . . . 8
3.4.7 Header or Tunneling overhead . . . . . . . . . . . . . . . 8 3.4.7 Header or Tunneling overhead . . . . . . . . . . . . . . . 8
3.4.8 Optimized signaling within the Local Coverage Area . . . . 8 3.4.8 Optimized signaling within the Local Coverage Area . . . . 8
3.5 Mobility Management Support . . . . . . . . . . . . . . . 9 3.5 Mobility Management Support . . . . . . . . . . . . . . . 8
3.5.1 No increase of latency or packet loss . . . . . . . . . . 9 3.5.1 No increase of latency or packet loss . . . . . . . . . . 9
3.5.2 No increase of service disruption . . . . . . . . . . . . 9 3.5.2 No increase of service disruption . . . . . . . . . . . . 9
3.5.3 No new messages to HA or CN . . . . . . . . . . . . . . . 9 3.5.3 No new messages to peer entities . . . . . . . . . . . . . 9
3.6 Auto-configuration capabilities for LMM constituents . . . 9 3.6 Auto-configuration capabilities for LMM constituents . . . 9
3.7 LMM inter-working with IP routing infrastructure . . . . . 9 3.7 LMM inter-working with IP routing infrastructure . . . . . 9
3.8 Sparse routing element population . . . . . . . . . . . . 9 3.8 Sparse routing element population . . . . . . . . . . . . 9
3.9 Support for Mobile IPv4 or Mobile IPv6 Handover . . . . . 10 3.9 Support for Mobile IPv4 or Mobile IPv6 Handover . . . . . 10
3.10 Simple Network design . . . . . . . . . . . . . . . . . . 10 3.10 Simple Network design . . . . . . . . . . . . . . . . . . 10
3.11 Stability . . . . . . . . . . . . . . . . . . . . . . . . 10 3.11 Stability . . . . . . . . . . . . . . . . . . . . . . . . 10
3.12 Quality of Service requirements . . . . . . . . . . . . . 10 3.12 Quality of Service requirements . . . . . . . . . . . . . 10
3.12.1 Co-exist with end-to-end QoS . . . . . . . . . . . . . . . 10 3.12.1 Co-exist with end-to-end QoS . . . . . . . . . . . . . . . 10
3.12.2 Co-exist with link-local QoS . . . . . . . . . . . . . . . 11 3.12.2 Co-exist with link-local QoS . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . 12
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 13
Normative references . . . . . . . . . . . . . . . . . . . 14 Normative references . . . . . . . . . . . . . . . . . . . 14
Informative References . . . . . . . . . . . . . . . . . . 15 Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
A. LMM requirements and HMIPv6 . . . . . . . . . . . . . . . 16 A. LMM requirements and HMIPv6 . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . 17
1. Introduction 1. Introduction
In order to meet the demands of real-time applications and the In order to meet the demands of real-time applications and the
expectations of future wireless users for service level quality expectations of future wireless users for service level quality
similar to the one of wireline users, IP based mobility management is similar to the one of wireline users, IP layer mobility management is
facing a number of technical challenges in terms of performance and facing a number of technical challenges in terms of performance and
scalability [4] [5] [6]. These manifest themselves as increased scalability [4] [5] [6]. These manifest themselves as increased
latencies in the control signaling between a Mobile Node and its peer latencies in the control signaling between a Mobile Node and its peer
entities, namely the Home Agent (HA) and its Corresponding Nodes entities, namely the Home Agent (HA) and its Corresponding Nodes
(CNs). (CNs).
In the base Mobile IP protocol [2] [3], movement between two subnets In the base Mobile IP protocols [2] [3], movement between two subnets
requires that the Mobile Node obtain a new Care of Address in the new requires that the Mobile Node obtain a new care-of address in the new
subnet. This allows the Mobile Node to receive traffic on the new subnet. This allows the Mobile Node to receive traffic on the new
subnet. In order for the routing change to become effective, subnet. In order for the routing change to become effective,
however, the Mobile Node must issue a binding update (also known in however, the Mobile Node must issue a binding update (also known in
Mobile IPv4 as a Home Agent registration) to the Home Agent so that Mobile IPv4 as a Home Agent registration) to the Home Agent so that
the Home Agent can change the routing from the previous subnet to the the Home Agent can change the routing from the previous subnet to the
new subnet. The binding update establishes a host route on the Home new subnet. The binding update establishes a host route on the Home
Agent between the Mobile Node's Home Address and its new Care of Agent between the Mobile Node's Home Address and its new care-of
Address. In addition, if route optimization is in use [3], the address. In addition, if route optimization is in use [3], the
Mobile Node may also issue binding updates to Correspondent Nodes to Mobile Node may also issue binding updates to Correspondent Nodes to
allow them to send traffic directly to the new Care of Address rather allow them to send traffic directly to the new care-of address rather
than tunneling their traffic through the Home Agent. than tunneling their traffic through the Home Agent.
Traffic destined for the Mobile Node is sent to the old Care of The same approach applies also to a number of other IP layer mobility
Address and is, effectively, dropped until the Home Agent processes management protocols. For example, in the Host Identity Protocol
the MIPv6 Binding Update or MIPv4 Home Agent Registration. If the (HIP) mobility management scheme, a Mobile Node sends an Readdress
Mobile Node is at some geographical and topological distance away (REA) packet to its peer; this is very similar the Binding Updates
from the Home Agent and Correspondent Nodes, the amount of time send in Mobile IPv6 Route Optimization. In general, IP layer
involved in sending the binding updates may be greater than 100 mobility protocols maintain a binding between a host identifier and
hundred milliseconds. This latency in routing update may cause some either one care-of address or a set of care-of addresses. In Mobile
packets for the Mobile Node to be lost at the old Access Router. IP, the home address acts as the host identifier, and only one
Recently, Mobile IP has been extended by certain local mobility care-of address is allowed. In other IP layer mobility protocols the
mechanisms, aiming to alleviate the above performance limitations; host identifier is typically something else and more than one care-of
they are identified as hierarchical/regional or more generically addresses may be allowed.
Localized Mobility Management (LMM).
After movement, traffic destined for the Mobile Node is sent to the
old care-of address and is, effectively, dropped until the peer
entities processes mobility management messages. If the Mobile Node
is at some geographical and topological distance away from a peer
entity, the amount of time involved in sending the binding updates
may be greater than 100 hundred milliseconds. This latency in routing
update may cause some packets for the Mobile Node to be lost at the
old Access Router. Recently, Mobile IP has been extended by certain
local mobility mechanisms, aiming to alleviate the above performance
limitations; they are identified as hierarchical/regional or more
generically Localized Mobility Management (LMM).
LMM Localized mobility management schemes allow the Mobile Node to LMM Localized mobility management schemes allow the Mobile Node to
continue receiving traffic on the new subnet without any change in continue receiving traffic on the new subnet without any change in
the Home Agent or Correspondent Node binding. The latency involved in the bindings at the peer entities. The latency involved in updating
updating the Care of Address bindings at far geographical and the care-of-address bindings at far geographical and topological
topological distances is eliminated or reduced until such time as the distances is eliminated or reduced until such time as the Mobile Node
Mobile Node is in a position to manage the latency cost. is in a position to manage the latency cost.
Having provided some motivation and brief summary of the underlying Having provided some motivation and brief summary of the underlying
principles of LMM, it is important to enumerate goals for LMM. principles of LMM, it is important to enumerate goals for LMM.
Goals for LMM: Goals for LMM:
o reduce the signaling induced by changes in the point of attachment o reduce the signaling induced by changes in the point of attachment
due to the movement of a host; reduction in signaling delay will due to the movement of a host; reduction in signaling delay will
minimize packet loss and possible session loss; minimize packet loss and possible session loss;
  Skipping to change at page 5, line 7:
aforementioned considerations becomes essential in designing a widely aforementioned considerations becomes essential in designing a widely
accepted solution. The remainder of this document present a set of accepted solution. The remainder of this document present a set of
requirements that encompass essential considerations for the design requirements that encompass essential considerations for the design
of an LMM scheme. It is with this foundation that we can seek to of an LMM scheme. It is with this foundation that we can seek to
ensure that the resulting LMM solution will best preserve the ensure that the resulting LMM solution will best preserve the
fundamental philosophies and architectural principles of the Internet fundamental philosophies and architectural principles of the Internet
in practice today. in practice today.
2. Terminology 2. Terminology
Please also see [7] for mobility terminology used in this document. See [7] for mobility terminology used in this document.
Peer entity A generic name used for nodes that communicate with a
mobile node. In Mobile IP and IPv6, the Home Agent and
Correspondent Node are peer entities.
3. Requirements 3. Requirements
This section describes the requirements for a LMM solution. The This section describes the requirements for a LMM solution. The
requirements are relevant to both Mobile IPv4 and Mobile IPv6. requirements are relevant to both all IP layer local mobility
management schemes, independent of the actual IP layer macro mobility
protocol.
3.1 Intra-domain mobility 3.1 Intra-domain mobility
LMM is introduced to minimize the signaling traffic to the Home Agent LMM is introduced to minimize the signaling traffic to the peer
and/or Correspondent Node(s) for intra-domain mobility (within a entities, e.g. Home Agent and/or Correspondent Node(s), for
Local Coverage Area). This is the fundamental reason for introducing intra-domain mobility (within a Local Coverage Area). This is the
localized mobility management extensions to core Mobile IPv6. In the fundamental reason for introducing localized mobility management. In
LMM infrastructure a Correspondent Node or Home Agent outside the the LMM infrastructure a peer entity outside the administration
administration domain MUST always be able to address the mobile host domain MUST always be able to address the mobile host by the same IP
by the same IP address, so that from the point of view of hosts address, so that from the point of view of hosts outside the
outside the administration domain, the IP address of the mobile host administration domain, the IP address of the mobile host remains
remains fixed regardless of any changes in the Mobile Node's subnet. fixed regardless of any changes in the Mobile Node's subnet.
3.2 Security 3.2 Security
3.2.1 Security provisioning 3.2.1 Security provisioning
LMM protocol MUST provide for "security provisioning" within the LMM protocol MUST provide for "security provisioning" within the
respective local coverage area. respective local coverage area.
The security of exchanging LMM specific information and signaling The security of exchanging LMM specific information and signaling
MUST be ensured. Security provisioning includes protecting the MUST be ensured. Security provisioning includes protecting the
integrity, confidentiality, and authenticity of the transfer of LMM integrity, confidentiality, and authenticity of the transfer of LMM
specific information within the administration domain. If applicable, specific information within the administration domain. If applicable,
replay protection MUST exist mutually between the LMM agents. replay protection MUST exist mutually between the LMM agents.
3.2.2 Non-interference with HA-MN 3.2.2 Non-interference with peer entities
LMM protocol MUST NOT interfere with the security provisioning that
exists between the Home Agent and the Mobile Node.
3.2.3 Non-interference with CN-MN
LMM protocol MUST NOT interfere with the security provisioning that LMM protocol MUST NOT interfere with the security provisioning that
exists between the Correspondent Node and the Mobile Node. exists between the peer entities and the Mobile Node.
3.2.4 No new vulnerabilities 3.2.3 No new vulnerabilities
LMM protocol MUST NOT introduce new security holes or the possibility LMM protocol MUST NOT introduce new security holes or the possibility
for DOS-style attacks. for DOS-style attacks.
3.3 Induced LMM functional requirements 3.3 Induced LMM functional requirements
3.3.1 No additional functionality at HA or CN 3.3.1 No additional functionality at peer entities
Any Localized Mobility Management protocol MUST NOT inject any Any Localized Mobility Management protocol MUST NOT inject any
additional functionality over base Mobility [2] [3] at the Home Agent additional functionality over the base IP layer macro mobility
or any of its peer CNs. Thus, the LMM framework MUST NOT add any protocol employed. Thus, the LMM framework MUST NOT add any
modifications or extensions to the Correspondent Node(s) and Home modifications or extensions to the peer entities, including Mobile IP
Agent. It is essential to minimize the involvement of the Mobile Node or Mobile IPv6 Correspondent Node(s) and Home Agents. It is
in routing beyond what is in the basic MIP and MIpv6 protocol. essential to minimize the involvement of the Mobile Node in routing
Preferences, load balancing, and other complex schemes requiring beyond what is in the basic mobility protocol. Preferences, load
heavy mobile node involvement in the mobility management task SHOULD balancing, and other complex schemes requiring heavy mobile node
BE avoided. involvement in the mobility management task SHOULD BE avoided.
3.3.2 No changes to existing components 3.3.2 No changes to existing components
Non-LMM-aware routers, hosts, Home Agents, and Mobile Nodes MUST be Non-LMM-aware routers, hosts, Mobile IP and IPv6 Home Agents, and
able to interoperate with LMM agents. Mobile Nodes MUST be able to interoperate with LMM agents.
3.3.3 No additional messages to CN or HA 3.3.3 No additional messages to peer entities
The LMM framework MUST NOT increase the number of messages between The LMM framework MUST NOT increase the number of messages between
the mobile host and the respective Correspondent Node(s) and Home the mobile host and the respective peer entities. Indeed, the LMM
Agent. Indeed, the LMM framework MUST minimize the global signaling framework MUST minimize the global signaling between the MN and its
between the MN and its peers. The amount of regional signaling MUST peers. The amount of regional signaling MUST NOT surpass the amount
NOT surpass the amount of global signaling that would have otherwise of global signaling that would have otherwise occurred if LMM were
occurred if LMM were not present. not present.
3.4 Scalability, Reliability, and Performance 3.4 Scalability, Reliability, and Performance
3.4.1 Linear complexity 3.4.1 Linear complexity
The LMM complexity MUST increase at most linearly with the size of The LMM complexity MUST increase at most linearly with the size of
the local domain and the number of Mobile Nodes. the local domain and the number of Mobile Nodes.
3.4.2 Linear routing state growth 3.4.2 Linear routing state growth
Any Localized Mobility Management protocol MUST assure that that LMM Any Localized Mobility Management protocol MUST assure that that LMM
routing state scales at most linearly with the number of Mobile Nodes routing state scales at most linearly with the number of Mobile Nodes
registered, and that the increase in routing state is confined to registered, and that the increase in routing state is confined to
those ARs/ANRs involved in implementing the LMM protocol at hand. those ARs/ANRs involved in implementing the LMM protocol at hand.
This would involve MIP-specific routing state as binding caches in While host routes apparently cannot be eliminated by any mobility
addition to standard routing table host routes. While host routes management protocol including base IP mobility, any LMM protocol MUST
cannot be eliminated by any mobility management protocol including keep the number of host routes to a minimum.
base IP mobility, any LMM protocol MUST keep the number of host
routes to a minimum.
3.4.3 No additional points of failure 3.4.3 No additional points of failure
The LMM framework MUST NOT introduce additional points of failure in The LMM framework MUST NOT introduce additional points of failure in
the network. The current access router would be excluded from this the network. The current access router would be excluded from this
requirement. requirement.
3.4.4 No worse performance 3.4.4 No worse performance
The LMM framework MUST NOT interfere with the basic IP mobility The LMM framework MUST NOT interfere with the basic IP mobility
performance of a mobile host communications with a Correspondent performance of a mobile host communications with a peer entity.
Node(s).
3.4.5 Scalable expansion of the network 3.4.5 Scalable expansion of the network
The LMM framework MUST allow for scalable expansion of the network The LMM framework MUST allow for scalable expansion of the network
and provide for reasonable network configuration with regard to and provide for reasonable network configuration with regard to
peering, inter-administrative domain connectivity, and other peering, inter-administrative domain connectivity, and other
inter-administrative domain interoperability characteristics of inter-administrative domain interoperability characteristics of
interest to wireless ISPs. The LMM framework MUST NOT introduce any interest to wireless ISPs. The LMM framework MUST NOT introduce any
additional restrictions in how wireless ISPs configure their network, additional restrictions in how wireless ISPs configure their network,
nor how they interconnect with other networks beyond those introduced nor how they interconnect with other networks beyond those introduced
  Skipping to change at page 8, line 44:
The LMM framework MUST not prevent header compression from being The LMM framework MUST not prevent header compression from being
applied. It is recommended that andidate LMM designs that require applied. It is recommended that andidate LMM designs that require
additional header overhead for tunnel be reviewed by the ROHC working additional header overhead for tunnel be reviewed by the ROHC working
group to determine if the header compressor can be restarted from group to determine if the header compressor can be restarted from
transferred compressor context when handover occurs without requiring transferred compressor context when handover occurs without requiring
any full header packet exchange on the new link. any full header packet exchange on the new link.
3.4.8 Optimized signaling within the Local Coverage Area 3.4.8 Optimized signaling within the Local Coverage Area
By its very nature, LMM reintroduces triangle routing into Mobile By its very nature, LMM reintroduces triangle routing into the base
IPv6 in that all traffic must go through the LMM agent. There is no IP layer mobility protocol in that all traffic must go through the
way to avoid this. The LMM framework SHOULD be designed in such a way LMM agent. There is no way to avoid this. The LMM framework SHOULD be
as to reduce the length of the unwanted triangle leg. The LMM design designed in such a way as to reduce the length of the unwanted
SHOULD not prohibit optimal placement of LMM agents to reduce or triangle leg. The LMM design SHOULD not prohibit optimal placement
eliminate additional triangle routing introduced by LMM. of LMM agents to reduce or eliminate additional triangle routing
introduced by LMM.
NOTE: It is not required that a LMM scheme specify LMM agents as part NOTE: It is not required that a LMM scheme specify LMM agents as part
of its solution. of its solution.
3.5 Mobility Management Support 3.5 Mobility Management Support
The following LMM requirements pertain to both inter-domain and The following LMM requirements pertain to both inter-domain and
intra-domain hand-off. intra-domain hand-off.
3.5.1 No increase of latency or packet loss 3.5.1 No increase of latency or packet loss
The LMM framework MUST NOT increase the amount of latency or amount The LMM framework MUST NOT increase the amount of latency or amount
of packet loss that exists with the core Mobile IP and Mobile IPv6 of packet loss, compared to what exists with the core Mobile IP and
specification [2] [3]. Indeed, the LMM framework SHOULD decrease the Mobile IPv6 specification [2] [3]. Indeed, the LMM framework SHOULD
amount of latency or amount of packet loss that exists with the core decrease the amount of latency or amount of packet loss that exists
mobility protocols. with the core mobility protocols.
3.5.2 No increase of service disruption 3.5.2 No increase of service disruption
The LMM framework MUST NOT increase the amount of service disruption The LMM framework MUST NOT increase the amount of service disruption,
that already exists with the core mobility specifications. Again, compared to that already exists with the Mobile IP and Mobile IPv6
the LMM framework SHOULD decrease the amount of service disruption core mobility specifications. Again, the LMM framework SHOULD
that already exists with the core mobility protocols. decrease the amount of service disruption that already exists with
the IP layer mobility management protocols.
3.5.3 No new messages to HA or CN 3.5.3 No new messages to peer entities
The LMM framework MUST NOT increase the number of messages between The LMM framework MUST NOT increase the number of messages between
the mobile host and the respective Correspondent Node(s) and Home the mobile host and the respective peer entities. The LMM framework
Agent as is in the core mobility specifications [2] [3]. The LMM SHOULD decrease the number of messages between the mobile host and
framework SHOULD decrease the number of messages between the mobile the respective peer entities. With respect to Mobile IP and Mobile
host and the respective Correspondent Node(s) and Home Agent as is in IPv6, the current number of messages is defined in the Mobile IP core
the core mobility specifications [2] [3]. mobility specifications [2] [3].
3.6 Auto-configuration capabilities for LMM constituents 3.6 Auto-configuration capabilities for LMM constituents
It is desirable that in order to allow for simple incremental It is desirable that in order to allow for simple incremental
deployment of an LMM scheme, the local mobility agents MUST require deployment of an LMM scheme, the local mobility agents MUST require
minimal (if any) manual configuration. This plug-and-play feature minimal (if any) manual configuration. This plug-and-play feature
could make use of IPv6 auto-configuration mechanisms in the case of could make use of IPv6 auto-configuration mechanisms in the case of
Mobile IPv6 [3], even though most likely other automatic IPv6, even though most likely other automatic configurations will be
configurations will be needed (such as, for example, learning about needed (such as, for example, learning about adjacent LMM agents).
adjacent LMM agents). Auto-configuration also facilitates the network Auto-configuration also facilitates the network to dynamically adapt
to dynamically adapt to general topological changes (whether planned to general topological changes (whether planned or due to link or
or due to link or node failures). node failures).
3.7 LMM inter-working with IP routing infrastructure 3.7 LMM inter-working with IP routing infrastructure
The LMM framework MUST NOT disrupt core IP routing outside the local The LMM framework MUST NOT disrupt core IP routing outside the local
domain. domain.
3.8 Sparse routing element population 3.8 Sparse routing element population
Any LMM protocol MUST be designed to be geared towards incremental Any LMM protocol MUST be designed to be geared towards incremental
deployment capabilities; the latter implies that the LMM scheme deployment capabilities; the latter implies that the LMM scheme
itself imposes minimum requirements on the carrierÂ’s network. itself imposes minimum requirements on the carrierÂ’s network.
Incremental deployment capabilities for an LMM protocol signifies Incremental deployment capabilities for an LMM protocol signifies
that an initial set of sparse LMM agents can populate the that an initial set of sparse LMM agents can populate the
administration domain of a network provider and operate sufficiently. administration domain of a network provider and operate sufficiently.
In addition, any LMM scheme MUST be compatible with any additional In addition, any LMM scheme MUST be compatible with any additional
deployment of LMM agents in future infrastructure expansions; that is deployment of LMM agents in future infrastructure expansions; that is
to say, allow progressive LMM deployment capabilities. to say, allow progressive LMM deployment capabilities.
  Skipping to change at page 15, line 15:
Informative References Informative References
[8] Koodli, R., "Fast Handovers for Mobile IPv6", [8] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mobileip-fast-mipv6-07 (work in progress), September draft-ietf-mobileip-fast-mipv6-07 (work in progress), September
2003. 2003.
[9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, [9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)", "Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mobileip-hmipv6-08 (work in progress), July 2003. draft-ietf-mobileip-hmipv6-08 (work in progress), July 2003.
Author's Address Authors' Addresses
Carl Williams Carl Williams
MCSR Labs MCSR Labs
3790 El Camino Real 3790 El Camino Real
Palo Alto, CA 94306 Palo Alto, CA 94306
USA USA
Phone: +1 650 279 5903 Phone: +1 650 279 5903
EMail: carlw@mcsr-labs.org EMail: carlw@mcsr-labs.org
Pekka Nikander
Ericsson Research Nomadiclab
Jorvas FI-02420
Finland
Phone: +358 9 299 1
EMail: pekka.nikander@nomadiclab.com
Appendix A. LMM requirements and HMIPv6 Appendix A. LMM requirements and HMIPv6
HMIPv6 was evaluated as a localized mobility management protocol, and HMIPv6 was evaluated as a localized mobility management protocol, and
that it was mostly found to satisfy the requirements put forth in that it was mostly found to satisfy the requirements put forth in
this document. This section details one exception with some this document. This section details one exception with some
explanation. explanation.
Exception 1: Exception 1: