+---------------+-------+  +----------+  +-------------+    =====   
|Residential |  |H(e)NB |  | Backhaul |  |Mobile       |   ( IP  )
|Enterprise  |..|-------|..|          |..|Operator     |..(Network)            
|Network     |  |L-GW   |  |          |  |Core network |   =======
+---------------+-------+  +----------+  +-------------+
                    /
                    |
                    /
                 +-----+
                 | UE  |
                 +-----+
        

Figure 8: LIPA architecture

The 3GPP architecture specifications also provide mechanisms to allow discovery and selection of gateways [SDO-3GPP.29.303]. These mechanisms enable decisions taking into consideration topological location and gateway collocation aspects, relying upon the DNS as a "location database".

Both SIPTO and LIPA have a very limited mobility support, specially in 3GPP specifications up to Rel-12. Briefly, LIPA mobility support is limited to handovers between HeNBs that are managed by the same L-GW (i.e., mobility within the local domain). There is no guarantee of IP session continuity for SIPTO.

5. Gap analysis

The goal of this section is to identify the limitations in the current practices, described in Section 4, with respect to the DMM requirements listed in [RFC7333].

5.1. Distributed mobility management - REQ1

According to requirement #1 stated in [RFC7333], IP mobility, network access and forwarding solutions provided by DMM must enable traffic to avoid traversing single mobility anchor far from the optimal route.

From the analysis performed in Section 4, a DMM deployment can meet the requirement "REQ#1 Distributed mobility management" usually relying on the following functions:

• Multiple (distributed) anchoring: ability to anchor different sessions of a single mobile node at different anchors. In order to provide improved routing, some anchors might need to be placed closer to the mobile node or the corresponding node.
• Dynamic anchor assignment/re-location: ability to i) assign the initial anchor, and ii) dynamically change the initially assigned anchor and/or assign a new one (this may also require to transfer mobility context between anchors). This can be achieved either by changing anchor for all ongoing sessions or by assigning new anchors just for new sessions.

Both the main client- and network-based IP mobility protocols, namely (DS)MIPv6 and PMIPv6 allow deploying multiple anchors (i.e., home agents and localized mobility anchors), therefore providing the multiple anchoring function. However, existing solutions only provide a initial anchor assignment, thus the lack of dynamic anchor change/new anchor assignment is a gap. Neither the HA switch nor the LMA runtime assignment allow changing the anchor during an ongoing session. This actually comprises several gaps: ability to perform anchor assignment at any time (not only at the initial MN's attachment), ability of the current anchor to initiate/trigger the relocation, and ability to transfer registration context between anchors.

Dynamic anchor assignment may lead the MN to manage different mobility sessions served by different mobility anchors. This is not an issue with client based mobility management where the mobility client natively knows each anchor associated to each mobility sessions. However, there is one gap, as the MN should be capable of handling IP addresses in a DMM-friendly way, meaning that the MN can perform smart source address selection (i.e., deprecating IP addresses from previous mobility anchors, so they are not used for new sessions). Besides, managing different mobility sessions served by different mobility anchors may raise issues with network based mobility management. In this case, the mobile client, located in the network (e.g., MAG), usually retrieves the MN's anchor from the MN's policy profile (e.g., Section 6.2 of [RFC5213]). Currently, the MN's policy profile implicitly assumes a single serving anchor and, thus, does not maintain the association between home network prefix and anchor.

The consequence of the distribution of the mobility anchors is that there might be more than one available anchor for a mobile node to use, which leads to an anchor discovery and selection issue. Currently, there is no efficient mechanism specified to allow dynamically discovering the presence of nodes that can play the anchor role, discovering their capabilities and selecting the most suitable one. There is also no mechanism to allow selecting a node that is currently anchoring a given home address/prefix (capability sometimes required to meet REQ#2). There are though some mechanisms that could help discovering anchors, such as the Dynamic Home Agent Address Discovery (DHAAD), the use of the Home Agent (H) flag in Router Advertisements (which indicates that the router sending the Router Advertisement is also functioning as a Mobile IPv6 home agent on the link) or the MAP option in Router Advertisements defined by HMIPv6. Note that there are 3GPP mechanisms providing that functionality defined in [SDO-3GPP.29.303].

Regarding the ability to transfer registration context between anchors, there are already some solutions that could be reused or adapted to fill that gap, such as Fast Handovers for Mobile IPv6 [RFC5568] -- to enable traffic redirection from the old to the new anchor --, the Context Transfer protocol [RFC4067] -- to enable the required transfer of registration information between anchors --, or the Handover Keying architecture solutions [RFC6697], to speed up the re-authentication process after a change of anchor. Note that some extensions might be needed in the context of DMM, as these protocols were designed in the context of centralized client IP mobility, focusing on the access re-attachment and authentication.

Also note that REQ1 is such that the data plane traffic can avoid suboptimal route. Distributed processing of the traffic is then needed only in the data plane. The needed capability in distributed processing therefore should not contradict with centralized control plane. Other control plane solutions such as charging, lawful interception, etc. should not be limited. Yet combining the control plane and data plane forwarding management (FM) function may limit the choice to distributing both data plane and control plane together. In order to enable distributing only the data plane without distributing the control plane, a gap is to split the forwarding management function into the control plane (FM-CP) and data plane (FM-DP).

5.2. Bypassable network-layer mobility support for each application session - REQ2

The need for "bypassable network-layer mobility support for each application session" introduced in [RFC7333] requires flexibility on determining whether network-layer mobility support is needed. The requirement enables one to choose whether or not use network-layer mobility support. It only enables the two following functions:

• Dynamically assign/relocate anchor: a mobility anchor is assigned only to sessions which uses the network-layer mobility support. The MN may thus manage more than one session; some of them may be associated with anchored IP address(es), while the others may be associated with local IP address(es).
• Multiple IP address management: this function is related to the preceding and is about the ability of the mobile node to simultaneously use multiple IP addresses and select the best one (from an anchoring point of view) to use on a per-session/application/service basis. This requires MN to acquire information regarding the properties of the available IP addresses.

The dynamic anchor assignment/relocation needs to ensure that IP address continuity is guaranteed for sessions that uses such mobility support (e.g., in some scenarios, the provision of mobility locally within a limited area might be enough from the mobile node or the application point of view) at the relocated anchor. Implicitly, when no applications are using the network-layer mobility support, DMM may release the needed resources. This may imply having the knowledge of which sessions at the mobile node are active and are using the mobility support. This is something typically known only by the MN (e.g., by its connection manager), and would also typically require some signaling support (e.g., socket API extensions) from applications to indicate the IP stack whether mobility support is required or not in. Therefore, (part of) this knowledge might need to be transferred to/shared with the network.

Multiple IP address management provides the MN with the choice to pick-up the correct address (provided with mobility support or not) depending on the application requirements. When using client based mobility management, the mobile node is itself aware of the anchoring capabilities of its assigned IP addresses. This is not necessarily the case with network based IP mobility management; current mechanisms do not allow the MN to be aware of the properties of its IP addresses (e.g., the MN does not know whether the allocated IP addresses are anchored). However, there are proposals that the network could indicate such IP address properties during assignment procedures, such as [I-D.bhandari-dhc-class-based-prefix], [I-D.korhonen-6man-prefix-properties] and [I-D.anipko-mif-mpvd-arch]. Although there exist these individual efforts that could be be considered as attempts to fix the gap, there is no solution adopted as a work item within any IETF working group.

The handling of mobility management to the granularity of an individual session of a user/device needs proper session identification in addition to user/device identification.

5.3. IPv6 deployment - REQ3

This requirement states that DMM solutions should primarily target IPv6 as the primary deployment environment. IPv4 support is not considered mandatory and solutions should not be tailored specifically to support IPv4.

All analyzed DMM practices support IPv6. Some of them, such as MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, SIPTO have also IPv4 support. There are also some solutions that have some limited IPv4 support (e.g., PMIPv6). In conclusion, this requirement is met by existing DMM practices.

5.4. Existing mobility protocols - REQ4

A DMM solution must first consider reusing and extending IETF-standardized protocols before specifying new protocols.

As stated in [RFC7333], a DMM solution could reuse existing IETF and standardized protocols before specifying new protocols. Besides, Section 4 of this document discusses various ways to flatten and distribute current mobility solutions. Actually, nothing prevent the distribution of mobility functions with in IP mobility protocols. However, as discussed in Section 5.1 and Section 5.2, limitations exist.

The 3GPP data plane anchoring function, i.e., the PGW, can be also be distributed, but with limitations; e.g., no anchoring relocation, no context transfer between anchors and centralized control plane. The 3GPP architecture is also going into the direction of flattening with SIPTO and LIPA, though they do not provide full mobility support. For example, mobility support for SIPTO traffic can be rather limited, and offloaded traffic cannot access operator services. Thus, the operator must be very careful in selecting which traffic to offload.

5.5. Coexistence with deployed networks/hosts and operability across different networks- REQ5

According to [RFC7333], DMM implementations are required to co-exist with existing network deployments, end hosts and routers. Additionally, DMM solutions are expected to work across different networks, possibly operated as separate administrative domains, when the needed mobility management signaling, forwarding, and network access are allowed by the trust relationship between them. All current mobility protocols can co-exist with existing network deployments and end hosts. There is no gap between existing mobility protocols and this requirement.

5.6. Operation and management considerations - REQ6

This requirement actually comprises several aspects, as summarized below.

• A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, responding to events that impact the device, possibly by modifying the configuration and storing the data in a format that can be analyzed later.
• A DMM solution has to describe in what environment and how it can be scalably deployed and managed.
• A DMM solution has to support mechanisms to test if the DMM solution is working properly.
• A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities.
• A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions.
• A DMM solution is expected to support mechanisms to check the liveness of forwarding path.
• A DMM solution has to provide fault management and monitoring mechanisms to manage situations where update of the mobility session or the data path fails.
• A DMM solution is expected to be able to monitor the usage of the DMM protocol.
• DMM solutions have to support standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, which are expected to be created for DMM when needed for such configuration.

Existing mobility management protocols have not thoroughly documented the above list of operation and management considerations. Each of the above needs to be considered from the beginning in a DMM solution.

Management information base (MIB) objects are currently defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6. Standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules is needed.

5.7. Security considerations - REQ7

As stated in [RFC7333], a DMM solution has to support any security protocols and mechanisms needed to secure the network and to make continuous security improvements. In addition, with security taken into consideration early in the design, a DMM solution cannot introduce new security risks, or amplify existing security risks, that cannot be mitigated by existing security protocols and mechanisms.

Current mobility protocols have all security mechanisms in place. For example, Mobile IPv6 defines security features to protect binding updates both to home agents and correspondent nodes. It also defines mechanisms to protect the data packets transmission for Mobile IPv6 users. Proxy Mobile IPv6 and other variations of mobile IP also have similar security considerations.

5.8. Multicast - REQ8

It is stated in [RFC7333] that DMM solutions are expected to enable multicast solutions to be developed to avoid network inefficiency in multicast traffic delivery.

Current IP mobility solutions address mainly the mobility problem for unicast traffic. Solutions relying on the use of an anchor point for tunneling multicast traffic down to the access router, or to the mobile node, introduce the so-called “tunnel convergence problem”. This means that multiple instances of the same multicast traffic can converge to the same node, diminishing the advantage of using multicast protocols.

[RFC6224] documents a baseline solution for the previous issue, and [RFC7028] a routing optimization solution. The baseline solution suggests deploying an MLD proxy function at the MAG, and either a multicast router or another MLD proxy function at the LMA. The routing optimization solution describes an architecture where a dedicated multicast tree mobility anchor (MTMA) or a direct routing option can be used to avoid the tunnel convergence problem.

Besides the solutions highlighted before, there are no other mechanisms for mobility protocols to address the multicast tunnel convergence problem.

5.9. Summary

We next list the main gaps identified from the analysis performed above:

• Existing solutions only provide an optimal initial anchor assignment, a gap being the lack of dynamic anchor change/new anchor assignment. Neither the HA switch nor the LMA runtime assignment allow changing the anchor during an ongoing session. MOBIKE allows change of GW but its applicability has been scoped to very narrow use case.
• The mobile node needs to simultaneously use multiple IP addresses with different properties, which requires to expose this information to the mobile node and to update accordingly the source address selection mechanism of the latter.
• Currently, there is no efficient mechanism specified by the IETF that allows to dynamically discover the presence of nodes that can play the role of anchor, discover their capabilities and allow the selection of the most suitable one. However, the following mechanisms that could help discovering anchors:
• Dynamic Home Agent Address Discovery (DHAAD): the use of the Home Agent (H) flag in Router Advertisements (which indicates that the router sending the Router Advertisement is also functioning as a Mobile IPv6 home agent on the link) and the MAP option in Router Advertisements defined by HMIPv6.
• While existing network-based DMM practices may allow to deploy multiple LMAs and dynamically select the best one, this requires to still keep some centralization in the control plane, to access the policy database (as defined in RFC5213). Although [I-D.ietf-netext-pmip-cp-up-separation] allows a MAG to perform splitting of its control and user planes, there is a lack of solutions/extensions that support a clear control and data plane separation for IETF IP mobility protocols in a DMM context.

6. Security Considerations

Distributed mobility management systems encounter same security threats as existing centralized IP mobility protocols. Without authentication, a malicious node could forge signaling messages and redirect traffic from its legitimate path. This would amount to a denial of service attack against the specific node or nodes for which the traffic is intended. Distributed mobility anchoring, while keeping current security mechanisms, might require more security associations to be managed by the mobility management entities, potentially leading to scalability and performance issues. Moreover, distributed mobility anchoring makes mobility security problems more complex, since traffic redirection requests might come from previously unconsidered origins, thus leading to distributed points of attack. Consequently, the DMM security design needs to account for the distribution of security associations between additional mobility entities.

7. IANA Considerations

None.

8. Contributors

Charles E. Perkins
Huawei Technologies
EMail: charliep@computer.org

This document has benefited to valuable contributions from

9. References

9.1. Normative References

[RFC7333]

Chan, H., Liu, D., Seite, P., Yokota, H. and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, August 2014.

9.2. Informative References

, "

[I-D.anipko-mif-mpvd-arch]	Anipko, D., "Multiple Provisioning Domain Architecture", Internet-Draft draft-anipko-mif-mpvd-arch-05, November 2013.
[I-D.bhandari-dhc-class-based-prefix]	Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L. and J. Korhonen, "DHCPv6 class based prefix", Internet-Draft draft-bhandari-dhc-class-based-prefix-04, February 2013.
[I-D.gundavelli-v6ops-community-wifi-svcs]	Gundavelli, S., Grayson, M., Seite, P. and Y. Lee, "Service Provider Wi-Fi Services Over Residential Architectures", Internet-Draft draft-gundavelli-v6ops-community-wifi-svcs-06, April 2013.
[I-D.ietf-netext-pmip-cp-up-separation]	Wakikawa, R., Pazhyannur, R., Gundavelli, S. and C. Perkins, "Separation of Control and User Plane for Proxy Mobile IPv6", Internet-Draft draft-ietf-netext-pmip-cp-up-separation-03, April 2014.
[I-D.korhonen-6man-prefix-properties]	Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D. Liu, "IPv6 Prefix Properties", Internet-Draft draft-korhonen-6man-prefix-properties-02, July 2013.
[IEEE.802-16.2009]	IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Broadband Wireless Access Systems", IEEE Standard 802.16, 2009.
[RFC3963]	Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC4066]	Liebsch, M., Singh, A., Chaskar, H., Funato, D. and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005.
[RFC4067]	Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
[RFC4225]	Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", RFC 4225, December 2005.
[RFC4295]	Keeni, G., Koide, K., Nagami, K. and S. Gundavelli, "Mobile IPv6 Management Information Base", RFC 4295, April 2006.
[RFC4555]	Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006.
[RFC4640]	Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006.
[RFC4889]	Ng, C., Zhao, F., Watari, M. and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007.
[RFC4960]	Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC5014]	Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5026]	Giaretta, G., Kempf, J. and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5142]	Haley, B., Devarapalli, V., Deng, H. and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008.
[RFC5213]	Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5380]	Soliman, H., Castelluccia, C., ElMalki, K. and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5555]	Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
[RFC5568]	Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5844]	Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5996]	Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC6020]	Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6097]	Korhonen, J. and V. Devarapalli, "Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 2011.
[RFC6224]	Schmidt, T., Waehlisch, M. and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6241]	Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 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, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, February 2012.
[RFC6475]	Keeni, G., Koide, K., Gundavelli, S. and R. Wakikawa, "Proxy Mobile IPv6 Management Information Base", RFC 6475, May 2012.
[RFC6611]	Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario", RFC 6611, May 2012.
[RFC6697]	Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K. and S. Decugis, "Handover Keying (HOKEY) Architecture Design", RFC 6697, July 2012.
[RFC6705]	Krishnan, S., Koodli, R., Loureiro, P., Wu, Q. and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012.
[RFC6724]	Thaler, D., Draves, R., Matsumoto, A. and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC7028]	Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S. and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September 2013.
[SDO-3GPP.23.401]	3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 10.10.0, March 2013.
[SDO-3GPP.23.402]	3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 10.8.0, September 2012.
[SDO-3GPP.24.303]	3GPP, "Mobility management based on Dual-Stack Mobile IPv6; Stage 3", 3GPP TS 24.303 10.0.0, June 2013.
[SDO-3GPP.29.060]	3GPP, "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface", 3GPP TS 29.060 3.19.0, March 2004.
[SDO-3GPP.29.274]	3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June 2013.
[SDO-3GPP.29.281]	3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011.
[SDO-3GPP.29.303]	3GPP, Domain Name System Procedures; Stage 3", 3GPP TS 29.303 10.4.0, September 2012.

Authors' Addresses