[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
Network Working Group D. Liu
Internet-Draft Z. Cao
Intended status: Informational China Mobile
Expires: January 11, 2011 P. Seite
France Telecom - Orange
H. Chan
Huawei Technologies
July 10, 2010
Distributed mobility management
draft-liu-distributed-mobility-02
Abstract
Current mobility solutions generally introduce an anchor point in the
network, e.g., HA in MIPv6, LMA in PMIPv6, GGSN in 3GPP. The anchor
point is used to maintain the mapping between the stable IP address
(e.g., Home address in MIPv6) and the current routable IP address
(e.g., CoA in MIPv6). However, one of the trend in mobile network
evolution is to "flatten" mobility architecture by confining mobility
support in the access network, e.g. at the access routers level,
keeping the rest of the network unaware of the mobility events and
their support. This document discusses the deployment of current IP
mobility mechanisms in such a flat architecture.
Status of this Memo
This Internet-Draft is submitted 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 11, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Liu, et al. Expires January 11, 2011 [Page 1]
Internet-Draft DMM July 2010
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Motivation for flattening mobile network architecture . . . . 4
3.1. General considerations . . . . . . . . . . . . . . . . . . 4
3.2. IP Flow Mobility support in flat architectures . . . . . . 5
3.3. Dynamic mobility anchoring . . . . . . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Considerations of distributed mobility solutions . . . . . . . 9
6.1. Client-based solutions . . . . . . . . . . . . . . . . . . 9
6.2. Network based solutions . . . . . . . . . . . . . . . . . 11
6.3. Splitting the routing and the location management
function . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Liu, et al. Expires January 11, 2011 [Page 2]
Internet-Draft DMM July 2010
1. Introduction
Most existing IP mobility solutions are derived from Mobile IP
[RFC3775] principles where a given mobility anchor (e.g. the Home
Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy
Mobile IPv6 [RFC5213] maintains Mobile Nodes (MNs) bindings. Data
traffic is then encapsulated between the MN or its Access Router
(e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility
agent. These approaches lead to the implementation of centralised
architectures where both MN context and traffic encapsulation need to
be maintained at a central network entity, the mobility anchor.
Such centralised approach provides the ability to route MN traffic
whatever MN's localisation while maintaining IP session continuity
during handovers. However, when hundreds of thousands of MNs are
communicating in a given cellular network, a centralized mobility
anchoring point causes well-known bottlenecks and single point of
failure issues, which requires costly network dimensioning and
engineering to be fixed. In addition, tunnelling encapsulations
impact the overall network efficiency since they require the
maintenance of MN's specific contexts in each tunnel end nodes and
they incur delays in packet processing and transport functions.
It is however well established that a huge amount of mobile
communications are set up while the user is not physically moving,
i.e. its MN stays in the same radio cell. For example, the user is
being communicating at home, in his office, at a cafe... Applying
the aforementioned centralised principles leads then to aggregate
user's contexts and traffic at a central node in the network for the
sake of mobility support whereas the MN remains motionless. As this
leads to the introduced scalability and performances issues,
alternative approaches may consider a way to better adapt mobility
support in the network to cope with MN's movements and its ongoing
traffic flows' requirements. Typically, one of the trend in the
evolution of mobile networks is to go to a flat architecture with the
distribution of network functions, including mobility functions,
close to the access gateways. This document discusses the deployment
of current IP mobility mechanisms (Mobile IPv6 and proxy Mobile IPv6)
in such a flat architecture by dynamically distributing the mobility
handling functions among terminals and access routers. The goal is
twofold:
o confining the mobility support at the access routers level,
keeping the rest of the network unaware of mobility events and
their support.
o dynamically adapting mobility support to each of the MN's needs by
applying traffic redirection only to MNs' flows that are already
established when an IP handover occurs;
Liu, et al. Expires January 11, 2011 [Page 3]
Internet-Draft DMM July 2010
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Motivation for flattening mobile network architecture
3.1. General considerations
Development of new mobile services and usages (e.g., video streaming,
mobile Internet) has led to huge increase of data traffic on the
mobile network, thus giving much pressure to the mobile operator's
core network. In order to address scalability and performance issues
with current centralized architecture, one of the trends in network
evolution is to leverage on local content delivery network (CDN)
where IP communications with local services are routed directly to
the CDN without going through the IP core network. For the same
reason, it is now preferable to offload the traffic that are not
generated by mobile services from the IP core of the mobile network
(e.g. Internet traffic should be offloaded). On the other hand, IP
communications with mobile services are routed via a centralized
anchor point (e.g., the PGW in 3GPP/EPS mobile network). In current
proposals for network evolution, a local traffic anchor (i.e. a local
gateway, L-GW), usually located near the access router, is in charge
of offloading the traffic (e.g. Internet and local traffic).
The generic mobile architecture with offload capabilities is depicted
in Figure 1; it illustrates the following use-cases:
o Mobile node MN1 is attached to access router AR1 and consumes
service delivered by the local CDN. So, the corresponding IP
flows are routed directly from AR1 to the CDN.
o MN2 is attached to AR1 and has an IP communication with CN. So,
the corresponding IP flows are routed to the packet data network
PDN, via a centralized traffic anchor.
o MN3 is attached to AR2. MN3 has an IP communication with CN and
get access to the Internet. The IP flow corresponding to Internet
traffic is offloaded to the local Internet access via the L-PGW,
whereas the IP communication with CN is routed via the centralized
traffic anchor.
Liu, et al. Expires January 11, 2011 [Page 4]
Internet-Draft DMM July 2010
+----+
,-'' |CN |. +----------+
,' +----+ \---------| central |
/ Packet \ | anchor |
| Data | +----------+
\ Network ,' |
`. _, |
`-..____,,' *****************
* IP network * __...._
* * ,' `-.
+---------+ +----+ +----+ / Internet \
| Local |__ |L-GW| |L-GW|--- | Access |
| Content | +----+ +----+ \ ,'
| Delivery| * * `-._ _,'
| Network | ****************** `'''
+---------+ || ||
+----+ +----+
|AR1 | |AR2 |
+----+ +----+
| | |
| | |
MN1 MN2 MN3
Figure 1: Deployment of Local content delivery and IP traffic offload
in a centralized mobility architecture
3.2. IP Flow Mobility support in flat architectures
When the host can simultaneously connect to different access systems,
IP flow mobility is considered by operator as a flexible way to route
traffic according network access and applications specific
contraints. For example, a given IP flow (e.g. video streaming),
initially routed through one access, could be selectively offloaded
to another access while maintaining other traffic (e.g. traffic with
specific QoS requirements) on the primary access. This kind of
traffic management is specified in [TR23.261] when considering
centralized architecture. This section discusses deployment of IP
mobility mechanisms in flat mobile architectures as specified in
Figure 1.
Existing mobility solutions generally introduce a mobility anchor in
the network; examples are HA in MIPv6, LMA in PMIPv6, and GGSN/PGW in
3GPP. The mobility anchor is used to maintain the mapping between
the stable IP address (e.g., Home address in MIPv6) and the current
routable IP address (e.g., CoA in MIPv6). In the centralized
architecture, the mobility anchor point is usually located at the top
Liu, et al. Expires January 11, 2011 [Page 5]
Internet-Draft DMM July 2010
of the architecture. Yet in a flat architecture, such as the one
depicted in Figure 1, the traffic anchor point can be much lower
(e.g. located in the access system) compared with centralized
architecture. So, for the sake of routing optimization the mobility
anchor should also be located closer to the traffic anchoring point,
otherwise the traffic could not break out locally. Actually, routing
optimization issue will become more severe in the flat architecture
if traditional mobility protocol is used. The mobility tunnel needs
to be connected back to the mobility anchor where the mobile node
attaches (and gets the IP address allocation). Then all IP traffic
of that mobile node will be routed through the mobility anchor.
Despite the well-known scalability issues brought by centralized
approaches, a central mobility anchor in a flat architecture leads to
non-optimal routing for local and offloaded traffic: the data path
goes through the central mobility anchor point before being routing
back to the local traffic anchoring point (e.g. L-GW). Such non-
optimal routing may degrade the user experience due to the latency
caused by the long route to the destination. So, in a mobile
architecture distributing the traffic anchoring, as depicted on
Figure 1, the mobility anchoring function shall also be distributed
to provide efficient IP session continuity for both local and
centralized traffic. Figure 2 shows an example of distributed IP
mobility architecture. In this example mobility anchors are deployed
both in the centralized traffic anchoring point and in the access
routers to manage respectively mobility of centralized and local
traffic.
Liu, et al. Expires January 11, 2011 [Page 6]
Internet-Draft DMM July 2010
+----+
,-'' |CN |. +-----------+
,' +----+ \---------| Mobility | Mobility
/ Packet \ |anchor (MA)| Anchor
| Data | +-----------+ for centralized
\ Network ,' | traffic
`. _, |
`-..____,,' *****************
* IP network * __...._
* * ,' `-.
+---------+ +----+ +----+ / Local \
| Local |__ |L-GW| |L-GW|--- | content |
| Content | | | | | | |
| Delivery| +----+ +----+ \ ,'
| Network | ****************** `''''''`'''
+---------+ || ||
+----+ +----+ mobility
|AR1 | |AR2 | anchors
|+MA |+MA | for local
+----+ +----+ traffic
| |
3GPP | |WiFi
+-----MN1----+
Figure 2: Distributed Mobility Anchoring
3.3. Dynamic mobility anchoring
Applying the centralized mobility management principles leads to
aggregate user's contexts and traffic at a central node in the
network whereas the MN remains stationary. However, once attached to
the new access router, the mobile node can again acquire a routable
global IPv6 address to be used for any new communication flow it sets
up. Hence, a flow based mobility support may be restricted to
provide traffic indirection to host's flows that are already ongoing
during host's handovers between access routers. Any new flow being
set up uses the new host's global address acquired on the new link
available after the handover.
When a multiple-interfaces node moves an IP flow between access
routers of different access technologies, such a simple approach can
also apply. Flow mobility management should then be required only to
support the necessary traffic indirection from the mobility anchor on
Liu, et al. Expires January 11, 2011 [Page 7]
Internet-Draft DMM July 2010
which the flow has been initially set up to the access router to
which the host is currently attached.
Hence, any given IP flow can be considered as implicitly anchored on
the current MN's access router when being set up. So, it leads to
deploy mobility anchors in access routers. While the MN is attached
to its initial access router, the IP flow is delivered as for any
standard IPv6 node. The mobility anchoring at the access router then
allow to manage traffic indirection if the MN moves to a new access
router (and for subsequent movements while the IP flow remains
active), maintaining the flow communication until it ends up.
4. Requirements
This section gives the requirements for mobility management support
in flat architectures.
o To ensure the IP traffic offload in the flat architecture and
still maintain the service continuity, the mobility anchoring
should close to the local gateway(access router),i.e. confining
mobility support to the access routers level, keeping the rest of
the network unaware of mobility events. For example, the access
router mayshould be the anchoring point of local IP traffic.
o IP flow mobility: it shall be possible to offload selected traffic
(e.g. Internet) by moving IP flows from one access to another.
o It is preferred for the distributed mobility solution requiring
less changes to the network and current mobility protocols. The
distributed mobility solution should compatible with legacy
mobility mechanisms. This requirement may help the distributed
mobility solution easier for deployment
o Mobility mechanism should come into play only for node on the move
(optional feature) . It leads to dynamically adapting mobility
support to each MN's needs by applying traffic redirection only to
MN's flows those are ongoing when handover occurs.
5. Gap analysis
Current mobility protocols (DSMIPv6/PMIPv6) may be used in the flat
architecture. For example, for the architecture depicted in figure
1, DSMIPv6 or PMIPv6 may be used. The L-GW (Local Gateway in Figure
2) could be the mobility anchor point (HA/LMA) for DSMIPv6/PMIPv6 and
also act as MAG for PMIPv6. But it is not optimized in many ways.
Liu, et al. Expires January 11, 2011 [Page 8]
Internet-Draft DMM July 2010
1. Non-optimized routing: When the UE attaches to the network
through one L-GW, that L-GW will be the anchor point of that UE.
When the UE moves out of this L-GW's service area, the UE/MAG has
to establish a mobility tunnel back the original L-GW.
Obviously, the routing is not optimized since the UE/MAG always
needs to establish the mobility tunnel back to the original L-GW
no matter where it has moved to. This will increase unnecessary
traffic to the operator's network compared with locally breaking
out the traffic. In LTE/SAE network, when the UE attaches to the
network it will always keep that IP address, this feature is
called "always on". The "always on" feature will worsen the
problem. The reason is that in 2G/3G mobile network, when the UE
terminates a session, it will detach from the network, when it
attach to the network again, it will get a new IP address and the
anchor point could be changed to the L-GW accordingly. But in
LTE/SAE, the UE does not detach from the network as long as it is
power on.
2. Increased delay: The non-optimized routing causes the routing
path to be much longer compared with local breakout, this will
increase the transmission delay.
3. Single point of failure: The UE will always depend on its
original anchor point to maintain service continuity to wherever
it has moved. This will cause the single point of failure
problem compared with distributing the mobility anchor function.
6. Considerations of distributed mobility solutions
This section discusses the applicability of MIPv6/PMIPv6 in flat
architectures. Based on the above analysis, there may be an interest
to consider specific deployment of mobility mechanisms in flat
architecture. This kind of solution may be called distributed
mobility solutions since the mobility anchor function is distributed
compared with the centralized mobility anchor point in traditional
mobility protocol.
The distributed mobility solutions should make minimal changes to the
existing network entity. It is preferable to require no change to
the UE and be transparent to the application layer.
The following sub-sections only give basics for distributed mobility,
the detailed solutions will be identified in future.
6.1. Client-based solutions
One solution to deploy Mobile IP in a flat architecture is to
implement the HA functionalities in the access routers, as shown on
Figure 3. Any given IP flow can be considered as implicitly anchored
Liu, et al. Expires January 11, 2011 [Page 9]
Internet-Draft DMM July 2010
on the current host's access router when set up.
In addition, dynamic mobility anchoring [I-D.kassi-mobileip-dmi]
could avoid data encapsulation for motionless nodes: until the host
does not move, the IP flow is delivered as for any standard IPv6
node. The anchoring function at the access router is acting only to
manage traffic indirection while the host moves to a new access
router. So, when the MN handoff, its current traffic is still
attached to the anchor access router which is responsible for
forwarding the IP flows to the MN.For example, let's consider an IP
flow, flow#1, initiated by the mobile node, MN, when attached to AR2.
Flow#1 will is routed in a standard way as long as the MN remain
attached to AR2. If the MN moves to AR3, flow#1 remains anchored to
AR2, which plays the role of HA. If MN starts a new IP
communication, flow#2, while attached to AR3; flow#2 will be routed
in a standard way as long as the MN remains attached to AR3. Then,
if the MN moves to AR1, flow#1 and flow#2 will be respectively
anchored to AR2/HA and AR3/HA.
+---+ +---+ +---+
|CN1| |CN2| |CN3|
+---+ +---+ +--,+
_.---------+----------. \
,----'' | `---'-.
,-' |flow#1 \ `-.
,' | ' `.
( IP Network| \
`. | ' ,'
`-. ; ,\'
;-----. ; _.----' '
,' `---------+----------'' |
/ | '
+---'---+ +---:---+ +-------+
| AR1 | | AR2`--|------------| AR3 |
| HA | | HA |------------|HA |
+-------+ +-------+ +-------+
flow#1 \\ \ flow#2
tunnelled \\ '
+-----+ +--\--+
| MN | ----move-------> | MN |
+-----+ +-----+
Figure 3: Distributed Client Based Mobility
Liu, et al. Expires January 11, 2011 [Page 10]
Internet-Draft DMM July 2010
6.2. Network based solutions
Figure 4 shows de deployment of PMIP [RFC5213] in a flat mobile
architecture. The basic is to distribute mobility traffic management
with dynamic user's traffic anchoring in the access network nodes.
Each AR supports both the MAG and LMA functionalities. Any given IP
flow can be considered as implicitly anchored on the current host's
access router when set up. Until the host does not move, the IP flow
is delivered as for any standard IPv6 node. The anchoring function
at the access router is thus acting only to manage traffic
indirection while the host moves to a new access router. So, when
the MN handoff, its current traffic is still attached to the anchor
access router which is responsible for forwarding its anchored MN's
IP flows to the new MN's location (i.e. to the AR the MN is attached
to). For example, let's consider an IP flow, flow#1, initiated by
the mobile node, MN, when attached to AR2. Flow#1 will is routed in
a standard way as long as the MN remain attached to AR2. If the MN
moves to AR3, flow#1 remains anchored to AR2, which plays the role of
LMA. AR3 plays the role of MAG for MN/flow#1. If MN starts a new IP
communication, flow#2, while attached to AR3; flow#2 will be routed
in a standard way as long as the MN remains attached to AR3. Then,
if the MN moves to AR1, flow#1 and flow#2 will be respectively
anchored to AR2/LMA and AR3/LMA and AR1 will provide MAG
functionalities for MN.
+---+ +---+ +---+
|CN1| |CN2| |CN3|
+---+ +---+ +--,+
_.---------+----------. \
,----'' | `---+-.
,-' |flow#1 \ `-.
,' | \ `.
( IP Network| \
`. | \ ,'
`-. ; ,+'
;-----. ; _.----' `.
,' `---------+----------'' |
/ | flow#1 \
+---'---+ +---:---+ tunnelled +-------+
| AR1 | | AR2`--|------------| AR3 |
|MAG/LMA| |MAG/LMA|------------|MAG/LMA|
+-------+ +-------+ +-------+
flow#1 `. \ flow#2
+--`--+ +-----+
| MN | ----move-------> | MN |
+-----+ +-----+
Liu, et al. Expires January 11, 2011 [Page 11]
Internet-Draft DMM July 2010
Figure 4: Distributed Network Based Mobility
6.3. Splitting the routing and the location management function
The logical functions of the mobility anchor defined in conventional
mobility protocols may be split for both a better scalability and
signaling efficiency. For instance [I-D.chan-netext-distributed-lma]
proposes to split the mobility anchor entity into the following
functions:
1. location management anchoring function
2. mobility routing anchoring function.
The location management anchoring function includes keeping track of
the internetwork location of the mobile node, which is identified
with a permanent home address HoA. The mobility routing anchoring
function includes routing the packets with HoA as destination address
to the destination or to some other network element that knows how to
forward to the destination.
In the conventional mobility protocols, these two anchoring functions
have been colocated into one mobility anchor. The collocated
mobility anchor contains the full location information to enable its
role to redirect packets to the new location of the mobile node. The
result is the dilemma in where to position this collocated mobility
anchor in a hierarchical network. On the one hand, it is simpler to
have only one or possibly a very small number of mobility anchors to
centrally manage the location of a larger number of mobile nodes.
However, routing the packets through such centralized nodes often
results in non-optimal routing. On the other hand, having many
mobility anchors whose locations are low in the hierarchy will
shorten the route. Yet it will then be costly and difficult to
synchronize the location information when many such collocated
mobility anchors are performing location management and each needs to
have full location information of all the mobile nodes.
Splitting the logical functions of location management and routing
enables each function to be optimized in the design.
The mobility routing function can be implemented in many physical
places instead of in one or very few centralized places only. There
are then many such places to provide the mobility routing function,
and the packets can always be served by one that is nearby. Many of
these packets would have to traverse a long route to reach a mobility
routing function if there were only one centralized mobility routing
function.
The location management function, being implemented separately from
the mobility routing function, do not need to be implemented in as
many places as the mobility routing function. The implementation of
Liu, et al. Expires January 11, 2011 [Page 12]
Internet-Draft DMM July 2010
the location information system can be optimized according to the
optimization of a database design. There may be only one, except for
backup, database system. The database may still be distributed but
are only distributed to much fewer number of places than the routing
functions.
After splitting the above functions, the mobility routing anchor
points serving a source node sending packet to a destination mobile
node may lack the location information of the destination mobile
node. The mobility routing anchor may query the location management
system to obtain the location information of the mobile node to which
it needs to route the first packet. Alternatively, the location
management anchor point may also possess routing function so that the
first packet may be forwarded to the location management anchor point
to route to the destination mobile node. Meanwhile the location
information of this mobile node is being sent to the mobility routing
anchor. After the mobility routing anchor has received the location
information, it caches this information for its use to route the
subsequent packets to the same mobile node.
One access gateway plays the role of LM. Location update may be
implemented in a separate entity (see figure)
+---+ +---+
|CN1| |CN2|
+---+ +---+
_.---------+----------.
,----'' | `----.
,-' |flow#1 `-.
,' | `.
( IP Network| )
`. | ,'
`-. ; +-----+ ,
;-----. ; +------ | LM |---+
,' `---------+--|-------+-----+ |
/ | | flow#1 |
+---'---+ +---:---+ tunnelled +-------+
| AR1 | | AR2`--|------------| AR3 |
|MAG | |MAG |------------|MAG |
+-------+ +-------+ +-------+
flow#1 `.
+--`--+ +-----+
| MN | ----move-------> | MN |
+-----+ +-----+
Liu, et al. Expires January 11, 2011 [Page 13]
Internet-Draft DMM July 2010
Figure 5: Distributed Network Based Mobility
7. Security Considerations
TBD
8. IANA Considerations
None
9. Contributors
The following people contributed to this document (in no specific
order):
Bo Zhou
China Mobile
zhouboyj@chinamobile.com
Philippe Bertin
France Telecom - Orange
philippe.bertin@orange-ftgroup.com
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[I-D.chan-netext-distributed-lma]
Chan, H., Xia, F., Xiang, J., and H. Ahmed, "Distributed
Local Mobility Anchors",
draft-chan-netext-distributed-lma-03 (work in progress),
March 2010.
[I-D.ietf-mext-flow-binding]
Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
Basic Support", draft-ietf-mext-flow-binding-06 (work in
progress), March 2010.
Liu, et al. Expires January 11, 2011 [Page 14]
Internet-Draft DMM July 2010
[I-D.kassi-mobileip-dmi]
Kassi-Lahlou, M., "Dynamic Mobile IP (DMI)",
draft-kassi-mobileip-dmi-01 (work in progress),
January 2003.
[I-D.seite-netext-dma]
Seite, P. and P. Bertin, "Dynamic Mobility Anchoring",
draft-seite-netext-dma-00 (work in progress), May 2010.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.
[TR23.261]
3GPP, "IP Flow Mobility and seamless WLAN offload", 2010.
Authors' Addresses
Dapeng Liu
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: liudapeng@chinamobile.com
Zhen Cao
China Mobile
Unit2, 28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: caozhen@chinamobile.com
Liu, et al. Expires January 11, 2011 [Page 15]
Internet-Draft DMM July 2010
Pierrick Seite
France Telecom - Orange
4, rue du clos courtel, BP 91226
Cesson-Sevigne 35512
France
Email: pierrick.seite@orange-ftgroup.com
H Anthony Chan
Huawei Technologies
1700 Alma Ave
Plano, TX 75075
USA
Email: anthonychan@huawei.com
Liu, et al. Expires January 11, 2011 [Page 16]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/