Internet Engineering Task Force (IETF) H. Chan, Ed.
Request for Comments: 7333 Huawei Technologies
Category: Informational D. Liu
ISSN: 2070-1721 China Mobile
P. Seite
Orange
H. Yokota
Landis+Gyr
J. Korhonen
Broadcom Communications
August 2014
Internet Engineering Task Force (IETF) H. Chan, Ed.
Request for Comments: 7333 Huawei Technologies
Category: Informational D. Liu
ISSN: 2070-1721 China Mobile
P. Seite
Orange
H. Yokota
Landis+Gyr
J. Korhonen
Broadcom Communications
August 2014
Requirements for Distributed Mobility Management
分布式移动性管理的需求
Abstract
摘要
This document defines the requirements for Distributed Mobility Management (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described.
本文件定义了网络层分布式移动性管理（DMM）的要求。传统无线网络中的分层结构主要导致集中部署移动锚。由于一些无线网络正在逐渐脱离分层结构，因此有一个分布式的移动性管理模型非常有用，在该模型中，流量不需要穿过远离最佳路由的集中部署的移动性锚。还描述了每个需求的动机和解决的问题。
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/rfc7333.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7333.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................2
2. Conventions Used in This Document ...............................4
2.1. Requirements Language ......................................4
2.2. Terminology ................................................4
3. Centralized versus Distributed Mobility Management ..............5
3.1. Centralized Mobility Management ............................6
3.2. Distributed Mobility Management ............................7
4. Problem Statement ...............................................8
5. Requirements ...................................................10
6. Security Considerations ........................................16
7. Contributors ...................................................17
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................4
2.1. Requirements Language ......................................4
2.2. Terminology ................................................4
3. Centralized versus Distributed Mobility Management ..............5
3.1. Centralized Mobility Management ............................6
3.2. Distributed Mobility Management ............................7
4. Problem Statement ...............................................8
5. Requirements ...................................................10
6. Security Considerations ........................................16
7. Contributors ...................................................17
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
In the past decade, a fair number of network-layer mobility protocols have been standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213]. Although these protocols differ in terms of functions and associated message formats, they all employ a mobility anchor to allow a mobile node to remain reachable after it has moved to a different network. Among other tasks that the anchor point performs, the anchor point ensures connectivity by forwarding packets destined to, or sent from, the mobile node. It is a centrally deployed mobility anchor in the sense that the deployed architectures today have a small number of these anchors and the traffic of millions of mobile nodes in an operator network is typically managed by the same anchor. Such a mobility anchor may still have to reside in the subscriber's provider network even when the subscriber is roaming to
在过去十年中，相当多的网络层移动协议已经标准化[RFC6275][RFC5944][RFC5380][RFC6301][RFC5213]。尽管这些协议在功能和相关消息格式方面有所不同，但它们都采用了移动锚，以允许移动节点在移动到不同网络后保持可访问性。在锚定点执行的其他任务中，锚定点通过转发目的地为移动节点或从移动节点发送的分组来确保连接性。它是一个集中部署的移动锚，因为今天部署的体系结构具有少量的移动锚，并且运营商网络中数百万移动节点的流量通常由同一个锚管理。即使在订户漫游到网络时，这样的移动锚仍然必须驻留在订户的提供商网络中
a visited network, in order that certain functions such as charging and billing can be performed more readily by the provider's network. An example provider network is a Third Generation Partnership Project (3GPP) network.
访问网络，以便提供商的网络能够更容易地执行诸如计费和计费之类的某些功能。一个示例提供商网络是第三代合作伙伴项目（3GPP）网络。
Distributed mobility management (DMM) is an alternative to the above-mentioned centralized deployment. The background behind the interest in studying DMM is primarily as follows.
分布式移动性管理（DMM）是上述集中式部署的替代方案。研究DMM的背景主要如下。
(1) More than ever, mobile users are consuming Internet content, including that of local Content Delivery Networks (CDNs). Such traffic imposes new requirements on mobile core networks for data traffic delivery. To prevent exceeding the available core network capacity, service providers need to implement new strategies such as selective IPv4 traffic offload (e.g., [RFC6909], 3GPP Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) work items [TS.23.401]) through alternative access networks such as Wireless Local Area Networks (WLANs) [MOB-DATA-OFFLOAD]. In addition, a gateway selection mechanism takes user proximity into account within the Evolved Packet Core (EPC) [TS.29.303]. However, these mechanisms were not pursued in the past, owing to charging and billing considerations that require solutions beyond the mobility protocol. Consequently, assigning a gateway anchor node from a visited network when roaming to the visited network has only recently been done and is limited to voice services.
(1) 移动用户比以往任何时候都更加消费互联网内容，包括本地内容交付网络（CDN）。这种流量对移动核心网络的数据流量传输提出了新的要求。为了防止超过可用的核心网络容量，服务提供商需要通过无线局域网（WLAN）等替代接入网络实施新策略，如选择性IPv4流量卸载（例如，[RFC6909]、3GPP本地IP访问（LIPA）和选择性IP流量卸载（SIPTO）工作项[TS.23.401]）[MOB-DATA-OFFLOAD]。此外，网关选择机制在演进包核心（EPC）内考虑用户接近度[TS.29.303]。但是，由于计费和计费方面的考虑需要移动协议以外的解决方案，这些机制在过去没有得到采用。因此，在漫游到访问网络时，仅在最近才从访问网络分配网关锚节点，并且仅限于语音服务。
Both traffic offloading and CDN mechanisms could benefit from the development of mobile architectures with fewer hierarchical levels introduced into the data path by the mobility management system. This trend of "flattening" the mobile networks works best for direct communications among peers in the same geographical area. Distributed mobility management in the flattening mobile networks would anchor the traffic closer to the point of attachment of the user.
流量卸载和CDN机制都可以从移动架构的开发中获益，移动管理系统在数据路径中引入的层次更少。这种“扁平化”移动网络的趋势最适合于同一地理区域内的对等方之间的直接通信。扁平化移动网络中的分布式移动性管理将使流量更接近用户的连接点。
(2) Today's mobile networks present service providers with new challenges. Mobility patterns indicate that mobile nodes often remain attached to the same point of attachment for considerable periods of time [LOCATING-USER]. Specific IP mobility management support is not required for applications that launch and complete their sessions while the mobile node is connected to the same point of attachment. However, IP mobility support is currently designed for always-on operation, maintaining all parameters of the context for each mobile subscriber for as long as they are connected to the network. This can result in a waste of resources and unnecessary costs for the service provider. Infrequent node mobility coupled with application
(2) 今天的移动网络给服务提供商带来了新的挑战。移动模式表明，移动节点通常在相当长的一段时间内保持与同一连接点的连接[定位-用户]。当移动节点连接到同一连接点时，启动并完成会话的应用程序不需要特定的IP移动性管理支持。然而，IP移动性支持目前设计用于始终在线操作，只要每个移动用户连接到网络，就可以维护其上下文的所有参数。这可能会导致资源浪费和服务提供商不必要的成本。与应用程序耦合的不频繁节点移动
intelligence suggest that mobility support could be provided selectively, e.g., as described in [DHCPv6-CLASS-BASED-PREFIX] and [IPv6-PREFIX-PROPERTIES], thus reducing the amount of context maintained in the network.
情报表明，可以选择性地提供移动性支持，例如，如[DHCPv6基于类的前缀]和[IPv6前缀属性]中所述，从而减少网络中维护的上下文量。
DMM may distribute the mobility anchors in the data plane in flattening the mobility network such that the mobility anchors are positioned closer to the user; ideally, mobility agents could be collocated with the first-hop router. Facilitated by the distribution of mobility anchors, it may be possible to selectively use or not use mobility protocol support, depending on whether such support is needed or not. DMM can thus reduce the amount of state information that must be maintained in various mobility agents of the mobile network and can then avoid the unnecessary establishment of mechanisms to forward traffic from an old mobility anchor to a new mobility anchor.
DMM可以在平坦移动网络中在数据平面中分布移动锚，使得移动锚定位在更靠近用户的位置；理想情况下，移动代理可以与第一跳路由器并置。通过移动锚的分布，可以有选择地使用或不使用移动协议支持，这取决于是否需要这种支持。因此，DMM可以减少必须在移动网络的各种移动代理中维护的状态信息量，并且可以避免不必要地建立将业务从旧的移动锚转发到新的移动锚的机制。
This document compares distributed mobility management with centralized mobility management in Section 3. The problems that can be addressed with DMM are summarized in Section 4. The mandatory requirements as well as the optional requirements for network-layer distributed mobility management are given in Section 5. Security considerations are mentioned in Section 6.
本文档在第3节中比较了分布式移动性管理和集中式移动性管理。第4节总结了DMM可以解决的问题。第5节给出了网络层分布式移动性管理的强制性要求和可选要求。第6节中提到了安全注意事项。
The problem statement and use cases [DMM-SCENARIO] can be found in [DIST-MOB-REVIEW].
问题陈述和用例[DMM-SCENARIO]可在[DIST-MOB-REVIEW]中找到。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
All of the general mobility-related terms, and their acronyms as used in this document, are to be interpreted as defined in the Mobile IPv6 base specification [RFC6275], the Proxy Mobile IPv6 (PMIPv6) specification [RFC5213], and "Mobility Related Terminology" [RFC3753]. These terms include the following: mobile node (MN), correspondent node (CN), and home agent (HA) as per [RFC6275]; local mobility anchor (LMA) and mobile access gateway (MAG) as per [RFC5213]; and context as per [RFC3753].
本文件中使用的所有通用移动相关术语及其首字母缩略词应按照移动IPv6基本规范[RFC6275]、代理移动IPv6（PMIPv6）规范[RFC5213]和“移动相关术语”[RFC3753]中的定义进行解释。这些术语包括以下内容：根据[RFC6275]，移动节点（MN）、对应节点（CN）和归属代理（HA）；符合[RFC5213]的本地移动锚（LMA）和移动接入网关（MAG）；和上下文符合[RFC3753]。
In addition, this document introduces the following terms:
此外，本文件还介绍了以下术语：
Centrally deployed mobility anchors
集中部署的移动锚
refers to the mobility management deployments in which there are very few mobility anchors and the traffic of millions of mobile nodes in an operator network is managed by the same anchor.
指移动性管理部署，其中移动性锚很少，运营商网络中数百万移动节点的流量由同一个锚管理。
Centralized mobility management
集中式移动性管理
makes use of centrally deployed mobility anchors.
利用集中部署的移动锚。
Distributed mobility management
分布式移动性管理
is not centralized, so that traffic does not need to traverse centrally deployed mobility anchors far from the optimal route.
不是集中的，因此流量不需要穿过远离最佳路线的集中部署的移动锚。
Hierarchical mobile network
分层移动网络
has a hierarchy of network elements arranged into multiple hierarchical levels that are introduced into the data path by the mobility management system.
具有由移动性管理系统引入到数据路径的多个层次结构中的网络元素层次结构。
Flattening mobile network
扁平化移动网络
refers to the hierarchical mobile network that is going through the trend of reducing its number of hierarchical levels.
指的是分层移动网络正在经历其分层数量减少的趋势。
Flatter mobile network
平坦移动网络
has fewer hierarchical levels compared to a hierarchical mobile network.
与分层移动网络相比，具有更少的分层。
Mobility context
移动上下文
is the collection of information required to provide mobility management support for a given mobile node.
是为给定移动节点提供移动性管理支持所需的信息集合。
Mobility management is needed because the IP address of a mobile node may change as the node moves. Mobility management functions may be implemented at different layers of the protocol stack. At the IP (network) layer, mobility management can be client-based or network-based.
需要移动性管理，因为移动节点的IP地址可能随着节点的移动而改变。移动性管理功能可以在协议栈的不同层上实现。在IP（网络）层，移动性管理可以是基于客户端的，也可以是基于网络的。
An IP-layer mobility management protocol is typically based on the principle of distinguishing between a session identifier and a forwarding address and maintaining a mapping between the two. In Mobile IP, the new IP address of the mobile node after the node has moved is the forwarding address, whereas the original IP address before the mobile node moves serves as the session identifier. The location management (LM) information is kept by associating the forwarding address with the session identifier. Packets addressed to the session identifier will first route to the original network, which redirects them using the forwarding address to deliver to the session. Redirecting packets this way can result in long routes. An existing optimization routes directly, using the forwarding address of the host, and as such is a host-based solution.
IP层移动性管理协议通常基于区分会话标识符和转发地址并维护两者之间的映射的原则。在移动IP中，移动节点移动后的新IP地址为转发地址，而移动节点移动前的原始IP地址为会话标识符。通过将转发地址与会话标识符相关联来保持位置管理（LM）信息。发送到会话标识符的数据包将首先路由到原始网络，原始网络使用转发地址重定向数据包，以将其发送到会话。以这种方式重定向数据包可能导致长路由。现有的优化直接路由，使用主机的转发地址，因此是基于主机的解决方案。
The next two subsections explain centralized and distributed mobility management functions in the network.
接下来的两个小节解释了网络中的集中式和分布式移动性管理功能。
In centralized mobility management, the location information in terms of a mapping between the session identifier and the forwarding address is kept at a single mobility anchor, and packets destined to the session identifier are forwarded via this anchor. In other words, such mobility management systems are centralized in both the control plane and the data plane (mobile node IP traffic).
在集中式移动性管理中，在会话标识符和转发地址之间的映射方面的位置信息保持在单个移动性锚处，并且目的地为会话标识符的分组经由该锚转发。换句话说，这种移动性管理系统集中在控制平面和数据平面（移动节点IP业务）中。
Many existing mobility management deployments make use of centralized mobility anchoring in a hierarchical network architecture, as shown in Figure 1. Examples are the home agent (HA) and local mobility anchor (LMA) serving as the anchors for the mobile node (MN) and mobile access gateway (MAG) in Mobile IPv6 [RFC6275] and in Proxy Mobile IPv6 [RFC5213], respectively. Cellular networks, such as 3GPP General Packet Radio System (GPRS) networks and 3GPP Evolved Packet System (EPS) networks, also employ centralized mobility management. In the 3GPP GPRS network, the Gateway GPRS Support Node (GGSN), Serving GPRS Support Node (SGSN), and Radio Network Controller (RNC) constitute a hierarchy of anchors. In the 3GPP EPS network, the Packet Data Network Gateway (P-GW) and Serving Gateway (S-GW) constitute another hierarchy of anchors.
许多现有的移动性管理部署在分层网络体系结构中使用集中式移动性锚定，如图1所示。例如，归属代理（HA）和本地移动锚（LMA）分别作为移动IPv6[RFC6275]和代理移动IPv6[RFC5213]中的移动节点（MN）和移动接入网关（MAG）的锚。蜂窝网络，例如3GPP通用分组无线系统（GPRS）网络和3GPP演进分组系统（EPS）网络，也采用集中式移动性管理。在3GPP GPRS网络中，网关GPRS支持节点（GGSN）、服务GPRS支持节点（SGSN）和无线网络控制器（RNC）构成锚的层次结构。在3GPP EPS网络中，分组数据网络网关（P-GW）和服务网关（S-GW）构成锚的另一层次结构。
3GPP GPRS 3GPP EPS MIP/PMIP
+------+ +------+ +------+
| GGSN | | P-GW | |HA/LMA|
+------+ +------+ +------+
/\ /\ /\
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
+------+ +------+ +------+ +------+ +------+ +------+
| SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG|
+------+ +------+ +------+ +------+ +------+ +------+
/\ /\
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|RNC| |RNC| |RNC| |RNC|
+---+ +---+ +---+ +---+
3GPP GPRS 3GPP EPS MIP/PMIP
+------+ +------+ +------+
| GGSN | | P-GW | |HA/LMA|
+------+ +------+ +------+
/\ /\ /\
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
/ \ / \ / \
+------+ +------+ +------+ +------+ +------+ +------+
| SGSN | | SGSN | | S-GW | | S-GW | |MN/MAG| |MN/MAG|
+------+ +------+ +------+ +------+ +------+ +------+
/\ /\
/ \ / \
/ \ / \
+---+ +---+ +---+ +---+
|RNC| |RNC| |RNC| |RNC|
+---+ +---+ +---+ +---+
Figure 1: Centralized Mobility Management
图1：集中式移动性管理
Mobility management functions may also be distributed in the data plane to multiple networks as shown in Figure 2, so that a mobile node in any of these networks may be served by a nearby function with appropriate forwarding management (FM) capability.
移动性管理功能也可以在数据平面中分布到多个网络，如图2所示，以便这些网络中的任何一个的移动节点都可以由附近具有适当转发管理（FM）能力的功能来服务。
+------+ +------+ +------+ +------+
| FM | | FM | | FM | | FM |
+------+ +------+ +------+ +------+
|
+----+
| MN |
+----+
+------+ +------+ +------+ +------+
| FM | | FM | | FM | | FM |
+------+ +------+ +------+ +------+
|
+----+
| MN |
+----+
Figure 2: Distributed Mobility Management
图2：分布式移动性管理
DMM is distributed in the data plane, whereas the control plane may be either centralized or distributed [DMM-SCENARIO]. The former case implicitly assumes separation of data and control planes as described in [PMIP-CP-UP-SPLIT]. While mobility management can be distributed, it is not necessary for other functions such as subscription management, subscription databases, and network access authentication to be similarly distributed.
DMM分布在数据平面中，而控制平面可以是集中式的，也可以是分布式的[DMM-SCENARIO]。前一种情况隐含地假设数据和控制平面分离，如[PMIP-CP-UP-SPLIT]中所述。虽然移动性管理可以是分布式的，但其他功能（如订阅管理、订阅数据库和网络访问身份验证）不需要类似地分布式。
A distributed mobility management scheme for a flattening mobile network consisting of access nodes is proposed in [DIST-DYNAMIC-MOB]. Its benefits over centralized mobility management have been shown through simulations [DIST-CENTRAL-MOB]. Moreover, the (re)use and extension of existing protocols in the design of both fully distributed mobility management [MIGRATING-HAs] [DIST-MOB-SAE] and partially distributed mobility management [DIST-MOB-PMIP] [DIST-MOB-MIP] have been reported in the literature. Therefore, before designing new mobility management protocols for a future distributed architecture, it is recommended to first consider whether existing mobility management protocols can be extended.
[DIST-DYNAMIC-MOB]提出了一种由接入节点组成的平坦移动网络的分布式移动性管理方案。通过仿真[DIST-CENTRAL-MOB]，它比集中式移动性管理的优势已经得到了证明。此外，文献中还报告了在设计全分布式移动性管理[MIGRATING HAs][DIST-MOB-SAE]和部分分布式移动性管理[DIST-MOB-PMIP][DIST-MOB-MIP]时（重新）使用和扩展现有协议的情况。因此，在为未来的分布式体系结构设计新的移动性管理协议之前，建议首先考虑是否可以扩展现有的移动性管理协议。
The problems that can be addressed with DMM are summarized as follows:
DMM可以解决的问题总结如下：
PS1: Non-optimal routes
PS1：非最佳路线
Forwarding via a centralized anchor often results in non-optimal routes, thereby increasing the end-to-end delay. The problem is manifested, for example, when accessing a nearby server or servers of a Content Delivery Network (CDN), or when receiving locally available IP multicast packets or sending IP multicast packets. (Existing route optimization is only a host-based solution. On the other hand, localized routing with PMIPv6 [RFC6705] addresses only a part of the problem where both the MN and the correspondent node (CN) are attached to the same MAG, and it is not applicable when the CN does not behave like an MN.)
通过集中锚转发通常会导致非最优路由，从而增加端到端延迟。例如，当访问附近的一个或多个内容交付网络（CDN）服务器时，或者当接收本地可用的IP多播分组或发送IP多播分组时，问题就表现出来了。（现有的路由优化只是一种基于主机的解决方案。另一方面，使用PMIPv6[RFC6705]的本地化路由仅解决了MN和对应节点（CN）都连接到同一MAG的部分问题，当CN的行为与MN不同时，它不适用。）
PS2: Divergence from other evolutionary trends in network architectures such as distribution of content delivery
PS2：与网络架构（如内容交付分发）中的其他演进趋势不同
Mobile networks have generally been evolving towards a flatter and flatter network. Centralized mobility management, which is non-optimal with a flatter network architecture, does not support this evolution.
移动网络一般都在向越来越平坦的网络发展。集中式移动性管理在更平坦的网络体系结构中不是最优的，不支持这种演进。
PS3: Lack of scalability of centralized tunnel management and mobility context maintenance
PS3：集中式隧道管理和移动上下文维护缺乏可扩展性
Setting up tunnels through a central anchor and maintaining mobility context for each MN usually requires more concentrated resources in a centralized design, thus reducing scalability. Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities with proper signaling protocol design can avoid increasing the concentrated resources with an increasing number of MNs.
在集中式设计中，通过中心锚建立隧道并维护每个MN的移动性上下文通常需要更集中的资源，从而降低了可伸缩性。通过适当的信令协议设计，在不同的网络实体之间分配隧道维护功能和移动性上下文维护功能，可以避免随着MN数量的增加而增加集中资源。
PS4: Single point of failure and attack
PS4：单点故障和攻击
Centralized anchoring designs may be more vulnerable to a single point of failure and attacks than a distributed system. The impact of a successful attack on a system with centralized mobility management can be far greater as well.
集中式锚定设计可能比分布式系统更容易受到单点故障和攻击。成功的攻击对具有集中移动管理的系统的影响也可能更大。
PS5: Unnecessary mobility support to clients that do not need it
PS5：为不需要的客户提供不必要的移动支持
IP mobility support is usually provided to all MNs. However, it is not always required, and not every parameter of mobility context is always used. For example, some applications or nodes do not need a stable IP address during a handover to maintain session continuity. Sometimes, the entire application session runs while the MN does not change the point of attachment. Besides, some sessions, e.g., SIP-based sessions, can handle mobility at the application layer and hence do not need IP mobility support; it is then unnecessary to provide IP mobility support for such sessions.
IP移动性支持通常提供给所有MN。然而，它并非总是必需的，并且并非总是使用移动上下文的每个参数。例如，某些应用程序或节点在切换期间不需要稳定的IP地址来保持会话连续性。有时，整个应用程序会话在MN不更改连接点的情况下运行。此外，一些会话，例如基于SIP的会话，可以在应用层处理移动性，因此不需要IP移动性支持；因此，没有必要为此类会话提供IP移动性支持。
PS6: Mobility signaling overhead with peer-to-peer communication
PS6：具有对等通信的移动信令开销
Resources may be wasted when mobility signaling (e.g., maintenance of the tunnel, keep-alive signaling, etc.) is not turned off for peer-to-peer communication.
当没有为对等通信关闭移动性信令（例如，隧道维护、保持活动信令等）时，可能会浪费资源。
PS7: Deployment with multiple mobility solutions
PS7：部署多个移动解决方案
There are already many variants and extensions of MIP as well as mobility solutions at other layers. Deployment of new mobility management solutions can be challenging, and debugging difficult, when they coexist with solutions already deployed in the field.
MIP的许多变体和扩展以及其他层的移动性解决方案已经存在。当新的移动性管理解决方案与已在现场部署的解决方案共存时，部署它们可能具有挑战性，并且调试困难。
PS8: Duplicate multicast traffic
PS8：重复多播流量
IP multicast distribution over architectures using IP mobility solutions (e.g., [RFC6224]) may lead to convergence of duplicated multicast subscriptions towards the downstream tunnel entity (e.g., MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels (e.g., a PMIPv6 tunnel), duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem may also exist or be more severe in a distributed mobility environment.
使用IP移动解决方案（例如，[RFC6224]）的架构上的IP多播分发可能导致复制多播订阅向下游隧道实体（例如，PMIPv6中的MAG）收敛。具体地说，当单个移动节点的多播订阅与移动隧道（例如，PMIPv6隧道）耦合时，容易通过不同的上游路径接收重复的多播订阅。在分布式移动环境中，此问题也可能存在或更严重。
Now that distributed mobility management has been compared with centralized deployment (Section 3) and the problems have been described (Section 4), this section identifies the following requirements:
现在，已将分布式移动性管理与集中式部署（第3节）进行了比较，并描述了问题（第4节），本节确定了以下要求：
REQ1: Distributed mobility management
需求1：分布式移动性管理
IP mobility, network access solutions, and forwarding solutions provided by DMM MUST enable traffic to avoid traversing a single mobility anchor far from the optimal route.
DMM提供的IP移动性、网络访问解决方案和转发解决方案必须使流量能够避免穿越远离最佳路由的单个移动性锚。
This requirement on distribution applies to the data plane only. It does not impose constraints on whether the control plane should be distributed or centralized. However, if the control plane is centralized while the data plane is distributed, it is implied that the control plane and data plane need to separate (Section 3.2).
此分布要求仅适用于数据平面。它不会对控制平面是分布式还是集中式施加约束。但是，如果控制平面是集中的，而数据平面是分布式的，则意味着控制平面和数据平面需要分开（第3.2节）。
Motivation: This requirement is motivated by current trends in network evolution: (a) it is cost- and resource-effective to cache contents, and the caching (e.g., CDN) servers are distributed so that each user in any location can be close to one of the servers; (b) the significantly larger number of mobile nodes and flows call for improved scalability; (c) single points of failure are avoided in a distributed system; and (d) threats against centrally deployed anchors, e.g., a home agent and a local mobility anchor, are mitigated in a distributed system.
动机：这一需求是由网络发展的当前趋势推动的：（a）缓存内容具有成本效益和资源效益，缓存（如CDN）服务器是分布式的，因此任何位置的每个用户都可以靠近其中一个服务器；（b） 移动节点和流的数量显著增加，需要提高可伸缩性；（c） 在分布式系统中避免了单点故障；和（d）在分布式系统中减轻对集中部署的锚（例如，归属代理和本地移动锚）的威胁。
This requirement addresses the problems PS1, PS2, PS3, and PS4 described in Section 4.
本要求解决了第4节中描述的问题PS1、PS2、PS3和PS4。
REQ2: Bypassable network-layer mobility support for each application session
REQ2：每个应用程序会话的可绕过网络层移动性支持
DMM solutions MUST enable network-layer mobility, but it MUST be possible for any individual active application session (flow) to not use it. Mobility support is needed, for example, when a mobile host moves and an application cannot cope with a change in the IP address. Mobility support is also needed when a mobile router changes its IP address as it moves together with a host and, in the presence of ingress filtering, an application in the host is interrupted. However, mobility support at the network layer is not always needed; a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix for an active application session.
DMM解决方案必须支持网络层移动性，但必须允许任何单个活动应用程序会话（流）不使用它。例如，当移动主机移动且应用程序无法应对IP地址的变化时，需要移动支持。当移动路由器在与主机一起移动时更改其IP地址，并且在存在入口过滤的情况下，主机中的应用程序被中断时，也需要移动性支持。然而，并非总是需要网络层的移动性支持；移动节点通常可以是静止的，并且还可以在其他层提供移动性支持。因此，并不总是需要为活动的应用程序会话维护稳定的IP地址或前缀。
Different active sessions can also differ in whether network-layer mobility support is needed. IP mobility, network access solutions, and forwarding solutions provided by DMM MUST then provide the possibility of independent handling for each application session of a user or mobile device.
不同的活动会话在是否需要网络层移动性支持方面也可能有所不同。DMM提供的IP移动性、网络接入解决方案和转发解决方案必须为用户或移动设备的每个应用程序会话提供独立处理的可能性。
The handling of mobility management to the granularity of an individual session of a user/device SHOULD need proper session identification in addition to user/device identification.
除了用户/设备标识之外，对用户/设备的单个会话粒度的移动性管理的处理还需要适当的会话标识。
Motivation: The motivation of this requirement is to enable more efficient forwarding and more efficient use of network resources by selecting an IP address or prefix according to whether mobility support is needed and by not maintaining context at the mobility anchor when there is no such need.
动机：该要求的动机是通过根据是否需要移动性支持选择IP地址或前缀，以及在不需要时不在移动性锚点维护上下文，从而实现更高效的转发和更高效地使用网络资源。
This requirement addresses the problems PS5 and PS6 described in Section 4.
本要求解决了第4节中描述的问题PS5和PS6。
REQ3: IPv6 deployment
要求3:IPv6部署
DMM solutions SHOULD target IPv6 as the primary deployment environment and SHOULD NOT be tailored specifically to support IPv4, particularly in situations where private IPv4 addresses and/or NATs are used.
DMM解决方案应将IPv6作为主要部署环境，而不应专门定制以支持IPv4，特别是在使用专用IPv4地址和/或NAT的情况下。
Motivation: This requirement conforms to the general orientation of IETF work. DMM deployment is foreseen as "on the mid- to long-term horizon", when IPv6 is expected to be far more common than today.
动机：该要求符合IETF工作的总体方向。DMM部署预计将处于“中长期”阶段，届时IPv6将比今天更为普遍。
This requirement avoids the unnecessarily complex solution of trying to provide the same level of functionality to both IPv4 and IPv6. Some of the IPv6-specific features are not available for IPv4.
这一要求避免了试图为IPv4和IPv6提供相同级别功能的不必要的复杂解决方案。某些特定于IPv6的功能不适用于IPv4。
REQ4: Existing mobility protocols
需求4：现有移动协议
A DMM solution MUST first consider reusing and extending IETF standard protocols before specifying new protocols.
在指定新协议之前，DMM解决方案必须首先考虑重用和扩展IETF标准协议。
Motivation: Reuse of existing IETF work is more efficient and less error-prone.
动机：重用现有的IETF工作更有效，更不容易出错。
This requirement attempts to avoid the need for development of new protocols and therefore their potential for being time-consuming and error-prone.
这一要求试图避免开发新协议的需要，从而避免其耗时和易出错的可能性。
REQ5: Coexistence with deployed networks/hosts and operability across different networks
要求5：与部署的网络/主机共存，以及跨不同网络的可操作性
A DMM solution may require loose, tight, or no integration into existing mobility protocols and host IP stacks. Regardless of the integration level, DMM implementations MUST be able to coexist with existing network deployments, end hosts, and routers that may or may not implement existing mobility protocols. Furthermore, a DMM solution SHOULD 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.
DMM解决方案可能需要松散、紧密或不集成到现有移动协议和主机IP堆栈中。无论集成级别如何，DMM实现必须能够与现有的网络部署、终端主机和路由器共存，这些网络部署、终端主机和路由器可能实现也可能不实现现有的移动协议。此外，当所需的移动性管理信令、转发和网络访问由它们之间的信任关系允许时，DMM解决方案应该跨不同的网络工作，可能作为单独的管理域操作。
Motivation: to (a) preserve backwards compatibility so that existing networks and hosts are not affected and continue to function as usual, and (b) enable inter-domain operation if desired.
动机：（a）保持向后兼容性，使现有网络和主机不受影响，并继续正常工作；（b）如果需要，启用域间操作。
This requirement addresses the problem PS7 described in Section 4.
该要求解决了第4节中描述的问题PS7。
REQ6: Operation and management considerations
要求6：运营和管理考虑事项
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. Different management protocols are available. For example:
DMM解决方案需要考虑配置设备，监视设备的当前操作状态，并响应影响设备的事件，可能通过修改配置并以稍后可分析的格式存储数据。可以使用不同的管理协议。例如：
(a) the Simple Network Management Protocol (SNMP) [RFC1157], with definitions of standardized management information base (MIB) objects for DMM that allow the monitoring of traffic steering in a consistent manner across different devices
(a) 简单网络管理协议（SNMP）[RFC1157]，具有DMM的标准化管理信息库（MIB）对象的定义，允许以一致的方式跨不同设备监控流量控制
(b) the Network Configuration Protocol (NETCONF) [RFC6241], with definitions of standardized YANG [RFC6020] modules for DMM to achieve a standardized configuration
(b) 网络配置协议（NETCONF）[RFC6241]，定义了DMM的标准化模块[RFC6020]，以实现标准化配置
(c) syslog [RFC5424], which is a one-way protocol allowing a device to report significant events to a log analyzer in a network management system
(c) syslog[RFC5424]，这是一种单向协议，允许设备向网络管理系统中的日志分析器报告重大事件
(d) the IP Flow Information Export (IPFIX) Protocol, which serves as a means for transmitting traffic flow information over the network [RFC7011], with a formal description of IPFIX Information Elements [RFC7012]
(d) IP流量信息导出（IPFIX）协议，作为通过网络传输流量信息的手段[RFC7011]，具有IPFIX信息元素的正式描述[RFC7012]
It is not the goal of this requirements document to impose which management protocol(s) should be used. An inventory of the management protocols and data models is covered in [RFC6632].
本需求文件的目的不是强制规定应使用哪些管理协议。[RFC6632]中介绍了管理协议和数据模型的清单。
The following paragraphs list the operation and management considerations required for a DMM solution; this list of considerations may not be exhaustive and may be expanded according to the needs of the solutions:
以下段落列出了DMM解决方案所需的操作和管理注意事项；该注意事项列表可能并非详尽无遗，可根据解决方案的需要进行扩展：
A DMM solution MUST describe how, and in what types of environments, it can be scalably deployed and managed.
DMM解决方案必须描述如何以及在何种类型的环境中可扩展地部署和管理它。
A DMM solution MUST support mechanisms to test whether the DMM solution is working properly. For example, when a DMM solution employs traffic indirection to support a mobility session, implementations MUST support mechanisms to test that the appropriate traffic indirection operations are in place,
DMM解决方案必须支持测试DMM解决方案是否正常工作的机制。例如，当DMM解决方案采用流量间接寻址来支持移动会话时，实现必须支持测试适当流量间接寻址操作是否到位的机制，
including the setup of traffic indirection and the subsequent teardown of the indirection to release the associated network resources when the mobility session has closed.
包括设置通信量间接寻址，以及在移动性会话关闭时随后拆除间接寻址以释放相关网络资源。
A DMM solution SHOULD expose the operational state of DMM to the administrators of the DMM entities. For example, when a DMM solution employs separation between a session identifier and forwarding address, it should expose the association between them.
DMM解决方案应向DMM实体的管理员公开DMM的运行状态。例如，当DMM解决方案在会话标识符和转发地址之间采用分离时，它应该公开它们之间的关联。
When flow mobility is supported by a DMM solution, the solution SHOULD support means to correlate the flow routing policies and the observed forwarding actions.
当DMM解决方案支持流移动性时，该解决方案应支持将流路由策略与观察到的转发操作关联起来的方法。
A DMM solution SHOULD support mechanisms to check the liveness of a forwarding path. If the DMM solution sends periodic update refresh messages to configure the forwarding path, the refresh period SHOULD be configurable and a reasonable default configuration value proposed. Information collected can be logged or made available with protocols such as SNMP [RFC1157], NETCONF [RFC6241], IPFIX [RFC7011], or syslog [RFC5424].
DMM解决方案应支持检查转发路径活动性的机制。如果DMM解决方案发送定期更新刷新消息以配置转发路径，则刷新周期应可配置，并建议合理的默认配置值。收集的信息可以通过SNMP[RFC1157]、NETCONF[RFC6241]、IPFIX[RFC7011]或syslog[RFC5424]等协议记录或提供。
A DMM solution MUST provide fault management and monitoring mechanisms to manage situations where an update of the mobility session or the data path fails. The system must also be able to handle situations where a mobility anchor with ongoing mobility sessions fails.
DMM解决方案必须提供故障管理和监控机制，以管理移动会话或数据路径更新失败的情况。系统还必须能够处理正在进行的移动会话的移动锚失败的情况。
A DMM solution SHOULD be able to monitor usage of the DMM protocol. When a DMM solution uses an existing protocol, the techniques already defined for that protocol SHOULD be used to monitor the DMM operation. When these techniques are inadequate, new techniques MUST be developed.
DMM解决方案应该能够监控DMM协议的使用情况。当DMM解决方案使用现有协议时，应使用已为该协议定义的技术来监控DMM操作。当这些技术不足时，必须开发新技术。
In particular, the DMM solution SHOULD
特别是，DMM解决方案应
(a) be able to monitor the number of mobility sessions per user, as well as their average duration
(a) 能够监控每个用户的移动会话数量及其平均持续时间
(b) provide an indication of DMM performance, such as
(b) 提供DMM性能的指示，例如
(1) handover delay, which includes the time necessary to reestablish the forwarding path when the point of attachment changes
(1) 切换延迟，包括连接点更改时重新建立转发路径所需的时间
(2) protocol reactivity, which is the time between handover events such as the attachment to a new access point and the completion of the mobility session update
(2) 协议反应性，即切换事件（如连接到新接入点）与完成移动性会话更新之间的时间
(c) provide means to measure the signaling cost of the DMM protocol
(c) 提供测量DMM协议信令成本的方法
(d) if tunneling is used for traffic redirection, monitor
(d) 如果隧道用于流量重定向，请监视
(1) the number of tunnels
(1) 隧道数目
(2) their transmission and reception information
(2) 他们的传输和接收信息
(3) the encapsulation method used, and its overhead
(3) 使用的封装方法及其开销
(4) the security used at the node level
(4) 在节点级别使用的安全性
DMM solutions SHOULD support standardized configuration with NETCONF [RFC6241], using YANG [RFC6020] modules, which SHOULD be created for DMM when needed for such configuration. However, if a DMM solution creates extensions to MIPv6 or PMIPv6, the allowed addition of definitions of management information base (MIB) objects to the MIPv6 MIB [RFC4295] or the PMIPv6 MIB [RFC6475] that are needed for the control and monitoring of the protocol extensions SHOULD be limited to read-only objects.
DMM解决方案应支持NETCONF[RFC6241]的标准化配置，使用YANG[RFC6020]模块，在需要此类配置时，应为DMM创建这些模块。但是，如果DMM解决方案创建了对MIPv6或PMIPv6的扩展，则允许将控制和监视协议扩展所需的管理信息库（MIB）对象的定义添加到MIPv6 MIB[RFC4295]或PMIPv6 MIB[RFC6475]中应限于只读对象。
Motivation: A DMM solution that is designed from the beginning for operability and manageability can implement efficient operations and management solutions.
动机：DMM解决方案从一开始就为可操作性和可管理性而设计，可以实施高效的运营和管理解决方案。
These requirements avoid DMM designs that make operations and management difficult or costly.
这些要求避免了使操作和管理困难或成本高昂的DMM设计。
REQ7: Security considerations
要求7：安全注意事项
A DMM solution MUST 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 MUST NOT introduce new security risks or amplify existing security risks that cannot be mitigated by existing security protocols and mechanisms.
DMM解决方案必须支持确保网络安全和持续安全改进所需的任何安全协议和机制。此外，在设计早期考虑安全性的情况下，DMM解决方案不得引入新的安全风险或放大现有安全协议和机制无法缓解的现有安全风险。
Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on may be launched in a DMM deployment. For instance, an illegitimate node may
动机：DMM部署中可能会发起各种攻击，如模拟、拒绝服务、中间人攻击等。例如，非法节点可能
attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages, thus redirecting traffic from its legitimate path. Consequently, the specific node or nodes to which the traffic is redirected may be under a denial-of-service attack and other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. should be used to protect the DMM entities as they are already used to protect existing networks and existing mobility protocols defined in the IETF. However, if a candidate DMM solution is such that these existing security mechanisms/protocols are unable to provide sufficient security protection even when properly used, then that candidate DMM solution is causing uncontrollable security problems.
尝试访问提供DMM的网络。另一个例子是，恶意节点可以伪造大量信令消息，从而从其合法路径重定向流量。因此，流量重定向到的一个或多个特定节点可能受到拒绝服务攻击，而其他节点不接收其流量。因此，应使用提供访问控制、完整性、认证、授权、机密性等的安全机制/协议来保护DMM实体，因为它们已被用于保护IETF中定义的现有网络和现有移动协议。但是，如果候选DMM解决方案使得这些现有安全机制/协议即使在正确使用时也无法提供足够的安全保护，则该候选DMM解决方案会导致无法控制的安全问题。
This requirement prevents a DMM solution from introducing uncontrollable problems of potentially insecure mobility management protocols that make deployment infeasible, because platforms conforming to such protocols are at risk for data loss and numerous other dangers, including financial harm to the users.
这一要求防止DMM解决方案引入潜在不安全的移动性管理协议的不可控问题，从而使部署变得不可行，因为符合此类协议的平台存在数据丢失和许多其他危险的风险，包括对用户的财务伤害。
REQ8: Multicast considerations
请求8：多播注意事项
DMM SHOULD enable multicast solutions to be developed to avoid network inefficiency in multicast traffic delivery.
DMM应该能够开发多播解决方案，以避免多播流量交付中的网络效率低下。
Motivation: Existing multicast deployments have been introduced after completing the design of the reference mobility protocol, often leading to network inefficiency and non-optimal forwarding for the multicast traffic. DMM should instead consider multicast early in the process, so that the multicast solutions can better consider the efficient nature of multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entities). The multicast solutions should then avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers.
动机：现有的多播部署是在完成参考移动协议的设计之后引入的，通常会导致网络效率低下和多播流量的非最佳转发。相反，DMM应该在过程中尽早考虑多播，以便多播解决方案可以更好地考虑组播业务传输的有效性（如对下游隧道实体的重复组播订阅）。然后，多播解决方案应避免通过支持多播的接入路由器上的专用（隧道）接口将所有IP多播流量的管理限制到单个主机。
This requirement addresses the problems PS1 and PS8 described in Section 4.
本要求解决了第4节中描述的问题PS1和PS8。
Please refer to REQ7 in Section 5.
请参考第5节中的要求7。
This requirements document is a joint effort among numerous participants working as a team. Valuable comments and suggestions in various reviews from the following area directors and IESG members have also contributed to many improvements: Russ Housley, Catherine Meadows, Adrian Farrel, Barry Leiba, Alissa Cooper, Ted Lemon, Brian Haberman, Stephen Farrell, Joel Jaeggli, Alia Atlas, and Benoit Claise.
本需求文件是众多团队成员的共同努力。以下区域主管和IESG成员在各种审查中提出的宝贵意见和建议也促进了许多改进：Russ Housley、Catherine Meadows、Adrian Farrel、Barry Leiba、Alissa Cooper、Ted Lemon、Brian Haberman、Stephen Farrell、Joel Jaeggli、Alia Atlas和Benoit Claise。
In addition to the authors, each of the following has made very significant and important contributions to this work:
除了作者之外，以下每一位都对这项工作做出了非常重要的贡献：
Charles E. Perkins Huawei Technologies EMail: charliep@computer.org
Charles E.Perkins华为技术公司电子邮件：charliep@computer.org
Melia Telemaco Alcatel-Lucent Bell Labs EMail: telemaco.melia@googlemail.com
Melia Telemaco阿尔卡特朗讯贝尔实验室电子邮件：Telemaco。melia@googlemail.com
Elena Demaria Telecom Italia via G. Reiss Romoli, 274, Torino, 10148, Italy EMail: elena.demaria@telecomitalia.it
Elena Demaria Telecom Italia通过G.Reiss Romoli，274，都灵，10148，意大利电子邮件：Elena。demaria@telecomitalia.it
Jong-Hyouk Lee Sangmyung University, Korea EMail: jonghyouk@smu.ac.kr
韩国郑孝利三明大学电子邮件：jonghyouk@smu.ac.kr
Kostas Pentikousis EICT GmbH EMail: k.pentikousis@eict.de
Kostas Pentikousis EICT GmbH电子邮件：k。pentikousis@eict.de
Tricci So ZTE EMail: tso@zteusa.com
中兴通讯电子邮箱：tso@zteusa.com
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30, Leganes, Madrid 28911, Spain EMail: cjbc@it.uc3m.es
卡洛斯·J·贝尔纳多斯大学卡洛斯三世马德里大道。西班牙马德里勒加内斯30号大学28911电子邮件：cjbc@it.uc3m.es
Peter McCann Huawei Technologies EMail: Peter.McCann@huawei.com
Peter McCann华为技术公司电子邮件：Peter。McCann@huawei.com
Seok Joo Koh Kyungpook National University, Korea EMail: sjkoh@knu.ac.kr
韩国Seok Joo Koh Kyungpook国立大学电子邮件：sjkoh@knu.ac.kr
Wen Luo ZTE No. 68, Zijinhua Rd, Yuhuatai District, Nanjing, Jiangsu 210012, China EMail: luo.wen@zte.com.cn
中国江苏省南京市雨花台区紫金华路68号文罗中兴通讯210012电子邮件：罗。wen@zte.com.cn
Sri Gundavelli Cisco sgundave@cisco.com
斯里冈达维利思科sgundave@cisco.com
Hui Deng China Mobile EMail: denghui@chinamobile.com
邓晖中国移动邮箱：denghui@chinamobile.com
Marco Liebsch NEC Laboratories Europe EMail: liebsch@neclab.eu
Marco Liebsch NEC实验室欧洲电子邮件：liebsch@neclab.eu
Carl Williams MCSR Labs EMail: carlw@mcsr-labs.org
Carl Williams MCSR实验室电子邮件：carlw@mcsr-实验室网站
Seil Jeon Instituto de Telecomunicacoes, Aveiro EMail: seiljeon@av.it.pt
Seil Jeon电信研究所，Aveiro电子邮件：seiljeon@av.it.pt
Sergio Figueiredo Universidade de Aveiro EMail: sfigueiredo@av.it.pt
塞尔吉奥·菲盖雷多阿维罗大学电子邮件：sfigueiredo@av.it.pt
Stig Venaas EMail: stig@venaas.com
Stig Venaas电子邮件：stig@venaas.com
Luis Miguel Contreras Murillo Telefonica I+D EMail: lmcm@tid.es
Luis Miguel Contreras Murillo Telefonica I+D电子邮件：lmcm@tid.es
Juan Carlos Zuniga InterDigital EMail: JuanCarlos.Zuniga@InterDigital.com
胡安·卡洛斯·祖尼加（JuanCarlos Zuniga）跨指电子邮件：JuanCarlos。Zuniga@InterDigital.com
Alexandru Petrescu EMail: alexandru.petrescu@gmail.com
Alexandru Petrescu电子邮件：Alexandru。petrescu@gmail.com
Georgios Karagiannis University of Twente EMail: g.karagiannis@utwente.nl
乔治斯卡拉吉安尼斯屯特大学电子邮件：G。karagiannis@utwente.nl
Julien Laganier Juniper EMail: julien.ietf@gmail.com
Julien Laganier Juniper电子邮件：Julien。ietf@gmail.com
Wassim Michel Haddad Ericsson EMail: Wassim.Haddad@ericsson.com
Wassim Michel Haddad Ericsson电子邮件：Wassim。Haddad@ericsson.com
Dirk von Hugo Deutsche Telekom Laboratories EMail: Dirk.von-Hugo@telekom.de
德国电信实验室电子邮件：Dirk.von-Hugo@telekom.de
Ahmad Muhanna Award Solutions EMail: asmuhanna@yahoo.com
Ahmad Muhanna Award Solutions电子邮件：asmuhanna@yahoo.com
Byoung-Jo Kim ATT Labs EMail: macsbug@research.att.com
Byoung Jo Kim ATT Labs电子邮件：macsbug@research.att.com
Hassan Ali-Ahmad Orange EMail: hassan.aliahmad@orange.com
哈桑·阿里·艾哈迈德·奥兰治电子邮件：哈桑。aliahmad@orange.com
Alper Yegin Samsung EMail: alper.yegin@partner.samsung.com
Alper-Yegin三星电子邮箱：Alper。yegin@partner.samsung.com
David Harrington Effective Software EMail: ietfdbh@comcast.net
David Harrington有效软件电子邮件：ietfdbh@comcast.net
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.，和J.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.和M.Kojo，“机动性相关术语”，RFC 3753，2004年6月。
[RFC4295] Keeni, G., Koide, K., Nagami, K., and S. Gundavelli, "Mobile IPv6 Management Information Base", RFC 4295, April 2006.
[RFC4295]Keeni，G.，Koide，K.，Nagami，K.，和S.Gundavelli，“移动IPv6管理信息库”，RFC 42952006年4月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020]Bjorklund，M.“YANG-网络配置协议（NETCONF）的数据建模语言”，RFC6020，2010年10月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241]Enns，R.，Bjorklund，M.，Schoenwaeld，J.，和A.Bierman，“网络配置协议（NETCONF）”，RFC 62412011年6月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6475] Keeni, G., Koide, K., Gundavelli, S., and R. Wakikawa, "Proxy Mobile IPv6 Management Information Base", RFC 6475, May 2012.
[RFC6475]Keeni，G.，Koide，K.，Gundavelli，S.，和R.Wakikawa，“代理移动IPv6管理信息库”，RFC 6475，2012年5月。
[RFC6632] Ersue, M. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, June 2012.
[RFC6632]Ersue，M.和B.Claise，“IETF网络管理标准概述”，RFC 6632，2012年6月。
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
[RFC7011]Claise，B.，Trammell，B.，和P.Aitken，“流量信息交换的IP流量信息导出（IPFIX）协议规范”，STD 77，RFC 7011，2013年9月。
[RFC7012] Claise, B. and B. Trammell, "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012]Claise，B.和B.Trammell，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，2013年9月。
[DHCPv6-CLASS-BASED-PREFIX] Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class based prefix", Work in Progress, July 2013.
[DHCPv6基于类前缀]班达里，S.，哈尔瓦西亚，G.，冈达维利，S.，邓，H.，蒂布特，L.，科霍宁，J.，和I.法雷尔，“DHCPv6基于类前缀”，在建工程，2013年7月。
[DIST-CENTRAL-MOB] Bertin, P., Bonjour, S., and J-M. Bonnin, "Distributed or Centralized Mobility?", Proceedings of the 28th IEEE Conference on Global Telecommunications (GlobeCom), December 2009.
[DIST-CENTRAL-MOB]Bertin，P.，Bonjour，S.，和J-M.Bonnin，“分布式还是集中式移动？”，第28届IEEE全球电信会议论文集，2009年12月。
[DIST-DYNAMIC-MOB] Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed Dynamic Mobility Management Scheme Designed for Flat IP Architectures", Proceedings of 3rd International Conference on New Technologies, Mobility and Security (NTMS), 2008.
[DIST-DYNAMIC-MOB]Bertin，P.，Bonjour，S.，和J-M.Bonnin，“为平面IP架构设计的分布式动态移动性管理方案”，第三届新技术、移动性和安全国际会议记录，2008年。
[DIST-MOB-MIP] Chan, H., "Distributed Mobility Management with Mobile IP", Proceedings of IEEE International Communication Conference (ICC) Workshop on Telecommunications: from Research to Standards, June 2012.
[DIST-MOB-MIP]Chan，H.，“移动IP分布式移动性管理”，IEEE国际通信会议（ICC）电信研讨会论文集：从研究到标准，2012年6月。
[DIST-MOB-PMIP] Chan, H., "Proxy Mobile IP with Distributed Mobility Anchors", Proceedings of GlobeCom Workshop on Seamless Wireless Mobility, December 2010.
[DIST-MOB-PMIP]Chan，H.，“具有分布式移动锚的代理移动IP”，GlobeCom无缝无线移动研讨会论文集，2010年12月。
[DIST-MOB-REVIEW] Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu, "Distributed and Dynamic Mobility Management in Mobile Internet: Current Approaches and Issues", Journal of Communications, vol. 6, no. 1, pp. 4-15, February 2011.
[DIST-MOB-REVIEW]Chan，H.，Yokota，H.，Xie，J.，Seite，P.，和D.Liu，“移动互联网中的分布式和动态移动性管理：当前方法和问题”，《通信杂志》，第6卷，第1期，第4-15页，2011年2月。
[DIST-MOB-SAE] Fischer, M., Andersen, F., Kopsel, A., Schafer, G., and M. Schlager, "A Distributed IP Mobility Approach for 3G SAE", Proceedings of the 19th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), 2008.
[DIST-MOB-SAE]Fischer，M.，Andersen，F.，Kopsel，A.，Schafer，G.，和M.Schlager，“3G SAE的分布式IP移动性方法”，第19届个人、室内和移动无线电通信国际研讨会论文集，2008年。
[DMM-SCENARIO] Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case scenarios for Distributed Mobility Management", Work in Progress, October 2010.
[DMM-场景]横田，H.，塞特，P.，德马里亚，E.，和Z.曹，“分布式移动性管理的用例场景”，正在进行的工作，2010年10月。
[IPv6-PREFIX-PROPERTIES] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Properties", Work in Progress, July 2013.
[IPv6前缀属性]Korhonen，J.，Patil，B.，Gundavelli，S.，Seite，P.，和D.Liu，“IPv6前缀属性”，正在进行的工作，2013年7月。
[LOCATING-USER] Kirby, G., "Locating the User", Communications International, 1995.
[定位用户]Kirby，G.“定位用户”，国际通信，1995年。
[MIGRATING-HAs] Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home Agents Towards Internet-scale Mobility Deployments", Proceedings of the ACM 2nd CoNEXT Conference on Future Networking Technologies, December 2006.
[迁移]Wakikawa，R.，Valadon，G.，和J.Murai，“将家庭代理迁移到互联网规模的移动部署”，ACM第二届未来网络技术大会论文集，2006年12月。
[MOB-DATA-OFFLOAD] Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile Data Offloading: How Much Can WiFi Deliver?", Proceedings of the ACM SIGCOMM 2010 Conference, 2010.
[MOB-DATA-OFFLOAD]Lee，K.，Lee，J.，Yi，Y.，Rhee，I.，和S.Chong，“移动数据卸载：WiFi能提供多少？”，ACM SIGCOMM 2010年会议记录，2010年。
[PMIP-CP-UP-SPLIT] Wakikawa, R., Pazhyannur, R., and S. Gundavelli, "Separation of Control and User Plane for Proxy Mobile IPv6", Work in Progress, July 2013.
[PMIP-CP-UP-SPLIT]Wakikawa，R.，Pazhyannur，R.，和S.Gundavelli，“代理移动IPv6的控制和用户平面分离”，正在进行的工作，2013年7月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010.
[RFC5944]Perkins，C.，“IPv4的IP移动支持，修订版”，RFC 59442010年11月。
[RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains", RFC 6224, April 2011.
[RFC6224]Schmidt，T.，Waehlisch，M.，和S.Krishnan，“代理移动IPv6（PMIPv6）域中支持多播侦听器的基本部署”，RFC 62242011年4月。
[RFC6301] Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility Support in the Internet", RFC 6301, July 2011.
[RFC6301]Zhu，Z.，Wakikawa，R.，和L.Zhang，“互联网移动支持调查”，RFC 63012011年7月。
[RFC6705] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, "Localized Routing for Proxy Mobile IPv6", RFC 6705, September 2012.
[RFC6705]Krishnan，S.，Koodli，R.，Loureiro，P.，Wu，Q.，和A.Dutta，“代理移动IPv6的本地化路由”，RFC 67052012年9月。
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. Koodli, "IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6", RFC 6909, April 2013.
[RFC6909]Gundavelli，S.，Zhou，X.，Korhonen，J.，Feige，G.，和R.Koodli，“代理移动IPv6的IPv4流量卸载选择器选项”，RFC 69092013年4月。
[TS.23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 12.5.0, June 2014, <http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS.23.401]3GPP，“通用分组无线业务（GPRS）增强，用于演进通用地面无线接入网（E-UTRAN）接入”，3GPP TS 23.401 12.5.012014年6月<http://www.3gpp.org/ftp/Specs/html-info/23401.htm>.
[TS.29.303] 3GPP, "Domain Name System Procedures; Stage 3", 3GPP TS 29.303 12.3.0, June 2014, <http://www.3gpp.org/ftp/ Specs/html-info/29303.htm>.
[TS.29.303]3GPP，“域名系统程序；第3阶段”，3GPP TS 29.303 12.3.012014年6月<http://www.3gpp.org/ftp/ Specs/html info/29303.htm>。
Authors' Addresses
作者地址
H. Anthony Chan (editor) Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024 USA
H.Anthony Chan（编辑）华为技术5340 Legacy Dr.Building 3 Plano，TX 75024美国
EMail: h.a.chan@ieee.org
EMail: h.a.chan@ieee.org
Dapeng Liu China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 China
中国北京市宣武区宣武门西大街28号刘大鹏中国移动2单元，邮编100053
EMail: liudapeng@chinamobile.com
EMail: liudapeng@chinamobile.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
Hidetoshi Yokota Landis+Gyr
横田英寿
EMail: hidetoshi.yokota@landisgyr.com
EMail: hidetoshi.yokota@landisgyr.com
Jouni Korhonen Broadcom Communications Porkkalankatu 24 Helsinki FIN-00180 Finland
Jouni Korhonen Broadcom Communications Porkkalankatu 24赫尔辛基FIN-00180芬兰
EMail: jouni.nospam@gmail.com
EMail: jouni.nospam@gmail.com