Internet DRAFT - draft-tu-dmm-with-mip
draft-tu-dmm-with-mip
Network Working Group Y. Tu
Internet-Draft W. Luo
Intended status: Standards Track ZTE
Expires: February 1, 2014 S. Tricci
ZTE USA
July 31, 2013
Distributed Mobility Management Approach with Mobile IP
draft-tu-dmm-with-mip-00
Abstract
Based on the analysis of current centralized mobility management
approaches, three main functions of current centralized mobility
anchor are introduced, which are Mobility Routing (MR), Home Address
Allocation (HAA), and Location Management (LM).
Based on the proposal of decoupling those functions, this document
provides a concept of architecture for Distributed Mobility
Management (DMM) with some key approaches for DMM.
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 February 1, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
Tu, et al. Expires February 1, 2014 [Page 1]
Internet-Draft dmm-mip July 2013
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 . . . . . . . . . . . . . . . . . . . . . . 3
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 . . 6
4.1. Initial Attachment . . . . . . . . . . . . . . . . . . . . 6
4.2. Dynamic Mobility Management . . . . . . . . . . . . . . . 7
4.3. Distributed Routing . . . . . . . . . . . . . . . . . . . 7
4.4. Handover with Active Session . . . . . . . . . . . . . . . 10
5. Considerations of the Optimized Routing . . . . . . . . . . . 12
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Tu, et al. Expires February 1, 2014 [Page 2]
Internet-Draft dmm-mip July 2013
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.ietf-dmm-requirements]. Based on the analysis of
current centralized mobility management approaches, three main
functions are introduced, including Mobility Routing (MR), Home
Address Allocation (HAA), and Location Management (LM).
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.
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.ietf-dmm-best-practices-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
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
Tu, et al. Expires February 1, 2014 [Page 3]
Internet-Draft dmm-mip July 2013
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.ietf-dmm-best-practices-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.
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
Tu, et al. Expires February 1, 2014 [Page 4]
Internet-Draft dmm-mip July 2013
are co-located as ana signal entity in local network 1 and 2, while
are deployed separately in local network 3.
It should be noticed that, this figure is only an example. In actual
deployment, for one signal local network, multiple LMs and HAAs could
also be deployed. Also, it is 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.
+-------------------------------------+ +--------------------------+
| +---------+ +---------+ | | +---------+ |
| | 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) 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 prefix
or IP address assignment, during the attachment of a mobile node
to a MR
Tu, et al. Expires February 1, 2014 [Page 5]
Internet-Draft dmm-mip July 2013
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.
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 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
assignment. The HoA assignment mechanism could be based on stateful
or stateless mechanism.
After configuring HoA 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 is anchored at mobile
node's currently attached MR. The traffic, which is designated to
mobile node's HoA, should be routed to that MR by regular IPv6
routing mechanism automatically.
Tu, et al. Expires February 1, 2014 [Page 6]
Internet-Draft dmm-mip July 2013
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 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 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 anchored at pMR and nMR
are respectively available for the mobile node.
In this case, newly initiated session after the handover is preferred
to use new HoA as source IP. Meantime, old session which has already
established before handover could still use the old HoA 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 be noted that, in the above configuration, mobile
node should have ability to manage multiple HoAs, 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
Tu, et al. Expires February 1, 2014 [Page 7]
Internet-Draft dmm-mip July 2013
should determine how to forward the traffic optimally.
+-----+ +-------+ +-------+ +--------+ +-----+
| 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 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.
Tu, et al. Expires February 1, 2014 [Page 8]
Internet-Draft dmm-mip July 2013
Only two example distributed routing mechanisms are list above. Some
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
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
Tu, et al. Expires February 1, 2014 [Page 9]
Internet-Draft dmm-mip July 2013
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.
It should be noted 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, 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.
Tu, et al. Expires February 1, 2014 [Page 10]
Internet-Draft dmm-mip July 2013
+---+ +--------+ +--------+ +-------+ +--------+ +---+
|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
Tu, et al. Expires February 1, 2014 [Page 11]
Internet-Draft dmm-mip July 2013
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. 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. 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
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 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.ietf-dmm-best-practices-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.
Tu, et al. Expires February 1, 2014 [Page 12]
Internet-Draft dmm-mip July 2013
6. 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 PB\PB messages
defined in [RFC3775] 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
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.
7. IANA Considerations
This document makes no request of IANA.
8. References
8.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.
Tu, et al. Expires February 1, 2014 [Page 13]
Internet-Draft dmm-mip July 2013
8.2. References
[I-D.bernardos-dmm-distributed-anchoring]
Bernardos , CJ. and JC. Zuniga , "PMIPv6-based distributed
anchoring", April 2013.
[I-D.ietf-dmm-best-practices-gap-analysis]
Liu, D., "Distributed Mobility Management: Current
practices and gap analysis", June 2013.
[I-D.ietf-dmm-requirements]
Chan, H., "Requirements for Distributed Mobility
Management", July 2013.
[I-D.korhonen-dmm-local-prefix]
Korhonen , J. and T. Savolainen , "Local Prefix Lifetime
Management for Proxy Mobile IPv6", June 2013.
[I-D.liebsch-mext-dmm-nat-phl]
Liebsch , M., "Per-Host Locators for Distributed Mobility
Management", March 2012.
[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
Yangwei Tu
ZTE
No.68, Zijinhua RD,Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: tu.yangwei@zte.com.cn
Tu, et al. Expires February 1, 2014 [Page 14]
Internet-Draft dmm-mip July 2013
Wen Luo
ZTE
No.68, Zijinhua RD,Yuhuatai District
Nanjing, Jiangsu 210012
China
Email: luo.wen@zte.com.cn
Tricci So
ZTE USA
Phone:
Fax:
Email: tso@zteusa.com
URI:
Tu, et al. Expires February 1, 2014 [Page 15]
