Mobile IPv6 Extensions (mext) C. Perkins
Internet-Draft Tellabs
Intended status: Informational Dapeng. Liu
Expires: January 5, 2012 China Mobile
Jul 4, 2011
DMM Comparison Matrix
draft-perkins-dmm-matrix-00
Abstract
Distributed Mobility Management (DMM) is proposed as a way to enable
scalable growth of mobile core networks so that network service
providers can meet new requirements for performance and reduced
operational expenditures. This requires reconsideration of existing
approaches within the IETF and elsewhere in order to determine which
if any such approaches may be used as part of a DMM solution.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 5, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Perkins & Liu Expires January 5, 2012 [Page 1]
Internet-Draft DMM Comparison Matrix Jul 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Matrix Comparing Existing Approaches for DMM . . . . . . . . . 4
3. Explanations for Matrix Entries . . . . . . . . . . . . . . . . 5
3.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 5
3.2. Source address selection refinements . . . . . . . . . . . 6
3.3. Dynamically allocated home agent . . . . . . . . . . . . . 6
3.4. Binding updates to CN even without HA . . . . . . . . . . . 7
3.5. Transport protocol . . . . . . . . . . . . . . . . . . . . 7
3.6. Local anchor . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
Perkins & Liu Expires January 5, 2012 [Page 2]
Internet-Draft DMM Comparison Matrix Jul 2011
1. Introduction
The goal of this document is to identify and compare known existing
approaches for Distributed Mobility Management (DMM).
Characterizations of each of the various methods selected for
comparison are provided in a matrix form according to whether or not
they meet certain criteria.
Efforts within the IETF have been launched to find improved mobility
management by decentralizing some or all of the traditional functions
associated with mobility, including handovers, location management,
identification, and so on.
The following abbreviations appear in this document:
MN: mobile node
HA: home agent
CN: correspondent node
FQDN: Fully Qualified Domain Name
The following approaches to mobility management are characterized:
Route optimization (RO): MN supplies Binding Updates directly to
CN.[RFC3775]
Source address selection refinements (SAddrSel): MN picks source
address appropriate for current point of attachment when launching
an application.
Dynamically allocated home agent (DynHA): Mobility anchor for MN
is allocated on demand.
Binding updates to CN even without HA (CN-wo-HA): Similar to RO,
but does not require protocol signaling with home agent.
Transport protocol (Trans-Mob) : MN modifies transport (e.g., TCP,
SCTP, DCCP, MPTCP) protocol parameters to change the IP address of
transport connection endpoint
Local anchor (Anchor-Mob): Local mobility anchor (e.g., MAP in
HMIP [RFC5380]) available for use by MN at its current point of
attachment.
Perkins & Liu Expires January 5, 2012 [Page 3]
Internet-Draft DMM Comparison Matrix Jul 2011
Dynamic DNS (DynDNS): When MN gets a new address, DNS is updated
so that the MN's FQDN resolves to that new address.
The approaches listed above will be characterized according to the
following criteria:
1. scalability: in # of nodes
2. specified?: whether there is a working group document specifying
the approach
3. IPadd continuity: provides stable IP address
4. backhaul friendly: reduces burden on backhaul
5. app friendly: apps do not require new code
6. server-friendly: server state minimized, servers do not require
new code
7. local routing: "local breakout" / "hairpinning" / local traffic
routed locally
8. low signaling: not too much signaling required
2. Matrix Comparing Existing Approaches for DMM
The following matrix rates the approaches described in the the
previous section according to the characteristics listed.
Perkins & Liu Expires January 5, 2012 [Page 4]
Internet-Draft DMM Comparison Matrix Jul 2011
RO SAddr DynHA CN-wo-HA Trans Anchor DynDNS
Sel Mob Mob
scalability Y Y M Y Y M M
specified? Y N N N Y Y Y
IPadd continuity Y N N Y Y Y N
backhaul friendly Y Y Y Y Y M Y
app friendly Y N Y Y N Y M
server-friendly M Y Y Y N Y Y
local routing Y Y M Y Y N Y
low signaling N Y M N N N N
Table 1: Comparison Matrix [Legend: Y=Yes, N=No, M=Maybe]
3. Explanations for Matrix Entries
Most of the matrix entries are relatively self-evident. For
instance, "Trans Mob" (Transport-based Mobility) approaches are rated
as not "app friendly" because applications require changes in order
to make use of the approach.
For approaches that are identified generically, it is ambiguous
whether or not they are properly specified in any working group
document. Here, such approaches are characterized as specified if
any particular approach in the generic family is specified. More
detail may be needed in the future, in which case more columns or a
new table may be needed.
In this initial pre-release of the document, not too many
explanations have been supplied. If the document is considered
worthwhile, explanations for more matrix entries will be developed,
concentrating first on those entries which have received mailing list
attention.
3.1. Route Optimization
Mobile IPv6 supports route optimization mode and bi-directional
tunnel mode. In route optimization mode, the mobile node can send
mobility signalling and subsequently data packets directly to the
correspondent node. The following aspects of route optimization are
characterized in the comparison matrix.
Perkins & Liu Expires January 5, 2012 [Page 5]
Internet-Draft DMM Comparison Matrix Jul 2011
1. Scalability: In route optimization mode, the signalling and data
could be sent without through the centralized mobility anchor.
So there is no single point of failure in RO mode. Moreover, the
effect of route optimization is to reduce traffic through the
home network -- therefore there is no scalability issue.
2. Specified: RFC 3775 specifies the route optimization mode of
MIPv6.
3. IP address continuity: In MIPv6 route optimization mode, the
mobile node still uses the same home address as the bi-
directional tunnel mode. RO mode supports IP address continuity.
4. backhaul friendly: In RO mode, the data can send directly to the
CN. Data do not need to send through centralized moblity anchor,
thence RO is backhaul friendly.
5. app friendly: RO mode does not require application changing, so
it is application friendly.
6. server-friendly: RO mode requires the server (i.e., CN) to also
support Mobile IP RO mode. In this sense, RO is not server
friendly.
7. local routing: In RO mode, the data is forwarded directly between
MN and CN, it thence can support local routing.
8. low signaling: MIPv6 RO mode use the return routability
procedure. which requires more signalling than MIPv6 bi-
directional tunnel mode.
3.2. Source address selection refinements
Dummy text here. Source address selection refinements (SAddrSel): MN
picks source address appropriate for current point of attachment when
launching an application.
3.3. Dynamically allocated home agent
Dynamically allocated home agent (DynHA): Mobility anchor for MN is
allocated on demand.
Scalability: If the network supports dynamically allocated home
agents, the mobile node can choose the nearest home agent. Other
mobile nodes can use different home agents. But when changing
location, home agent may not be able to change accordingly. The
mechanism for associating home agents to mobile nodes can vary, and
different algorithms have different scalability characteristics; some
Perkins & Liu Expires January 5, 2012 [Page 6]
Internet-Draft DMM Comparison Matrix Jul 2011
may be more scalable than others. Method relying on anycast
addresses for home agents are among the more scalable approaches.
Specified: RFC 3775 specifies dynamic home agent address discovery
and dynamic home prefix discovery. But it does not support changing
home agent after the mobility session setting up.
IP address continuity: When mobile node changes location, it may
choose a new home agent, but home address would also need to change
accordingly.
backhaul friendly: The mobile node can choose the nearest home agent,
in this sense, it is backhaul friendly.
app friendly: application does not need to change to support
dynamically allocated home agent. So it is app friendly.
server-friendly: server does not need to change to support
dynamically allocated home agent, so it is server friendly.
Local routing: When mobile node selecting the nearest home agent, it
can support local routing in some degree.
Low signaling: Dynamical discovery and assignment of a home agent may
need additionally signaling.
3.4. Binding updates to CN even without HA
Dummy text here. Binding updates to CN even without HA (CN-wo-HA):
Similar to RO, but does not require protocol signaling with home
agent.
3.5. Transport protocol
Dummy text here. Transport protocol (Trans-Mob) : MN modifies
transport (e.g., TCP, SCTP, DCCP, MPTCP) protocol parameters to
change the IP address of transport connection endpoint
3.6. Local anchor
Dummy text here. Local anchor (Anchor-Mob): Local mobility anchor
(e.g., MAP in HMIP [RFC5380]) available for use by MN at its current
point of attachment.
4. Security Considerations
This document does not have any security considerations.
Perkins & Liu Expires January 5, 2012 [Page 7]
Internet-Draft DMM Comparison Matrix Jul 2011
5. IANA Considerations
This document does not have any IANA actions.
6. References
6.1. Normative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
Management", RFC 5380, October 2008.
6.2. Informative References
[cool_draft] Doe, J. and J. Doe, "A cool draft.",
draft-does-cia-rules.txt (work in progress), 2010.
Appendix A. Acknowledgements
This document has benefitted from discussions with the following
people, in no particular order: Seok Joo Koh, Jouni Korhonen, Julien
Laganier, Dapeng Liu, Telemaco Melia, Pierrick Seite
Authors' Addresses
Charles E. Perkins
Tellabs
Phone: +1-408-421-1172
EMail: charliep@computer.com
Dapeng Liu
China Mobile
Phone: +86-123-456-7890
EMail: liudapeng@chinamobile.com
Perkins & Liu Expires January 5, 2012 [Page 8]