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
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では、移動ノードは、トポロジー的登録されたモバイルノードのためのすべてのデータを転送するローカル・モビリティ・アンカーで固定されています。転送中に自分のローカルモビリティアンカーの関与なしに2つのモバイルノードのモビリティアクセスゲートウェイとの間でデータパケットの転送を可能にローカライズされたルーティングのセットアップやメンテナンスが考慮されていません。この文書では、プロキシモバイル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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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の）ネットワークベース局所モビリティ管理（のNetLMM）のための基本プロトコルとして[RFC5213]を指定しています。基本プロトコルの範囲は、モバイルノードの（MNの）モバイル・アクセス・ゲートウェイ（MAG）と、その選択されたローカル・モビリティ・アンカー（LMA）との間のトンネルのセットアップおよびメンテナンスをカバーします。データパケットは、常にMNの遠隔通信エンドポイントの場所にかかわらず、MNのMAGとLMAを横断します。 MNが同一のMAGまたは同じプロバイダドメイン内のその対応ノード（CN）として異なるMAGに結合することができるにもかかわらず、それらの通信に関連付けられたパケットはMNのとCNのLMA、トポロジー的に遠く離れて配置することができるが横断しますMNさんとCNのMAG、あるいは別のプロバイダーのドメイン内から。
[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のプロトコル[RFC5213]に記載のモビリティサービスを受信しながら、MNのとCNのMAGとの間のデータパケットの直接ルーティング経路の設定をサポートするためのPMIPv6コンポーネント間のプロトコルメッセージの仕様および関連するプロトコルの動作を含みます。ローカライズされたルーティングの結果として、これらのパケットはMNのCNとのLMA（単数または複数）を横断することなく、2つの関連のMAG間で転送されます。異なるMAGへの1つのまたは両方のノードのハンドオーバーの場合には、ローカライズされたルーティングプロトコルは、ローカライズされたルーティングパスを維持します。関連するプロトコルインタフェースは、MAGとLMAとの間、及びのLMAとの間に、関連のMAGとの間のインターフェースを含むことができます。 PMIPv6ネットワークに登録されていないのCNとローカライズされたルーティングの設定は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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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）のPMIPv6仕様[RFC5213]に記載のモバイル・アクセス・ゲートウェイ（MAG）に取り付けられており、ローカル・モビリティ・アンカー（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はMAGに取り付けられ、PMIPv6の仕様に従って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の介入なしに同じプロバイダのドメインを共有するのMAGに接続されている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のパラダイムに続いて、MNがモビリティシグナリングに関与していないので、ローカライズされたルートを設定するシグナリングを実行することはできません。代わりに、ローカライズされたルーティングのためのソリューションは、ローカライズされたルートが使用され、それに応じてMNとCNからの支援なしに設定し、ローカライズされたルーティング状態の維持を制御するかどうかを調べるために、ネットワーク内の機能を考慮する必要があります。 PMIPv6のネットワークインフラストラクチャと、各ノードがLMAに登録されている場合、これら2つのノード間のデータパケットは常に責任LMA（単数または複数）を横断するに取り付けられた2つのノード間の通信の場合には。少なくともいくつかの展開では、このような通信が有するパケットがLMA（複数可）に、コアネットワークを通過するのではなく、ローカライズされたことから利益を得るであろう。本文書の文脈において、そのような局在化通信はオフロードのLMAからのトラフィックと二つの通信エンドポイントとの間の最適化された転送パスを確立することを含みます。
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.
局所的なルーティングは、同一のMAGに接続されたアクセスリンクに接続されているMNとCNとの間のトラフィックの最適化として、[RFC5213]で理解されています。このような場合には、直接MNとCNとの間のトラフィックを転送MAGは、MAGと仮定すると、この機能（MAG上のEnableMAGLocalRoutingフラグの設定）をサポートすることが可能になるとMNのLMAは、この最適化を強制します。 [RFC5213]はLMAは、ローカル通信のために最適化を適用する方法を指定していません。 MNと通常のIPv6 CNとの間の局所的な転送を維持することは、MNが異なるMAGへのハンドオーバーを行う場合には、より複雑になります。このようなユースケースは、仕様書で考慮して、この問題文の範囲外であるされていません。この文書では、両方のノード、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との間の直接経路の確立は、以下の理由のために有益であることができる：まず、アクセスノードへの通信を制限することにより、MAGを横断するデータトラフィック - LMA経路（ネットワーク）を低減することができます。これは、アクセスとコアの間のトランスポートネットワークは、多くの場合、コストとパフォーマンスの面でのボトルネックであることを考えると、重要です。データはMNとCNが同じMAGに接続されている場合は特に、遅延やパケットロスの面でMNとCNの間で流れ、LMAは遠く離れているMAGから位相幾何学であるために第二に、パフォーマンス上の利点があるかもしれません。 MNとCNが別のMAGに接続されている場合であっても、なくLMAへの輸送ネットワークを横断するよりも、唯一のアクセスネットワークへの通信を制限することに利点があり得ます。それは多くのMAGによって転送されるトラフィックのボトルネックを表すようさらに、局在ルーティングによって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.
この問題文は、PMIPv6のは同じプロバイダのドメインを共有するのMAGに接続するノードを、管理間のローカル通信に焦点を当てています。以下のリストは、複数の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:
全て「」のユースケースは、以下MNとCNの両方がのPMIPv6プロトコルに従ってLMAに登録されていると仮定する。 MAG1は常にMNの現在のプロキシ気付アドレスとして考えられているのに対し、CNは同じMAGまたはMNなど、さまざまなMAGまたはLMAに接続のいずれかになります。次のようによって、これらのトポロジカル違いが示されています。
A[number of MAGs][number of LMAs]
【のMAGの数] [の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）に登録されています。ローカライズされたルーティングの結果は、MNのMAG1及びMAG2 CNの間のパケットの直接転送を可能MAG1と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）が異なるMAG（MAG2）とMNとは異なるLMA（LMA2）（MAG1、LMA1）に接続されています。ローカライズされたルーティングの結果は、MNのMAG1及びMAG2 CNの間のパケットの直接転送を可能MAG1とMAG2でルーティング情報の存在、であるべきです。 CNとMNの位置情報が異なるのLMAに維持されるように、両方のLMAは、ローカライズされたルーティングを設定する手順に関与する必要があります。異なるMAGに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のMNは、モビリティ管理に参加していないので、自分でCNにバインディング登録を行うことができません。むしろ、ネットワークインフラストラクチャ内のエンティティを設定し、直接ルートを維持するためのMNの役割を引き継ぐ必要があります。したがって、のPMIPv6の局所的ルーティングのための解決策は、MNのとCNのLMA（複数可）を通過することなく、データトラフィックのためのローカライズされたルーティングを可能にするために、そのようなMAGと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の両方がそのようなMNの現在のMAGとCNなどのPMIPv6プロトコルに従って別のLMA、ローカライズされたルーティング経路の設定に関連する情報、登録されている場合には、これらの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.
MNとCNの間のルーティングを局在場合oは正常に設定されており、両方のノードがレースに実行することができる、関連するルータに局在化ルーティングのための状態の新たな位置とメンテナンスシグナリング、同時に新たなアクセスルータに移動し、付着します条件状況。ローカライズされたルーティングおよび関連する状態情報のプロビジョニングのためのシグナリングの調整は、異なるネットワークエンティティ、例えば、別のLMAの間で分配される場合、これは場合に起こり得ます。 CNは既に新しいMAGに移動したが、このような場合には、MNのハンドオーバの結果として、MNの位置に関する更新情報は、CNのMAG前に到着することができます。同じことは、MNは、その間に新しいMAGに移動している間、システムは、CNの新しい位置についてMNの以前のMAGを更新することができる他の方向に適用されます。プロトコル・ソリューションは、このような問題を回避または解決するための効率的な例外ハンドオーバーのケースに対処する必要があります。
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とのMAGは関係なく、これらのコンポーネント間の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上の概念的なデータ構造は、ローカライズされたトラフィックを転送するための適切なパラメータを用いて拡張されなければなりません。 MAGは、各MN-CN-ペアのためのルーティング状態を維持し、パケットの完全な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.
既知の制約として、プライベートアドレス空間からアドレスを保持する二つのノードの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（S）および/またはMAG（S））を維持し、ローカライズされたルーティング経路を設定するために必要な関連情報を提供することができます。そのような情報は、1つのまたは両方のモバイルノードが接続し、そのLMA又はMAGに登録されている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、のMAG）は、MNによって縛らとCNが異なるプロバイダドメイン（すなわち、ドメインA、B、C）とMNとの間で分散させることができる、および/またはCN一から移動するのPMIPv6ローミングケース別のものにプロバイダドメイン。ローミングが発生したときにローカライズルーティングをサポートするためには、MNとCNが接続されるのMAGは、同一のプロバイダドメイン内にあることが必要であり、各MAGは、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.
「（CNのPMIPv6ドメインがCNのMAG MAG2 / MAG2）によって特徴付けられ、一方、そのLMA（LMA1）図2に示すようにローミングモデルによれば、MNのPMIPv6ドメインは、そのMAG（MAG1 / MAG1）」によって特徴付けられますそしてそのLMA（LMA2 / LMA2' ）。ローカライズされたルーティングのためのソリューションは、MNとCNが同じPMIPv6ドメインを共有しているか否かについての仮定を取ることはできません。したがって、MAG1 / MAG1' は、MAG2及び/ MAG2' LMA2 / LMA2' とのセキュリティアソシエーションを共有することはできませんは、それぞれ、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：CNのLMA（LMA2' ）はプロバイダドメインBに位置しているMNのMAG（MAG1）、CNのMAG（MAG2）、およびMNのLMA（LMA1）は、同一のドメインA内に配置されています
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'）MNのLMA（LMA1）とCNのLMA（LMA2）はプロバイダドメインAに配置されている間、ドメインCに配置されています
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'）MNのLMA（LMA1）は、プロバイダドメインAに位置し、CNのLMAは、（LMA2' ）に位置している間に、プロバイダのドメインCに配置されていますプロバイダのドメイン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が訪問ドメインにそのホームドメインから移動）そのドメイン内でローミングを許可（MNのLMAが配置されている、例えば、MNのホームドメイン）または異なるドメインにわたることができます。モビリティの間に、CNとMNは自分のMAG間のトラフィックの効率的なルーティングを維持するために、同じプロバイダのドメインの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.
MNおよびCNS以外のネットワークエンティティがローカライズルーティングをセットアップするためにシグナリングを行うため、MIPv6のリターン・ルータビリティ・テスト[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におけるルート最適化のための問題空間の多くの側面には、貢献者のこのグループはSangjinチョン、クリスチャン・フォークト、隆次Wakikawaを含んで2007年11月のNetLMM WGに提出されたのPMIPv6ルート最適化設計目標の文書の文脈で議論されてきました、マルコ・Liebsch、ベーチェットSarikaya、信太杉本、ロングル、アリスQinxia、およびJaehwoonリー。 NetExt WGのため、この問題文の構造と範囲についての彼のコメントのためのラジーブ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グループでの議論の結果を反映しています。彼らのコメントやサポートのための横田英俊、カルロスBernardos、アッシュートッシュDuttaさん、スリGundavelli、Mohana Jeyatharan、Jouni Korhonen、グレン・ソーン、ディルク・フォン・ヒューゴ、フランク夏、Xiangsong崔、およびBasavarajパティルへの感謝は、問題文の品質を向上させるために。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
【Ramphsi 5213] gundavelli、S。、ら、Leunji、K.、Devarapalliは、VEの、Chaudhuriの、K.、およびb。パティル、 "プロキシ・モバイル・20 6"、rphak 5213 2008年8月。
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
[RFC5844] Wakikawa、R.およびS. Gundavelli、 "プロキシモバイル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]ゾルン、G.、ウー、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]ジョンソン、D.、パーキンス、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.、編、Bournelle、J.、チョードリ、K.、Muhanna、A.、およびU.マイヤー。 "直径プロキシモバイルIPv6：ダイアメータサーバとモバイル・アクセス・ゲートウェイとローカル・モビリティ・アンカー相互作用"、 RFC 5779、2010年2月。
Authors' Addresses
著者のアドレス
Marco Liebsch (editor) NEC Laboratories Europe NEC Europe Ltd. Kurfuersten-Anlage 36 69115 Heidelberg Germany
NEC欧州研究所NECヨーロッパ社マルコLiebsch（編集者） Kurfuerstenコンディショニング36 69115ハイデルベルク、ドイツ
Phone: +49 6221 4342146 EMail: liebsch@neclab.eu
電話：+49 6221 4342146 Eメール：liebsch@neclab.eu
Sangjin Jeong ETRI 218 Gajeongno, Yuseong Daejeon 305-700 Korea
SangjinチョンETRI 218 Gajeongno、儒城大田305から700韓国
Phone: +82 42 860 1877 EMail: sjjeong@etri.re.kr
電話：+82 42 860 1877 Eメール：sjjeong@etri.re.kr
Qin Wu Huawei Technologies Co., Ltd 101 Software Avenue, Yuhua District Nanjing 210012 China
技術の共同に蕪湖AでQ。、株式会社101ソフトウェア大通り、Y U地区のNaN北京210012中国を描きます
Phone: +86 25 56623633 EMail: sunseawq@huawei.com
電話：+86 25 56623633 Eメール：sunseawq@huawei.com