draft-ietf-dmm-best-practices-gap-analysis-08.txt   draft-ietf-dmm-best-practices-gap-analysis-09.txt 
DMM D. Liu, Ed. DMM D. Liu, Ed.
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational JC. Zuniga, Ed. Intended status: Informational JC. Zuniga, Ed.
Expires: April 2, 2015 InterDigital Expires: May 8, 2015 InterDigital
P. Seite P. Seite
Orange Orange
H. Chan H. Chan
Huawei Technologies Huawei Technologies
CJ. Bernardos CJ. Bernardos
UC3M UC3M
September 29, 2014 November 4, 2014
Distributed Mobility Management: Current practices and gap analysis Distributed Mobility Management: Current practices and gap analysis
draft-ietf-dmm-best-practices-gap-analysis-08 draft-ietf-dmm-best-practices-gap-analysis-09
Abstract Abstract
This document analyzes deployment practices of existing IP mobility This document analyzes deployment practices of existing IP mobility
protocols in a distributed mobility management environment. It then protocols in a distributed mobility management environment. It then
identifies existing limitations when compared to the requirements identifies existing limitations when compared to the requirements
defined for a distributed mobility management solution. defined for a distributed mobility management solution.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2015. This Internet-Draft will expire on May 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 42 skipping to change at page 4, line 42
based on the internetwork location information, either to the based on the internetwork location information, either to the
destination or to some other network element that knows how to destination or to some other network element that knows how to
forward the packets to their destination. forward the packets to their destination.
FM may optionally be split into the control plane (FM-CP) and FM may optionally be split into the control plane (FM-CP) and
data plane (FM-DP). data plane (FM-DP).
In Mobile IPv6, the home agent (HA) typically provides the anchoring In Mobile IPv6, the home agent (HA) typically provides the anchoring
function (AF); the location information server (LIs) is at the HA function (AF); the location information server (LIs) is at the HA
whereas the location information client (LIc) is at the MN; the whereas the location information client (LIc) is at the MN; the
Forwarding Management (FM) function resides in both ends of the Forwarding Management (FM) function is distributed between the ends
tunnel at the HA and the MN. of the tunnel at the HA and the MN.
In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the In Proxy Mobile IPv6, the Local Mobility Anchor (LMA) provides the
anchoring function (AF); the location information server (LIs) is at anchoring function (AF); the location information server (LIs) is at
the LMA whereas the location information client (LIc) is at the the LMA whereas the location information client (LIc) is at the
mobile access gateway (MAG); the Forwarding Management (FM) function mobile access gateway (MAG); the Forwarding Management (FM) function
resides in both ends of the tunnel at the HA and the MAG. is distributed between the ends of the tunnel at the HA and the MAG.
In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the Mobility Anchor In Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], the Mobility Anchor
Point (MAP) serves as a location information aggregator between the Point (MAP) serves as a location information aggregator between the
LIs at the HA and the LIc at the MN. The MAP also provides the FM LIs at the HA and the LIc at the MN. The MAP also provides the FM
function to enable tunneling between HA and itself as well as function to enable tunneling between HA and itself as well as
tunneling between MN and itself. tunneling between MN and itself.
4. DMM practices 4. DMM practices
This section documents deployment practices of existing mobility This section documents deployment practices of existing mobility
skipping to change at page 7, line 9 skipping to change at page 7, line 9
Controller (WLC), which performs radio resource management on the Controller (WLC), which performs radio resource management on the
APs, domain-wide mobility policy enforcement and centralized APs, domain-wide mobility policy enforcement and centralized
forwarding function for the user traffic. The WLC could also forwarding function for the user traffic. The WLC could also
implement layer-3 routing functions, or attach to an access router implement layer-3 routing functions, or attach to an access router
(AR). Last, on the right-hand side of the figure, access points AP3 (AR). Last, on the right-hand side of the figure, access points AP3
and AP4 are directly connected to an access router. This can also be and AP4 are directly connected to an access router. This can also be
used as a generic connectivity model. used as a generic connectivity model.
IP mobility protocols can be used to provide heterogeneous network IP mobility protocols can be used to provide heterogeneous network
mobility support to users, e.g., handover from Wi-Fi to cellular mobility support to users, e.g., handover from Wi-Fi to cellular
access. Two kind of protocols can be used: Proxy Mobile IPv6 access. Two kinds of protocols can be used: Proxy Mobile IPv6
[RFC5213] or Mobile IPv6 [RFC5555], with the role of mobility anchor, [RFC5213] or Mobile IPv6 [RFC5555], with the role of mobility anchor,
e.g., Local Mobility Anchor or home agent, typically being played by e.g., Local Mobility Anchor or home agent, typically being played by
the edge router of the mobile network [SDO-3GPP.23.402]. the edge router of the mobile network [SDO-3GPP.23.402].
Although this section has made use of the example of Wi-Fi networks, Although this section has made use of the example of Wi-Fi networks,
there are other flattening mobile network architectures specified, there are other flattening mobile network architectures specified,
such as WiMAX [IEEE.802-16.2009], which integrates both host- and such as WiMAX [IEEE.802-16.2009], which integrates both host- and
network-based IP mobility functions. network-based IP mobility functions.
Existing IP mobility protocols can also be deployed in a flatter Existing IP mobility protocols can also be deployed in a flatter
skipping to change at page 8, line 11 skipping to change at page 8, line 11
to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in to each MN [RFC4640], [RFC5026], [RFC6611]. In the example shown in
Figure 2, the mobile node MN1 is assigned to the home agent HA1 and Figure 2, the mobile node MN1 is assigned to the home agent HA1 and
uses a home address anchored by HA1 to communicate with the uses a home address anchored by HA1 to communicate with the
correspondent node CN1. Similarly, the mobile node MN2 is assigned correspondent node CN1. Similarly, the mobile node MN2 is assigned
to the home agent HA2 and uses a home address anchored by HA2 to to the home agent HA2 and uses a home address anchored by HA2 to
communicate with the correspondent node CN2. Note that MIPv6/NEMO communicate with the correspondent node CN2. Note that MIPv6/NEMO
specifications do not prevent the simultaneous use of multiple home specifications do not prevent the simultaneous use of multiple home
agents by a single mobile node. In this deployment model, the mobile agents by a single mobile node. In this deployment model, the mobile
node can use several anchors at the same time, each of them anchoring node can use several anchors at the same time, each of them anchoring
IP flows initiated at a different point of attachment. However, IP flows initiated at a different point of attachment. However,
there is currently no mechanism specified in IETF to enable an there is currently no mechanism specified in IETF standard to enable
efficient dynamic discovery of available anchors and the selection of an efficient dynamic discovery of available anchors and the selection
the most suitable one. of the most suitable one.
<-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK -------> <-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
+-----+ +-----+ +--------+ +-----+ +-----+ +--------+
| CN1 |--- ===| AR1 |=======| MN1 | | CN1 |--- ===| AR1 |=======| MN1 |
+-----+ \ +-----------+ // +-----+ |(FM,LMc)| +-----+ \ +-----------+ // +-----+ |(FM,LMc)|
---| HA1 |=== +--------+ ---| HA1 |=== +--------+
|(AF,FM,LMs)| +-----+ (anchored |(AF,FM,LMs)| +-----+ (anchored
+-----------+ | AR2 | at HA1) +-----------+ | AR2 | at HA1)
+-----+ +-----+ +-----+ +-----+
| CN2 |-------------- | CN2 |--------------
+-----+ \ +-----+ +--------+ +-----+ \ +-----+ +--------+
-------------| AR3 |-------| MN2 | -------------| AR3 |-------| MN2 |
+-----------+ +-----+ |(FM,LMc)| +-----------+ +-----+ |(FM,LMc)|
| HA2 | +--------+ | HA2 | +--------+
|(AF,FM,LMs)| +-----+ (anchored |(AF,FM,LMs)| +-----+ (anchored
+-----------+ | AR4 | at HA2) +-----------+ | AR4 | at HA2)
+-----+ +-----+
CN1 CN2 HA1 HA2 AR1 AR3 MN1 MN2 CN1 CN2 HA1 HA2 AR1 AR3 MN1 MN2
| | | | | | | | | | | | | | | |
|<-------------->|<================+=============>| | BT mode |<-------------->|<======tunnel====+=============>| | BT mode
| | | | | | | | | | | | | | | |
| |<---------------------------------+-------------->| RO mode | |<---------------------------------+-------------->| RO mode
| | | | | | | | | | | | | | | |
Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO Figure 2: Distributed operation of Mobile IPv6 (BT and RO) / NEMO
One goal of the deployment of mobility protocols in a distributed One goal of the deployment of mobility protocols in a distributed
mobility management environment is to avoid the suboptimal routing mobility management environment is to avoid the suboptimal routing
caused by centralized anchoring. Here, the Route Optimization (RO) caused by centralized anchoring. Here, the Route Optimization (RO)
support provided by Mobile IPv6 can be used to achieve a flatter IP support provided by Mobile IPv6 can be used to achieve a flatter IP
skipping to change at page 10, line 25 skipping to change at page 10, line 25
at HA1 / at MAP1 at HA1 / at MAP1
/ +---+ / +---+
/ |AR3| / |AR3|
+-----+ / +----------+ +---+ +-----+ / +----------+ +---+
| CN2 |---------------- | MAP2 | | CN2 |---------------- | MAP2 |
+-----+ |(AF,FM,LM)| +---+ +-----+ |(AF,FM,LM)| +---+
+----------+ |AR4| +----------+ |AR4|
+---+ +---+
CN1 CN2 HA1 MAP1 AR1 MN1 CN1 CN2 HA1 MAP1 AR1 MN1
| | | | | | | | | | | |
|<-------------->|<===============>|<======================>| HoA |<-------------->|<===============>|<====tunnel============>| HoA
| | | | | | | | | | | |
| |<-------------------------->|<======================>| RCoA | |<-------------------------->|<====tunnel============>| RCoA
| | | | | | | | | | | |
Figure 3: Hierarchical Mobile IPv6 Figure 3: Hierarchical Mobile IPv6
When HMIPv6 is used, the MN has two different temporary addresses: When HMIPv6 is used, the MN has two different temporary addresses:
the Regional Care-of Address (RCoA) and the Local Care-of Address the Regional Care-of Address (RCoA) and the Local Care-of Address
(LCoA). The RCoA is anchored at one MAP, which plays the role of (LCoA). The RCoA is anchored at one MAP, which plays the role of
local home agent, while the LCoA is anchored at the access router local home agent, while the LCoA is anchored at the access router
level. The mobile node uses the RCoA as the CoA signaled to its home level. The mobile node uses the RCoA as the CoA signaled to its home
agent. Therefore, while roaming within a local domain handled by the agent. Therefore, while roaming within a local domain handled by the
same MAP, the mobile node does not need to update its home agent, same MAP, the mobile node does not need to update its home agent,
i.e., the mobile node does not change its RCoA. i.e., the mobile node does not change its RCoA.
The use of HMIPv6 enables some form of route optimization, since a The use of HMIPv6 enables a form of route optimization, since a
mobile node may decide to directly use the RCoA as source address for mobile node may decide to directly use the RCoA as source address for
a communication with a given correspondent node, particularly if the a communication with a given correspondent node, particularly if the
MN does not expect to move outside the local domain during the MN does not expect to move outside the local domain during the
lifetime of the communication. This can be seen as a potential DMM lifetime of the communication. This can be seen as a potential DMM
mode of operation, though it fails to provide session continuity if mode of operation, though it fails to provide session continuity if
and when the MN moves outside the local domain. In the example shown and when the MN moves outside the local domain. In the example shown
in Figure 3, MN1 is using its global HoA to communicate with CN1, in Figure 3, MN1 is using its global HoA to communicate with CN1,
while it is using its RCoA to communicate with CN2. while it is using its RCoA to communicate with CN2.
Furthermore, a local domain might have several MAPs deployed, Furthermore, a local domain might have several MAPs deployed,
enabling therefore a different kind of HMIPv6 deployments which are enabling therefore a different kind of HMIPv6 deployments which are
flattening and distributed. The HMIPv6 specification supports a flattening and distributed. The HMIPv6 specification supports a
flexible selection of the MAP, including those based on the distance flexible selection of the MAP, including those based on the distance
between the MN and the MAP, or taking into consideration the expected between the MN and the MAP, or taking into consideration the expected
mobility pattern of the MN. mobility pattern of the MN.
Another extension that can be used to help distributing mobility Another extension that can be used to help with distributing mobility
management functions is the Home Agent switch specification management functions is the Home Agent switch specification
[RFC5142], which defines a new mobility header for signaling a mobile [RFC5142], which defines a new mobility header for signaling a mobile
node that it should acquire a new home agent. [RFC5142] does not node that it should acquire a new home agent. [RFC5142] does not
specify the case of changing the mobile node's home address, as that specify the case of changing the mobile node's home address, as that
might imply loss of connectivity for ongoing persistent connections. might imply loss of connectivity for ongoing persistent connections.
Nevertheless, that specification could be used to force the change of Nevertheless, that specification could be used to force the change of
home agent in those situations where there are no active persistent home agent in those situations where there are no active persistent
data sessions that cannot cope with a change of home address. data sessions that cannot cope with a change of home address.
There are other host-based approaches standardized that can be used There are other host-based approaches standardized that can be used
skipping to change at page 12, line 45 skipping to change at page 12, line 45
+-----+ | MAG2 | +-----+ | MAG2 |
| CN2 |--- |(FM,LMc)| | CN2 |--- |(FM,LMc)|
+-----+ \ +-----------+ +--------+ +-----+ \ +-----------+ +--------+
---| LMA2 |======= ---| LMA2 |=======
+-----+ |(AF,FM,LMs)| \\ +--------+ +---+ +-----+ |(AF,FM,LMs)| \\ +--------+ +---+
| CN3 | +-----------+ =======| MAG3 |------|MN2| | CN3 | +-----------+ =======| MAG3 |------|MN2|
+-----+ |(FM,LMs)| +---+ +-----+ |(FM,LMs)| +---+
+--------+ +--------+
CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2 CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2
| | | | | | | | | | | | | | | |
|<-------------->|<=========================>|<----------->| | |<-------------->|<===========tunnel========>|<----------->| |
| | | | | | | | | | | | | | | |
| |<-------------->|<========================>|<----------->| | |<-------------->|<=====tunnel=============>|<----------->|
| | | | | | | | | | | | | | | |
Figure 4: Distributed operation of Proxy Mobile IPv6 Figure 4: Distributed operation of Proxy Mobile IPv6
In a similar way to the host-based IP mobility case, network-based IP In a similar way to the host-based IP mobility case, network-based IP
mobility has some extensions defined to mitigate the suboptimal mobility has some extensions defined to mitigate the suboptimal
routing issues that may arise due to the use of a centralized anchor. routing issues that may arise due to the use of a centralized anchor.
The Local Routing extensions [RFC6705] enable optimal routing in The Local Routing extensions [RFC6705] enable optimal routing in
Proxy Mobile IPv6 in three cases: i) when two communicating MNs are Proxy Mobile IPv6 in three cases: i) when two communicating MNs are
attached to the same MAG and LMA, ii) when two communicating MNs are attached to the same MAG and LMA, ii) when two communicating MNs are
skipping to change at page 22, line 28 skipping to change at page 22, line 28
defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6.
Standardized configuration with NETCONF [RFC6241], using Standardized configuration with NETCONF [RFC6241], using
YANG [RFC6020] modules is lacking. YANG [RFC6020] modules is lacking.
5.7. Security considerations - REQ7 5.7. Security considerations - REQ7
As stated in [RFC7333], a DMM solution has to support any security As stated in [RFC7333], a DMM solution has to support any security
protocols and mechanisms needed to secure the network and to make protocols and mechanisms needed to secure the network and to make
continuous security improvements. In addition, with security taken continuous security improvements. In addition, with security taken
into consideration early in the design, a DMM solution cannot into consideration early in the design, a DMM solution cannot
introduce new security risks, or amplify existing security risks, introduce new security risks, or privacy concerns, or amplify
that cannot be mitigated by existing security protocols and existing security risks, that cannot be mitigated by existing
mechanisms. security protocols and mechanisms.
Any solutions that are intended to fill in gaps identified in this Any solutions that are intended to fill in gaps identified in this
document need to meet this requirement. At present, it does not document need to meet this requirement. At present, it does not
appear that using existing solutions to support DMM has introduced appear that using existing solutions to support DMM has introduced
any new security issues. For example, Mobile IPv6 defines security any new security issues. For example, Mobile IPv6 defines security
features to protect binding updates both to home agents and features to protect binding updates both to home agents and
correspondent nodes. It also defines mechanisms to protect the data correspondent nodes. It also defines mechanisms to protect the data
packets transmission for Mobile IPv6 users. Proxy Mobile IPv6 and packets transmission for Mobile IPv6 users. Proxy Mobile IPv6 and
other variations of mobile IP also have similar security other variations of mobile IP also have similar security
considerations. considerations.
skipping to change at page 25, line 41 skipping to change at page 25, line 41
path. This would amount to a denial of service attack against the path. This would amount to a denial of service attack against the
specific node or nodes for which the traffic is intended. specific node or nodes for which the traffic is intended.
Distributed mobility anchoring, while keeping current security Distributed mobility anchoring, while keeping current security
mechanisms, might require more security associations to be managed by mechanisms, might require more security associations to be managed by
the mobility management entities, potentially leading to scalability the mobility management entities, potentially leading to scalability
and performance issues. Moreover, distributed mobility anchoring and performance issues. Moreover, distributed mobility anchoring
makes mobility security problems more complex, since traffic makes mobility security problems more complex, since traffic
redirection requests might come from previously unconsidered origins, redirection requests might come from previously unconsidered origins,
thus leading to distributed points of attack. Consequently, the DMM thus leading to distributed points of attack. Consequently, the DMM
security design needs to account for the distribution of security security design needs to account for the distribution of security
associations between additional mobility entities. associations between additional mobility entities and fulfill the
security requirement of [RFC7333].
7. Contributors 7. Contributors
This document has benefited to valuable contributions from This document has benefited to valuable contributions from
Charles E. Perkins Charles E. Perkins
Huawei Technologies Huawei Technologies
EMail: charliep@computer.org EMail: charliep@computer.org
who had produced a matrix to compare the different mobility protocols who had produced a matrix to compare the different mobility protocols
and extensions against a list of desired DMM properties. They were and extensions against a list of desired DMM properties. They were
useful inputs in the early work of gap analysis. He had continued to useful inputs in the early work of gap analysis. He had continued to
give suggestions as well as extensive review comments to this give suggestions as well as extensive review comments to this
documents. documents.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 26, line 12 skipping to change at page 26, line 14
who had produced a matrix to compare the different mobility protocols who had produced a matrix to compare the different mobility protocols
and extensions against a list of desired DMM properties. They were and extensions against a list of desired DMM properties. They were
useful inputs in the early work of gap analysis. He had continued to useful inputs in the early work of gap analysis. He had continued to
give suggestions as well as extensive review comments to this give suggestions as well as extensive review comments to this
documents. documents.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, [RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", RFC "Requirements for Distributed Mobility Management", RFC
7333, August 2014. 7333, August 2014.
8.2. Informative References 8.2. Informative References
[I-D.anipko-mif-mpvd-arch] [I-D.anipko-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture", Anipko, D., "Multiple Provisioning Domain Architecture",
draft-anipko-mif-mpvd-arch-05 (work in progress), November draft-anipko-mif-mpvd-arch-05 (work in progress), November
2013. 2013.
skipping to change at page 28, line 38 skipping to change at page 28, line 45
2011. 2011.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
Deployment for Multicast Listener Support in Proxy Mobile Deployment for Multicast Listener Support in Proxy Mobile
IPv6 (PMIPv6) Domains", RFC 6224, April 2011. IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
[RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
"Runtime Local Mobility Anchor (LMA) Assignment Support "Runtime Local Mobility Anchor (LMA) Assignment Support
for Proxy Mobile IPv6", RFC 6463, February 2012. for Proxy Mobile IPv6", RFC 6463, February 2012.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, [RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa,
"Proxy Mobile IPv6 Management Information Base", RFC 6475, "Proxy Mobile IPv6 Management Information Base", RFC 6475,
May 2012. May 2012.
[RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) [RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6)
Bootstrapping for the Integrated Scenario", RFC 6611, May Bootstrapping for the Integrated Scenario", RFC 6611, May
 End of changes. 21 change blocks. 
27 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/