[要約] このRFCは、Proxy Mobile IPv6（PMIPv6）のローカライズドルーティングの問題を説明しています。目的は、PMIPv6ネットワーク内でのローカライズドルーティングの問題を特定し、解決策を提案することです。
Internet Engineering Task Force (IETF) M. Liebsch, Ed.
Request for Comments: 6279 NEC
Category: Informational S. Jeong
ISSN: 2070-1721 ETRI
Q. Wu
Huawei
June 2011
Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement
プロキシモバイルIPv6（PMIPv6）ローカライズされたルーティング問題ステートメント
Abstract
概要
Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6.
プロキシモバイルIPv6は、ネットワークベースのモビリティ管理のIETF標準です。プロキシモバイルIPv6では、モバイルノードはローカルモビリティアンカーにトポロジカルに固定されており、登録されたモバイルノードのすべてのデータを転送します。ローカルノードのモバイルノードのモビリティアクセスゲートウェイ間のデータパケットの転送を可能にするローカライズされたルーティングのセットアップとメンテナンスは、転送にローカルモビリティアンカーを関与させることなく、考慮されません。このドキュメントでは、プロキシモバイルIPv6におけるローカライズされたルーティングの問題スペースについて説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6279.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6279で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions and Terminology .....................................3
3. Problem Statement for Localized Routing in PMIPv6 ...............4
3.1. General Observation ........................................4
3.2. Use Cases Analysis .........................................5
3.3. IPv4 Considerations ........................................8
3.3.1. Localized Routing for Communication between
IPv4 Home Addresses .................................8
3.3.2. IPv4 Transport Network Considerations ...............9
4. Functional Requirements for Localized Routing ...................9
5. Roaming Considerations .........................................10
6. Security Considerations ........................................11
7. Acknowledgments ................................................12
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the base protocol for network-based localized mobility management (NetLMM). The scope of the base protocol covers the setup and maintenance of a tunnel between a Mobile Node's (MN's) Mobile Access Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data packets will always traverse the MN's MAG and its LMA, irrespective of the location of the MN's remote communication endpoint. Even though an MN may be attached to the same MAG or a different MAG as its Correspondent Node (CN) within the same provider domain, packets being associated with their communication will traverse the MN's and the CN's LMA, which can be located topologically far away from the MN's and the CN's MAG or even in a separate provider domain.
IETFは、プロキシモバイルIPv6（PMIPv6）[RFC5213]を、ネットワークベースのローカライズモビリティ管理（NetLMM）のベースプロトコルとして指定しています。ベースプロトコルの範囲は、モバイルノード（MN）モバイルアクセスゲートウェイ（MAG）と選択したローカルモビリティアンカー（LMA）の間のトンネルのセットアップとメンテナンスをカバーします。データパケットは、MNのリモート通信エンドポイントの位置に関係なく、常にMNのMAGとそのLMAを通過します。MNは、同じプロバイダードメイン内の特派員ノード（CN）と同じMAGまたは異なるMAGに取り付けられている場合がありますが、通信に関連付けられているパケットはMNとCNのLMAを横断します。MNとCNの雑誌から、または別のプロバイダードメインから。
[RFC5213] addresses the need to enable local routing of traffic between two nodes being attached to the same MAG, but does not specify the complete procedure to establish such localized routing state on the shared MAG.
[RFC5213]は、同じMAGに取り付けられている2つのノード間のトラフィックのローカルルーティングを有効にする必要性に対処しますが、共有MAGにそのような局所的なルーティング状態を確立するための完全な手順を指定していません。
The NetLMM Extensions (NetExt) Working Group has an objective to design a solution for localized routing in PMIPv6. This objective includes the specification of protocol messages and associated protocol operation between PMIPv6 components to support the setup of a direct routing path for data packets between the MN's and the CN's MAG, while both hosts receive mobility service according to the PMIPv6 protocol [RFC5213]. As a result of localized routing, these packets will be forwarded between the two associated MAGs without traversing the MN's and the CN's LMA(s). In cases where one or both nodes hand over to a different MAG, the localized routing protocol maintains the localized routing path. Relevant protocol interfaces may include the interface between associated MAGs, between a MAG and an LMA, and between LMAs. The setup of localized routing with CNs not registered with a PMIPv6 network is out of scope of the NetExt solution and this problem statement.
NetLMM拡張機能（NetExt）ワーキンググループには、PMIPv6のローカライズされたルーティングのソリューションを設計する目的があります。この目的には、PMIPv6コンポーネント間のプロトコルメッセージの仕様と関連するプロトコル操作が含まれ、MNとCNのMAG間のデータパケットの直接ルーティングパスのセットアップをサポートしますが、両方のホストはPMIPv6プロトコル[RFC5213]に従ってモビリティサービスを受けます。ローカライズされたルーティングの結果として、これらのパケットは、MNとCNのLMAを通過することなく、2つの関連するMAGの間に転送されます。片方または両方のノードが異なるMAGに引き渡される場合、ローカライズされたルーティングプロトコルはローカライズされたルーティングパスを維持します。関連するプロトコルインターフェイスには、関連するMAGS、MAGとLMA間、およびLMA間のインターフェイスが含まれる場合があります。PMIPv6ネットワークに登録されていないCNSを使用したローカライズされたルーティングのセットアップは、NetExtソリューションとこの問題ステートメントの範囲外です。
This document analyzes and discusses the problem space of always using the default route through two communicating mobile nodes' local mobility anchors. Furthermore, the problem space of enabling localized routing in PMIPv6 is analyzed and described, while different communication and mobility scenarios are taken into account. Based on the analysis, a list of key functional requirements is provided, serving as input to the design of the protocol solution.
このドキュメントは、2つのモバイルノードのローカルモビリティアンカーを介して常にデフォルトルートを使用するという問題の空間を分析および説明します。さらに、PMIPv6でローカライズされたルーティングを有効にする問題スペースを分析および説明しますが、さまざまな通信およびモビリティシナリオが考慮されます。分析に基づいて、主要な機能要件のリストが提供され、プロトコルソリューションの設計への入力として機能します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document uses the terminology of [RFC5213]. In addition, the following terms are used in the context of this problem statement:
この文書は、[RFC5213]の用語を使用しています。さらに、次の用語は、この問題ステートメントのコンテキストで使用されます。
o Mobile Node (MN): Mobile Node without IP mobility support, which is attached to a Mobile Access Gateway (MAG) and registered with a Local Mobility Anchor (LMA) according to the PMIPv6 specification [RFC5213].
o モバイルノード（MN）：モバイルアクセスゲートウェイ（MAG）に接続され、PMIPv6仕様[RFC5213]に従ってローカルモビリティアンカー（LMA）に登録されているIPモビリティサポートのないモバイルノード。
o Correspondent Node (CN): Correspondent Node according to its definition in [RFC3775] with or without IP mobility support. The CN represents the communication peer of an MN that is attached to a MAG and registered with an LMA according to the PMIPv6 specification.
o 特派員ノード（CN）：IPモビリティサポートの有無にかかわらず、[RFC3775]の定義に従って特派員ノード。CNは、PMIPv6仕様に従ってMAGに取り付けられ、LMAに登録されているMNの通信ピアを表します。
o Localized Routing: Result of signaling to set up routing states on relevant network entities to allow forwarding of data packets between an MN and a CN, which are attached to MAGs sharing the same provider domain, without intervention of the MN's LMA and the CN's LMA in data forwarding.
o ローカライズされたルーティング：関連するネットワークエンティティにルーティング状態を設定するためのシグナリングの結果、MNのLMAとCNのLMAを介入することなく、同じプロバイダードメインを共有するMAGSに接続されているMNとCNの間のデータパケットの転送を許可します。データ転送。
o Localized Routing States: Information for localized routing on relevant forwarding entities on the optimized data path between an MN and a CN. Such information includes route entries and tunnel endpoints and may include further information about the MN and the CN, such as the communicating nodes' Mobile Node Identifier and their assigned Home Network Prefix.
o ローカライズされたルーティング状態：MNとCNの間の最適化されたデータパスに関する関連する転送エンティティに関するローカライズされたルーティングに関する情報。このような情報には、ルートエントリとトンネルエンドポイントが含まれており、通信ノードのモバイルノード識別子や割り当てられたホームネットワークプレフィックスなど、MNとCNに関するさらなる情報が含まれる場合があります。
o Provider Domain: A network domain in which network components are administered by a single authority, e.g., the mobile operator.
o プロバイダードメイン：ネットワークコンポーネントが単一の権限、例えばモバイルオペレーターによって管理されるネットワークドメイン。
The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms for direct communication between an MN and a CN. Mechanisms for route optimization in MIPv6 cannot be directly applied in PMIPv6. Following the paradigm of PMIPv6, MNs are not involved in mobility signaling and hence cannot perform signaling to set up localized routes. Instead, the solution for localized routing must consider functions in the network to find out whether or not a localized route is to be used and then control the setup and maintenance of localized routing states accordingly without any assistance from the MN and the CN. In the case of communication between two nodes attached to the PMIPv6 network infrastructure and where each node is registered with an LMA, data packets between these two nodes will always traverse the responsible LMA(s). At least some deployments would benefit from having such communication localized, rather than having packets traverse the core network to the LMA(s). In the context of this document, such localized communication comprises offloading traffic from LMAs and establishing an optimized forwarding path between the two communication endpoints.
モバイルIPv6（MIPV6）プロトコル[RFC3775]には、MNとCNの間で直接通信するための組み込みメカニズムがあります。MIPV6のルート最適化のメカニズムは、PMIPv6で直接適用することはできません。PMIPv6のパラダイムに従って、MNSはモビリティシグナル伝達に関与していないため、局所的なルートをセットアップするためにシグナリングを実行できません。代わりに、ローカライズされたルーティングのソリューションは、ネットワーク内の関数を検討して、ローカライズされたルートを使用するかどうかを調べ、MNとCNの支援なしにローカライズされたルーティング状態のセットアップとメンテナンスを制御する必要があります。PMIPv6ネットワークインフラストラクチャに接続されている2つのノード間の通信の場合、および各ノードがLMAに登録されている場合、これら2つのノード間のデータパケットは常に責任あるLMAを横断します。少なくとも一部の展開は、パケットをLMAにコアネットワークを通過させるのではなく、このような通信をローカライズすることから恩恵を受けるでしょう。このドキュメントのコンテキストでは、このようなローカライズされた通信は、LMAからのトラフィックをオフロードし、2つの通信エンドポイント間の最適化された転送パスを確立することで構成されています。
Localized routing is understood in [RFC5213] as optimization of traffic between an MN and a CN that are attached to an access link connected to the same MAG. In such a case, the MAG forwards traffic directly between the MN and the CN, assuming the MAG is enabled to support this feature (setting of the EnableMAGLocalRouting flag on the MAG) and the MN's LMA enforces this optimization. [RFC5213] does not specify how an LMA can enforce optimization for such local communication. Maintaining local forwarding between the MN and the regular IPv6 CN gets more complex in the case where the MN performs a handover to a different MAG. Such a use case is not considered in the specification and is out of scope of this problem statement. This document focuses on use cases where both nodes, the MN and the CN, are within a PMIPv6 network and served by an LMA in a domain of LMAs.
局所的なルーティングは、[RFC5213]では、MNと同じMAGに接続されたアクセスリンクに接続されているCN間のトラフィックの最適化として理解されています。そのような場合、MAGはMNとCNの間でトラフィックを直接転送し、MAGがこの機能（MAGのEnableMaglocalRoutingフラグの設定）をサポートできると仮定し、MNのLMAがこの最適化を実施します。[RFC5213]は、LMAがこのようなローカルコミュニケーションの最適化をどのように実施できるかを指定していません。MNと通常のIPv6 CNの間のローカル転送を維持することは、MNが別の雑誌に引き継がれる場合、より複雑になります。このようなユースケースは、仕様では考慮されておらず、この問題声明の範囲外です。このドキュメントは、MNとCNの両方のノードの両方がPMIPv6ネットワーク内で、LMAのドメインでLMAが提供するユースケースに焦点を当てています。
With localized routing, operators have the possibility of offloading traffic from LMAs and from the core network. Establishment of a direct path between the MN's and the CN's MAG can be beneficial for the following reasons: First, by limiting the communication to the access nodes, the data traffic traversing the MAG - LMA path (network) can be reduced. This is significant, considering that the transport network between the access and the core is often the bottleneck in terms of costs and performance. Second, there may be performance benefits for data flows between the MN and the CN in terms of delay and packet loss, especially when the MN and the CN are attached to the same MAG and the LMA is topologically far away from that MAG. Even when the MN and the CN are attached to different MAGs, there could be benefit in limiting the communication to the access network only, rather than traversing the transport network to the LMA. Furthermore, offloading traffic from the LMA by means of localized routing can improve scalability of the LMA, as it represents a bottleneck for traffic being forwarded by many MAGs.
ローカライズされたルーティングにより、オペレーターはLMAとコアネットワークからトラフィックをオフロードする可能性があります。MNとCNの雑誌の間に直接的な経路を確立することは、次の理由で有益です。まず、通信をアクセスノードに制限することにより、MAG -LMAパス（ネットワーク）を通過するデータトラフィックを削減できます。これは、アクセスとコアの間の輸送ネットワークが、多くの場合、コストとパフォーマンスの点でボトルネックであることが多いことを考えると、重要です。第二に、特にMNとCNが同じMAGに取り付けられ、LMAがそのMAGからトポロジカルに離れている場合、遅延とパケット損失の観点から、MNとCNの間のデータフローにパフォーマンスの利点がある場合があります。MNとCNが異なるMAGに接続されている場合でも、輸送ネットワークをLMAに通過するのではなく、アクセスネットワークのみへの通信を制限することに利点があります。さらに、ローカライズされたルーティングによるLMAからのトラフィックをオフロードすると、多くの雑誌によって転送されるトラフィックのボトルネックを表すため、LMAのスケーラビリティが向上する可能性があります。
This problem statement focuses on local communication between PMIPv6 managed nodes, which attach to MAGs sharing the same provider domain. The following list analyzes different use cases, which consider the existence of multiple LMAs. Figure 1 depicts a PMIPv6-based network with two mobility anchors. According to [RFC5213], the MN moves in the PMIPv6 domain being built by its LMA and MAG. The same applies to the CN, which moves in the PMIPv6 domain built by the CN's LMA and MAG. The analysis takes no assumption on whether the MN and the CN share the same PMIPv6 domain or not.
この問題ステートメントは、同じプロバイダードメインを共有するMAGSに付着するPMIPv6マネージドノード間のローカル通信に焦点を当てています。次のリストは、複数のLMAの存在を考慮するさまざまなユースケースを分析します。図1は、2つのモビリティアンカーを備えたPMIPV6ベースのネットワークを示しています。[RFC5213]によると、MNはLMAとMAGによって構築されているPMIPv6ドメインで移動します。同じことがCNのLMAとMAGによって構築されたPMIPv6ドメインで移動するCNにも当てはまります。分析では、MNとCNが同じPMIPV6ドメインを共有するかどうかについての仮定はありません。
Internet Backbone
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+----+------------------+----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: : :
+---+ +---+ +---+
|MN | |CN1| |CN2|
+---+ +---+ +---+
Figure 1: Reference Architecture for Localized Routing in PMIPv6
図1：PMIPv6のローカライズされたルーティングのリファレンスアーキテクチャ
All "A" use cases below assume that both the MN and the CN are registered with an LMA according to the PMIPv6 protocol. Whereas MAG1 is always considered as the MN's current Proxy Care-of Address, the CN can be either connected to the same MAG or to a different MAG or LMA as the MN. Accordingly, these topological differences are denoted as follows:
以下のすべての「A」ユースケースは、MNとCNの両方がPMIPv6プロトコルに従ってLMAに登録されていると仮定します。MAG1は常にMNの現在のプロキシケアオブアドレスと見なされますが、CNは同じMAGまたはMNと同じMAGまたはLMAに接続できます。したがって、これらのトポロジーの違いは次のように示されます。
A[number of MAGs][number of LMAs]
[雑誌の数] [LMAの数]
A11: The MN and the CN (CN1) connect to the same MAG (MAG1) and are registered with the same LMA (LMA). The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMA. [RFC5213] addresses this use case, but does not specify the complete procedure to establish such localized routing state on the shared MAG.
A11：MNとCN（CN1）は同じMAG（MAG1）に接続し、同じLMA（LMA）に登録されています。一般的なMAGは、パケットをLMAに転送せずに、MNとCNの間のデータパケットを直接転送できます。[RFC5213]はこのユースケースに対処しますが、共有MAGにそのような局所的なルーティング状態を確立するための完全な手順を指定していません。
A12: The MN and the CN (CN1) connect to the same MAG (MAG1) and are registered with different LMAs (LMA1 and LMA2). The common MAG may forward data packets between the MN and the CN directly without forwarding any packet to the LMAs. Following the policy of [RFC5213] and enforcement of the setup of a localized forwarding path, potential problems exist in the case where LMA1 and LMA2 differ in their policy to control the MAG.
A12：MNとCN（CN1）は同じMAG（MAG1）に接続し、異なるLMA（LMA1およびLMA2）に登録されています。一般的なMAGは、パケットをLMAに転送せずに、MNとCNの間のデータパケットを直接転送できます。[RFC5213]のポリシーとローカライズされた転送パスのセットアップの実施に従って、LMA1とLMA2がMAGを制御するポリシーが異なる場合には潜在的な問題が存在します。
A21: The CN (CN2) connects to a different MAG (MAG2) than the MN (MAG1), but the MN and the CN are registered with the same LMA (LMA1). The result of localized routing should be the existence of routing information at MAG1 and MAG2, which allows direct forwarding of packets between the MN's MAG1 and the CN's MAG2. As LMA1 is the common anchor for the MN and the CN and maintains location information for both nodes, no major race condition and instability in updating the states for localized routing is expected.
A21：CN（CN2）はMN（MAG1）とは異なるMAG（MAG2）に接続しますが、MNとCNは同じLMA（LMA1）に登録されています。ローカライズされたルーティングの結果は、MAG1とMAG2でのルーティング情報の存在である必要があります。これにより、MNのMAG1とCNのMAG2の間のパケットの直接転送が可能になります。LMA1はMNおよびCNの一般的なアンカーであり、両方のノードの位置情報を維持するため、ローカライズされたルーティングの状態を更新する際の主要な人種状態と不安定性は予想されません。
A22: The CN (CN2) connects to a different MAG (MAG2) and a different LMA (LMA2) than the MN (MAG1, LMA1). The result of localized routing should be the existence of routing information at MAG1 and MAG2, which allows direct forwarding of packets between the MN's MAG1 and the CN's MAG2. As the location information of the CN and the MN is maintained at different LMAs, both LMAs need to be involved in the procedure to set up localized routing. In the case of a handover of the MN and/or the CN to a different MAG, non-synchronized control of updating the states for localized routing may result in race conditions, superfluous signaling, and packet loss.
A22：CN（CN2）は、MN（MAG1、LMA1）とは異なるMAG（MAG2）と異なるLMA（LMA2）に接続します。ローカライズされたルーティングの結果は、MAG1とMAG2でのルーティング情報の存在である必要があります。これにより、MNのMAG1とCNのMAG2の間のパケットの直接転送が可能になります。CNとMNの位置情報が異なるLMAで維持されるため、両方のLMAはローカライズされたルーティングをセットアップするための手順に関与する必要があります。MNおよび/またはCNの別の雑誌への引き渡しの場合、ローカライズされたルーティングのために状態を更新することの非同期制御により、人種条件、余分なシグナル伝達、およびパケット損失が生じる可能性があります。
The following list summarizes general problems with setting up and maintaining localized routing between an MN and a CN. In the context of this problem statement, the MN and the CN are always assumed to be registered at an LMA according to the PMIPv6 protocol [RFC5213].
次のリストは、MNとCNの間のローカライズされたルーティングのセットアップと維持に関する一般的な問題をまとめたものです。この問題声明の文脈では、MNとCNは常にPMIPV6プロトコル[RFC5213]に従ってLMAに登録されると想定されています。
o MNs do not participate in mobility management and hence cannot perform binding registration at a CN on their own. Rather, entities in the network infrastructure must take over the role of MNs to set up and maintain a direct route. Accordingly, a solution for localized routing in PMIPv6 must specify protocol operation between relevant network components, such as between a MAG and an LMA, to enable localized routing for data traffic without traversing the MN's and the CN's LMA(s).
o MNSはモビリティ管理に参加せず、したがって、CNで拘束力のある登録を実行できません。むしろ、ネットワークインフラストラクチャのエンティティは、MNSの役割を引き継ぎ、直接ルートを設定および維持する必要があります。したがって、PMIPv6のローカライズされたルーティングのソリューションは、MAGとLMAの間の関連するネットワークコンポーネント間のプロトコル操作を指定する必要があり、MNとCNのLMAを通過することなくデータトラフィックのローカライズされたルーティングを可能にします。
o In the case where the MN and the CN are both registered with different LMAs according to the PMIPv6 protocol, relevant information for the setup of a localized routing path, such as the current MAG of the MN and the CN, is distributed between these LMAs. This may complicate the setup and stable maintenance of states enabling localized routing.
o MNとCNが両方ともPMIPv6プロトコルに従って異なるLMAに登録されている場合、MNおよびCNの現在のMAGなどのローカライズされたルーティングパスのセットアップに関連する情報がこれらのLMA間に分布しています。これにより、ローカライズされたルーティングを可能にする状態のセットアップと安定したメンテナンスが複雑になる可能性があります。
o In the case where localized routing between an MN and a CN has been successfully set up and both nodes move and attach to a new access router simultaneously, signaling the new location and maintenance of states for localized routing at relevant routers may run into a race condition situation. This can happen in the case where coordination of signaling for localized routing and provisioning of relevant state information is distributed between different network entities, e.g., different LMAs. In such a case, as a result of the MN's handover, updated information about the MN's location may arrive at the CN's previous MAG, while the CN has already moved to a new MAG. The same applies to the other direction, where the system may update the MN's previous MAG about the CN's new location, while the MN has moved to a new MAG in the meantime. The protocol solution must deal with such exceptional handover cases efficiently to avoid or resolve such problems.
o MNとCNの間のローカライズされたルーティングが正常にセットアップされ、両方のノードが移動して新しいアクセスルーターに同時に付着する場合、関連するルーターでのローカライズされたルーティングの新しい場所と状態のメンテナンスが人種条件に陥る可能性があります状況。これは、関連する状態情報のローカライズされたルーティングとプロビジョニングのシグナリングの調整が異なるネットワークエンティティ、例えば異なるLMA間で分散される場合に発生する可能性があります。そのような場合、MNの引き渡しの結果として、MNの位置に関する更新された情報は、CNの以前の雑誌に到達する可能性がありますが、CNはすでに新しい雑誌に移動しています。同じことが他の方向にも当てはまり、システムはCNの新しい場所に関するMNの以前の雑誌を更新する場合がありますが、MNはその間に新しい雑誌に移動しました。プロトコルソリューションは、そのような問題を回避または解決するために、そのような例外的なハンドオーバーケースを効率的に処理する必要があります。
According to [RFC5844], the basic configuration requirements for supporting IPv4 in PMIPv6 are that LMAs and MAGs are both IPv4 and IPv6 enabled. Also, LMAs and MAGs must have a globally unique IPv6 address configured, irrespective of enabled support for IPv6 routing between these components. This requirement should also apply to configuration requirements of localized routing.
[RFC5844]によると、PMIPV6でIPv4をサポートするための基本的な構成要件は、LMAとMAGがIPv4とIPv6の両方の有効であることです。また、LMAとMAGSには、これらのコンポーネント間のIPv6ルーティングの有効化されたサポートに関係なく、グローバルに一意のIPv6アドレスが構成されている必要があります。この要件は、ローカライズされたルーティングの構成要件にも適用する必要があります。
Additional issues emerge when localized routing is considered for PMIPv6 with IPv4 support. These can be classified into two general groups: issues with localized routing between an MN's and a CN's IPv4 Home Addresses, and transport plane issues. The following subsections analyze these two groups.
IPv4サポートを備えたPMIPv6のローカライズされたルーティングが考慮されると、追加の問題が発生します。これらは、MNとCNのIPv4ホームアドレスと輸送機の問題の間のローカライズされたルーティングの問題の2つの一般的なグループに分類できます。次のサブセクションは、これら2つのグループを分析します。
In the case where an LMA and a MAG hold a registration to support IPv4 Home Address mobility for an MN, the MAG and the LMA must support appropriate encapsulation of IPv4 packets. To enable localized routing, the MN's MAG must encapsulate and forward routing path optimized packets to the CN's MAG and needs to ensure that the chosen encapsulation mode is supported by the correspondent MAG. Incompatibility in a selected encapsulation mode causes failure in setting up a localized route.
LMAとMAGがMNのIPv4ホームアドレスモビリティをサポートするために登録を保持している場合、MAGとLMAはIPv4パケットの適切なカプセル化をサポートする必要があります。ローカライズされたルーティングを有効にするには、MNのMAGがCNのMAGに最適化されたパスをカプセル化および転送する必要があり、選択したカプセル化モードが特派員MAGによってサポートされるようにする必要があります。選択したカプセル化モードでの非互換性により、ローカライズされたルートのセットアップに障害が発生します。
When localized routing is used for IPv4 traffic, the conceptual data structures on associated MAGs must be augmented with appropriate parameters for forwarding localized traffic. MAGs may need to maintain a routing state for each MN-CN-pair and make routing decisions for uplink traffic based on the packet's complete IPv4 source and destination address. Hence, conceptual data structures to handle states for localized routes need to comprise this address tuple for unique identification.
IPv4トラフィックにローカライズされたルーティングが使用される場合、関連するMAGの概念データ構造は、ローカライズされたトラフィックを転送するための適切なパラメーターで補強する必要があります。MAGSは、各MN-CN-PAIRのルーティング状態を維持し、パケットの完全なIPv4ソースと宛先アドレスに基づいてアップリンクトラフィックのルーティング決定を行う必要がある場合があります。したがって、ローカライズされたルートの状態を処理するための概念データ構造は、一意の識別のためにこのアドレスタプルを構成する必要があります。
As a known constraint, IPv4 addresses of two nodes that hold addresses from a private address space may overlap. To uniquely identify both nodes, the IPv4 address of the MN and the CN must not overlap. To cope with overlapping address spaces, the localized routing solution could use additional mechanisms to tag and uniquely identify the MN and the CN.
既知の制約として、プライベートアドレス空間からアドレスを保持する2つのノードのIPv4アドレスが重複する場合があります。両方のノードを一意に識別するために、MNとCNのIPv4アドレスが重複してはなりません。オーバーラップアドレススペースに対処するために、ローカライズされたルーティングソリューションは追加のメカニズムを使用して、MNとCNをタグ付けし、一意に識別できます。
The transport network between the LMA and the MAG may be based on IPv6 or IPv4. Deployments may ensure that the same transport mechanism (i.e., IPv6 or IPv4) is used for operational consistency. Similar to the encapsulation requirement stated in the previous section, the IP version used for localized routing is also assumed, by configuration, to be consistent across all MAGs within the associated provider domain. The design of optional mechanisms for negotiating the IP version to use as well as the encapsulation mode to use are outside the scope of the NetExt WG's solution for localized routing.
LMAとMAGの間の輸送ネットワークは、IPv6またはIPv4に基づいている場合があります。展開により、同じ輸送メカニズム（つまり、IPv6またはIPv4）が動作の一貫性に使用されることを保証する場合があります。前のセクションで述べたカプセル化要件と同様に、ローカライズされたルーティングに使用されるIPバージョンは、構成によって、関連するプロバイダードメイン内のすべてのMAGで一貫していると想定されています。使用するIPバージョンをネゴシエートするためのオプションのメカニズムの設計と使用するカプセル化モードは、ローカライズされたルーティング用のNetext WGのソリューションの範囲外です。
Several tasks need to be performed by the network infrastructure components before relevant information for such direct communication is discovered and associated states for localized routing can be set up. The following list summarizes some key functions that need to be performed by the PMIPv6-enabled network infrastructure to substitute mobile nodes in setting up a direct route.
このような直接通信に関連する情報が発見され、ローカライズされたルーティングの関連状態を設定する前に、ネットワークインフラストラクチャコンポーネントによっていくつかのタスクを実行する必要があります。次のリストは、PMIPv6対応ネットワークインフラストラクチャによって実行する必要があるいくつかの重要な関数をまとめて、直接ルートを設定する際にモバイルノードを置き換えます。
o Detection of the possibility to perform localized routing. This function includes looking at a data packet's source and destination address.
o ローカライズされたルーティングを実行する可能性の検出。この機能には、データパケットのソースと宛先アドレスを見ることが含まれます。
o Initiation of a procedure that sets up a localized routing path.
o ローカライズされたルーティングパスを設定する手順の開始。
o Discovery of stateful entities (i.e., the LMA(s) and/or the MAG(s)) that maintain and can provide relevant information needed to set up a localized routing path. Such information may include the routable address of an LMA or MAG, where one or both mobile nodes are connected to and registered with that LMA or MAG.
o ローカライズされたルーティングパスをセットアップするために必要な関連情報を維持し、提供できる、ステートフルエンティティ（つまり、LMAおよび/またはMAG（S））の発見。このような情報には、LMAまたはMAGのルーティング可能なアドレスが含まれる場合があります。このアドレスでは、1つまたは両方のモバイルノードがそのLMAまたはMAGに接続され、登録されています。
o Control in setting up and maintaining (e.g., during handover) the localized routing path. Control is also needed to terminate the use of a localized routing path and to delete associated states, whereas a trigger for the termination may come from a non-PMIPv6- related component.
o ローカライズされたルーティングパスのセットアップと維持（例：ハンドオーバー）の制御。また、ローカライズされたルーティングパスの使用を終了し、関連する状態を削除するためにも制御が必要ですが、終了のトリガーは非PMIPV6関連コンポーネントから生じる場合があります。
o Enforcement of administrative policy rules to localized routing. Such policies allow operators to have further control of the setup of a localized route and enable the possibility to disallow localized routing, for example, to ensure that traffic traverses charging-related functions on the LMA. Explicit authorization of localized routing is, for example, discussed in [PMIP6-LR]. As a further example, mobile-node- and operator-specific policy rules can be established on PMIPv6 components during PMIPv6 bootstrapping according to [RFC5779].
o ローカライズされたルーティングに対する管理ポリシー規則の施行。このようなポリシーにより、オペレーターはローカライズされたルートのセットアップをさらに制御し、たとえばトラフィックがLMAで充電関連の機能を通過するようにローカライズされたルーティングを許可する可能性を可能にします。たとえば、ローカライズされたルーティングの明示的な許可は、[PMIP6-LR]で説明されています。さらに例として、[RFC5779]に従ってPMIPv6ブートストラップ中に、PMIPv6コンポーネントにモバイルノードおよびオペレーター固有のポリシールールを確立できます。
Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g., LMAs, MAGs) tied by the MN and the CN may be distributed between different provider domains (i.e., domain A, B, C) and the MN and/or CN moves from one provider domain to another one. In order to support localized routing when roaming occurs, it is required that MAGs to which the MN and CN connect be within the same provider domain, and each MAG has a security relationship with the corresponding LMA, which maintains the registration of the MN or the CN, respectively.
図2は、PMIPV6コンポーネント（例：LMA、MAGS）がMNによって結ばれ、CNが異なるプロバイダードメイン（つまり、ドメインA、B、C）およびMNおよび/またはCNの移動間に分布できるPMIPV6ローミングケースを示しています。別のドメインからプロバイダードメイン。ローミングが発生したときにローカライズされたルーティングをサポートするために、MNとCNが接続するMAGSが同じプロバイダードメイン内にあるMAGSが必要であり、各MAGは、MNまたはMNの登録を維持する対応するLMAとセキュリティ関係を持つことが必要です。それぞれCN。
According to the roaming model as depicted in Figure 2, the MN's PMIPv6 domain is characterized by its MAG (MAG1/MAG1') and its LMA (LMA1), whereas the CN's PMIPv6 domain is characterized by the CN's MAG (MAG2/MAG2') and its LMA (LMA2/LMA2'). A solution for localized routing cannot take any assumption about whether or not the MN and CN share the same PMIPv6 domain; hence, MAG1/MAG1' may not share a security association with LMA2/LMA2', and MAG2/MAG2' may not share a security association with LMA1, respectively.
図2に示すローミングモデルによれば、MNのPMIPV6ドメインはMAG（MAG1/MAG1 '）とLMA（LMA1）によって特徴付けられますが、CNのPMIPV6ドメインはCNのMAG（MAG2/MAG2'）によって特徴付けられます。およびそのLMA（LMA2/LMA2 '）。ローカライズされたルーティングのソリューションは、MNとCNが同じPMIPV6ドメインを共有するかどうかについての仮定をとることはできません。したがって、MAG1/MAG1 'は、LMA2/LMA2'とセキュリティ関連を共有していない可能性があり、MAG2/MAG2 'はそれぞれLMA1とセキュリティ関連を共有しない場合があります。
It is not required that LMAs, which hold the registration for the MN and the CN, respectively, be part of the same provider domain as the MAGs where the MN and CN attach. When the MN's MAG and LMA belong to different provider domains (A and C), localized routing is subject to policy governing the service level agreements between these domains. The same applies to the provider domains that provide the CN's MAG and LMA. Based on the above requirements, four PMIPv6 roaming and non-roaming cases can be taken into account.
それぞれMNとCNの登録を保持するLMAが、MNとCNが付着するMAGと同じプロバイダードメインの一部であることは必須ではありません。MNのMAGとLMAが異なるプロバイダードメイン（AおよびC）に属している場合、ローカライズされたルーティングは、これらのドメイン間のサービスレベル契約を管理するポリシーの対象となります。同じことが、CNのMAGとLMAを提供するプロバイダードメインにも当てはまります。上記の要件に基づいて、4つのPMIPV6ローミングと非ローミングケースを考慮することができます。
o Case 1: The MN's MAG (MAG1), the CN's MAG (MAG2), the MN's LMA (LMA1), and the CN's LMA (LMA2) are located in the same provider domain A.
o ケース1：MNのMAG（MAG1）、CNのMAG（MAG2）、MNのLMA（LMA1）、およびCNのLMA（LMA2）は、同じプロバイダードメインAにあります。
o Case 2: The MN's MAG (MAG1), the CN's MAG (MAG2), and the MN's LMA (LMA1) are located in the same domain A, while the CN's LMA (LMA2') is located in provider domain B.
o ケース2：MNのMAG（MAG1）、CNのMAG（MAG2）、およびMNのLMA（LMA1）は同じドメインAにあり、CNのLMA（LMA2 '）はプロバイダードメインBにあります。
o Case 3: The MN's MAG (MAG1') and the CN's MAG (MAG2') are located in domain C, while the MN's LMA (LMA1) and the CN's LMA (LMA2) are located in provider domain A.
o ケース3：MNのMAG（MAG1 '）とCNのMAG（MAG2'）はドメインCにあり、MNのLMA（LMA1）とCNのLMA（LMA2）はプロバイダードメインAにあります。
o Case 4: The MN's MAG (MAG1') and the CN's MAG (MAG2') are located in provider domain C, while the MN's LMA (LMA1) is located in provider domain A and the CN's LMA (LMA2') is located in provider domain B.
o ケース4：MNのMAG（MAG1 '）とCNのMAG（MAG2'）はプロバイダードメインCにあり、MNのLMA（LMA1）はプロバイダードメインAにあり、CNのLMA（LMA2 '）はプロバイダーにありますドメインB。
In these roaming cases, the MN can be allowed to roam within its domain (e.g., the MN's home domain in which the MN's LMA is located) or over different domains (e.g., the MN moves from its home domain to a visited domain). During mobility, the CN and MN should remain attached to MAGs of the same provider domain to maintain efficient routing of traffic between their MAGs.
これらのローミングの場合、MNは、そのドメイン（たとえば、MNのLMAが配置されているMNのホームドメイン）または異なるドメイン（例えば、MNがホームドメインから訪問ドメインへと移動する）内をローミングすることができます。モビリティ中、CNとMNは同じプロバイダードメインの雑誌に取り付けられたままで、MAG間のトラフィックの効率的なルーティングを維持する必要があります。
|
+-----+ +-----+ | +-----+
|LMA1 | |LMA2 | | |LMA2'|
+-----+ +-----+ | +-----+
|
|
|
|
+-----+ +-----+ |
|MAG1 | |MAG2 | |
+-----+ +-----+ |
|
|
Provider Domain A | Provider Domain B
------------------------------+-------------------------------
Provider Domain C
+-----+ +-----+
|MAG1'| |MAG2'|
+-----+ +-----+
Figure 2: PMIPv6 Roaming Cases Considered for Localized Routing
図2：PMIPV6ローカライズされたルーティングで検討されているローミングケース
A protocol solution for localized routing in a PMIPv6 network must counter unauthorized change of a routing path. In particular, the control plane for localized routing must preclude the blocking or hijacking of mobile nodes' traffic by malicious or compromised network components. A security solution must support suitable mechanisms for authentication of control plane components of the localized routing functional architecture for both roaming and non-roaming scenarios. Any possibility for Internet hosts to interfere with the localized routing procedure in a malicious manner must be precluded.
PMIPv6ネットワーク内のローカライズされたルーティングのプロトコルソリューションは、ルーティングパスの不正な変更に対抗する必要があります。特に、ローカライズされたルーティング用の制御プレーンは、悪意のあるまたは侵害されたネットワークコンポーネントによるモバイルノードのトラフィックのブロッキングまたはハイジャックを排除する必要があります。セキュリティソリューションは、ローミングシナリオと非ローミングシナリオの両方に対してローカライズされたルーティング機能アーキテクチャの制御プレーンコンポーネントの認証に適したメカニズムをサポートする必要があります。インターネットホストが悪意のある方法でローカライズされたルーティング手順を妨害する可能性を排除する必要があります。
Since network entities other than MNs and CNs perform signaling to set up localized routing, the MIPv6 return routability test [RFC3775] is not suitable to authenticate associated signaling messages in PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate, or to provide sufficient defense against, possible security threats. When PMIPv6 participants are administered within the same domain, infrastructure-based authorization mechanisms, such as IPsec, may be usable to protect signaling for localized routing.
MNS以外のネットワークエンティティとCNSはシグナル伝達を実行してローカライズされたルーティングをセットアップするため、MIPV6 RETURN ROUDabilityテスト[RFC3775]は、PMIPv6の関連シグナル伝達メッセージを認証するのに適していません。PMIPv6のローカライズされたルーティングのソリューションは、セキュリティの脅威の可能性を軽減する、または十分な防御を提供する必要があります。PMIPV6参加者が同じドメイン内で管理されると、IPSECなどのインフラストラクチャベースの認証メカニズムが、ローカライズされたルーティングのシグナリングを保護するために使用できる場合があります。
Existing security associations according to [RFC5213] can be re-used to protect signaling for localized routing on the interface between a MAG and an LMA. In the case where a protocol solution for localized routing in PMIPv6 relies on protocol operation between MAGs, means for protection of signaling between these MAGs must be provided. The same applies for signaling on a possible protocol interface between two LMAs of the same domain.
[RFC5213]による既存のセキュリティ協会は、MAGとLMAの間のインターフェイス上のローカライズされたルーティングのシグナル伝達を保護するために再利用できます。PMIPv6のローカライズされたルーティングのプロトコルソリューションがMAG間のプロトコル操作に依存している場合、これらのMAG間のシグナル伝達の保護を提供する必要があります。同じことが、同じドメインの2つのLMA間の可能なプロトコルインターフェイスのシグナル伝達にも当てはまります。
Many aspects of the problem space for route optimization in PMIPv6 have been discussed in the context of a PMIPv6 Route Optimization Design Goals document, which was submitted to the NetLMM WG in November 2007. This group of contributors includes Sangjin Jeong, Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya, Shinta Sugimoto, Long Le, Alice Qinxia, and Jaehwoon Lee. Many thanks to Rajeev Koodli for his comments about the structure and scope of this problem statement for the NetExt WG.
PMIPv6のルート最適化のための問題スペースの多くの側面は、2007年11月にNetlmm WGに提出されたPMIPV6ルート最適化設計目標ドキュメントのコンテキストで議論されています。、Marco Liebsch、Behcet Sarikaya、Shinta Sugimoto、Long Le、Alice Qinxia、Jaehwoon Lee。Netext WGのこの問題声明の構造と範囲についての彼のコメントについて、Rajeev Koodliに感謝します。
This problem statement reflects the results of the discussion in the NetExt group. Many thanks to Hidetoshi Yokota, Carlos Bernardos, Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn, Dirk von Hugo, Frank Xia, Xiangsong Cui, and Basavaraj Patil for their comments and support to improve the quality of the problem statement.
この問題声明は、Netextグループでの議論の結果を反映しています。横浜のヒデトシ、カルロス・バーナルドス、アシュトシュ・ダッタ、スリ・ガンダヴェッリ、モハナ・ジェヤタラン、ジュニア・コルホーネン、グレン・ゾーン、ダーク・フォン・ヒューゴ、フランク・シア、Xiangsong cui、およびバサヴァラジ・パテルのためにコメントを改善するためのコメントを改善するために、問題に感謝します。。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R。およびS. Gundavelli、「Proxy Mobile IPv6のIPv4サポート」、RFC 5844、2010年5月。
[PMIP6-LR] Zorn, G., Wu, Q., Liebsch, M., and J. Korhonen, "Diameter Support for Proxy Mobile IPv6 Localized Routing", Work in Progress, May 2011.
[PMIP6-LR] Zorn、G.、Wu、Q.、Liebsch、M。、およびJ. Korhonen、「プロキシモバイルIPv6ローカライズされたルーティングの直径サポート」、2011年5月の作業。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC5779] Korhonen, J., Ed., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.
[RFC5779] Korhonen、J.、ed。、Bournelle、J.、Chowdhury、K.、Muhanna、A。、およびU. Meyer、「Diameter Proxy Mobile IPv6：Mobile Access Gateway and Local Mobility Anchor octionaction with Diameter Server」RFC 5779、2010年2月。
Authors' Addresses
著者のアドレス
Marco Liebsch (editor) NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
Marco Liebsch（編集者）Nec Laboratories Europe Nec Europe Ltd. Kurfuersten-Anlage 36 69115ハイデルベルクドイツ
Phone: +49 6221 4342146
EMail: liebsch@neclab.eu
Sangjin Jeong ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea
Sangjin Jeong Etri 218 Gajeongno、Yusong daejeon 305-700 Korea
Phone: +82 42 860 1877
EMail: sjjeong@etri.re.kr
Qin Wu Huawei Technologies Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China
Qin Wu Huawei Technologies Co.、Ltd 101 Software Avenue、Yuhua District Nanjing 210012 China
Phone: +86 25 56623633
EMail: sunseawq@huawei.com