[要約] 要約：RFC 7429は、分散型の移動管理の現在の実践と課題分析に関する情報を提供しています。 目的：このRFCの目的は、分散型の移動管理の現在の状況を理解し、課題や改善のための提案を行うことです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 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ネットワークのセットアップを可能にし、中央に配置されたモビリティアンカーに依存せずに最適な方法でトラフィックが分散されるシナリオを指し、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）とロケーション管理サーバー（LM）の間で交換されます。
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を提供します。 LMは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を提供します。 LMは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のLMとMNのLMcの間の位置情報アグリゲーターとして機能します。 MAPは、HAとそれ自体の間のトンネリング、およびMNとそれ自体の間のトンネリングを可能にするFM機能も提供します。
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.
このセクションでは、分散モビリティ管理の要件を満たすための既存のモビリティプロトコルの導入方法について説明します。この説明では、進化したWi-FiホットスポットなどのIPワイヤレスと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
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) 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.
図1では、3つの一般的な展開オプションが示されています[COMMUNITY-WIFI]。図の左側では、モバイルノードMN1とMN2が顧客の構内にある住宅用ゲートウェイ（RG）に直接接続しています。 RGは、802.11アクセスポイント（AP）機能をホストして、ワイヤレスレイヤー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]の2種類のプロトコルを使用できます。通常、モバイルネットワークのエッジルーターがモビリティアンカー（ローカルモビリティアンカーやホームエージェントなど）の役割を果たします[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モビリティプロトコルをフラットな方法で展開して、アンカー機能とアクセス集約機能を分散させることもできます。次に、分散モビリティ管理環境に既存のモビリティプロトコルを導入するためのいくつかのプラクティスについて説明します。このセクションの分析は、モバイルIPv6 [RFC6275] [RFC5555]、プロキシモバイルIPv6（PMIPv6）[RFC5213] [RFC5844]など、ホストベースまたはネットワークベースの既存のIPモビリティプロトコルに基づくプロトコルソリューションに限定されます。ネットワークモビリティ（NEMO）基本サポートプロトコル[RFC3963]。これらの基本プロトコルソリューションの拡張も考慮されます。分析は、ホストベースとネットワークベースのプラクティスという2つの部分に分かれています。
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 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.
モバイルIPv6（MIPv6）[RFC6275]およびモバイルネットワークをサポートするためのその拡張であるNEMO基本サポートプロトコル（以下、単にNEMOと呼ぶ）[RFC3963]は、よく知られているホストベースのIPモビリティプロトコルです。それらは、モバイルノード（ホストおよびルーター）にモビリティサポートを提供するために、集中型アンカーであるホームエージェント（HA）の機能に依存しています。これらのアプローチでは、ホームエージェントは通常、AF、FM機能、およびロケーション管理サーバー（LM）機能を提供します。モバイルノードは、ロケーション管理クライアント（LMc）機能とFM機能を備えており、HAとそれ自体の間のトンネリングを可能にします。次に、分散モビリティ管理環境で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.
アンカーを分散する1つのアプローチは、複数の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 |
+-----+
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: 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].
分散型モビリティ管理環境にモビリティプロトコルを導入する目的の1つは、集中型アンカーによって引き起こされる次善のルーティングを回避することです。ここでは、モバイルIPv6によって提供されるルート最適化（RO）サポートを使用して、よりフラットなIPデータ転送を実現できます。デフォルトでは、モバイルIPv6とNEMOはいわゆる双方向トンネル（BT）モードを使用します。このモードでは、データトラフィックは常にMNとそのHAの間でカプセル化されてから、他の宛先に転送されます。 ROモードを使用すると、MNはCN上の現在の場所を更新し、CN間の直接パスを使用できます。図2に示す例を使用すると、MN1とMN2はそれぞれCN1とCN2でBTモードを使用し、MN2はCN3でROモードになっています。ただし、ROモードにはいくつかの欠点があります。o ROモードはモバイルIPv6でのみサポートされます。多くの異なる解決策が提案されていますが[RFC4889]、プレフィックスのリターンルーティング可能性テストを拡張することによりもたらされるセキュリティ問題のため、NEMOプロトコル用に標準化されたルート最適化サポートはありません。
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]。したがって、HAは単一障害点のままです。
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モードは、関連するコレスポンデントノードでサポートできる場合に、ホームエージェントを通過するトラフィックを大幅に削減する可能性を提供します。モバイルノードは、同じリンクまたはインターネット内のどこかでCNと通信するときに、気付アドレス（CoA）を直接使用することもできますが、この場合、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.
HMIPv6 [RFC5380]は、図3に示すように、より集中化されていないモビリティ展開を提供するための補完物と見なすことができる別のホストベースのIPモビリティ拡張です。ローカルのモビリティを処理する新しい階層レベルを導入することで、モビリティシグナリングの量を削減し、モバイルIPv6の全体的なハンドオーバーパフォーマンスを向上させることができます。モビリティアンカーポイント（MAP）エンティティは、モバイルノードの近くに配置されたローカルモビリティ処理ノードとして導入されました。 HAのLMと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
| | | | | |
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には2つの異なる一時アドレスがあります。リージョナル気付アドレス（RCoA）とローカル気付アドレス（LCoA）です。 RCoAは1つのMAPにアンカーされます。MAPはローカルホームエージェントの役割を果たし、LCoAはアクセスルーターレベルにアンカーされます。モバイルノードは、ホームエージェントにシグナリングされるCoAとしてRCoAを使用します。したがって、同じ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.
モバイルノードが特定のコレスポンデントノードとの通信のソースアドレスとしてRCoAを直接使用することを決定する場合があるため、HMIPv6を使用すると、ルートの最適化が可能になります。コミュニケーションの寿命。これは、潜在的な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.
さらに、ローカルドメインには複数のMAPが展開されている場合があり、フラット化および分散されたさまざまな種類のHMIPv6展開が可能になります。 HMIPv6仕様は、MNの予想されるモビリティパターンまたはMNとMAP間の距離に基づく選択を含む、MAPの柔軟な選択をサポートしています。
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 Mobility and Multihoming（MOBIKE）[RFC4555]では、モバイルノードがインターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC7296]を介してトラフィックを暗号化し、仮想プライベートネットワーク（VPN）セッションを維持しながら接続ポイントを変更できます。 MOBIKEプロトコルでは、最初に使用された基本接続が失われ、再確立する必要がある場合に、VPNセキュリティアソシエーション（SA）を更新できます。 MOBIKEプロトコルを使用すると、IKEv2再ネゴシエーションを実行する必要がなくなります。モバイルIPv6に対して行われたものと同様の考慮事項をMOBIKEに適用できます。ただし、MOBIKEは、少なくとも1つのエンドポイントのアドレスが比較的安定していて、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]は、ハンドオーバー遅延を最適化する拡張機能です。新しいネットワーク検出のレイテンシを削減するために、ハンドオーバー前の新しいアクセスルーター検出メカニズムを定義します。また、以前のアクセスルータと新しいアクセスルータの間のトンネルを定義して、ハンドオーバー中のパケット損失を減らします。 Candidate Access Router Discovery（CARD）[RFC4066]およびContext Transfer Protocol（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 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.
プロキシモバイルIPv6（PMIPv6）[RFC5213]は、IPv6に指定された主要なネットワークベースのIPモビリティプロトコルです。 Proxy Mobile IPv4 [RFC5844]は、いくつかのIPv4拡張を定義しています。ネットワークベースのIPモビリティプロトコルを使用すると、LMAは通常、AF、FM機能、およびロケーション管理サーバー（LM）機能を提供します。モバイルアクセスゲートウェイ（MAG）は、LMAとトンネリングするためのロケーション管理クライアント（LMc）機能とFM機能を提供します。 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運用を分散化する1つの方法は、複数の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=============>|<----------->|
| | | | | | | |
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]は、3つのケースでプロキシモバイルIPv6で最適なルーティングを可能にします。i）2つの通信するMNが同じMAGおよびLMAに接続されている場合、ii）2つの通信するMNが異なるMAGに接続されているが同じLMAに接続されている場合iii）2つの通信中のMNが同じMAGに接続されているが、LMAが異なる場合。これらの3つのケースでは、トラフィックはエッジでローカルにルーティングされるため、2つのモバイルノード間のデータトラフィックはLMAを通過しないため、何らかの形のパス最適化が提供されます。このアプローチの主な欠点は、MNから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ランタイム割り当てのサポートです。この拡張機能は、Proxy Mobile 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は、第3世代モバイルネットワークとEvolved Packet System（EPS）[SDO-3GPP.23.402]を規定する標準開発組織であり、主にEvolved Packet Core（EPC）と新しい無線アクセスネットワークで構成されます。 LTE（Long Term Evolution）として。
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ネットワークは、モバイルノードにモビリティサポートを提供するためにパケットデータネットワークゲートウェイ（P-GW）アンカーサービスに依存しているため、PMIPv6またはMIPv6を実行するIPワイヤレスネットワークに似ています（図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--------------------| | | |
| | | | | |
+----+ +--------------------+ +---+
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-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
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 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]) .
GPRSトンネリングプロトコル（GTP）[SDO-3GPP.29.060] [SDO-3GPP.29.281] [SDO-3GPP.29.274]は、3GPPネットワーク（S2a、S2b、S5、およびS8インターフェイス）に指定されたネットワークベースのモビリティプロトコルです。 。 PMIPv6と同様に、モバイルノードの関与を必要とせずにモビリティを処理できます。この場合、モバイルノード機能は、Serving Data Gateway（S-GW）、Evolved Packet Data Gateway（ePDG）、またはTrusted Wireless Access Gateway（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（DSMIPv6）[RFC5555]の使用を採用したクライアントベースのモビリティサポートも含まれています。この場合、ユーザー機器（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 |
+-----------+
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の接続ポイントに地理的/トポロジー的に近い一連のGW（下図のS-GWおよびP-GW1）を選択することで行われます。
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 |
+-----+
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は、特にRel-12までの3GPP仕様では、非常に限られたモビリティサポートを備えています。簡単に言うと、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、DSMIPv6、および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アドレスを処理できる必要があるため、1つのギャップがあります。つまり、MNはスマートソースアドレス選択を実行できます（つまり、以前のモビリティアンカーのIPアドレスを非推奨にして、新しいセッション）。さらに、さまざまなモビリティアンカーによって提供されるさまざまなモビリティセッションを管理すると、ネットワークベースのモビリティ管理で問題が発生する可能性があります。この場合、MAGなどのネットワークにあるモバイルクライアントは通常、[RFC5213]のセクション6.2で説明されているように、MNのポリシープロファイルからMNのアンカーを取得します。現在、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で定義されたルーターアドバタイズメントのMAPオプションです。 [SDO-3GPP.29.303]で定義されている機能を提供する3GPPメカニズムがあることに注意してください。
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]。これらのプロトコルは、集中型クライアントIPモビリティ（アクセスの再接続と認証に焦点を当てた）のコンテキストで設計されているため、DMMのコンテキストではいくつかの拡張が必要になる場合があることに注意してください。
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には、ネットワーク層モビリティサポートが必要かどうかを決定する柔軟性が必要です。この要件により、ネットワーク層のモビリティサポートを使用するかどうかを選択できます。次の2つの関数も必要です。
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アドレスを同時に使用し、（アンカーの観点から）セッション/アプリケーションごとに使用するのに最適なアドレスを選択する機能です。 /サービスベース。これには、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 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.
GAP2-1：動的アンカーの割り当て/再配置では、そのようなモビリティサポートを使用するセッションでIPアドレスの連続性が保証されるようにする必要があります（たとえば、一部のシナリオでは、限られたエリア内でローカルにモビリティを提供するだけで十分な場合があります）移動したアンカーでのモバイルノードまたはアプリケーションの）。暗黙的に、ネットワーク層モビリティサポートを使用しているアプリケーションがない場合、DMMは必要なリソースを解放する可能性があります。次に、DMMは、モバイルノードのどのセッションがアクティブで、モビリティサポートを使用しているかを知るために必要になる可能性があります。通常、これはMN（たとえば、その接続マネージャー）によってのみ認識され、モビリティサポートが必要かどうかをIPスタックに示すには、アプリケーションからのソケットAPI拡張などのシグナリングサポートが必要です。これは、モバイルノードのどのセッションがアクティブで、モビリティサポートを使用しているのかを把握していることを意味します。これは通常、MNによってのみ（たとえば、その接続マネージャーによって）知られているものであり、モビリティサポートが必要かどうかをIPスタックに示すために、通常はアプリケーションからのソケットAPI拡張などのシグナリングサポートも必要です。したがって、この知識（の一部）をネットワークに転送したり、ネットワークと共有したりする必要がある場合があります。
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アドレスのアンカー機能を認識しています。現在のメカニズムではMNがIPアドレスのプロパティを認識できないため、これはネットワークベースの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. 展開されたネットワーク/ホストとの共存と異なるネットワーク間の操作性-REQ5
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：管理情報ベース（MIB）オブジェクトは現在、MIPv6の[RFC4295]とPMIPv6の[RFC6475]で定義されています。 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 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.
このドキュメントで特定されたギャップを埋めることを目的としたソリューションは、この要件を満たす必要があります。現時点では、DMMをサポートするために既存のソリューションを使用しても、新しいセキュリティの問題が発生しているようには見えません。たとえば、モバイル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ホームエージェントとしても機能していることを示します）およびMAPオプション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の展開が可能で、最適なものを動的に選択できますが、これには、ポリシープレーン（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：管理情報ベース（MIB）オブジェクトは現在、MIPv6の[RFC4295]とPMIPv6の[RFC6475]で定義されています。 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、「Mobility Support in IPv6」、RFC 6275、2011年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、「Distributed Mobility Managementの要件」、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クラスベースのプレフィックス」、Work in Progress 、draft-bhandari-dhc-class-based-prefix-05、2013年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、 "Service Provider Wi-Fi Services Over Residential Architectures"、Work in Progress、draft-gundavelli-v6ops-community-wifi -svcs-06、2013年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 Standard for Local and Metropolitan Area Network Part 16：Air Interface for Broadband Wireless Access Systems」、IEEE Standard 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。、編、「Multiple Provisioning Domain Architecture」、Work in Progress、draft-ietf-mif-mpvd-arch-08、2015年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 Prefix Properties」、Work in Progress、draft-korhonen-6man-prefix-properties- 2013年7月2日。
[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。、脇川、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、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、「Candidate Access Router Discovery（CARD）」、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、「Context Transfer Protocol（CXTP）」、RFC 4067、2005年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 4225、2005年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、「Mobile IPv6 Management Information Base」、RFC 4295、2006年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 Mobility and Multihoming Protocol（MOBIKE）」、RFC 4555、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 4640、2006年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、「Network Mobility Route Optimization Solution Space Analysis」、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。、「Stream Control Transmission Protocol」、RFC 4960、2007年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 5014、2007年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]ジャレッタ、G。、ケンプ、J。、およびV.デバラパリ、「スプリットシナリオでのモバイル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、「Mobility Header Home Agent Switch Message」、RFC 5142、2008年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.、and B. Patil、 "Proxy Mobile IPv6"、RFC 5213、August 2008、<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]ソリマンH.、カステッルキアC.、エルマルキK.、およびL.ベリエ、「階層型モバイルIPv6（HMIPv6）モビリティ管理」、RFC 5380、2008年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]ソリマンH.、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、2009年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。、「Mobile IPv6 Fast Handovers」、RFC 5568、2009年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]脇川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 6020、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 6097、2011年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 6224、2011年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.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年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、「Runtime Local Mobility Anchor（LMA）Assignment Support for Proxy Mobile IPv6」、RFC 6463、2012年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、「Proxy Mobile IPv6 Management Information Base」、RFC 6475、2012年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、「Mobile IPv6（MIPv6）Bootstrapping for the Integrated Scenario」、RFC 6611、2012年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、「Handover Keying（HOKEY）Architecture Design」、RFC 6697、2012年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 6705、2012年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 6724、2012年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 7296、2014年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.、and C. Perkins、 "Separation of Control and User Plane for Proxy Mobile IPv6"、RFC 7389、October 2014、<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、「進化したユニバーサル地上無線アクセスネットワーク（E-UTRAN）アクセスのための一般的なパケット無線サービス（GPRS）の拡張機能」、3GPP TS 23.401 10.10.0、2013年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.0、2012年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.0、2013年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、「General Packet Radio Service（GPRS）; GPRS Tunneling Protocol（GTP）through Gn and Gp interface」、3GPP TS 29.060 3.19.0、March 2004。
[SDO-3GPP.29.274] 3GPP, "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3", 3GPP TS 29.274 10.11.0, June 2013.
[SDO-3GPP.29.274] 3GPP、「3GPP Evolved Packet System（EPS）; Evolved General Packet Radio Service（GPRS）Tunneling Protocol for Control Plan（GTPv2-C）; Stage 3」、3GPP TS 29.274 10.11.0、June 2013 。
[SDO-3GPP.29.281] 3GPP, "General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0, September 2011.
[SDO-3GPP.29.281] 3GPP、「General Packet Radio System（GPRS）Tunneling Protocol User Plane（GTPv1-U）」、3GPP TS 29.281 10.3.0、2011年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.0、2012年9月。
Contributors
貢献者
This document has benefited due to valuable contributions from
このドキュメントは、
Charles E. Perkins Huawei Technologies EMail: charliep@computer.org
Charles E. Perkins Huawei Technologies EMail：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
DA Pengl IU（編集者）Chinaモバイルユニット2、28 X u 5つのドアを押す、X UA N地区なし北京100053中国
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 Sherbrooke Street West、10階Montreal、ケベックH3A 3G4カナダ
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、rue du Clos Courtel、BP 91226 Cesson-Sevigne 35512 France
EMail: pierrick.seite@orange.com H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3 Plano, TX 75024 United States
Eメール：pierrick.seite@orange.com H Anthony Chan Huawei Technologies 5340 Legacy Dr. Building 3 Plano、TX 75024 United States
EMail: h.a.chan@ieee.org
Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain
カルロスJ.ベルナルドスカルロスIIIマドリッド大学Av。Universidad、30 Leganes、Madrid 28911 Spain
Phone: +34 91624 6236
EMail: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/