Internet DRAFT - draft-luo-dmm-with-ipv6-prefix-properties
draft-luo-dmm-with-ipv6-prefix-properties
Network Working Group W. Luo
Internet-Draft ZTE
Intended status: Informational S. Tricci
Expires: April 18, 2013 ZTE USA
October 15, 2012
Distributed Mobility Management Approaches with IPv6 Prefix Properties
draft-luo-dmm-with-ipv6-prefix-properties-00
Abstract
This draft extends the existing PMIP-based mobility management
protocol to support a more distributed model by introducing two new
logical functions to enable distributed anchoring and location
management. Given the consideration that, the MN may not always
require the mobility support that requires the use of the global
prefix and additional network resources, this draft supports the
option to leverage the extended properties of IPv6 prefixes source
address selection hint (i.e. IPv6 Neighbor Discovery protocol and
its Prefix Information Option) to enable the UE's selection of IPv6
prefix according to its service/application's mobility support
requirement. When the extended prefix properties feature is
supported by the MN, this draft enable the MN to select the
appropriate prefix according to the mechanism as described in
[I-D.korhonen-dmm-prefix-properties]. Once the IPv6 prefix is
determined, the rest of the DMM mechanism is similar to the luo draft
[I-D.luo-dmm-pmip-based-dmm-approach].
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
Luo & Tricci Expires April 18, 2013 [Page 1]
Internet-Draft dmm-with--prefix-properties October 2012
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2013.
Copyright Notice
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.
Luo & Tricci Expires April 18, 2013 [Page 2]
Internet-Draft dmm-with--prefix-properties October 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
3. Detailed Scenarios and Approaches . . . . . . . . . . . . . . 6
3.1. Initial Attach . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Data forwarding . . . . . . . . . . . . . . . . . . . . . 7
3.3. Handoff Scenario . . . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Luo & Tricci Expires April 18, 2013 [Page 3]
Internet-Draft dmm-with--prefix-properties October 2012
1. Introduction
Centralized mobility anchoring imposes some limitations to the system
such as single point of congestion and failure, non optimal routing
etc. which are discussed in [I-D.liu-mext-distributed-mobile-ip].
With the effect of social media phenomenon and the exponential growth
of smart-phone devices (e.g. iPhone) with mobile applications that
demand the real-time performance and high bandwidth, mobile and
access network providers have trouble to keep up with such demands
even with their aggressive deployment of more efficient and higher
capacity mobile access networks (e.g. 4G and 802.11n-WLAN). It comes
to recognize that the centralized mobility anchoring model is no
longer sufficient to handle the new traffic pattern happening in the
internet and in private networks. The objective of Distributed
Mobility Management (DMM) is intended to mitigate those drawbacks,
and the purpose of this draft is to present a PMIP-based extension
for DMM support.
This draft extends the existing PMIP-based mobility management
protocol to support a more distributed model by introducing two new
logical functions to enable distributed anchoring and location
management. Given the consideration that, the MN may not always
require the mobility support that requires the use of the global
prefix and additional network resources, this draft supports the
option to leverage the extended properties of IPv6 prefixes source
address selection hint (i.e. IPv6 Neighbor Discovery protocol and
its Prefix Information Option) to enable the UE's selection of IPv6
prefix according to its service/application's mobility support
requirement. When the extended prefix properties feature is
supported by the MN, this draft enable the MN to select the
appropriate prefix according to the mechanism as described in
[I-D.korhonen-dmm-prefix-properties]. Once the IPv6 prefix is
determined, the rest of the DMM mechanism is similar to the luo draft
[I-D.luo-dmm-pmip-based-dmm-approach].
2. Solution Overview
This draft introduces two new logic functions to the existing PMIP-
based protocol to support the distributed mobility management:
1. Location Management Function (LMF) is designed to maintain the
mappings between IP addresses and location of MNs.
2. Distributed Anchoring Function (DAF) is designed to provide the
local anchoring support for the MN at its first hop router as
described in luo draft [I-D.luo-dmm-pmip-based-dmm-approach],
section 7, which is referred as enhanced LMA (eLMA) with the
Luo & Tricci Expires April 18, 2013 [Page 4]
Internet-Draft dmm-with--prefix-properties October 2012
similar property of the LMA as described in RFC[5213].
DAF is composed of Distributed Routing sub-Function (DRF) and
Distributed Mobility sub-Function (DMF). The DRF operates as the
distributed tunnel end-point at the first hop router of the MN to
support the optimized routing between two DMM-capable end-points
(i.e. MN and its corresponding node, i.e. the CN). DMF is designed
to support the mobile node's mobility handover operation, with the
intention to minimize the packet loss during the optimized route
establishment.
During the initial MN attachment, this draft re-uses an option to
leverage korhonen draft [I-D.korhonen-dmm-prefix-properties] to
deliver source address selection hint of IPv6 prefixes to the MN
(i.e. the 'M' flag in Prefix Information Option as defined in this
draft).
When eLMA detects an initial attachment of a MN, it will send a RA
message to that MN. The RA includes IPv6 prefixes, and each prefix
is tagged with its properties which includes its mobility management
property. According to the mobility management property, the IPv6
prefix is differentiated by the MN based on two categories, i.e.
global prefix and local prefix and they are defined as follows:
1. Global Prefix: if an IPv6 address derived from a global prefix is
used as source address for a session, this session will be
provided with fully mobility support by using the mobility
management mechanism specified in this draft. That means, the
address always remains valid even the point of attachment is
changed.
2. Local Prefix: if an IPv6 address derived from a local prefix is
used as source address for a session, no or limited mobility
support will be provided for this session. The address may not
be valid when the point of attachment is changed.
Based on the acquired mobility management property, MN supports its
service applications according to these two categories of IPv6
prefix. If application on MN requires mobility support, the MN will
derive an IPv6 address from the global prefix by having the
application to invoke an appropriate socket API extension.
Otherwise, the application on the MN requires no or limited mobility
support, the MN will derive IPv6 address from local prefix by
invoking another appropriate socket API extension.
The network will not provide mobility for those local IPv6 prefixes,
which implies when MN changes its point of attachment, i.e. eLMA, the
local prefix assigned by previous eLMA will be
Luo & Tricci Expires April 18, 2013 [Page 5]
Internet-Draft dmm-with--prefix-properties October 2012
deprecated\invalidated. When attached to next eLMA, the new local
prefix will be advertised by the new eLMA.
eLMA only updates the location information to the LMF for those
global prefixes. Section 3.1 provides more detailed description. If
the MN does not support the extended prefix property features as
described in [I-D.korhonen-dmm-prefix-properties], the MN will derive
the IPv6 address based on IPv6 global prefix. If either the MN does
not support this extended prefix property or the MN selects the
global prefix, the DMM mechanisms as described in
[I-D.luo-dmm-pmip-based-dmm-approach] will leverage the global IPv6
prefixes to maintain the mobility support for the MN for data
forwarding and handoff operations and they are described as follows:
a. Data Forwarding: if the application on the MN requires mobility
support (such as VOIP), it will leverages the IPv6 address
derived from a global prefix to establish a session based on this
global address as its source address with its CN. When eLMA of
the correspondent node receives traffic send to that global
address, eLMA will query the LMF for the location information of
that global address and forward the traffic based on the location
information (e.g. IP in IP tunnel). Section 3.2 below provides
more detailed descriptions.
b. Handoff: when MN changes its point of attachment from previous
eLMA to next eLMA, the next eLMA will advertise the same global
prefix to the MN over the new link and update new location
information for that global prefix to the LMF for the purpose of
maintaining the reachability of MN's global prefix. Section 3.3
below provides more detailed descriptions.
3. Detailed Scenarios and Approaches
As described above, the distributed anchor in this draft is referred
as eLMA as shown in figures below. Note that, although the MAG as
defined in RFC[5213] is not shown in the figures below, one should
aware that, the MAG could be co-located with the eLMA.
3.1. Initial Attach
Luo & Tricci Expires April 18, 2013 [Page 6]
Internet-Draft dmm-with--prefix-properties October 2012
Internet
| +-----+
| | LMF |
Border Router +-----+
|
+-----------------+---------
|
+---+---+
| eLMA1 |
| (DAF) |
+--+----+
Global Prefix | |Local Prefix
(PreB) | | (PreA)
V V
+----+
| MN |
+----+
IP1: From PreA (Local, without mobility)
IP2: From PreB (Global, with mobility)
Figure 1. Initial Attach
When eLMA1 detects an initial attachment of a mobile node, it sends a
RA message to that mobile. The RA includes two categories of
prefixes, local prefix (PreA) and global prefix (PreB). The eLMA
should set PreA (i.e. local prefix) with high priority and PreB (i.e.
global prefix) with low priority as according to
[I-D.korhonen-dmm-prefix-properties].
The mobile node will derive its IPv6 addresses based on these two
categories of IPv6 prefixes provided by the RA message. The derived
IPv6 addresses include local IPv6 address (IP1 in figure 1) and
global IPv6 address (IP2 in figure 1). Applications on the mobile
node could select an appropriate IPv6 address as its source address
as described in section 4 in [I-D.korhonen-dmm-prefix-properties].
Furthermore, the eLMA1 needs to perform the location update for the
MN based on the MN's global prefix-to-location mapping info, i.e.
{MN's global prefix, eLMA's IPv6 address}, for this particular mobile
node to the LMF based on the mechanism introduced in section 7.2 of
[I-D.luo-dmm-pmip-based-dmm-approach]. Note that, the distributed
anchor performs the location update only for the MN's global prefix.
3.2. Data forwarding
Luo & Tricci Expires April 18, 2013 [Page 7]
Internet-Draft dmm-with--prefix-properties October 2012
IP1 as destination:
common routing
| +-------+ +----+
| | eLMA3 |_______| CN |
+-----+ +-------------+ (DAF) | +----+
| LMF | | +-------+
+-----+ | IP2 as destination:
| Routing based on location
--------------+----+ (e.g. IP in IP tunnel)
|
+---+---+
| eLMA1 |
| (DAF) |
+--+----+
Global Prefix | |Local Prefix
(PreB) | | (PreA)
V V
+----+
| MN |
+----+
IP1: From PreA (Local, without mobility)
IP2: From PreB (Global, with mobility)
Figure 2.1 Data forwarding mechanism
When correspondent node (CN) sends traffic to the mobile node, the
traffic will arrive at CN's distributed anchor first (i.e. eLMA3 in
figure 2.1). Depending on the category of the destination IPv6
address, eLMA3 will operate accordingly:
1. If the destination IPv6 address with local IPv6 prefix (IP1 in
figure 2.1), eLMA3 will route the IP packet by using the generic
IPv6 routing mechanism.
2. Otherwise, if the destination IPv6 address with global IPv6
prefix (IP2 in figure 2.1), then eLMA3 will route this IP packet
using routing mechanism as specified in section 7.2 of
[I-D.luo-dmm-pmip-based-dmm-approach].
Luo & Tricci Expires April 18, 2013 [Page 8]
Internet-Draft dmm-with--prefix-properties October 2012
+-------+ +----+
| eLMA3 |<--------------+ CN |
| (DAF) | +----+
+-------+ Destination IP (IP2)is
Tunneled || global IPv6 address
forwarding || configured on MN
based on MN's ||
location ||
VV
+-------+ +----+
| eLMA1 +-------------->| MN |
| (DAF) | +----+
+-------+
Figure 2.2 traffic between CN and MN, when destination is global IPv6
address of MN, routing is optimized.
As shown in figure 2.2, if the traffic from CN is sent to the mobile
node's global IPv6 address (i.e. IP2), the routing will be:
CN-->eLMA3==>eLMA1-->MN which is based on optimized route.
Note that, the tunnel between eLMA1 and eLMA3 is not per MN-CN pair,
rather, it is a single tunnel between two distributed anchor peers.
Any traffic between the MNs which are attached to these two peers
will be routed over the same tunnel of which the tunnel is over an
optimal routing path between the peers.
3.3. Handoff Scenario
Luo & Tricci Expires April 18, 2013 [Page 9]
Internet-Draft dmm-with--prefix-properties October 2012
IP1 as destination:
can not be reachable
after handoff
Internet IP3 as destination:
| common routing
| +-------+ +----+
| | | eLMA3 |_______| CN |
| +-----+ +------+ (DAF) | +----+
Border Router | LMF | | +-------+
| +-----+ | IP2 as destination:
| | Routing based on location
+-----+---------------------+--+
| |
+---+---+ +---+---+
| eLMA2 | | eLMA1 |
| (DAF) | | (DAF) |
+-------+ +--+----+
Local Prefix | | Global Prefix | |Local Prefix
(PreC) | | (PreB) | | (PreA)
V V V V
+----+ +----+
| MN | <------------ | MN |
+----+ +----+
IP3: From PreC IP1: From PreA
(Local, without mobility) (Local, without mobility)
IP2:Keep unchanged IP2: From PreB
(Global, with mobility) (Global, with mobility)
Figure 3.1 Handover Scenario
The handover between distributed anchors happens when the mobile node
switches to a new distributed anchor, i.e. switching its anchor from
eLMA1 to eLMA2 as shown in figure 3.1. Once eLMA2 detects the
attachment from the MN, it will send a RA which includes local
prefix(es) and global prefix(es) to the mobile node and the handover
operation is described as follows:
a. MN's local prefix assigned by the previous distributed anchor
(PreA in figure 3.1) will be deprecated\invalidated. In this
case, the traffic which is sent to IP1 (configured from PreA)
from CN will be discarded by the IPv6 routing system
automatically; unless, a temporary tunnel between the previous
and the next distributed anchors is setup to maintain the
reachability to the previous local prefix. Applications which
rely on those local prefixes may suffer a change of source IP
address.
Luo & Tricci Expires April 18, 2013 [Page 10]
Internet-Draft dmm-with--prefix-properties October 2012
b. New local prefix(es) (i.e. PreC in figure 3.1) carried in the RA
message and is assigned by eLMA2 is now have high priority. The
MN will derive a new IPv6 local address (IP3 in figure 3.1) for
the PreC.
c. The global prefix(es) (i.e.PreB in figure 3.1) in the RA message
remain the same global prefix(es) as assigned by eLMA1 which is
the distributed anchor of this MN during its initial attachment.
The eLMA2 shall perform the location update for the global
prefixes of this MN based on the IPv6 address of eLMA2 to LMF to
maintain the reachability of those global prefix(es). The
details for the handover can be reviewed in section 7.2 of
[I-D.luo-dmm-pmip-based-dmm-approach]
Thus, after the handover, the mobile node can be reached either via
its new local IPv6 address (i.e. IP3) or via its global IPv6 address
(i.e. IP2); and if a temporary tunnel is present between eLMA1 and
eLMA2, also be researchable via its previous local IPv6 address
(i.e.IP1).
It is the network policy to decide to maintain the reachability to
the previous local prefix via a temporary tunnel between the previous
distributed anchor and the next distributed anchor as described in
section 4.4.2 of [I-D.korhonen-dmm-local-prefix] (Note that the
distributed anchor refers to MAG in [I-D.korhonen-dmm-local-prefix]
and eLMA in this draft). Never-the-less, the purpose for such
temporary tunnel to support service continuity when employing the
local prefix is similar to the tunnel used by the global prefix for
the mobility management purpose.
+-------+ +----+
| eLMA3 |<--------------+ CN |
| (DAF) | +----+
+-------+ Destination IP (IP2) is
Tunneled || global IPv6 address
forwarding || configured on MN
based on MN's ||
new location ||
VV
+-------+ +----+
| eLMA2 +-------------->| MN |
| (DAF) | +----+
+-------+
(New Distributed anchor after handoff)
Figure 3.2 traffic between CN and MN after the handover, when
destination is global IPv6 address of MN, routing is also optimized.
Luo & Tricci Expires April 18, 2013 [Page 11]
Internet-Draft dmm-with--prefix-properties October 2012
As shown in figure 3.2, if the traffic from CN is sent to the mobile
node's global IPv6 address (i.e. IP2) after the handover, the
routing will be: CN-->eLMA3==>eLMA2-->MN. The routing is still
optimized.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
TBD
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
6.2. References
[I-D.korhonen-dmm-local-prefix]
Korhonen, J. and T. Savolainen , "Local Prefix Lifetime
Management for Proxy Mobile IPv6", March 2012.
[I-D.korhonen-dmm-prefix-properties]
Korhonen , J., "IPv6 Prefix Mobility Management
Properties", July 2012.
[I-D.liu-mext-distributed-mobile-ip]
Liu, D., "Distributed Deployment of Mobile IPv6",
March 2010.
[I-D.luo-dmm-pmip-based-dmm-approach]
Luo, W., "PMIP Based DMM Approaches", March 2012.
Luo & Tricci Expires April 18, 2013 [Page 12]
Internet-Draft dmm-with--prefix-properties October 2012
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
Phone:
Fax:
Email: tso@zteusa.com
URI:
Luo & Tricci Expires April 18, 2013 [Page 13]
