Internet Engineering Task Force (IETF) D. Liu, Ed.
Request for Comments: 7429 China Mobile
Category: Informational JC. Zuniga, Ed.
ISSN: 2070-1721 InterDigital
P. Seite
Orange
H. Chan
Huawei Technologies
CJ. Bernardos
UC3M
January 2015
Internet Engineering Task Force (IETF) D. Liu, Ed.
Request for Comments: 7429 China Mobile
Category: Informational JC. Zuniga, Ed.
ISSN: 2070-1721 InterDigital
P. Seite
Orange
H. Chan
Huawei Technologies
CJ. Bernardos
UC3M
January 2015
Distributed Mobility Management: Current Practices and Gap Analysis
分布式移动性管理：当前实践和差距分析
Abstract
摘要
This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution.
本文分析了分布式移动性管理环境中现有IP移动性协议的部署实践。然后，与为分布式移动性管理解决方案定义的需求相比，它确定了现有的限制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7429.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7429.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of Existing Mobility Protocols . . . . . . . . . . 4
4. DMM Practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IP Flat Wireless Network . . . . . . . . . . . . . . . . 6
4.2.1. Host-Based IP DMM Practices . . . . . . . . . . . . . 7
4.2.2. Network-Based IP DMM Practices . . . . . . . . . . . 12
4.3. Flattening 3GPP Mobile Network Approaches . . . . . . . . 15
5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Distributed Mobility Management - REQ1 . . . . . . . . . 19
5.2. Bypassable Network-Layer Mobility Support for Each
Application Session - REQ2 . . . . . . . . . . . . . . . 21
5.3. IPv6 Deployment - REQ3 . . . . . . . . . . . . . . . . . 22
5.4. Considering Existing Mobility Protocols - REQ4 . . . . . 23
5.5. Coexistence with Deployed Networks/Hosts and Operability
across Different Networks - REQ5 . . . . . . . . . . . . 23
5.6. Operation and Management Considerations - REQ6 . . . . . 23
5.7. Security Considerations - REQ7 . . . . . . . . . . . . . 24
5.8. Multicast Considerations - REQ8 . . . . . . . . . . . . 25
5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functions of Existing Mobility Protocols . . . . . . . . . . 4
4. DMM Practices . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. IP Flat Wireless Network . . . . . . . . . . . . . . . . 6
4.2.1. Host-Based IP DMM Practices . . . . . . . . . . . . . 7
4.2.2. Network-Based IP DMM Practices . . . . . . . . . . . 12
4.3. Flattening 3GPP Mobile Network Approaches . . . . . . . . 15
5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Distributed Mobility Management - REQ1 . . . . . . . . . 19
5.2. Bypassable Network-Layer Mobility Support for Each
Application Session - REQ2 . . . . . . . . . . . . . . . 21
5.3. IPv6 Deployment - REQ3 . . . . . . . . . . . . . . . . . 22
5.4. Considering Existing Mobility Protocols - REQ4 . . . . . 23
5.5. Coexistence with Deployed Networks/Hosts and Operability
across Different Networks - REQ5 . . . . . . . . . . . . 23
5.6. Operation and Management Considerations - REQ6 . . . . . 23
5.7. Security Considerations - REQ7 . . . . . . . . . . . . . 24
5.8. Multicast Considerations - REQ8 . . . . . . . . . . . . 25
5.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 28
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Existing network-layer mobility management protocols have primarily employed a mobility anchor to ensure connectivity of a mobile node by forwarding packets destined to, or sent from, the mobile node after the node has moved to a different network. The mobility anchor has been centrally deployed in the sense that the traffic of millions of mobile nodes in an operator network is typically managed by the same anchor. This centralized deployment of mobility anchors to manage IP sessions poses several problems. In order to address these problems, a distributed mobility management (DMM) architecture has been proposed. This document investigates whether it is feasible to deploy current IP mobility protocols in a DMM scenario in a way that can fulfill the requirements as defined in [RFC7333], discusses current deployment practices of existing mobility protocols, and identifies the limitations (gaps) in these practices from the standpoint of satisfying DMM requirements. The analysis is primarily towards IPv6 deployment but can be seen to also apply to IPv4 whenever there are IPv4 counterparts equivalent to the IPv6 mobility protocols.
现有的网络层移动性管理协议主要采用移动性锚来确保移动节点的连接性，方法是在节点移动到不同的网络之后，转发目的地为移动节点或从移动节点发送的分组。移动锚集中部署的意义在于，运营商网络中数百万移动节点的流量通常由同一锚管理。这种集中部署移动锚来管理IP会话的做法带来了几个问题。为了解决这些问题，提出了一种分布式移动性管理（DMM）体系结构。本文件调查以满足[RFC7333]中定义的要求的方式在DMM场景中部署当前IP移动协议是否可行，讨论现有移动协议的当前部署实践，并确定限制（差距）在这些实践中，从满足DMM要求的角度出发。该分析主要针对IPv6部署，但只要存在与IPv6移动协议等效的IPv4对等协议，就可以认为也适用于IPv4。
The rest of this document is organized as follows: Section 3 analyzes existing IP mobility protocols by examining their functions and how these functions can be configured and used to work in a DMM environment, Section 4 presents the current practices of IP wireless networks and 3GPP architectures (both network- and host-based mobility protocols are considered), and Section 5 presents the gap analysis with respect to the current practices.
本文档的其余部分组织如下：第3节通过检查现有IP移动协议的功能以及如何配置和使用这些功能在DMM环境中工作来分析它们，第4节介绍IP无线网络和3GPP体系结构的当前实践（考虑了基于网络和基于主机的移动性协议），第5节介绍了与当前实践相关的差距分析。
All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275], in the Proxy Mobile IPv6 specification [RFC5213], and in the Distributed Mobility Management Requirements [RFC7333]. These terms include mobile node (MN), correspondent node (CN), home agent (HA), local mobility anchor (LMA), mobile access gateway (MAG), centrally deployed mobility anchors, distributed mobility management, hierarchical mobile network, flatter mobile network, and flattening mobile network.
本文件中使用的所有通用移动相关术语及其首字母缩略词应按照移动IPv6基本规范[RFC6275]、代理移动IPv6规范[RFC5213]和分布式移动管理要求[RFC7333]中的定义进行解释。这些术语包括移动节点（MN）、对应节点（CN）、归属代理（HA）、本地移动锚（LMA）、移动接入网关（MAG）、集中部署的移动锚、分布式移动管理、分层移动网络、平坦移动网络和平坦移动网络。
In addition, this document also introduces some definitions of IP mobility functions in Section 3.
此外，本文还在第3节中介绍了IP移动性功能的一些定义。
In this document there are also references to a "distributed mobility management environment." By this term, we refer to a scenario in which the IP mobility, access network, and routing solutions allow
在本文档中还提到了“分布式移动性管理环境”。在这个术语中，我们指的是IP移动性、接入网络和路由解决方案允许的场景
for setting up IP networks so that traffic is distributed in an optimal way without relying on centrally deployed mobility anchors to manage IP mobility sessions.
用于设置IP网络，以便在不依赖集中部署的移动锚来管理IP移动会话的情况下以最佳方式分配流量。
The host-based Mobile IPv6 (MIPv6) [RFC6275] and its network-based extension, Proxy Mobile IPv6 (PMIPv6) [RFC5213], as well as Hierarchical Mobile IPv6 (HMIPv6) [RFC5380], are logically centralized mobility management approaches addressing primarily hierarchical mobile networks. Although these approaches are centralized, they have important mobility management functions resulting from years of extensive work to develop and to extend these functions. It is therefore useful to take these existing functions and examine them in a DMM scenario in order to understand how to deploy the existing mobility protocols to provide distributed mobility management.
基于主机的移动IPv6（MIPv6）[RFC6275]及其基于网络的扩展、代理移动IPv6（PMIPv6）[RFC5213]以及分层移动IPv6（HMIPv6）[RFC5380]是逻辑上集中的移动性管理方法，主要解决分层移动网络。尽管这些方法是集中的，但由于多年来开发和扩展这些功能的大量工作，它们具有重要的移动性管理功能。因此，采用这些现有功能并在DMM场景中对其进行检查非常有用，以便了解如何部署现有移动协议以提供分布式移动管理。
The main mobility management functions of MIPv6, PMIPv6, and HMIPv6 are the following:
MIPv6、PMIPv6和HMIPv6的主要移动性管理功能如下：
1. Anchoring Function (AF): allocation to a mobile node of an IP address, i.e., Home Address (HoA), or prefix, i.e., Home Network Prefix (HNP), topologically anchored by the advertising node. That is, the anchor node is able to advertise a connected route into the routing infrastructure for the allocated IP prefixes. This function is a control-plane function.
1. 锚定功能（AF）：向移动节点分配IP地址，即家庭地址（HoA），或前缀，即家庭网络前缀（HNP），由广告节点拓扑锚定。也就是说，锚节点能够为分配的IP前缀将连接的路由播发到路由基础结构中。此函数是控制平面函数。
2. Internetwork Location Management (LM) function: managing and keeping track of the internetwork location of an MN. The location information may be a binding of the advertised IP address/prefix, e.g., HoA or HNP, to the IP routing address of the MN, or it may be a binding of a node that can forward packets destined to the MN. It is a control-plane function.
2. 网络位置管理（LM）功能：管理和跟踪MN的网络位置。位置信息可以是广告的IP地址/前缀（例如HoA或HNP）与MN的IP路由地址的绑定，或者它可以是可以转发目的地为MN的分组的节点的绑定。它是一个控制平面函数。
In a client-server protocol model, location query and update messages may be exchanged between a Location Management client (LMc) and a Location Management server (LMs).
在客户机-服务器协议模型中，位置查询和更新消息可以在位置管理客户机（LMc）和位置管理服务器（LMs）之间交换。
3. Forwarding Management (FM) function: packet interception and forwarding to/from the IP address/prefix assigned to the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination.
3. 转发管理（FM）功能：根据网络间位置信息，对分配给MN的IP地址/前缀进行数据包截获和转发至/转发至目的地或其他知道如何将数据包转发至目的地的网络元件。
FM may optionally be split into the control plane (FM-CP) and data plane (FM-DP).
FM可选择性地分为控制平面（FM-CP）和数据平面（FM-DP）。
In Mobile IPv6, the home agent (HA) typically provides the AF; the LMs is at the HA, whereas the LMc is at the MN; the FM function is distributed between the ends of the tunnel at the HA and the MN.
在移动IPv6中，归属代理（HA）通常提供AF；LMs位于HA，而LMc位于MN；FM功能分布在HA和MN的隧道端部之间。
In Proxy Mobile IPv6, the local mobility anchor (LMA) provides the AF; the LMs is at the LMA, whereas the LMc is at the MAG; the FM function is distributed between the ends of the tunnel at the LMA and the MAG.
在代理移动IPv6中，本地移动锚（LMA）提供AF；LMs位于LMA，而LMc位于MAG；FM功能分布在LMA和MAG的隧道端部之间。
In HMIPv6 [RFC5380], the Mobility Anchor Point (MAP) serves as a location information aggregator between the LMs at the HA and the LMc at the MN. The MAP also provides the FM function to enable tunneling between HA and itself, as well as tunneling between the MN and itself.
在HMIPv6[RFC5380]中，移动性锚点（MAP）充当HA处LMs和MN处LMc之间的位置信息聚合器。MAP还提供FM功能，以启用HA和自身之间的隧道，以及MN和自身之间的隧道。
This section documents deployment practices of existing mobility protocols to satisfy distributed mobility management requirements. This description considers both IP wireless, e.g., evolved Wi-Fi hotspots, and 3GPP flattening mobile networks.
本节记录了现有移动性协议的部署实践，以满足分布式移动性管理需求。该描述考虑了IP无线（例如演进的Wi-Fi热点）和3GPP平坦化移动网络。
While describing the current DMM practices, the section provides references to the generic mobility management functions described in Section 3 as well as some initial hints on the identified gaps with respect to the DMM requirements documented in [RFC7333].
在描述当前DMM实践的同时，本节提供了第3节中描述的通用移动性管理功能的参考资料，以及关于[RFC7333]中记录的DMM要求的已识别差距的一些初步提示。
There are many different approaches that can be considered to implement and deploy a distributed anchoring and mobility solution. The focus of the gap analysis is on certain current mobile network architectures and standardized IP mobility solutions, considering any kind of deployment options that do not violate the original protocol specifications. In order to limit the scope of our analysis of DMM practices, we consider the following list of technical assumptions:
有许多不同的方法可以用来实现和部署分布式锚定和移动性解决方案。差距分析的重点是某些当前的移动网络架构和标准化的IP移动解决方案，同时考虑任何不违反原始协议规范的部署选项。为了限制我们对DMM实践的分析范围，我们考虑以下技术假设列表：
1. Both host- and network-based solutions are considered.
1. 同时考虑了基于主机和基于网络的解决方案。
2. Solutions should allow selecting and using the most appropriate IP anchor among a set of available candidates.
2. 解决方案应允许在一组可用的候选者中选择和使用最合适的IP锚。
3. Mobility management should be realized by the preservation of the IP address across the different points of attachment (i.e., provision of IP address continuity). This is in contrast to certain transport-layer-based approaches such as Stream Control Transmission Protocol (SCTP) [RFC4960] or application-layer mobility.
3. 移动性管理应通过在不同的连接点上保留IP地址来实现（即，提供IP地址连续性）。这与某些基于传输层的方法形成对比，例如流控制传输协议（SCTP）[RFC4960]或应用层移动性。
Applications that can cope with changes in the MN's IP address do not depend on IP mobility management protocols such as DMM. Typically, a connection manager, together with the operating system, will configure the source address selection mechanism of the IP stack. This might involve identifying application capabilities and triggering the mobility support accordingly. Further considerations on application management and source address selection are out of the scope of this document, but the reader might consult [RFC6724].
能够应对MN IP地址变化的应用程序不依赖于DMM等IP移动性管理协议。通常，连接管理器将与操作系统一起配置IP堆栈的源地址选择机制。这可能涉及识别应用程序功能并相应地触发移动性支持。关于应用程序管理和源地址选择的进一步考虑超出了本文档的范围，但读者可以参考[RFC6724]。
This section focuses on common IP wireless network architectures and how they can be flattened from an IP mobility and anchoring point of view using common and standardized protocols. We take Wi-Fi as a useful wireless technology since it is widely known and deployed nowadays. Some representative examples of Wi-Fi deployment architectures are depicted in Figure 1.
本节重点介绍常见的IP无线网络体系结构，以及如何使用通用和标准化协议从IP移动性和锚定的角度将其展平。我们认为Wi-Fi是一种非常有用的无线技术，因为它现在已经被广泛使用。Wi-Fi部署架构的一些代表性示例如图1所示。
+-------------+ _----_
+---+ | Access | _( )_
|AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Gateway | (_ _)
+-------------+ '----'
| | |
| | +-------------+
| | |
| | +-----+
+---------------+ | | AR |
| | +--+--+
+-----+ +-----+ *----+----*
| RG | | WLC | ( LAN )
+-----+ +-----+ *---------*
. / \ / \
/ \ +-----+ +-----+ +-----+ +-----+
/ \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 |
+-----+ +-----+ +-----+ +-----+
. .
/ \ / \
/ \ / \
MN3 MN4 MN5 MN6
+-------------+ _----_
+---+ | Access | _( )_
|AAA|. . . . . . | Aggregation |----------( Internet )
+---+ | Gateway | (_ _)
+-------------+ '----'
| | |
| | +-------------+
| | |
| | +-----+
+---------------+ | | AR |
| | +--+--+
+-----+ +-----+ *----+----*
| RG | | WLC | ( LAN )
+-----+ +-----+ *---------*
. / \ / \
/ \ +-----+ +-----+ +-----+ +-----+
/ \ |Wi-Fi| |Wi-Fi| |Wi-Fi| |Wi-Fi|
MN1 MN2 | AP1 | | AP2 | | AP3 | | AP4 |
+-----+ +-----+ +-----+ +-----+
. .
/ \ / \
/ \ / \
MN3 MN4 MN5 MN6
Figure 1: IP Wi-Fi Network Architectures
图1:IP Wi-Fi网络架构
In Figure 1, three typical deployment options are shown [COMMUNITY-WIFI]. On the left-hand side of the figure, mobile nodes MN1 and MN2 directly connect to a Residential Gateway (RG) at the customer premises. The RG hosts the 802.11 Access Point (AP)
图1中显示了三种典型的部署选项[COMMUNITY-WIFI]。在图的左侧，移动节点MN1和MN2直接连接到客户场所的住宅网关（RG）。RG承载802.11接入点（AP）
function to enable wireless Layer 2 access connectivity and also provides Layer 3 routing functions. In the middle of the figure, mobile nodes MN3 and MN4 connect to Wi-Fi access points AP1 and AP2 that are managed by a Wireless LAN Controller (WLC), which performs radio resource management on the APs, domain-wide mobility policy enforcement, and centralized forwarding function for the user traffic. The WLC could also implement Layer 3 routing functions or attach to an access router (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 used as a generic connectivity model.
用于启用无线第2层访问连接的功能，还提供第3层路由功能。在图的中部，移动节点MN3和MN4连接到由无线LAN控制器（WLC）管理的Wi-Fi接入点AP1和AP2，该无线局域网接入点执行AP上的无线资源管理、全域移动性策略强制执行以及针对用户业务的集中转发功能。WLC还可以实现第3层路由功能或连接到接入路由器（AR）。最后，在图的右侧，接入点AP3和AP4直接连接到接入路由器。这也可用作通用连接模型。
IP mobility protocols can be used to provide heterogeneous network mobility support to users, e.g., handover from Wi-Fi to cellular access. Two kinds of protocols can be used: Proxy Mobile IPv6 [RFC5213] or Mobile IPv6 [RFC5555], with the role of mobility anchor (e.g., local mobility anchor or home agent) typically being played by the edge router of the mobile network [SDO-3GPP.23.402].
IP移动协议可用于向用户提供异构网络移动支持，例如，从Wi-Fi切换到蜂窝接入。可以使用两种协议：代理移动IPv6[RFC5213]或移动IPv6[RFC5555]，移动锚（例如，本地移动锚或归属代理）的角色通常由移动网络的边缘路由器扮演[SDO-3GPP.23.402]。
Although this section has made use of the example of Wi-Fi networks, there are other flattening mobile network architectures specified, such as Worldwide Interoperability for Microwave Access (WiMAX) [IEEE.802-16.2009], which integrates both host- and network-based IP mobility functions.
尽管本节使用了Wi-Fi网络的示例，但还指定了其他扁平化移动网络架构，如全球微波接入互操作性（WiMAX）[IEEE.802-16.2009]，它集成了基于主机和基于网络的IP移动功能。
Existing IP mobility protocols can also be deployed in a flatter manner so that the anchoring and access aggregation functions are distributed. We next describe several practices for the deployment of existing mobility protocols in a distributed mobility management environment. The analysis in this section is limited to protocol solutions based on existing IP mobility protocols, either host- or network-based, such as Mobile IPv6 [RFC6275] [RFC5555], Proxy Mobile IPv6 (PMIPv6) [RFC5213] [RFC5844], and Network Mobility (NEMO) Basic Support Protocol [RFC3963]. Extensions to these base protocol solutions are also considered. The analysis is divided into two parts: host- and network-based practices.
现有的IP移动协议也可以以更平坦的方式部署，以便锚定和访问聚合功能是分布式的。接下来，我们将描述在分布式移动性管理环境中部署现有移动性协议的几种实践。本节中的分析仅限于基于现有IP移动性协议（基于主机或网络）的协议解决方案，如移动IPv6[RFC6275][RFC5555]、代理移动IPv6（PMIPv6）[RFC5213][RFC5844]和网络移动性（NEMO）基本支持协议[RFC3963]。还考虑了对这些基本协议解决方案的扩展。分析分为两部分：基于主机的实践和基于网络的实践。
Mobile IPv6 (MIPv6) [RFC6275] and its extension to support mobile networks, the NEMO Basic Support protocol (hereafter, simply referred to as NEMO) [RFC3963], are well-known, host-based IP mobility protocols. They depend on the function of the home agent (HA), a centralized anchor, to provide mobile nodes (hosts and routers) with mobility support. In these approaches, the home agent typically provides the AF, FM function, and Location Management server (LMs) functions. The mobile node possesses the Location Management client (LMc) function and the FM function to enable tunneling between the HA
移动IPv6（MIPv6）[RFC6275]及其支持移动网络的扩展，NEMO基本支持协议（以下简称NEMO）[RFC3963]是众所周知的基于主机的IP移动协议。它们依赖于归属代理（HA）的功能，归属代理（HA）是一个集中的锚，为移动节点（主机和路由器）提供移动性支持。在这些方法中，归属代理通常提供AF、FM功能和位置管理服务器（LMs）功能。移动节点具有位置管理客户端（LMc）功能和FM功能，以支持HA之间的隧道
and itself. We next describe some practices that show how MIPv6/NEMO and several other protocol extensions can be deployed in a distributed mobility management environment.
还有它本身。接下来，我们将描述一些实践，展示如何在分布式移动性管理环境中部署MIPv6/NEMO和其他几个协议扩展。
One approach to distribute the anchors can be to deploy several HAs (as shown in Figure 2), and assign the topologically closest anchor 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 uses a home address anchored by HA1 to communicate with the correspondent node CN1. Similarly, the mobile node MN2 is assigned to the home agent HA2 and uses a home address anchored by HA2 to communicate with the correspondent node CN2. Note that MIPv6/NEMO specifications do not prevent the simultaneous use of multiple home 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 IP flows initiated at a different point of attachment. However, there is currently no mechanism specified in IETF standard to enable an efficient dynamic discovery of available anchors and the selection of the most suitable one.
分配锚的一种方法是部署几个HA（如图2所示），并将拓扑上最接近的锚分配给每个MN[RFC4640][RFC5026][RFC6611]。在图2所示的示例中，移动节点MN1被分配给归属代理HA1，并使用由HA1锚定的归属地址与对应节点CN1通信。类似地，移动节点MN2被分配给归属代理HA2，并使用由HA2锚定的归属地址与对应节点CN2通信。请注意，MIPv6/NEMO规范并不阻止单个移动节点同时使用多个归属代理。在此部署模型中，移动节点可以同时使用多个锚，其中每个锚都锚定在不同连接点启动的IP流。然而，目前在IETF标准中没有规定任何机制来实现对可用锚的有效动态发现和选择最合适的锚。
<-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
+-----+ +-----+ +--------+
| CN1 |--- ===| AR1 |=======| MN1 |
+-----+ \ +-----------+ // +-----+ |(FM,LMc)|
---| HA1 |=== +--------+
|(AF,FM,LMs)| +-----+ (anchored
+-----------+ | AR2 | at HA1)
+-----+
+-----+ +-----------+
| CN2 |-------| HA2 |===
+-----+ |(AF,FM,LMs)| \\ +-----+=======+--------+
+-----------+ ===| AR3 | | MN2 |
+-----+-------|(FM,LMc)|
+-----+ / +--------+
| CN3 |-----------------------------/ (anchored
+-----+ at HA2)
+-----+
| AR4 |
+-----+
<-INTERNET-> <- HOME NETWORK -> <------- ACCESS NETWORK ------->
+-----+ +-----+ +--------+
| CN1 |--- ===| AR1 |=======| MN1 |
+-----+ \ +-----------+ // +-----+ |(FM,LMc)|
---| HA1 |=== +--------+
|(AF,FM,LMs)| +-----+ (anchored
+-----------+ | AR2 | at HA1)
+-----+
+-----+ +-----------+
| CN2 |-------| HA2 |===
+-----+ |(AF,FM,LMs)| \\ +-----+=======+--------+
+-----------+ ===| AR3 | | MN2 |
+-----+-------|(FM,LMc)|
+-----+ / +--------+
| CN3 |-----------------------------/ (anchored
+-----+ at HA2)
+-----+
| AR4 |
+-----+
CN1 CN2 CN3 HA1 HA2 AR1 AR3 MN1 MN2
| | | | | | | | |
|<-------------->|<======tunnel====+=============>| | BT mode
| | | | | | | | |
| |<-------------->|<======tunnel====+==============>| BT mode
| | | | | | | | |
| | |<----------------------------+-------------->| RO mode
| | | | | | | | |
CN1 CN2 CN3 HA1 HA2 AR1 AR3 MN1 MN2
| | | | | | | | |
|<-------------->|<======tunnel====+=============>| | BT mode
| | | | | | | | |
| |<-------------->|<======tunnel====+==============>| BT mode
| | | | | | | | |
| | |<----------------------------+-------------->| RO mode
| | | | | | | | |
Figure 2: Distributed Operation of Mobile IPv6 (BT and RO)/NEMO
图2：移动IPv6（BT和RO）/NEMO的分布式运行
One goal of the deployment of mobility protocols in a distributed mobility management environment is to avoid the suboptimal routing caused by centralized anchoring. Here, the Route Optimization (RO) support provided by Mobile IPv6 can be used to achieve a flatter IP data forwarding. By default, Mobile IPv6 and NEMO use the so-called Bidirectional Tunnel (BT) mode, in which data traffic is always encapsulated between the MN and its HA before being directed to any other destination. The RO mode allows the MN to update its current location on the CNs and then use the direct path between them. Using the example shown in Figure 2, MN1 and MN2 are using BT mode with CN1 and CN2, respectively, while MN2 is in RO mode with CN3. However, the RO mode has several drawbacks:
在分布式移动性管理环境中部署移动性协议的一个目标是避免集中式锚定导致的次优路由。在这里，移动IPv6提供的路由优化（RO）支持可用于实现更平坦的IP数据转发。默认情况下，移动IPv6和NEMO使用所谓的双向隧道（BT）模式，在这种模式下，数据流量总是在被定向到任何其他目的地之前封装在MN和其HA之间。RO模式允许MN更新其在CNs上的当前位置，然后使用它们之间的直接路径。使用图2所示的示例，MN1和MN2分别与CN1和CN2一起使用BT模式，而MN2与CN3一起使用RO模式。但是，RO模式有几个缺点：
o The RO mode is only supported by Mobile IPv6. There is no route optimization support standardized for the NEMO protocol because of the security problems posed by extending return routability tests for prefixes, although many different solutions have been proposed [RFC4889].
o RO模式仅受移动IPv6支持。由于扩展前缀返回可路由性测试带来的安全问题，NEMO协议没有标准化的路由优化支持，尽管已经提出了许多不同的解决方案[RFC4889]。
o The RO mode requires signaling that adds some protocol overhead.
o RO模式需要增加一些协议开销的信令。
o The signaling required to enable RO involves the home agent and is repeated periodically for security reasons [RFC4225]. Therefore, the HA remains a single point of failure.
o 启用RO所需的信令涉及归属代理，并出于安全原因定期重复[RFC4225]。因此，医管局仍然是一个单一的失败点。
o The RO mode requires support from the CN.
o RO模式需要CN的支持。
Notwithstanding these considerations, the RO mode does offer the possibility of substantially reducing traffic through the home agent, in cases when it can be supported by the relevant correspondent nodes. Note that a mobile node can also use its Care-of Address (CoA) directly [RFC5014] when communicating with CNs on the same link or anywhere in the Internet, although no session continuity support would be provided by the IP stack in this case.
尽管有这些考虑，但是RO模式确实提供了在相关对应节点可以支持的情况下通过归属代理大幅减少通信量的可能性。请注意，移动节点在同一链路上或互联网上任何位置与CNs通信时，也可以直接使用其转交地址（CoA）[RFC5014]，尽管在这种情况下，IP堆栈不会提供会话连续性支持。
HMIPv6 [RFC5380], as shown in Figure 3, is another host-based IP mobility extension that can be considered as a complement to provide a less centralized mobility deployment. It allows the reduction of the amount of mobility signaling as well as improving the overall handover performance of Mobile IPv6 by introducing a new hierarchy level to handle local mobility. The Mobility Anchor Point (MAP) entity is introduced as a local mobility handling node deployed closer to the mobile node. It provides LM intermediary function between the LMs at the HA and the LMc at the MN. It also performs the FM function to tunnel with the HA and also with the MN.
如图3所示，HMIPv6[RFC5380]是另一个基于主机的IP移动性扩展，可被视为提供较不集中的移动性部署的补充。通过引入新的层次结构级别来处理本地移动性，它允许减少移动性信令的数量，并提高移动IPv6的整体切换性能。移动性锚点（MAP）实体被引入作为部署在移动节点附近的本地移动性处理节点。它在HA的LMs和MN的LMc之间提供LM中介功能。它还执行FM功能，与HA和MN进行隧道连接。
<INTERNET> <- HOME NETWORK -> <---------- ACCESS NETWORK ---------->
LCoA anchored
at AR1
+---+ +--------+
===|AR1|==| MN1 |
+-----+ +-----------+ +----------+ // +---+ |(FM,LMc)|
| CN1 |----| HA1 |======| MAP1 |=== +--------+
+-----+ |(AF,FM,LMs)| /|(AF,FM,LM)| +---+ HoA,
+-----------+ / +----------+ |AR2| RCoA,
HoA anchored / RCoA anchored +---+ LCoA
at HA1 / at MAP1
/ +---+
/ |AR3|
+-----+ / +----------+ +---+
| CN2 |---------------- | MAP2 |
+-----+ |(AF,FM,LM)| +---+
+----------+ |AR4|
+---+
CN1 CN2 HA1 MAP1 AR1 MN1
| | | | | |
|<-------------->|<===============>|<====tunnel============>| HoA
| | | | | |
| |<-------------------------->|<====tunnel============>| RCoA
| | | | | |
<INTERNET> <- HOME NETWORK -> <---------- ACCESS NETWORK ---------->
LCoA anchored
at AR1
+---+ +--------+
===|AR1|==| MN1 |
+-----+ +-----------+ +----------+ // +---+ |(FM,LMc)|
| CN1 |----| HA1 |======| MAP1 |=== +--------+
+-----+ |(AF,FM,LMs)| /|(AF,FM,LM)| +---+ HoA,
+-----------+ / +----------+ |AR2| RCoA,
HoA anchored / RCoA anchored +---+ LCoA
at HA1 / at MAP1
/ +---+
/ |AR3|
+-----+ / +----------+ +---+
| CN2 |---------------- | MAP2 |
+-----+ |(AF,FM,LM)| +---+
+----------+ |AR4|
+---+
CN1 CN2 HA1 MAP1 AR1 MN1
| | | | | |
|<-------------->|<===============>|<====tunnel============>| HoA
| | | | | |
| |<-------------------------->|<====tunnel============>| RCoA
| | | | | |
Figure 3: Hierarchical Mobile IPv6
图3：分层移动IPv6
When HMIPv6 is used, the MN has two different temporary addresses: 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 local home agent, while the LCoA is anchored at the access-router level. The mobile node uses the RCoA as the CoA that is signaled to its home agent. Therefore, while roaming within a local domain handled by the same MAP, the mobile node does not need to update its home agent, i.e., the mobile node does not change its RCoA.
当使用HMIPv6时，MN有两个不同的临时地址：区域托管地址（RCoA）和本地托管地址（LCoA）。RCoA锚定在一个地图上，该地图扮演本地归属代理的角色，而LCoA锚定在接入路由器级别。移动节点使用RCoA作为向其归属代理发送信号的CoA。因此，当在由相同MAP处理的本地域内漫游时，移动节点不需要更新其归属代理，即，移动节点不改变其RCoA。
The use of HMIPv6 enables a form of route optimization, since a mobile node may decide to directly use the RCoA as the source address for a communication with a given correspondent node, particularly if 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 mode of operation, though it fails to provide session continuity if 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, while it is using its RCoA to communicate with CN2.
使用HMIPv6能够实现一种形式的路由优化，因为移动节点可以决定直接使用RCoA作为与给定对应节点的通信的源地址，特别是如果MN在通信的生存期内不期望移动到本地域之外。这可以看作是一种潜在的DMM操作模式，尽管当MN移动到本地域之外时，它无法提供会话连续性。在图3所示的示例中，MN1使用其全局HoA与CN1通信，而它使用其RCoA与CN2通信。
Furthermore, a local domain might have several MAPs deployed, thus enabling different kinds of HMIPv6 deployments that are flattening and distributed. The HMIPv6 specification supports a flexible selection of the MAP, including selections based on the expected mobility pattern of the MN or on the distance between the MN and the MAP.
此外，一个本地域可能部署了多个映射，从而支持不同类型的扁平化和分布式HMIPv6部署。HMIPv6规范支持地图的灵活选择，包括基于MN的预期移动模式或MN与地图之间的距离的选择。
Another extension that can be used to help with distributing mobility management functions is the Home Agent switch specification [RFC5142], which defines a new mobility header to signal to a mobile 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 might imply loss of connectivity for ongoing persistent connections. Nevertheless, that specification could be used to force the change of home agent in those situations where there are no active persistent data sessions that cannot cope with a change of home address.
可用于帮助分发移动性管理功能的另一个扩展是归属代理交换机规范[RFC5142]，该规范定义了一个新的移动性报头，以向移动节点发出其应获取新归属代理的信号。[RFC5142]未指定更改移动节点的家庭地址的情况，因为这可能意味着正在进行的持续连接的连接丢失。然而，该规范可用于在没有无法应对家庭地址更改的活动持久数据会话的情况下强制更改家庭代理。
There are other host-based approaches standardized that can be used to provide mobility support. For example, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] allows a mobile node encrypting traffic through Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] to change its point of attachment while maintaining a Virtual Private Network (VPN) session. The MOBIKE protocol allows updating the VPN Security Associations (SAs) in cases where the base connection initially used is lost and needs to be re-established. The use of the MOBIKE protocol avoids having to perform an IKEv2 renegotiation. Similar considerations to those made for Mobile IPv6 can be applied to MOBIKE; though MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable and can be discovered using existing mechanisms such as DNS.
还有其他基于主机的标准化方法可用于提供移动性支持。例如，IKEv2移动和多归属（MOBIKE）[RFC4555]允许通过互联网密钥交换协议版本2（IKEv2）[RFC7296]加密流量的移动节点在维护虚拟专用网络（VPN）会话的同时更改其连接点。MOBIKE协议允许在最初使用的基本连接丢失且需要重新建立的情况下更新VPN安全关联（SAs）。使用MOBIKE协议可以避免执行IKEv2重新协商。与移动IPv6类似的考虑可应用于MOBIKE；尽管MOBIKE最适合于至少一个端点的地址相对稳定并且可以使用现有机制（如DNS）发现的情况。
Extensions have been defined to the mobility protocol to optimize the handover performance. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] is the extension to optimize handover latency. It defines new access router discovery mechanism before handover to reduce the new network discovery latency. It also defines a tunnel between the previous access router and the new access router to reduce the packet loss during handover. The Candidate Access Router Discovery (CARD) [RFC4066] and Context Transfer Protocol (CXTP) [RFC4067] protocols were standardized to improve the handover performance. The DMM deployment practice discussed in this section can also use those extensions to improve the handover performance.
对移动性协议进行了扩展，以优化切换性能。移动IPv6快速切换（FMIPv6）[RFC5568]是优化切换延迟的扩展。它定义了新的接入路由器切换前发现机制，以减少新的网络发现延迟。它还定义了先前接入路由器和新接入路由器之间的隧道，以减少切换期间的数据包丢失。候选接入路由器发现（CARD）[RFC4066]和上下文传输协议（CXTP）[RFC4067]协议被标准化，以提高切换性能。本节讨论的DMM部署实践也可以使用这些扩展来提高切换性能。
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is the main network-based IP mobility protocol specified for IPv6. Proxy Mobile IPv4 [RFC5844] defines some IPv4 extensions. With network-based IP mobility
代理移动IPv6（PMIPv6）[RFC5213]是为IPv6指定的基于网络的主要IP移动协议。代理移动IPv4[RFC5844]定义了一些IPv4扩展。基于网络的IP移动性
protocols, the LMA typically provides the AF, FM function, and Location Management server (LMs) function. The mobile access gateway (MAG) provides the Location Management client (LMc) function and FM function to tunnel with LMA. PMIPv6 is architecturally almost identical to MIPv6, as the mobility signaling and routing between LMA and MAG in PMIPv6 is similar to those between the HA and MN in MIPv6. The required mobility functionality at the MN is provided by the MAG so that the involvement in mobility support by the MN is not required.
在协议中，LMA通常提供AF、FM功能和位置管理服务器（LMs）功能。移动接入网关（MAG）提供位置管理客户端（LMc）功能和FM功能，以便通过LMA进行隧道传输。PMIPv6在架构上几乎与MIPv6相同，因为PMIPv6中LMA和MAG之间的移动性信令和路由类似于MIPv6中HA和MN之间的移动性信令和路由。MN所需的移动功能由MAG提供，因此不需要MN参与移动支持。
We next describe some practices that show how network-based mobility protocols and several other protocol extensions can be deployed in a distributed mobility management environment.
接下来，我们将描述一些实践，展示如何在分布式移动性管理环境中部署基于网络的移动性协议和其他几个协议扩展。
One way to decentralize Proxy Mobile IPv6 operation can be to deploy several LMAs and use some selection criteria to assign LMAs to attaching mobile nodes. An example of this type of assignment is shown in Figure 4. As with the client-based approach, a mobile node may use several anchors at the same time, each of them anchoring IP flows initiated at a different point of attachment. This assignment can be static or dynamic. The main advantage of this simple approach is that the IP address anchor, i.e., the LMA, could be placed closer to the mobile node. Therefore, the resulting paths are close to optimal. On the other hand, as soon as the mobile node moves, the resulting path will start deviating from the optimal one.
分散代理移动IPv6操作的一种方法是部署多个LMA，并使用一些选择标准将LMA分配给连接的移动节点。图4显示了这种分配类型的示例。与基于客户端的方法一样，移动节点可以同时使用多个锚，其中每个锚都锚定在不同的连接点处启动的IP流。此分配可以是静态的，也可以是动态的。这种简单方法的主要优点是IP地址锚，即LMA，可以放置在更靠近移动节点的位置。因此，得到的路径接近最优。另一方面，一旦移动节点移动，产生的路径将开始偏离最佳路径。
<INTERNET> <--- HOME NETWORK ---> <------ ACCESS NETWORK ------->
+--------+ +---+
=======| MAG1 |------|MN1|
+-----+ +-----------+ // |(FM,LMc)| +---+
| CN1 |-------| LMA1 |======= +--------+
+-----+ |(AF,FM,LMs)|
+-----------+ +--------+
+-----+ | MAG2 |
| CN2 |--- |(FM,LMc)|
+-----+ \ +-----------+ +--------+
---| LMA2 |=======
+-----+ |(AF,FM,LMs)| \\ +--------+ +---+
| CN3 | +-----------+ =======| MAG3 |------|MN2|
+-----+ |(FM,LMc)| +---+
+--------+
CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2
| | | | | | | |
|<-------------->|<===========tunnel========>|<----------->| |
| | | | | | | |
| |<-------------->|<=====tunnel=============>|<----------->|
| | | | | | | |
<INTERNET> <--- HOME NETWORK ---> <------ ACCESS NETWORK ------->
+--------+ +---+
=======| MAG1 |------|MN1|
+-----+ +-----------+ // |(FM,LMc)| +---+
| CN1 |-------| LMA1 |======= +--------+
+-----+ |(AF,FM,LMs)|
+-----------+ +--------+
+-----+ | MAG2 |
| CN2 |--- |(FM,LMc)|
+-----+ \ +-----------+ +--------+
---| LMA2 |=======
+-----+ |(AF,FM,LMs)| \\ +--------+ +---+
| CN3 | +-----------+ =======| MAG3 |------|MN2|
+-----+ |(FM,LMc)| +---+
+--------+
CN1 CN2 LMA1 LMA2 MAG1 MAG3 MN1 MN2
| | | | | | | |
|<-------------->|<===========tunnel========>|<----------->| |
| | | | | | | |
| |<-------------->|<=====tunnel=============>|<----------->|
| | | | | | | |
Figure 4: Distributed Operation of Proxy Mobile IPv6
图4：代理移动IPv6的分布式操作
In a similar way to the host-based IP mobility case, network-based IP mobility has some extensions defined to mitigate the suboptimal routing issues that may arise due to the use of a centralized anchor. The Local Routing extensions [RFC6705] enable optimal routing in 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 different MAGs but to the same LMA, and iii) when two communicating MNs are attached to the same MAG but have different LMAs. In these three cases, data traffic between the two mobile nodes does not traverse the LMA(s), thus providing some form of path optimization, since the traffic is locally routed at the edge. The main disadvantage of this approach is that it only tackles the MN-to-MN communication scenario and only under certain circumstances.
与基于主机的IP移动性情况类似，基于网络的IP移动性定义了一些扩展，以缓解由于使用集中锚而可能出现的次优路由问题。本地路由扩展[RFC6705]在三种情况下启用代理移动IPv6中的最佳路由：i）当两个通信MN连接到同一MAG和LMA时，ii）当两个通信MN连接到不同MAG但连接到相同LMA时，以及iii）当两个通信MN连接到相同MAG但具有不同LMA时。在这三种情况下，两个移动节点之间的数据流量不穿过LMA，因此提供某种形式的路径优化，因为流量在边缘局部路由。这种方法的主要缺点是它只处理MN-to-MN通信场景，并且仅在某些情况下。
An interesting extension that can also be used to facilitate the deployment of network-based mobility protocols in a distributed mobility management environment is the support of an LMA runtime assignment described in [RFC6463]. This extension specifies a runtime LMA assignment functionality and corresponding mobility options for Proxy Mobile IPv6. This runtime LMA assignment takes place during the Proxy Binding Update / Proxy Binding Acknowledgment message exchange between a mobile access gateway and an LMA. While this mechanism is mainly aimed for load-balancing purposes, it can also be used to select an optimal LMA from the routing point of view.
[RFC6463]中描述的LMA运行时分配支持是一个有趣的扩展，它也可用于促进分布式移动管理环境中基于网络的移动协议的部署。此扩展为代理移动IPv6指定运行时LMA分配功能和相应的移动选项。此运行时LMA分配在移动接入网关和LMA之间的代理绑定更新/代理绑定确认消息交换期间发生。虽然该机制主要用于负载平衡，但它也可用于从路由角度选择最优LMA。
A runtime LMA assignment can be used to change the assigned LMA of an MN, for example, in cases when the mobile node does not have any active session or when the running sessions can survive an IP address change. Note that several possible dynamic LMA discovery solutions can be used, as described in [RFC6097].
运行时LMA分配可用于改变MN的分配的LMA，例如，在移动节点没有任何活动会话或运行会话可在IP地址改变后存活的情况下。请注意，如[RFC6097]所述，可以使用几种可能的动态LMA发现解决方案。
The 3GPP is the standards development organization that specifies the 3rd generation mobile network and the Evolved Packet System (EPS) [SDO-3GPP.23.402], which mainly comprises the Evolved Packet Core (EPC) and a new radio access network, usually referred to as LTE (Long Term Evolution).
3GPP是指定第三代移动网络和演进分组系统（EPS）[SDO-3GPP.23.402]的标准开发组织，其主要包括演进分组核心（EPC）和新的无线接入网络，通常称为LTE（长期演进）。
Architecturally, the 3GPP EPC network is similar to an IP wireless network running PMIPv6 or MIPv6, as it relies on the Packet Data Network Gateway (P-GW) anchoring services to provide mobile nodes with mobility support (see Figure 5). There are client-based and network-based mobility solutions in 3GPP, which for simplicity will be analyzed together. We next describe how 3GPP mobility protocols and several other completed or ongoing extensions can be deployed to meet some of the DMM requirements [RFC7333].
在架构上，3GPP EPC网络类似于运行PMIPv6或MIPv6的IP无线网络，因为它依赖分组数据网络网关（P-GW）锚定服务来为移动节点提供移动性支持（见图5）。3GPP中有基于客户端和基于网络的移动解决方案，为了简单起见，将一起分析。接下来，我们将描述如何部署3GPP移动协议和其他几个已完成或正在进行的扩展，以满足一些DMM需求[RFC7333]。
+---------------------------------------------------------+
| PCRF |
+-----------+--------------------------+----------------+-+
| | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | |
| | | |GERAN/|_|G| \ | | | HSS | | | | | |
| +-----+ UTRAN| |S| \ | | +---+----+ | | | | E |
| | | +------+ |N| +-+-+ | | | | | | | x |
| | | +-+ /|MME| | | +---+----+ | | | | t |
| | | +---------+ / +---+ | | | 3GPP | | | | | e |
| +-----+ E-UTRAN |/ | | | AAA | | | | | r |
| | | +---------+\ | | | SERVER | | | | | n |
| | | \ +----+ | | +--------+ | | | | a |
| | | 3GPP AN \|S-GW+---- S5---------------+ P | | | l |
| | | +----+ | | | - | | | |
| | +------------------------+ | | G | | | I |
| UE | | | W | | | P |
| | +------------------------+ | | +-----+ |
| | |+-------------+ +------+| | | | | | n |
| | || Untrusted +-+ ePDG +-S2b---------------+ | | | e |
| +---+| non-3GPP AN | +------+| | | | | | t |
| | |+-------------+ | | | | | | w |
| | +------------------------+ | | | | | o |
| | | | | | | r |
| | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | |
| | | +-+-+ | | |
| +--------------------------S2c--------------------| | | |
| | | | | |
+----+ +--------------------+ +---+
+---------------------------------------------------------+
| PCRF |
+-----------+--------------------------+----------------+-+
| | |
+----+ +-----------+------------+ +--------+-----------+ +-+-+
| | | +-+ | | Core Network | | |
| | | +------+ |S|__ | | +--------+ +---+ | | |
| | | |GERAN/|_|G| \ | | | HSS | | | | | |
| +-----+ UTRAN| |S| \ | | +---+----+ | | | | E |
| | | +------+ |N| +-+-+ | | | | | | | x |
| | | +-+ /|MME| | | +---+----+ | | | | t |
| | | +---------+ / +---+ | | | 3GPP | | | | | e |
| +-----+ E-UTRAN |/ | | | AAA | | | | | r |
| | | +---------+\ | | | SERVER | | | | | n |
| | | \ +----+ | | +--------+ | | | | a |
| | | 3GPP AN \|S-GW+---- S5---------------+ P | | | l |
| | | +----+ | | | - | | | |
| | +------------------------+ | | G | | | I |
| UE | | | W | | | P |
| | +------------------------+ | | +-----+ |
| | |+-------------+ +------+| | | | | | n |
| | || Untrusted +-+ ePDG +-S2b---------------+ | | | e |
| +---+| non-3GPP AN | +------+| | | | | | t |
| | |+-------------+ | | | | | | w |
| | +------------------------+ | | | | | o |
| | | | | | | r |
| | +------------------------+ | | | | | k |
| +---+ Trusted non-3GPP AN +-S2a--------------+ | | | s |
| | +------------------------+ | | | | | |
| | | +-+-+ | | |
| +--------------------------S2c--------------------| | | |
| | | | | |
+----+ +--------------------+ +---+
where E-UTRAN - Evolved Universal Terrestrial Radio Access Network GERAN - GSM EDGE Radio Access Network HSS - Home Subscriber Server MME - Mobility Management Entity PCRF - Policy and Charging Rule Function SGSN - Serving GPRS Support Node UTRAN - Universal Terrestrial Radio Access Network
其中E-UTRAN-演进型通用地面无线接入网络GERAN-GSM边缘无线接入网络HSS-家庭用户服务器MME-移动性管理实体PCRF-策略和计费规则功能SGSN-服务GPRS支持节点UTRAN-通用地面无线接入网络
Figure 5: EPS (Non-roaming) Architecture Overview
图5:EPS（非漫游）体系结构概述
The GPRS Tunneling Protocol (GTP) [SDO-3GPP.29.060] [SDO-3GPP.29.281] [SDO-3GPP.29.274] is a network-based mobility protocol specified for 3GPP networks (S2a, S2b, S5, and S8 interfaces). In a similar way to PMIPv6, it can handle mobility without requiring the involvement of
GPRS隧道协议（GTP）[SDO-3GPP.29.060][SDO-3GPP.29.281][SDO-3GPP.29.274]是为3GPP网络（S2a、S2b、S5和S8接口）指定的基于网络的移动性协议。与PMIPv6类似，它可以处理移动性，而不需要
the mobile nodes. In this case, the mobile node functionality is provided in a proxy manner by the Serving Data Gateway (S-GW), Evolved Packet Data Gateway (ePDG), or Trusted Wireless Access Gateway (TWAG [SDO-3GPP.23.402]) .
移动节点。在这种情况下，移动节点功能由服务数据网关（S-GW）、演进分组数据网关（ePDG）或可信无线接入网关（TWAG[SDO-3GPP.23.402]）以代理方式提供。
3GPP specifications also include client-based mobility support, based on adopting the use of Dual-Stack Mobile IPv6 (DSMIPv6) [RFC5555] for the S2c interface [SDO-3GPP.24.303]. In this case, the User Equipment (UE) implements the binding update functionality, while the home agent role is played by the P-GW.
3GPP规范还包括基于客户端的移动性支持，其基于对S2c接口[SDO-3GPP.24.303]采用双栈移动IPv6（dsmpv6）[rfc555]。在这种情况下，用户设备（UE）实现绑定更新功能，而归属代理角色由P-GW扮演。
A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) enabled network [SDO-3GPP.23.401] allows offloading some IP services at the local access network above the Radio Access Network (RAN) without the need to travel back to the P-GW (see Figure 6).
启用本地IP接入（LIPA）和选定IP流量卸载（SIPTO）的网络[SDO-3GPP.23.401]允许在无线接入网络（RAN）上方的本地接入网络卸载一些IP服务，而无需返回P-GW（见图6）。
+---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN)
| Equipm. |..................
+---------+ . Local IP traffic
.
+-----------+
|Residential|
|enterprise |
|IP network |
+-----------+
+---------+ IP traffic to mobile operator's CN
| User |....................................(Operator's CN)
| Equipm. |..................
+---------+ . Local IP traffic
.
+-----------+
|Residential|
|enterprise |
|IP network |
+-----------+
Figure 6: LIPA Scenario
图6:LIPA场景
SIPTO enables an operator to offload certain types of traffic at a network node close to the UE's point of attachment to the access network. This is done by selecting a set of GWs (S-GW and P-GW1 in the figure below) that are geographically/topologically close to the UE's point of attachment.
SIPTO使运营商能够在靠近UE接入网络的连接点的网络节点上卸载某些类型的业务。这是通过选择一组地理/拓扑上靠近UE连接点的GWs（下图中的S-GW和P-GW1）来实现的。
SIPTO Traffic
|
.
.
+-------+ +------+
| P-GW1 | ---- | MME |
+-------+ / +------+
| /
+------+ +-----+ +------+/ +-------+
| UE |.....| eNB |...| S-GW |........| P-GW2 |... CN Traffic
+------+ +-----+ +------+ +-------+
SIPTO Traffic
|
.
.
+-------+ +------+
| P-GW1 | ---- | MME |
+-------+ / +------+
| /
+------+ +-----+ +------+/ +-------+
| UE |.....| eNB |...| S-GW |........| P-GW2 |... CN Traffic
+------+ +-----+ +------+ +-------+
Figure 7: SIPTO Architecture
图7:SIPTO体系结构
LIPA, on the other hand, enables an IP addressable UE connected via a Home evolved Network B (HeNB) to access other IP addressable entities in the same residential/enterprise IP network without traversing the mobile operator's network core in the user plane. In order to achieve this, a Local GW (L-GW) collocated with the HeNB is used. To establish LIPA, the UE requests a new Public Data Network (PDN) connection to an access point name for which LIPA is permitted, the network selects the Local GW associated with the HeNB, and the network enables a direct user-plane path between the Local GW and the HeNB.
另一方面，LIPA使得经由家庭演进网络B（HeNB）连接的IP可寻址UE能够访问同一住宅/企业IP网络中的其他IP可寻址实体，而无需在用户平面中遍历移动运营商的网络核心。为了实现这一点，使用与HeNB搭配的本地GW（L-GW）。为了建立LIPA，UE请求到允许LIPA的接入点名称的新公共数据网络（PDN）连接，网络选择与HeNB相关联的本地GW，并且网络启用本地GW和HeNB之间的直接用户平面路径。
+------------+ +------+ +----------+ +-------------+ =====
|Residential | | HeNB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|------|..| |..|Operator |..(Network)
|Network | | L-GW | | | |Core network | =======
+------------+ +------+ +----------+ +-------------+
/
|
/
+-----+
| UE |
+-----+
+------------+ +------+ +----------+ +-------------+ =====
|Residential | | HeNB | | Backhaul | |Mobile | ( IP )
|Enterprise |..|------|..| |..|Operator |..(Network)
|Network | | L-GW | | | |Core network | =======
+------------+ +------+ +----------+ +-------------+
/
|
/
+-----+
| UE |
+-----+
Figure 8: LIPA Architecture
图8:LIPA体系结构
The 3GPP architecture specifications also provide mechanisms to allow discovery and selection of gateways [SDO-3GPP.29.303]. These mechanisms enable decisions that take into consideration topological location and gateway collocation aspects, by relying upon the DNS as a "location database."
3GPP架构规范还提供了允许发现和选择网关的机制[SDO-3GPP.29.303]。这些机制通过将DNS作为“位置数据库”来实现考虑拓扑位置和网关配置方面的决策
Both SIPTO and LIPA have a very limited mobility support, especially 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.
SIPTO和LIPA都有非常有限的移动性支持，特别是在3GPP规范中，直到Rel-12。简单地说，LIPA移动性支持仅限于由相同的L-GW管理的henb之间的切换（即本地域内的移动性）。SIPTO无法保证IP会话的连续性。
This section identifies the limitations in the current practices, described in Section 4, with respect to the DMM requirements listed in [RFC7333].
本节针对[RFC7333]中列出的DMM要求，确定了第4节中描述的当前实践中的限制。
According to requirement REQ1 stated in [RFC7333], IP mobility, network access, and forwarding solutions provided by DMM must make it possible for traffic to avoid traversing a single mobility anchor far from the optimal route.
根据[RFC7333]中所述的要求REQ1，DMM提供的IP移动性、网络访问和转发解决方案必须使流量能够避免穿越远离最佳路由的单个移动性锚点。
From the analysis performed in Section 4, a DMM deployment can meet the requirement "REQ1 Distributed mobility management" usually relying on the following functions:
根据第4节中进行的分析，DMM部署可以满足“REQ1分布式移动性管理”的要求，通常依赖于以下功能：
o 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.
o 多（分布式）锚定：能够在不同的锚定位置锚定单个移动节点的不同会话。为了提供改进的路由，可能需要将一些锚放置在更靠近移动节点或相应节点的位置。
o 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 the transfer of 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.
o 动态锚点分配/重新定位：能够i）分配初始锚点，ii）动态更改初始分配的锚点和/或分配新的锚点（这也可能需要在锚点之间转移移动性上下文）。这可以通过为所有正在进行的会话更改锚定或仅为新会话分配新锚定来实现。
GAP1-1: Both the main client- and network-based IP mobility protocols (namely, MIPv6, DSMIPv6, and PMIPv6) allow deploying multiple anchors (i.e., home agents and localized mobility anchors), thereby providing the multiple anchoring function. However, existing solutions only provide an 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 allows 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.
GAP1-1：主客户端和基于网络的IP移动协议（即MIPv6、DSMPv6和PMIPv6）都允许部署多个锚（即，归属代理和本地化移动锚），从而提供多个锚功能。然而，现有解决方案仅提供初始锚定分配，因此缺少动态锚定变更/新锚定分配是一个缺口。HA交换机和LMA运行时分配都不允许在正在进行的会话期间更改锚。这实际上包括几个差距：在任何时候执行锚分配的能力（不仅仅是在初始MN连接时）、当前锚启动/触发重新定位的能力，以及在锚之间传输注册上下文的能力。
GAP1-2: 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 the anchor associated with each of its mobility sessions.
GAP1-2：动态锚分配可能导致MN管理由不同移动锚服务的不同移动会话。这不是基于客户端的移动性管理的问题，其中移动性客户端本机知道与其每个移动性会话相关联的锚。
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, as described in 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.
然而，存在一个差距，因为MN应该能够以DMM友好的方式处理IP地址，这意味着MN可以执行智能源地址选择（即，从以前的移动锚中弃用IP地址，以便它们不用于新会话）。此外，管理由不同移动锚服务的不同移动会话可能会引起基于网络的移动管理问题。在这种情况下，位于网络中的移动客户端（例如MAG）通常从MN的策略配置文件中检索MN的锚，如[RFC5213]第6.2节所述。目前，MN的策略配置文件隐式地假定单个服务锚，因此不维护家庭网络前缀和锚之间的关联。
GAP1-3: 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 the dynamic discovery of the presence of nodes that can play the anchor role, the discovery of their capabilities, and the selection of 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). However, there are some mechanisms that could help to discover anchors, such as the Dynamic Home Agent Address Discovery (DHAAD) [RFC6275], the use of the home agent flag (H) 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].
GAP1-3：移动锚的分布的结果是，可能有多个可用锚供移动节点使用，这导致锚发现和选择问题。目前，没有指定有效的机制来允许动态发现可以扮演锚角色的节点的存在、发现它们的能力以及选择最合适的节点。也没有允许选择当前锚定给定家庭地址/前缀的节点的机制（有时需要满足REQ#2的功能）。然而，有一些机制可以帮助发现锚，例如动态归属代理地址发现（DHAAD）[RFC6275]，在路由器广告中使用归属代理标志（H）（这表明发送路由器广告的路由器也在链路上作为移动IPv6归属代理运行）或HMIPv6定义的路由器广告中的映射选项。注意，有3GPP机制提供[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 reattachment and authentication).
关于在锚之间传输注册上下文的能力，已经有一些解决方案可以重用或调整以填补这一空白，例如移动IPv6的快速切换[RFC5568]，以实现从旧锚到新锚的流量重定向，上下文传输协议[RFC4067]启用锚之间所需的注册信息传输，或切换密钥体系结构解决方案[RFC6697]，以加快锚更改后的重新身份验证过程。请注意，在DMM的上下文中可能需要一些扩展，因为这些协议是在集中式客户端IP移动的上下文中设计的（重点是访问重新连接和身份验证）。
GAP1-4: Also note that REQ1 is intended to prevent the data-plane traffic from taking a suboptimal route. Distributed processing of the traffic may then be needed only in the data plane. Provision of this capability for distributed processing should not conflict with the use of a centralized control plane. Other control-plane solutions (such as charging, lawful interception, etc.) should not be constrained by the DMM solution. On the other hand, combining the control-plane and data-plane FM function may limit the choice of solutions to those that distribute both data plane and control plane together. In order to enable distribution of only the data plane without distributing the control plane, it would be necessary to split the forwarding management function into the control-plane (FM-CP) and data-plane (FM-DP) components; there is currently a gap here.
GAP1-4：还请注意，REQ1旨在防止数据平面通信采用次优路由。然后，可能只需要在数据平面中对流量进行分布式处理。为分布式处理提供这种能力不应与使用集中控制平面相冲突。其他控制平面解决方案（如充电、合法拦截等）不应受到DMM解决方案的限制。另一方面，结合控制平面和数据平面FM功能可能会将解决方案的选择限制为同时分布数据平面和控制平面的解决方案。为了仅分发数据平面而不分发控制平面，有必要将转发管理功能拆分为控制平面（FM-CP）和数据平面（FM-DP）组件；目前这里有一个缺口。
5.2. Bypassable Network-Layer Mobility Support for Each Application Session - REQ2
5.2. 每个应用程序会话的可绕过网络层移动性支持-REQ2
The requirement REQ2 for "bypassable network-layer mobility support for each application session" introduced in [RFC7333] requires flexibility in determining whether network-layer mobility support is needed. This requirement enables one to choose whether or not to use network-layer mobility support. The following two functions are also needed:
[RFC7333]中介绍的“每个应用程序会话的可绕过网络层移动性支持”要求REQ2在确定是否需要网络层移动性支持时具有灵活性。这一要求使人们能够选择是否使用网络层移动性支持。还需要以下两个功能：
o Dynamically assign/relocate anchor: A mobility anchor is assigned only to sessions that use 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).
o 动态分配/重新定位锚：移动锚只分配给使用网络层移动支持的会话。因此，MN可以管理多个会话；其中一些可能与锚定IP地址关联，而其他可能与本地IP地址关联。
o Multiple IP address management: This function is related to the preceding item 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.
o 多IP地址管理：此功能与前一项相关，并且是关于移动节点同时使用多个IP地址并（从锚定角度）选择最佳IP地址以在每个会话/应用程序/服务的基础上使用的能力。这要求MN获取有关可用IP地址属性的信息。
GAP2-1: The dynamic anchor assignment/relocation needs to ensure that IP address continuity is guaranteed for sessions that use such mobility support (e.g., in some scenarios, the provision of mobility locally within a limited area might be enough from the point of view of the mobile node or the application) at the relocated anchor. Implicitly, DMM may release the needed resources when no applications are using the network-layer mobility support. DMM is then potentially
GAP2-1：动态锚分配/重新定位需要确保在重新定位的锚处为使用这种移动性支持的会话保证IP地址连续性（例如，在某些场景中，从移动节点或应用程序的角度来看，在有限区域内本地提供移动性可能就足够了）。隐含地，当没有应用程序使用网络层移动性支持时，DMM可能会释放所需的资源。因此，DMM是潜在的
required to know which sessions at the mobile node are active and are using the mobility support. Typically, this is known only by the MN (e.g., by its connection manager) and would require some signaling support, such as socket API extensions, from applications to indicate to the IP stack whether or not mobility support is required. 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, such as socket API extensions, from applications to indicate to the IP stack whether mobility support is required or not. Therefore, (part of) this knowledge might need to be transferred to/shared with the network.
需要知道移动节点上的哪些会话处于活动状态，并且正在使用移动支持。通常，这仅由MN（例如，其连接管理器）知道，并且将需要来自应用程序的一些信令支持，例如套接字API扩展，以向IP堆栈指示是否需要移动性支持。这可能意味着知道移动节点上的哪些会话是活动的并且正在使用移动支持。这通常仅由MN（例如，其连接管理器）知道，并且通常还需要来自应用程序的一些信令支持，例如套接字API扩展，以向IP堆栈指示是否需要移动性支持。因此，（部分）这些知识可能需要转移到网络或与网络共享。
GAP2-2: Management of multiple IP addresses provides the MN with the choice to pick the correct address (e.g., from those provided or not provided with mobility support) depending on the application requirements. When using client-based mobility management, the MN is itself aware of the anchoring capabilities of its assigned IP addresses. This is not necessarily the case with network-based IP mobility management, as current mechanisms do not allow the MN to be aware of the properties of its IP addresses. For example, the MN does not know whether or not the allocated IP addresses are anchored. However, there are proposals such as [CLASS-PREFIX], [PREFIX-PROPERTIES], and [MULTI-ARCH], where the network could indicate such properties during IP address assignment procedures. These proposals could be considered as attempts to fix the gap.
GAP2-2：多个IP地址的管理为MN提供了根据应用要求选择正确地址的选择（例如，从提供或未提供移动性支持的地址中）。当使用基于客户端的移动性管理时，MN本身知道其分配的IP地址的锚定能力。基于网络的IP移动性管理不一定如此，因为当前的机制不允许MN知道其IP地址的属性。例如，MN不知道所分配的IP地址是否被锚定。然而，也有一些建议，如[CLASS-PREFIX]、[PREFIX-PROPERTIES]和[MULTI-ARCH]，其中网络可以在IP地址分配过程中指示这些属性。这些建议可被视为试图弥补这一差距。
GAP2-3: 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.
GAP2-3：除了用户/设备标识外，对用户/设备单个会话粒度的移动性管理的处理还需要适当的会话标识。
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.
该要求指出，DMM解决方案应主要以IPv6作为主要部署环境。IPv4支持不是强制性的，解决方案不应专门定制以支持IPv4。
All analyzed DMM practices support IPv6. Some of them, such as MIPv6/NEMO (including the support of dynamic HA selection), MOBIKE, and SIPTO also have IPv4 support. Some solutions, e.g., PMIPv6, also have some limited IPv4 support. In conclusion, this requirement is met by existing DMM practices.
所有分析过的DMM实践都支持IPv6。其中一些，如MIPv6/NEMO（包括对动态HA选择的支持）、MOBIKE和SIPTO也支持IPv4。一些解决方案，例如PMIPv6，也有一些有限的IPv4支持。总之，现有DMM实践满足了这一要求。
A DMM solution must first consider reusing and extending IETF-standardized protocols before specifying new protocols.
在指定新协议之前，DMM解决方案必须首先考虑重用和扩展IETF标准化协议。
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 prevents the distribution of mobility functions within IP mobility protocols. However, as discussed in Sections 5.1 and 5.2, limitations exist. The 3GPP data-plane anchoring function, i.e., the P-GW, can also be distributed but with limitations such as no anchoring relocation and no context transfer between anchors and the centralized control plane. The 3GPP architecture is also going in 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.
如[RFC7333]所述，DMM解决方案可以在指定新协议之前重用现有的IETF和标准化协议。此外，本文档的第4节讨论了扁平化和分发当前移动解决方案的各种方法。事实上，没有什么可以阻止移动功能在IP移动协议中的分布。但是，如第5.1节和第5.2节所述，存在限制。3GPP数据平面锚定功能，即P-GW，也可以是分布式的，但是具有诸如锚定重新定位和锚定与集中控制平面之间的上下文传输等限制。3GPP架构也正朝着SIPTO和LIPA的扁平化方向发展，尽管它们不提供完全的移动性支持。例如，SIPTO流量的移动性支持可能相当有限，卸载的流量无法访问运营商服务。因此，运营商在选择要卸载的流量时必须非常小心。
5.5. Coexistence with Deployed Networks/Hosts and Operability across Different Networks - REQ5
5.5. 与部署的网络/主机共存以及跨不同网络的可操作性-要求5
According to [RFC7333], DMM implementations are required to coexist 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 necessary mobility management signaling, forwarding, and network access are allowed by the trust relationship between them. All current mobility protocols can coexist with existing network deployments and end hosts. There is no gap between existing mobility protocols and this requirement.
根据[RFC7333]，DMM实现需要与现有网络部署、终端主机和路由器共存。此外，当必要的移动性管理信令、转发和网络访问被它们之间的信任关系允许时，DMM解决方案有望跨不同的网络工作，可能作为单独的管理域运行。所有当前的移动协议都可以与现有的网络部署和终端主机共存。现有的移动协议与此要求之间没有差距。
This requirement actually comprises several aspects, as summarized below.
这一要求实际上包括以下几个方面。
o 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.
o DMM解决方案需要考虑配置设备，监视设备的当前操作状态，响应影响设备的事件，可能通过修改配置，并以稍后可分析的格式存储数据。
o A DMM solution has to describe in what environment and how it can be scalably deployed and managed.
o DMM解决方案必须描述在什么环境中以及如何可扩展地部署和管理。
o A DMM solution has to support mechanisms to test if the DMM solution is working properly.
o DMM解决方案必须支持测试DMM解决方案是否正常工作的机制。
o A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities.
o DMM解决方案将向DMM实体的管理员公开DMM的运行状态。
o A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions.
o 支持流移动性的DMM解决方案还应支持将流路由策略与观察到的转发操作关联起来的方法。
o A DMM solution is expected to support mechanisms to check the liveness of the forwarding path.
o DMM解决方案应支持检查转发路径活性的机制。
o 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.
o DMM解决方案必须提供故障管理和监控机制，以管理移动会话或数据路径更新失败的情况。
o A DMM solution is expected to be able to monitor the usage of the DMM protocol.
o DMM解决方案预计能够监控DMM协议的使用情况。
o DMM solutions have to support standardized configuration with Network Configuration Protocol (NETCONF) [RFC6241] using YANG [RFC6020] modules, which are expected to be created for DMM when needed for such configuration.
o DMM解决方案必须支持使用YANG[RFC6020]模块的网络配置协议（NETCONF）[RFC6241]的标准化配置，在需要此类配置时，预计将为DMM创建这些模块。
GAP6-1: Existing mobility management protocols have not thoroughly documented how, or whether, they support the above list of operation and management considerations. Each of the above needs to be considered from the beginning in a DMM solution.
GAP6-1：现有的移动性管理协议尚未完全记录它们如何或是否支持上述操作和管理注意事项。在DMM解决方案中，需要从一开始就考虑上述各项。
GAP6-2: 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 lacking.
GAP6-2:MIPv6的[RFC4295]和PMIPv6的[RFC6475]中目前定义了管理信息库（MIB）对象。缺少使用YANG[RFC6020]模块的NETCONF[RFC6241]的标准化配置。
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 privacy concerns, or amplify existing security risks that cannot be mitigated by existing security protocols and mechanisms.
如[RFC7333]所述，DMM解决方案必须支持网络安全和持续安全改进所需的任何安全协议和机制。此外，在设计早期考虑安全性的情况下，DMM解决方案不能引入新的安全风险或隐私问题，也不能放大现有安全协议和机制无法缓解的现有安全风险。
Any solutions that are intended to fill in gaps identified in this document need to meet this requirement. At present, it does not appear that using existing solutions to support DMM has introduced
任何旨在填补本文件中确定的空白的解决方案都需要满足这一要求。目前，似乎还没有引入使用现有解决方案支持DMM
any new security issues. 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.
任何新的安全问题。例如，移动IPv6定义了安全功能，以保护对归属代理和对应节点的绑定更新。它还定义了保护移动IPv6用户数据包传输的机制。代理移动IPv6和移动IP的其他变体也有类似的安全考虑。
It is stated in [RFC7333] that DMM solutions are expected to allow the development of multicast solutions to avoid network inefficiency in multicast traffic delivery.
[RFC7333]中指出，DMM解决方案有望允许多播解决方案的开发，以避免多播流量交付中的网络效率低下。
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.
当前的IP移动性解决方案主要解决单播业务的移动性问题。依赖于使用锚定点将多播通信量隧道到接入路由器或移动节点的解决方案引入了所谓的“隧道收敛问题”。这意味着相同多播流量的多个实例可以聚合到同一节点，从而降低了使用多播协议的优势。
[RFC6224] documents a baseline solution for the previous issue, and [RFC7028] documents a routing optimization solution. The baseline solution suggests deploying a Multicast Listener Discovery (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 or a direct routing option can be used to avoid the tunnel convergence problem.
[RFC6224]记录了上一期的基线解决方案，[RFC7028]记录了路由优化解决方案。基线解决方案建议在MAG部署多播侦听器发现（MLD）代理功能，在LMA部署多播路由器或另一个MLD代理功能。路由优化解决方案描述了一种架构，其中可以使用专用的多播树移动锚或直接路由选项来避免隧道收敛问题。
Besides the solutions highlighted before, there are no other mechanisms for mobility protocols to address the multicast tunnel convergence problem.
除了前面强调的解决方案外，移动协议没有其他机制来解决多播隧道收敛问题。
We next list the main gaps identified from the analysis performed above:
我们接下来列出了从上述分析中发现的主要差距：
GAP1-1: 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 allows changing the anchor during an ongoing session. MOBIKE allows change of GW, but its applicability has been scoped to a very narrow use case.
GAP1-1：现有解决方案仅提供最佳初始锚定分配，差距在于缺少动态锚定变更/新锚定分配。HA交换机和LMA运行时分配都不允许在正在进行的会话期间更改锚。MOBIKE允许更改GW，但其适用范围仅限于非常狭窄的用例。
GAP1-2: The MN needs to be able to perform source address selection. A proper mechanism to inform the MN is lacking, so there is not a basis for performing the correct selection.
GAP1-2:MN需要能够执行源地址选择。缺乏通知MN的适当机制，因此没有执行正确选择的基础。
GAP1-3: Currently, there is no efficient mechanism specified by the IETF that allows the dynamic discovery of 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 could help discovering anchors:
GAP1-3：目前，IETF没有指定有效的机制来允许动态发现可以扮演锚角色的节点的存在，发现它们的能力，并允许选择最合适的节点。但是，以下机制有助于发现锚：
Dynamic Home Agent Address Discovery (DHAAD): The use of the home agent flag (H) 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.
动态归属代理地址发现（DHAAD）：在路由器播发中使用归属代理标志（H）（表示发送路由器播发的路由器也在链路上充当移动IPv6归属代理）和HMIPv6定义的路由器播发中的映射选项。
GAP1-4: While existing network-based DMM practices may allow the deployment of 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 RFC 5213). Although [RFC7389] 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.
GAP1-4：虽然现有的基于网络的DMM实践可能允许部署多个LMA并动态选择最佳LMA，但这仍需要在控制平面上保持一定的集中，以访问策略数据库（如RFC 5213中所定义）。尽管[RFC7389]允许MAG执行其控制平面和用户平面的拆分，但缺少支持DMM环境下IETF IP移动性协议的明确控制平面和数据平面分离的解决方案/扩展。
GAP2-1: The information of which sessions at the mobile node are active and are using the mobility support need to be transferred to, or shared with, the network. Such mechanism has not been defined.
GAP2-1：移动节点上哪些会话处于活动状态且正在使用移动支持的信息需要传输到网络或与网络共享。这种机制尚未确定。
GAP2-2: The mobile node needs to simultaneously use multiple IP addresses with different properties. There is a lack of mechanism to expose this information to the mobile node, which can then update accordingly its source address selection mechanism.
GAP2-2：移动节点需要同时使用具有不同属性的多个IP地址。缺少将此信息公开给移动节点的机制，移动节点随后可以相应地更新其源地址选择机制。
GAP2-3: The handling of mobility management has not been to the granularity of an individual session of a user/device before. The combination of session identification and user/ device identification may be lacking.
GAP2-3：以前，移动管理的处理还没有达到用户/设备单个会话的粒度。可能缺少会话标识和用户/设备标识的组合。
GAP6-1: Mobility management protocols have not thoroughly documented how, or whether, they support the following list of operation and management considerations:
GAP6-1：移动性管理协议尚未完全记录它们如何或是否支持以下操作和管理注意事项：
* A DMM solution needs to consider configuring a device, monitoring the current operational state of a device, and responding to events that impact the device possibly by modifying the configuration and storing the data in a format that can be analyzed later.
* DMM解决方案需要考虑配置设备，监视设备的当前操作状态，并通过修改配置并以稍后可分析的格式存储数据来影响影响设备的事件。
* A DMM solution has to describe in what environment, and how, it can be scalably deployed and managed.
* DMM解决方案必须描述在什么环境中以及如何可扩展地部署和管理。
* A DMM solution has to support mechanisms to test if the DMM solution is working properly.
* DMM解决方案必须支持测试DMM解决方案是否正常工作的机制。
* A DMM solution is expected to expose the operational state of DMM to the administrators of the DMM entities.
* DMM解决方案将向DMM实体的管理员公开DMM的运行状态。
* A DMM solution, which supports flow mobility, is also expected to support means to correlate the flow routing policies and the observed forwarding actions.
* 支持流移动性的DMM解决方案还应支持将流路由策略与观察到的转发操作关联起来的方法。
* A DMM solution is expected to support mechanisms to check the liveness of the forwarding path.
* DMM解决方案应支持检查转发路径活性的机制。
* 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.
* DMM解决方案必须提供故障管理和监控机制，以管理移动会话或数据路径更新失败的情况。
* A DMM solution is expected to be able to monitor the usage of the DMM protocol.
* DMM解决方案预计能够监控DMM协议的使用情况。
* 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.
* DMM解决方案必须支持NETCONF[RFC6241]的标准化配置，使用YANG[RFC6020]模块，在需要此类配置时，预计将为DMM创建这些模块。
GAP6-2: 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 lacking.
GAP6-2:MIPv6的[RFC4295]和PMIPv6的[RFC6475]中目前定义了管理信息库（MIB）对象。缺少使用YANG[RFC6020]模块的NETCONF[RFC6241]的标准化配置。
The deployment of DMM using existing IP mobility protocols raises similar security threats as those encountered in centralized mobility management systems. 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 and fulfill the security requirement of [RFC7333].
使用现有IP移动协议部署DMM会带来与集中式移动管理系统类似的安全威胁。如果没有身份验证，恶意节点可能伪造信令消息并从其合法路径重定向流量。这相当于针对特定节点的拒绝服务攻击。分布式移动性锚定在保持当前安全机制的同时，可能需要移动性管理实体管理更多的安全关联，这可能会导致可伸缩性和性能问题。此外，分布式移动锚定使移动安全问题更加复杂，因为流量重定向请求可能来自以前未考虑的来源，从而导致分布式攻击点。因此，DMM安全设计需要考虑额外移动实体之间安全关联的分布，并满足[RFC7333]的安全要求。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月<http://www.rfc-editor.org/info/rfc6275>.
[RFC7333] Chan, H., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, August 2014, <http://www.rfc-editor.org/info/rfc7333>.
[RFC7333]Chan，H.，Liu，D.，Seite，P.，Yokota，H.，和J.Korhonen，“分布式移动性管理的要求”，RFC 7333，2014年8月<http://www.rfc-editor.org/info/rfc7333>.
[CLASS-PREFIX] Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class based prefix", Work in Progress, draft-bhandari-dhc-class-based-prefix-05, July 2013.
[CLASS-PREFIX]Systems，C.，Halwasia，G.，Gundavelli，S.，Deng，H.，Thiebaut，L.，Korhonen，J.，和I.Farrer，“DHCPv6基于类的前缀”，在建工程，草稿-bhandari-dhc-CLASS-based-PREFIX-052013年7月。
[COMMUNITY-WIFI] Gundavelli, S., Grayson, M., Seite, P., and Y. Lee, "Service Provider Wi-Fi Services Over Residential Architectures", Work in Progress, draft-gundavelli-v6ops-community-wifi-svcs-06, April 2013.
[COMMUNITY-WIFI]Gundavelli，S.，Grayson，M.，Seite，P.，和Y.Lee，“住宅建筑上的服务提供商Wi-Fi服务”，正在进行的工作，草稿-Gundavelli-v6ops-COMMUNITY-WIFI-svcs-062013年4月。
[IEEE.802-16.2009] IEEE, "IEEE Standard for Local and metropolitan area networks Part 16: Air Interface for Broadband Wireless Access Systems", IEEE Standard 802.16, 2009, <http://standards.ieee.org/getieee802/ download/802.16-2009.pdf>.
【IEEE.802-16.2009】IEEE，“局域网和城域网的IEEE标准第16部分：宽带无线接入系统的空中接口”，IEEE标准802.16，2009<http://standards.ieee.org/getieee802/ 下载/802.16-2009.pdf>。
[MULTI-ARCH] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", Work in Progress, draft-ietf-mif-mpvd-arch-08, January 2015.
[MULTI-ARCH]Anipko，D.，编辑，“多供应域体系结构”，正在进行的工作，草稿-ietf-mif-mpvd-ARCH-082015年1月。
[PREFIX-PROPERTIES] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Properties", Work in Progress, draft-korhonen-6man-prefix-properties-02, July 2013.
[PREFIX-PROPERTIES]Korhonen，J.，Patil，B.，Gundavelli，S.，Seite，P.，和D.Liu，“IPv6前缀属性”，正在进行的工作，草稿-Korhonen-6man-PREFIX-PROPERTIES-022013年7月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005, <http://www.rfc-editor.org/info/rfc3963>.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月<http://www.rfc-editor.org/info/rfc3963>.
[RFC4066] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005, <http://www.rfc-editor.org/info/rfc4066>.
[RFC4066]Liebsch，M.，Singh，A.，Chaskar，H.，Funato，D.，和E.Shim，“候选接入路由器发现（卡）”，RFC 4066，2005年7月<http://www.rfc-editor.org/info/rfc4066>.
[RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005, <http://www.rfc-editor.org/info/rfc4067>.
[RFC4067]Loughney，J.，Nakhjiri，M.，Perkins，C.，和R.Koodli，“上下文传输协议（CXTP）”，RFC 40672005年7月<http://www.rfc-editor.org/info/rfc4067>.
[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, <http://www.rfc-editor.org/info/rfc4225>.
[RFC4225]Nikander，P.，Arkko，J.，Aura，T.，黑山，G.，和E.Nordmark，“移动IP版本6路由优化安全设计背景”，RFC 42252005年12月<http://www.rfc-editor.org/info/rfc4225>.
[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, "Mobile IPv6 Management Information Base", RFC 4295, April 2006, <http://www.rfc-editor.org/info/rfc4295>.
[RFC4295]Keeni，G.，Koide，K.，Nagami，K.，和S.Gundavelli，“移动IPv6管理信息库”，RFC 42952006年4月<http://www.rfc-editor.org/info/rfc4295>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006, <http://www.rfc-editor.org/info/rfc4555>.
[RFC4555]Eronen，P.，“IKEv2移动和多址协议（MOBIKE）”，RFC4555，2006年6月<http://www.rfc-editor.org/info/rfc4555>.
[RFC4640] Patel, A. and G. Giaretta, "Problem Statement for bootstrapping Mobile IPv6 (MIPv6)", RFC 4640, September 2006, <http://www.rfc-editor.org/info/rfc4640>.
[RFC4640]Patel，A.和G.Giaretta，“引导移动IPv6（MIPv6）的问题陈述”，RFC 46402006年9月<http://www.rfc-editor.org/info/rfc4640>.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007, <http://www.rfc-editor.org/info/rfc4889>.
[RFC4889]Ng，C.，Zhao，F.，Watari，M.，和P.Thubert，“网络移动性路由优化解决方案空间分析”，RFC 4889，2007年7月<http://www.rfc-editor.org/info/rfc4889>.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月<http://www.rfc-editor.org/info/rfc4960>.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007, <http://www.rfc-editor.org/info/rfc5014>.
[RFC5014]Nordmark，E.，Chakrabarti，S.，和J.Laganier，“用于源地址选择的IPv6套接字API”，RFC 50142007年9月<http://www.rfc-editor.org/info/rfc5014>.
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007, <http://www.rfc-editor.org/info/rfc5026>.
[RFC5026]Giaretta，G.，Kempf，J.和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月<http://www.rfc-editor.org/info/rfc5026>.
[RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, "Mobility Header Home Agent Switch Message", RFC 5142, January 2008, <http://www.rfc-editor.org/info/rfc5142>.
[RFC5142]Haley，B.，Devarapalli，V.，Deng，H.，和J.Kempf，“移动头归属代理切换消息”，RFC 51422008年1月<http://www.rfc-editor.org/info/rfc5142>.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 52132008年8月<http://www.rfc-editor.org/info/rfc5213>.
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008, <http://www.rfc-editor.org/info/rfc5380>.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月<http://www.rfc-editor.org/info/rfc5380>.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009, <http://www.rfc-editor.org/info/rfc5555>.
[RFC5555]Soliman，H.，“双栈主机和路由器的移动IPv6支持”，RFC 55552009年6月<http://www.rfc-editor.org/info/rfc5555>.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009, <http://www.rfc-editor.org/info/rfc5568>.
[RFC5568]Koodli，R.，“移动IPv6快速切换”，RFC 55682009年7月<http://www.rfc-editor.org/info/rfc5568>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>.
[RFC5844]Wakikawa，R.和S.Gundavelli，“代理移动IPv6的IPv4支持”，RFC 5844，2010年5月<http://www.rfc-editor.org/info/rfc5844>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 602020，2010年10月<http://www.rfc-editor.org/info/rfc6020>.
[RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, February 2011, <http://www.rfc-editor.org/info/rfc6097>.
[RFC6097]Korhonen，J.和V.Devarapalli，“代理移动IPv6的本地移动锚（LMA）发现”，RFC 60972011年2月<http://www.rfc-editor.org/info/rfc6097>.
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011, <http://www.rfc-editor.org/info/rfc6224>.
[RFC6224]Schmidt，T.，Waehlisch，M.，和S.Krishnan，“代理移动IPv6（PMIPv6）域中支持多播侦听器的基本部署”，RFC 62242011年4月<http://www.rfc-editor.org/info/rfc6224>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Bjorklund，M.，Schoenwaeld，J.，和A.Bierman，“网络配置协议（NETCONF）”，RFC 62412011年6月<http://www.rfc-editor.org/info/rfc6241>.
[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, <http://www.rfc-editor.org/info/rfc6463>.
[RFC6463]Korhonen，J.，Gundavelli，S.，Yokota，H.，和X.Cui，“代理移动IPv6的运行时本地移动锚（LMA）分配支持”，RFC 64632012年2月<http://www.rfc-editor.org/info/rfc6463>.
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, "Proxy Mobile IPv6 Management Information Base", RFC 6475, May 2012, <http://www.rfc-editor.org/info/rfc6475>.
[RFC6475]Keeni，G.，Koide，K.，Gundavelli，S.，和R.Wakikawa，“代理移动IPv6管理信息库”，RFC 64752012年5月<http://www.rfc-editor.org/info/rfc6475>.
[RFC6611] Chowdhury, K. and A. Yegin, "Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario", RFC 6611, May 2012, <http://www.rfc-editor.org/info/rfc6611>.
[RFC6611]Chowdhury，K.和A.Yegin，“集成场景下的移动IPv6（MIPv6）引导”，RFC 66112012年5月<http://www.rfc-editor.org/info/rfc6611>.
[RFC6697] Zorn, G., Wu, Q., Taylor, T., Nir, Y., Hoeper, K., and S. Decugis, "Handover Keying (HOKEY) Architecture Design", RFC 6697, July 2012, <http://www.rfc-editor.org/info/rfc6697>.
[RFC6697]Zorn，G.，Wu，Q.，Taylor，T.，Nir，Y.，Hoeper，K.，和S.Decugis，“切换键控（HOKEY）架构设计”，RFC 66972012年7月<http://www.rfc-editor.org/info/rfc6697>.
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012, <http://www.rfc-editor.org/info/rfc6705>.
[RFC6705]Krishnan，S.，Koodli，R.，Loureiro，P.，Wu，Q.，和A.Dutta，“代理移动IPv6的本地化路由”，RFC 67052012年9月<http://www.rfc-editor.org/info/rfc6705>.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and Y. Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", RFC 7028, September 2013, <http://www.rfc-editor.org/info/rfc7028>.
[RFC7028]Zuniga，JC.，Contreras，LM.，Bernardos，CJ.，Jeon，S.，和Y.Kim，“代理移动IPv6的多播移动路由优化”，RFC 7028，2013年9月<http://www.rfc-editor.org/info/rfc7028>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，RFC 72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7389] Wakikawa, R., Pazhyannur, R., Gundavelli, S., and C. Perkins, "Separation of Control and User Plane for Proxy Mobile IPv6", RFC 7389, October 2014, <http://www.rfc-editor.org/info/rfc7389>.
[RFC7389]Wakikawa，R.，Pazhyannur，R.，Gundavelli，S.，和C.Perkins，“代理移动IPv6的控制和用户平面分离”，RFC 7389，2014年10月<http://www.rfc-editor.org/info/rfc7389>.
[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.401]3GPP，“通用分组无线业务（GPRS）对演进型通用地面无线接入网（E-UTRAN）接入的增强”，3GPP TS 23.401 10.10.012013年3月。
[SDO-3GPP.23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 10.8.0, September 2012.
[SDO-3GPP.23.402]3GPP，“非3GPP接入的架构增强”，3GPP TS 23.402 10.8.01212年9月。
[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.24.303]3GPP，“基于双栈移动IPv6的移动性管理；第3阶段”，3GPP TS 24.303 10.0.012013年6月。
[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.060]3GPP，“通用分组无线业务（GPRS）；通过Gn和Gp接口的GPRS隧道协议（GTP）”，3GPP TS 29.060 3.19.012004年3月。
[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.274]3GPP，“3GPP演进分组系统（EPS）；用于控制平面的演进通用分组无线业务（GPRS）隧道协议（GTPv2-C）；第3阶段”，3GPP TS 29.274 10.11.012013年6月。
[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.281]3GPP，“通用分组无线系统（GPRS）隧道协议用户平面（GTPv1-U）”，3GPP TS 29.281 10.3.012011年9月。
[SDO-3GPP.29.303] 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 29.303 10.4.0, September 2012.
[SDO-3GPP.29.303]3GPP，“域名系统程序；第3阶段”，3GPP TS 29.303 10.4.012年9月。
Contributors
贡献者
This document has benefited due to valuable contributions from
本文件得益于以下方面的宝贵贡献：
Charles E. Perkins Huawei Technologies EMail: charliep@computer.org
Charles E.Perkins华为技术公司电子邮件：charliep@computer.org
who produced a matrix to compare the different mobility protocols and extensions against a list of desired DMM properties. They were useful inputs in the early work of gap analysis. He continued to give suggestions as well as extensively review comments for this document.
他制作了一个矩阵，将不同的移动协议和扩展与所需的DMM属性列表进行比较。它们是差距分析早期工作的有用投入。他继续为这份文件提出建议，并广泛审查意见。
Authors' Addresses
作者地址
Dapeng Liu (editor) China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 China
刘大鹏（编辑）中国移动北京市宣武区宣武门西路28号2单元100053
EMail: liudapeng@chinamobile.com
EMail: liudapeng@chinamobile.com
Juan Carlos Zuniga (editor) InterDigital Communications, LLC 1000 Sherbrooke Street West, 10th floor Montreal, Quebec H3A 3G4 Canada
Juan Carlos Zuniga（编辑）InterDigital Communications，LLC加拿大魁北克省蒙特利尔谢布鲁克西街1000号10楼H3A 3G4
EMail: JuanCarlos.Zuniga@InterDigital.com
URI: http://www.InterDigital.com/
EMail: JuanCarlos.Zuniga@InterDigital.com
URI: http://www.InterDigital.com/
Pierrick Seite Orange 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France
Pierrick Seite Orange 4号，英国石油公司，邮编91226，法国塞森塞维涅35512
EMail: pierrick.seite@orange.com
EMail: pierrick.seite@orange.com
H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024 United States
H Anthony Chan华为技术5340 Legacy Dr.美国德克萨斯州普莱诺3号楼75024
EMail: h.a.chan@ieee.org
EMail: h.a.chan@ieee.org
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
卡洛斯·J·贝尔纳多斯大学卡洛斯三世马德里大道。西班牙马德里勒冈30号大学28911
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/