Internet DRAFT - draft-luo-dmm-with-mip-and-pmip
draft-luo-dmm-with-mip-and-pmip
Network Working Group W. Luo
Internet-Draft ZTE
Intended status: Standards Track S. Tricci
Expires: April 18, 2013 ZTE USA
October 15, 2012
Distributed Mobility Management Approach with Mobile IP and Proxy Mobile
IP
draft-luo-dmm-with-mip-and-pmip-00
Abstract
Based on the analysis of current centralized mobility management
approaches, three main functions of current centralized mobility
anchor are identified, which are Mobility Routing (MR), Home Address
Allocation (HAA), and Location Management (LM), in this draft.
Based on the proposal of decoupling those functions, this draft
provides a concept of architecture for Distributed Mobility
Management (DMM) with some key approaches for DMM. Those approaches
are compatible with both current MIP and PMIP protocols.
Requirements Language
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 RFC 2119 [RFC2119].
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 April 18, 2013.
Copyright Notice
Luo & Tricci Expires April 18, 2013 [Page 1]
Internet-Draft dmm-mip-pmip October 2012
Copyright (c) 2012 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions used in this document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Functional Decomposition . . . . . . . . . . . . . . . . . 4
3.2. An Example of Networking Model . . . . . . . . . . . . . . 4
3.3. Concept Architecture of Distributed Mobility Management . 5
4. Overview of the Distributed Mobility Management Approaches . . 7
4.1. Initial Attachment . . . . . . . . . . . . . . . . . . . . 7
4.2. Dynamic Mobility Management . . . . . . . . . . . . . . . 7
4.3. Distributed Routing . . . . . . . . . . . . . . . . . . . 8
4.4. Handover with Active Session . . . . . . . . . . . . . . . 11
5. Supporting Client Based and Network Based Mobile IP . . . . . 13
6. Considerations of the Optimized Routing . . . . . . . . . . . 13
7. Security Consideration . . . . . . . . . . . . . . . . . . . . 14
8. Gaps with the Distributed Mobility Management Requirement . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. References . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Luo & Tricci Expires April 18, 2013 [Page 2]
Internet-Draft dmm-mip-pmip October 2012
1. Introduction
Centralized mobility anchoring has several drawbacks such as single
point of failure, routing in a non optimal route and etc. which are
discussed in [I-D.liu-mext-distributed-mobile-ip].
Based on the analysis of current centralized mobility management
approaches, three main functions of current centralized mobility
anchor are identified, which are Mobility Routing (MR), Home Address
Allocation (HAA), and Location Management (LM), in this draft.
Based on the proposal of decoupling those functions, this draft
provides a concept of architecture for Distributed Mobility
Management (DMM) with some key approaches for DMM. Those approaches
are compatible with both current MIP and PMIP protocols.
This is an initial version, and not aimed to solve all issues which
are defined in [I-D.liu-mext-distributed-mobile-ip]. Further,
whether the architecture and approaches proposed in this draft can
meet the DMM requirements defined in [I-D.ietf-dmm-requirements] is
not examined carefully yet. The gap analysis will be provided in the
future.
2. Conventions and Terminology
2.1. 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].
2.2. Terminology
This draft introduces following terms which are very similar with
terms defined in [I-D.chan-dmm-framework-gap-analysis].
Mobility Routing (MR), which is a logical function used for
intercepting packets to/from the HoA of a mobile node and forwarding
the packets, based on the corresponding location information to
perform distributed routing.
Home Address Allocation (HAA), which is a logical function used for
allocating home network prefix or home address to a mobile node.
Location Management (LM), which is a logical function, used for
managing and keeping track of the internetwork location information
of a mobile node, which includes a mapping of the HoA of the MN to
Luo & Tricci Expires April 18, 2013 [Page 3]
Internet-Draft dmm-mip-pmip October 2012
the routing address of the MN (i.e. routing location) or another
network element that knows how to forward packets towards the MN.
3. Solution Overview
3.1. Functional Decomposition
The existing mobility management technology, such as MIP, PMIP and
etc., bundles all the mobility management functions into one
centralized Home Agent (HA) or Local Mobility Anchor (LMA).
Sharing similar view with [I-D.chan-dmm-framework-gap-analysis], this
draft decomposes those centralized anchor into the following logical
functions to allow a more flexible design to achieve distributed
mobility management (DMM):
a. Home Address Allocation (HAA) function
b. Mobility Routing (MR) function
c. Location Management (LM) function
Assuming for any given administrative domain, it consists of one or
more so called local network (as illustrated in figure 1). Further,
each those local networks most likely consists of several routers
which are deployed with mobility routing (MR) function, and one home
address allocation (HAA) function and one location management (LM)
function.
The HAA and LM, depended on the operating policy, could be deployed
as a combined entity or be deployed separately.
3.2. An Example of Networking Model
Figure 1 illustrates a possible deployment of distribute mobility
management specified by this draft, which contains 3 local networks.
Luo & Tricci Expires April 18, 2013 [Page 4]
Internet-Draft dmm-mip-pmip October 2012
One Administrative Domain
( LM1/HAA1 )( LM2/HAA2 )( LM3 HAA3 )
( )( )( )
( )( )( )
( MR11 MR12 )( MR2 )( MR31 MR32 )
+ +
| Local Local | Local
| Network1 Network2 | Network3
+ +
MN1 MN2
Figure 1. An example of DMM deployment
Both local network 1 and local network 3 contain multiple MRS (e.g.
two MRs), while local network 2 includes one MR. The LM and the HAA
are co-located as ana signal entity in local network 1 and 2, while
are deployed separately in local network 3.
One should be noticed that, the above figure is only an example. In
actual deployment, for one signal local network, multiple LMs and
HAAs could also be deployed.
One should also be noticed that, in this draft, assuming all local
networks belong to a same administrative domain (e.g. one operator).
Otherwise, out of the scope of this draft.
3.3. Concept Architecture of Distributed Mobility Management
For supporting distributed mobility management, signaling
interactions are needed between those MR, LM and HAA. This section
tries to illustrate architecture of the DMM approaches specified in
this draft.
Luo & Tricci Expires April 18, 2013 [Page 5]
Internet-Draft dmm-mip-pmip October 2012
+-------------------------------------+ +--------------------------+
| +---------+ +---------+ | | +---------+ |
| | HAA | | LM +<---+--+------->+ LM | |
| +---+-----+ +----+----+ | | +----+----+ |
| ; /|\ | | /|\ |
| /|\ | | | | |
| | \|/ | | \|/ |
| | +----+----+ | | +----+----+ |
| +-------------> | MR +<---+--+------->+ MR | |
| +--+---+--+ | | +--+---+--+ |
| /|\ /|\ | | /|\ /|\ |
| | | | | | | |
| |___| | | |___| |
| | | |
| Home Local Network | | Visited Local Network |
+-------------------------------------+ +--------------------------+
Figure 2. Architecture
The local network to which the MN is initially attached is known as
its home local network. The HAA function of mobile node's home local
network is responsible for IP address\prefix (i.e. HoA\HNP)
assignment for the mobile node. During the movement, the mobile node
could leave its home and enter one another local network which is
known as visited local network in this draft.
Interfaces among HAA, LM and MR are needed, and are described as
following
a. Interface between HAA and MR, which supports signaling for IP
prefix or address assignment, during the attachment of a mobile
node to a MR
b. Interface between LM and MR, which supports signaling for
maintaining the routing location of mobile node, and the set up
of an optimized routing for mobile node
c. Interface between MR and MR, which supports the signaling for the
handover of a mobile node from previous MR (pMR) to new MR (nMR)
in control plane, and supports delivering traffic between mobile
node and its correspondent node in a distributed manner in data
plane.
An administrative domain may have a large amount of mobile nodes;
therefore the LM may need to maintain a large amount of information
(i.e. tracing the routing location of those mobile nodes).
It is better for an administrative domain to deploy multiple LMs.
Luo & Tricci Expires April 18, 2013 [Page 6]
Internet-Draft dmm-mip-pmip October 2012
Those LMs could be deployed in a form of distributed database, and
interfaces between them are necessary for information interactive.
4. Overview of the Distributed Mobility Management Approaches
4.1. Initial Attachment
The initial attachment for distributed mobility management specified
in this draft is triggered when a mobile node is initialized and
attached to an access link on which the mobile node is connected to a
MR.
When determining that mobile node is authorized for the DMM service,
MR interacts with HAA, which is in the same local network, by
signaling, over the interface between them, for the purpose of
HoA\HNP assignment. The HoA\HNP assignment mechanism could be based
on stateful or stateless mechanism.
After configuring HoA\HNP for the mobile node, that local network
becomes mobile node's home local network. The MR, depends on the
local policy, may interact with a LM which is also in mobile node's
home local network (i.e. MN's home LM) to update the mobile node's
routing location.
Updating mobile node's routing location during initial attachment is
not a mandatory step. Since the mobile node is currently attached to
its home local network and the assigned HoA\HNP is anchored at mobile
node's currently attached MR. The traffic, which is designated to
mobile node's HoA\HNP, should be routed to that MR by regular IPv6
routing mechanism automatically.
4.2. Dynamic Mobility Management
Mobile node may change its point of attachment from pMR to nMR when
it moves. The nMR may locate at mobile node's home local network, or
may at a different local network (i.e. visited local network).
Based on the attachment event, the nMR should try to retrieve mobile
node's HoA\HNP configuration status first (e.g. from mobile node's
HAA in home local network), and update mobile node's LM with its new
routing location (e.g. IP address of nMR).
Depend on the configuration of the network, new HoA\HNP which is
anchored at nMR could be assigned to mobile node when the mobile node
is attached to the nMR. In this case, both HoAs\HNPs which are
anchored at pMR and nMR respectively are available for the mobile
node.
Luo & Tricci Expires April 18, 2013 [Page 7]
Internet-Draft dmm-mip-pmip October 2012
In this case, newly initiated session after the handover is preferred
to use new HoA\HNP as source IP. Meantime, old session which has
already initiated before handover could still use the old HoA\HNP as
source IP for the purpose of keeping session continuity. The similar
idea is also proposed in [I-D.seite-dmm-dma],
[I-D.bernardos-dmm-distributed-anchoring] and
[I-D.korhonen-dmm-local-prefix].
But, one should note that, in the above configuration, mobile node
should have ability to manage multiple HoAs\HNPs, and should have
ability to decide to return which one of those multiple HoAs when
applications on the mobile node ask for an IP address to bind.
4.3. Distributed Routing
To perform optimized routing, the MRs need the location information
which is maintained at the LMs. Use the scenario illustrated in
figure 1 as an example.
The assumptions are as following:
o MN1 and MN2 are currently attached to MR11 and MR 31 respectively
o The destination IP address of the traffic (from MN2 to MN1) is set
to the HoA of MN1
o The MN1's HoA above is anchor at MR12 (which means the regular
IPv6 routing mechanism will deliver any packet whose destination
IP address is set to MN1's HoA to MR12), not the MR to which the
MN1 is currently attached (i.e. MR11).
Then, upon receiving the initial few packets of the traffic, MR31
should determine how to forward the traffic optimally.
Luo & Tricci Expires April 18, 2013 [Page 8]
Internet-Draft dmm-mip-pmip October 2012
+-----+ +-------+ +-------+ +--------+ +-----+
| MN2 | | MR31 | | LM | | MR11 | | MN1 |
+-----+ +-------+ +-------+ +--------+ +-----+
| | | | |
|1.IP Traffic | | | |
|===========> | 2. Query | | |
| |----------> | | |
| | 3. Rsp | | |
| |<------ ----| | |
| +------------------+ | | |
| | 4.Record Location| | | |
| | of MN1 Locally | | | |
| +------------------+ | | |
| | 5. Distributed Routing | |
| |========================> | |
| | | |6.IP Traffic |
| | | |===========> |
| | | | |
Figure 3. Optimized routing based on location query
Figure 3 illustrates one possible behavior the MR31 could take for
the purpose of determining how to forward the traffic in an optimized
manner.
MR31 first determines whether it holds the routing location
information of MN1 locally. If not, MR31 will initiate a query to a
LM (e.g. MN1's home LM), who holds such information, by sending a
query message via the interface between MR and LM.
When receiving the response, MR31 should save the queried routing
location information of MN1 locally.
Based on the routing location information retrieved, MR31 could
perform so called distributed routing for delivering the traffic.
o One of distributed routing mechanism: MR31 could set up its
endpoint of a tunnel (e.g. IP in IP tunnel) to MR11 based on
MN1's routing location, encapsulate all IP packets of the traffic
and send those encapsulated IP packets to MR11 in the established
tunnel directly.
o Another one of distributed routing mechanism: as specified in
[I-D.liebsch-mext-dmm-nat-phl], per-host-locator mechanism can be
used by MR31 to perform distributed routing, in which, the locator
is MN1's routing location.
Only two example distributed routing mechanisms are list above. Some
Luo & Tricci Expires April 18, 2013 [Page 9]
Internet-Draft dmm-mip-pmip October 2012
better mechanisms can be developed in the future.
+-----+ +-------+ +-------+ +--------+ +--------+ +-----+
| MN2 | | MR31 | | LM1 | | MR12 | | MR11 | | MN1 |
+-----+ +-------+ +-------+ +--------+ +--------+ +-----+
| | | | | |
|1.IP Traffic | | | | |
|============>| | | | |
| +-------------------+ | | | |
| |2.Don't have MN1's | | | | |
| | Routing Location | | | | |
| +-------------------+ | | | |
| | 3. Regular IPv6 Routing | | |
| |========================> | | |
| | | 4. Query | | |
| | |<------------| | |
| | | 5. Rsp | 6. Distributed |
| | |------------>| Routing |
| | 8. Redirect |===========>| |
| |<-------------------------| 7.IP Traffic|
| | | | |==========>|
| | 9. Distributed Routing | |
| |======================================>| |
| | | | 10.IP Traffic|
| | | | |==========>|
| | | | | |
| | | | | |
Figure 4. Another approach for optimized routing
As indicated in [I-D.chan-dmm-framework-gap-analysis], multiple
mechanisms can be used for setting up optimized routing for DMM.
Figure 4 illustrates another possible behavior the MR31 could take
for the purpose of determining how to forward the traffic in an
optimized manner.
MR31 first determine whether it holds the routing location
information of MN1 locally. And if MR31 determines it doesn't hold
such information, it will forward the traffic received by regular
IPv6 routing mechanism.
The traffic will be forwarded to MR12, based on the assumption that
the destination IP address of the traffic (i.e. HoA of MN1) is
anchored at MR12. Upon receiving the traffic, MR12 will determine
that the MN1 is not attached to itself. As a result, MR12 will query
with LM for MN1's routing location.
When MN1's routing location information is determined, MR12 could
Luo & Tricci Expires April 18, 2013 [Page 10]
Internet-Draft dmm-mip-pmip October 2012
perform distributed routing for delivering the traffic, as described
above, to MR11 to which the MN1 is currently attached and then
forwarded to MN1 by MR11.
MR12 is further preferred to send another message to MR31 via
interface between MRs to inform MR31 with MN1 current routing
location to trigger the direction. The MR31, based on the received
routing location information, will perform distributed routing for
delivering the rest IP packets of traffic, first to MR11, then to
MN1, as described above.
One can note that, for both behaviors described above, when the
routing between MN1 and MN2 is established, the routing is optimized:
MN2=>MR31=>MR11=>MN1.
For the latter behavior, one can also note that, if the MN1 is
currently attached to the MR12, the routing for traffic from MN2 to
MN1 will be identical with regular IPv6. But, how the MR12 can
determine MR31 (i.e. the MR to which the MN2 is attached) is a
challenge.
4.4. Handover with Active Session
Section 4.2 has already discussed scenarios the mobile node changes
its point of attachment, but without discussing how to maintain the
continuity of sessions which are initiated before the handover.
Luo & Tricci Expires April 18, 2013 [Page 11]
Internet-Draft dmm-mip-pmip October 2012
+---+ +--------+ +--------+ +-------+ +--------+ +---+
|MN1| | MR11 | | MR2 | | LM1 | | MR31 | |MN2|
+---+ +--------+ +--------+ +-------+ +--------+ +---+
| | | | | |
| | 1. Ongoing traffic | |
|<==========>|<==================================>|<========> |
| | 2. Context| | | |
| | Transfer | | | |
| |<---------->| | | 3. IP |
| | | | | Traffic |
| | 4. Distributed Routing |<========= |
| |<===================================| |
| |5. Transfer | | | |
| |==========> | | | |
| 6. IP Traffic | | | |
|<======================= | | | |
| | | 7. Redirect | |
| |----------------------------------> | |
| | | | +----------------+ |
| | | | | 8. Update | |
| | | | | Location of MN1| |
| | | | +----------------+ |
| | | | | 9. IP |
| | | | | Traffic |
| | |10. Distributed Routing|<==========|
| 11. IP Traffic |<======================| |
|<========================| | |
| | | | |
Figure 5. Handover with Active Session
Figure 5 illustrates approaches for handover of MN1 from pMR (MR11)
to nMR (MR2). During the handover, the nMR need to update MN1's new
routing location to the LM.
Context transfer between nMR and pMR is always necessary, e.g.
security context. The nMR could inform the pMR with MN1's new
routing location information during the context transfer.
Based on the received information, pMR sets up mobility context for
MN1 locally to at least record MN1's new routing location. It should
be noted that, the mobility context for a specific mobile node which
is performing handover is just a temporarily information. When the
handover is finished, the correspondent mobility context need to be
deleted.
MR31 to which the MN2 is attached isn't aware of the handover event
of MN1. Thus, the traffic from MN2 to MN1 will still be forwarded by
Luo & Tricci Expires April 18, 2013 [Page 12]
Internet-Draft dmm-mip-pmip October 2012
MR31 to the pMR (MR11) in a distributed routing manner (which is
described in section 4.3 above).
For reducing packet loss, the pMR is preferred to establish a
directional tunnel to nMR and forward the received packets from MR31
to nMR via the tunnel. The key is that, the pMR needs to send a
message to MR31 to update MN1's routing location stored in MR31
locally. Based on the updated routing location information of MN1,
MR31 will forward the upcoming traffic from MN2 to MN1 to the nMR
directly.
5. Supporting Client Based and Network Based Mobile IP
Figure 2 in [I-D.chan-dmm-framework-gap-analysis] analyzes MIP and
PMIP by comparing the destination IP address in the network-layer
header as a packet traverses from a CN to an MN. According to the
comparison, as far as the data-plane traffic is concerned, the route
from CN to MN in MIP is similar to the route from CN to MAG in PMIP.
The difference is only in replacing the MN in MIP with the MAG-MN
combination in PMIP. Therefore, the architecture using MIP can be
adapted to the architecture using PMIP by replacing the MN with the
MAG-MN combination.
Based on the above analysis which is provided
[I-D.chan-dmm-framework-gap-analysis], the idea of DMM solution
proposed in this draft applied to both MIP and PMIP supported
clients.
o If applying MIP to the deployment scenario illustrated in figure
1, the MR could be implemented with part of HA function
o If applying PMIP to the deployment scenario illustrated in figure
1, the MR could be implemented with part of LMA function, and put
MAGs between MRs and MNs. Otherwise, the MR could be implemented
with part of both LMA and MAG functions.
6. Considerations of the Optimized Routing
One can note that, the routing between MN and CN is optimized based
on the mechanism described in section 4.2. And in section 4.2, the
CN is assumed to be a mobile node. That means CN must be attached to
a certain MR, and that MR will keep track of the location of CN and
interpreted any packet sent from CN to MN. But, when CN is a fixed
node, there may be no such MR which servers the CN.
In real world, most of such fixed nodes (CN) are deployed in a
Luo & Tricci Expires April 18, 2013 [Page 13]
Internet-Draft dmm-mip-pmip October 2012
centralized manner, e.g. CDN/IDC/Web Servers and etc. Those fixed
nodes are generally converged by a couple of access routers, although
the topology within those fixed nodes may be very complicating, to
access operator's IP bearer network. Figure 6 is an example.
__________
/ CN \ ,--------.
((CDN\IDC\Web )---Access Router `.
( Server) ) ,--' `'
\___________/ \ _ -'
'-- MR -----''
|
|
MN1
Figure 6. CNs are fixed nodes
For the scenario described in figure 6, a direct solution is to
implement MR function with that so called convergence access router
or gateway router (i.e. the access router illustrated in the above
figure).
Another alternative is to use anycast mechanism described in
[I-D.chan-dmm-framework-gap-analysis] and
[I-D.wakikawa-mext-global-haha-spec]. Anycast mechanism could
guarantee the traffic sent from CN to MN to reach a nearest MR which
anycast the HNP aggregation of the mobile node.
7. Security Consideration
This draft proposes signaling messages interaction over interfaces
among MRs, LMs and HAAs for supporting Distributed Mobility
Management (figure 2). The security issues should be considered for
those messages.
Since, this draft assumes all local networks belong to a same
administrative domain (e.g. one operator), then signaling interfaces
among those MRs, LMs and HAAs can be established directly. Security
association mechanism which is used for protecting PBU\PBA messages
defined in [RFC5213] can be reused for protecting signaling messages
(such as IP address allocation, routing location information
update\query) between MR and LM\HAA.
Signaling between MRs (such as signaling for distributed mobility
support) in this draft is preferred to be protected by using end-to-
end security association(s) offering integrity and data origin
authentication. The MR is proposed to implement IPsec [RFC4301] or
Luo & Tricci Expires April 18, 2013 [Page 14]
Internet-Draft dmm-mip-pmip October 2012
other equivalents for protecting the messages. E.g. IPsec
Encapsulating Security Payload (ESP, [RFC4303]) in transport mode
with mandatory integrity protection could be used for protecting
those signaling messages.
8. Gaps with the Distributed Mobility Management Requirement
TBD
9. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
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.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
10.2. References
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos , CJ. and JC. Zuniga , "PMIPv6-based distributed
anchoring", September 2012.
[I-D.chan-dmm-framework-gap-analysis]
Chan, H., "A unified mobility management protocol
framework and DMM gap analysis", July 2012.
Luo & Tricci Expires April 18, 2013 [Page 15]
Internet-Draft dmm-mip-pmip October 2012
[I-D.ietf-dmm-requirements]
Chan, H., "Requirements for Distributed Mobility
Management", September 2012.
[I-D.korhonen-dmm-local-prefix]
Korhonen , J. and T. Savolainen , "Local Prefix Lifetime
Management for Proxy Mobile IPv6", March 2012.
[I-D.liebsch-mext-dmm-nat-phl]
Liebsch , M., "Per-Host Locators for Distributed Mobility
Management", March 2012.
[I-D.liu-mext-distributed-mobile-ip]
Liu, D., "Distributed Deployment of Mobile IPv6",
March 2010.
[I-D.seite-dmm-dma]
Seite , P. and P. Bertin , "Distributed Mobility
Anchoring", July 2012.
[I-D.wakikawa-mext-global-haha-spec]
Wakikawa , R., "Global HA to HA Protocol Specification",
September 2011.
Authors' Addresses
Wen Luo
ZTE
No.68, Zijinhua RD,Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: luo.wen@zte.com.cn
Tricci So
ZTE USA
Email: tso@zteusa.com
Luo & Tricci Expires April 18, 2013 [Page 16]
