RFC4889 日本語訳
4889 Network Mobility Route Optimization Solution Space Analysis. C.Ng, F. Zhao, M. Watari, P. Thubert. July 2007. (Format: TXT=95880 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Ng
Request for Comments: 4889 Panasonic Singapore Labs
Category: Informational F. Zhao
UC Davis
M. Watari
KDDI R&D Labs
P. Thubert
Cisco Systems
July 2007
コメントを求めるワーキンググループC.ウン要求をネットワークでつないでください: 4889年のパナソニックシンガポール研究室カテゴリ: 情報のF.の研究開発研究室P.ThubertシスコシステムズチャオUCデイヴィスM.亘理KDDI2007年7月
Network Mobility Route Optimization Solution Space Analysis
ネットワーク移動性経路最適化ソリューション宇宙分析
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the Mobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization.
モバイルネットワークが離れているとき、現在のNetwork Mobility(ネモ)の基本的なSupportと共に、Network Nodesと、そして、モバイルNetwork NodesからのすべてのコミュニケーションがモバイルRouterとホームのエージェント(MRHA)トンネルを通らなければなりません。 多くの場合、これは増加する長さのパケットルートと増加するパケット遅れをもたらします。 これらの限界を克服するために、1つはネモのために、Route Optimization(RO)に変わらなければならないかもしれません。 このメモは、Route Optimizationの様々なタイプをネモに記録して、ネモRoute Optimizationの異なった局面で利益と見返りを探ります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Benefits of NEMO Route Optimization . . . . . . . . . . . . . 4
3. Different Scenarios of NEMO Route Optimization . . . . . . . . 6
3.1. Non-Nested NEMO Route Optimization . . . . . . . . . . . . 6
3.2. Nested Mobility Optimization . . . . . . . . . . . . . . . 8
3.2.1. Decreasing the Number of Home Agents on the Path . . . 8
3.2.2. Decreasing the Number of Tunnels . . . . . . . . . . . 9
3.3. Infrastructure-Based Optimization . . . . . . . . . . . . 9
3.4. Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 10
4. Issues of NEMO Route Optimization . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 2。 ネモの利益は最適化. . . . . . . . . . . . . 4 3を発送します。 ネモの異なったシナリオは最適化. . . . . . . . 6 3.1を発送します。 非入れ子にされたネモ経路最適化. . . . . . . . . . . . 6 3.2。 入れ子にされた移動性最適化. . . . . . . . . . . . . . . 8 3.2.1。 経路. . . 8 3.2.2でホームのエージェントの数を減少させます。 Tunnels. . . . . . . . . . . 9 3.3の数を減少させます。 インフラストラクチャベースの最適化. . . . . . . . . . . . 9 3.4。 IntraネモOptimization. . . . . . . . . . . . . . . . . 10 4。 ネモ経路最適化. . . . . . . . . . . . . . 11の問題
Ng, et al. Informational [Page 1] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [1ページ]情報のRFC4889ネモROスペース分析2007年7月
4.1. Additional Signaling Overhead . . . . . . . . . . . . . . 11
4.2. Increased Protocol Complexity and Processing Load . . . . 12
4.3. Increased Delay during Handoff . . . . . . . . . . . . . . 12
4.4. Extending Nodes with New Functionalities . . . . . . . . . 13
4.5. Detection of New Functionalities . . . . . . . . . . . . . 14
4.6. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Mobility Transparency . . . . . . . . . . . . . . . . . . 14
4.8. Location Privacy . . . . . . . . . . . . . . . . . . . . . 15
4.9. Security Consideration . . . . . . . . . . . . . . . . . . 15
4.10. Support of Legacy Nodes . . . . . . . . . . . . . . . . . 15
5. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 16
5.1. Which Entities Are Involved? . . . . . . . . . . . . . . . 16
5.1.1. Mobile Network Node and Correspondent Node . . . . . . 16
5.1.2. Mobile Router and Correspondent Node . . . . . . . . . 17
5.1.3. Mobile Router and Correspondent Router . . . . . . . . 17
5.1.4. Entities in the Infrastructure . . . . . . . . . . . . 18
5.2. Who Initiates Route Optimization? When? . . . . . . . . . 18
5.3. How Is Route Optimization Capability Detected? . . . . . . 19
5.4. How is the Address of the Mobile Network Node
Represented? . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. How Is the Mobile Network Node's Address Bound to
Location? . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.1. Binding to the Location of Parent Mobile Router . . . 21
5.5.2. Binding to a Sequence of Upstream Mobile Routers . . . 23
5.5.3. Binding to the Location of Root Mobile Router . . . . 24
5.6. How Is Signaling Performed? . . . . . . . . . . . . . . . 26
5.7. How Is Data Transmitted? . . . . . . . . . . . . . . . . . 27
5.8. What Are the Security Considerations? . . . . . . . . . . 28
5.8.1. Security Considerations of Address Binding . . . . . . 28
5.8.2. End-to-End Integrity . . . . . . . . . . . . . . . . . 30
5.8.3. Location Privacy . . . . . . . . . . . . . . . . . . . 30
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
4.1. 追加シグナリングオーバーヘッド. . . . . . . . . . . . . . 11 4.2。 増加するプロトコルの複雑さと処理は.124.3をロードします。 移管. . . . . . . . . . . . . . 12 4.4の間の増加する遅れ。 新しい機能性. . . . . . . . . 13 4.5でノードについて敷衍しています。 新しい機能性. . . . . . . . . . . . . 14 4.6の検出。 スケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . 14 4.7。 移動性透明. . . . . . . . . . . . . . . . . . 14 4.8。 位置のプライバシー. . . . . . . . . . . . . . . . . . . . . 15 4.9。 警備上の配慮. . . . . . . . . . . . . . . . . . 15 4.10。 遺産ノード. . . . . . . . . . . . . . . . . 15 5のサポート。 ソリューションスペース. . . . . . . . . . . . . . . . . . 16 5.1の分析。 どの実体がかかわりますか? . . . . . . . . . . . . . . . 16 5.1.1. モバイルネットワークノードと通信員ノード. . . . . . 16 5.1.2。 モバイルルータと通信員ノード. . . . . . . . . 17 5.1.3。 モバイルルータと通信員ルータ. . . . . . . . 17 5.1.4。 インフラストラクチャ. . . . . . . . . . . . 18 5.2における実体。 だれが経路最適化を開始しますか? いつですか? . . . . . . . . . 18 5.3. 経路最適化能力はどのように検出されますか? . . . . . . 19 5.4. モバイルNetwork Node RepresentedのAddressはいかがでしょうか? . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. モバイルネットワークノードのアドレスはどのように位置に縛られますか? . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5.1. 親のモバイルルータ. . . 21 5.5.2の位置まで付きます。 上流のモバイルルータ. . . 23 5.5.3の系列に付きます。 根のモバイルルータ. . . . 24 5.6の位置まで付きます。 シグナリングはどのように実行されますか? . . . . . . . . . . . . . . . 26 5.7. データはどのように送られますか? . . . . . . . . . . . . . . . . . 27 5.8. セキュリティ問題は何ですか? . . . . . . . . . . 28 5.8.1. アドレス結合. . . . . . 28 5.8.2のセキュリティ問題。 終わりから終わりへの保全. . . . . . . . . . . . . . . . . 30 5.8.3。 位置のプライバシー. . . . . . . . . . . . . . . . . . . 30 6。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 31 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 32 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 32 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 32 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 33
Ng, et al. Informational [Page 2] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [2ページ]情報のRFC4889ネモROスペース分析2007年7月
1. Introduction
1. 序論
Network Mobility Route Optimization Problem Statement [1] describes operational limitations and overheads incurred in a deployment of Network Mobility (NEMO) Basic Support [2], which could be alleviated by a set of NEMO Route Optimization techniques to be defined. The term "Route Optimization" is used in a broader sense than already defined for IPv6 Host Mobility in [3] to loosely refer to any approach that optimizes the transmission of packets between a Mobile Network Node and a Correspondent Node.
ネットワークMobility Route Optimization Problem Statement[1]は定義されるために1セットのネモRoute Optimizationのテクニックで軽減できるだろうNetwork Mobility(ネモ)の基本的なSupport[2]の展開で被られた操作上の制限とオーバーヘッドについて説明します。 「経路最適化」という用語は[3]のIPv6 Host Mobilityが緩くモバイルNetwork NodeとCorrespondent Nodeの間のパケットのトランスミッションを最適化するどんなアプローチについても言及するように既に定義されるより広い意味で使用されます。
Solutions that would fit that general description were continuously proposed since the early days of NEMO, even before the Working Group was formed. Based on that long-standing stream of innovation, this document classifies, at a generic level, the solution space of the possible approaches that could be taken to solve the Route Optimization-related problems for NEMO. The scope of the solutions, the benefits, and the impacts to the existing implementations and deployments are analyzed. This work should serve as a foundation for the NEMO WG to decide where to focus its Route Optimization effort, with a deeper understanding of the relative strengths and weaknesses of each approach.
ネモの初期以来その概説に合うソリューションが絶え間なく提案されました、作業部会が形成される前にさえ。 革新のその長年の流れに基づいて、このドキュメントはネモのために一般的なレベルでRoute Optimization関連の問題を解決するために取ることができた可能なアプローチの解決策スペースを分類します。 既存の実現と展開への解決策の範囲、利益、および影響は分析されます。 この仕事はNEMO WGがどこでRoute Optimizationの努力の焦点を合わせるかを決める基礎として機能するべきです、相対的な強さの、より深い理解とそれぞれのアプローチの弱点で。
It should be beneficial for readers to keep in mind the design requirements of NEMO [4]. A point to note is that since this document discusses aspects of Route Optimization, the reader may assume that a mobile network or a mobile host is away when they are mentioned throughout this document, unless it is explicitly specified that they are at home.
読者がネモ[4]の設計の品質を覚えておくのは、有益であるべきです。 注意するポイントはこのドキュメント以来のそれがRoute Optimizationの局面について議論して、読者は、それらがこのドキュメント中で言及されるとき、モバイルネットワークかモバイルホストが遠くにいると仮定するかもしれません、それらが家にあると明らかに指定されない場合ことです。
1.1. Terminology
1.1. 用語
It is expected that readers are familiar with terminologies related to mobility in [3] and [5], and NEMO-related terms defined in [6]. In addition, the following Route Optimization-specific terms are used in this document:
読者が[3]と[5]の移動性に関連する用語と[6]で定義されるネモ関連の用語に詳しいと予想されます。 さらに、次のRoute Optimization-種の用語は本書では費やされます:
Correspondent Router (CR)
通信員ルータ(CR)
This refers to the router that is capable of terminating a Route
Optimization session on behalf of a Correspondent Node.
これはCorrespondent Nodeを代表してRoute Optimizationセッションを終えることができるルータを示します。
Correspondent Entity (CE)
通信員実体(Ce)
This refers to the entity that a Mobile Router or Mobile Network
Node attempts to establish a Route Optimization session with.
Depending on the Route Optimization approach, the Correspondent
Entity may be a Correspondent Node or Correspondent Router.
これは確立するモバイルRouterかモバイルNetwork NodeがRoute Optimizationセッションを試みる実体を示します。 Route Optimizationアプローチによって、Correspondent EntityはCorrespondent NodeかCorrespondent Routerであるかもしれません。
Ng, et al. Informational [Page 3] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [3ページ]情報のRFC4889ネモROスペース分析2007年7月
2. Benefits of NEMO Route Optimization
2. ネモ経路最適化の恩恵
NEMO Route Optimization addresses the problems discussed in [1]. Although a standardized NEMO Route Optimization solution has yet to materialize, one can expect it to show some of the following benefits:
ネモRoute Optimizationは[1]で議論したその問題を訴えます。 標準化されたネモRoute Optimization解決策はまだ実現していませんが、人は、以下の利益のいくつかを示すと予想できます:
o Shorter Delay
o より少しな遅れ
Route Optimization involves the selection and utilization of a
lesser-cost (thus generally shorter and faster) route to be taken
for traffic between a Mobile Network Node and its Correspondent
Node. Hence, Route Optimization should improve the latency of the
data traffic between the two end nodes. This may in turn lead to
better overall Quality of Service characteristics, such as reduced
jitter and packet loss.
ルートOptimizationは、モバイルNetwork NodeとそのCorrespondent Nodeの間の交通に取るために、より少ない費用の(その結果、一般により短くより速い)のルートの選択と利用にかかわります。 したがって、Route Optimizationは2つのエンドノードの間のデータ通信量の潜在を改良するはずです。 これは順番に減少しているジターやパケット損失などのServiceの特性の、より良い総合的なQualityに通じるかもしれません。
o Reduced Consumption of Overall Network Resources
o 総合的なネットワーク資源の減少した消費高
Through the selection of a shorter route, the total link
utilization for all links used by traffic between the two end
nodes should be much lower than that used if Route Optimization is
not carried out. This would result in a lighter network load with
reduced congestion.
いっそう早く行けるルートの選択で、2つのエンドノードの間の交通で使用されるすべてのリンクのための総リンク利用はRoute Optimizationが行われないなら使用されるそれよりはるかに低いはずです。 これは減少している混雑がある、より軽いネットワーク負荷をもたらすでしょう。
o Reduced Susceptibility to Link Failure
o 失敗をリンクする減少している敏感さ
If a link along the bi-directional tunnel is disrupted, all
traffic to and from the mobile network will be affected until IP
routing recovers from the failure. An optimized route would
conceivably utilize a smaller number of links between the two end
nodes. Hence, the probability of a loss of connectivity due to a
single point of failure at a link should be lower as compared to
the longer non-optimized route.
双方向のトンネルに沿ったリンクが混乱させられると、IPルーティングが失敗から回復するまで、モバイルネットワークとモバイルネットワークからのすべての交通が影響を受けるでしょう。 最適化されたルートは多分2つのエンドノードの間の、より少ない数のリンクを利用するでしょう。 したがって、より長い非最適化されたルートと比べて、リンクでの1ポイントの失敗による接続性の損失の確率は低いはずです。
o Greater Data Efficiency
o 大データ効率
Depending on the actual solution for NEMO Route Optimization, the
data packets exchanged between two end nodes may not require as
many levels of encapsulation as that in NEMO Basic Support. This
would mean less packet overheads and higher data efficiency. In
particular, avoiding packet fragmentation that may be induced by
the multiple levels of tunneling is critical for end-to-end
efficiency from the viewpoints of buffering and transport
protocols.
ネモRoute Optimizationの実際の解決策によって、2つのエンドノードの間で交換されたデータ・パケットはネモBasic Supportのそれとして同じくらい多くのレベルのカプセル化を必要としないかもしれません。 これは、より少ないパケットオーバーヘッドと、より高いデータ効率を意味するでしょう。 バッファリングとトランスポート・プロトコルの観点からの終わりから終わりへの効率に、複数のレベルのトンネリングによって引き起こされるかもしれないパケット断片化を避けるのは特に、重要です。
Ng, et al. Informational [Page 4] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [4ページ]情報のRFC4889ネモROスペース分析2007年7月
o Reduced Processing Delay
o 遅れを処理しながら、減少します。
In a nested mobile network, the application of Route Optimization
may eliminate the need for multiple encapsulations required by
NEMO Basic Support, which may result in less processing delay at
the points of encapsulation and decapsulation.
入れ子にされたモバイルネットワークでは、Route Optimizationのアプリケーションはカプセル化と被膜剥離術のポイントで、より少ない処理遅れをもたらすかもしれないネモBasic Supportによって必要とされた複数のカプセル化の必要性を排除するかもしれません。
o Avoiding a Bottleneck in the Home Network
o ホームネットワークにおけるボトルネックを避けます。
NEMO Route Optimization allows traffic to bypass the Home Agents.
Apart from having a more direct route, this also avoids routing
traffic via the home network, which may be a potential bottleneck
otherwise.
ネモRoute Optimizationは交通にホームのエージェントを迂回させます。 また、よりダイレクトなルートを持っていることは別として、これは、ホームネットワークで交通を発送するのを避けます。(そうでなければ、ホームネットワークは潜在的ボトルネックであるかもしれません)。
o Avoid the Security Policy Issue
o 安全保障政策問題を避けてください。
Security policy may forbid a Mobile Router from tunneling traffic
of Visiting Mobile Nodes into the home network of the Mobile
Router. Route Optimization can be used to avoid this issue by
forwarding traffic from Visiting Mobile Nodes directly to their
destinations without going through the home network of the Mobile
Router.
安全保障政策はVisitingのモバイルNodesのトンネリング交通からモバイルRouterのホームネットワークにモバイルRouterを禁じるかもしれません。 VisitingのモバイルNodesから直接彼らの目的地までの推進交通でモバイルRouterのホームネットワークに直面していなくてこの問題を避けるのにルートOptimizationを使用できます。
However, it should be taken into consideration that a Route
Optimization mechanism may not be an appropriate solution since
the Mobile Router may still be held responsible for illegal
traffic sent from its Mobile Network Nodes even when Route
Optimization is used. In addition, there can be a variety of
different policies that might conflict with the deployment of
Route Optimization for Visiting Mobile Nodes. Being a policy
issue, solving this with a protocol at the policy plane might be
more appropriate.
しかしながら、Route Optimizationが使用されてさえいるときモバイルNetwork Nodesから送られた不法な交通がまだモバイルRouterの責任を負わせられているかもしれないのでRoute Optimizationメカニズムが適切な解決策でないかもしれないことが考慮に入れられるべきです。 さらに、VisitingのモバイルNodesのためにRoute Optimizationの展開と衝突するかもしれないさまざまな異なった方針があることができます。 政策問題であり、プロトコルが方針飛行機にある状態でこれを解決するのは、より適切であるかもしれません。
o Avoid the Instability and Stalemate
o 不安定性と手詰まりを避けてください。
[1] described a potential stalemate situation when a Home Agent is
nested within a mobile network. Route Optimization may circumvent
such stalemate situations by directly forwarding traffic upstream.
However, it should be noted that certain Route Optimization
schemes may require signaling packets to be first routed via the
Home Agent before an optimized route can be established. In such
cases, a Route Optimization solution cannot avoid the stalemate.
ホームのエージェントであるときに、[1] 説明されて、潜在的手詰まりの状況はモバイルネットワークの中で入れ子にされます。 ルートOptimizationは、直接上流へ交通を進めることによって、そのような手詰まりの状況を回避するかもしれません。 しかしながら、あるRoute Optimization計画が、最適化されたルートを確立できる前に最初にホームのエージェントを通して発送されるようにパケットに合図するのを必要とするかもしれないことに注意されるべきです。 そのような場合、Route Optimization解決策は手詰まりを避けることができません。
Ng, et al. Informational [Page 5] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [5ページ]情報のRFC4889ネモROスペース分析2007年7月
3. Different Scenarios of NEMO Route Optimization
3. ネモ経路最適化の異なったシナリオ
There are multiple proposals for providing various forms of Route Optimization in the NEMO context. In the following sub-sections, we describe the different scenarios that would require a Route Optimization mechanism and list the potential solutions that have been proposed in that area.
ネモ文脈のRoute Optimizationの様々なフォームを提供するための複数の提案があります。 以下の小区分では、私たちは、Route Optimizationメカニズムを必要とする異なったシナリオについて説明して、その領域で提案された潜在的解決策を記載します。
3.1. Non-Nested NEMO Route Optimization
3.1. 非入れ子にされたネモ経路最適化
The Non-Nested NEMO Route Optimization involves a Mobile Router sending binding information to a Correspondent Entity. It does not involve nesting of Mobile Routers or Visiting Mobile Nodes. The Correspondent Entity can be a Correspondent Node or a Correspondent Router. The interesting case is when the Correspondent Entity is a Correspondent Router. With the use of Correspondent Router, Route Optimization session is terminated at the Correspondent Router on behalf of the Correspondent Node. As long as the Correspondent Router is located "closer" to the Correspondent Node than the Home Agent of the Mobile Router, the route between Mobile Network Node and the Correspondent Node can be said to be optimized. For this purpose, Correspondent Routers may be deployed to provide an optimal route as illustrated in Figure 1.
Nonによって入れ子にされたネモRoute OptimizationはモバイルRouter送付拘束力がある情報にCorrespondent Entityにかかわります。 それは、モバイルRoutersかVisitingのモバイルNodesを巣ごもらせることを伴いません。 Correspondent EntityはCorrespondent NodeかCorrespondent Routerであるかもしれません。 おもしろいケースはCorrespondent EntityがCorrespondent Routerである時です。 Correspondent Routerの使用で、Route OptimizationセッションはCorrespondent RouterでCorrespondent Nodeを代表して終えられます。 Correspondent Routerが「モバイルRouterのホームのエージェントより近いところにCorrespondent Nodeの」位置している限り、最適化されるとモバイルNetwork NodeとCorrespondent Nodeの間のルートを言うことができます。 このために、Correspondent Routersは、図1で例証されるように最適のルートを提供するために配備されるかもしれません。
************************** HAofMR
* #*#
* #*# +---------------------+
CN #*# | LEGEND |
o #*# +---------------------+
o ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
############### | | o: Optimized route |
MNN +---------------------+
************************** HAofMR*#*#*##*+---------------------+ CN#*#| 伝説| o #*# +---------------------+ o################*#| #: トンネル| CR ooooooooooooooo MR| *: ネモBasicルート| ############### | | o: 最適化されたルート| MNN+---------------------+
Figure 1: MR-CR Optimization
図1: MR-CR最適化
This form of optimization can carry traffic in both directions or independently for the two directions of traffic:
この形式の最適化は交通の2つの方向のために両方の指示か独自に交通を運ぶことができます:
o From MNN to CN
o MNNからCNまで
The Mobile Router locates the Correspondent Router, establishes a
tunnel with that Correspondent Router and sets up a route to the
Correspondent Node via the Correspondent Router over the tunnel.
Traffic to the Correspondent Node would no longer flow through the
Home Agent anymore.
モバイルRouterはトンネルの上のCorrespondent Routerを通してCorrespondent Routerの場所を見つけて、そのCorrespondent Routerと共にトンネルを確立して、Correspondent Nodeにルートをセットアップします。 Correspondent Nodeへの交通はそれ以上もうホームのエージェントを通して流れないでしょう。
Ng, et al. Informational [Page 6] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [6ページ]情報のRFC4889ネモROスペース分析2007年7月
o From CN to MNN
o CNからMNNまで
The Correspondent Router is on the path of the traffic from the
Correspondent Node to the Home Agent. In addition, it has an
established tunnel with the current Care-of Address (CoA) of the
Mobile Router and is aware of the Mobile Network Prefix(es)
managed by the Mobile Router. The Correspondent Router can thus
intercept packets going to the mobile network, and forward them to
the Mobile Router over the established tunnel.
Correspondent RouterがCorrespondent Nodeからホームのエージェントまでの交通の経路にあります。 さらに、電流を伴う確立したトンネルを持っている、Care、-、モバイルRouterのAddress(CoA)、モバイルRouterによって管理されたモバイルNetwork Prefix(es)を意識しています。 Correspondent Routerはその結果、モバイルネットワークに行くパケットを妨害して、確立したトンネルの上のモバイルRouterにそれらを送ることができます。
A straightforward approach to Route Optimization in NEMO is for the Mobile Router to attempt Route Optimization with a Correspondent Entity. This can be viewed as a logical extension to NEMO Basic Support, where the Mobile Router would send Binding Updates containing one or more Mobile Network Prefix options to the Correspondent Entity. The Correspondent Entity, having received the Binding Update, can then set up a bi-directional tunnel with the Mobile Router at the current Care-of Address of the Mobile Router, and inject a route to its routing table so that packets destined for addresses in the Mobile Network Prefix will be routed through the bi- directional tunnel.
ネモのRoute Optimizationへの簡単なアプローチはモバイルRouterがCorrespondent Entityと共にRoute Optimizationを試みることです。 論理的な拡大としてネモBasic Supportにおいてこれを見なすことができます。そこでは、モバイルRouterが1つ以上のモバイルNetwork PrefixオプションをCorrespondent Entityに含むBinding Updatesを送るでしょう。 次に、Correspondent EntityがBinding Updateを受けたので電流のモバイルRouterと共に双方向のトンネルを設立できる、Care、-、モバイルRouterのAddress、モバイルNetwork Prefixのアドレスのために運命づけられたパケットが両性愛者の方向のトンネルを通って発送されるように、経路指定テーブルにルートを注入してください。
The definition of Correspondent Router does not limit it to be a fixed router. Here we consider the case where the Correspondent Router is a Mobile Router. Thus, Route Optimization is initiated and performed between a Mobile Router and its peer Mobile Router. Such solutions are often posed with a requirement to leave the Mobile Network Nodes untouched, as with the NEMO Basic Support protocol, and therefore Mobile Routers handle the optimization management on behalf of the Mobile Network Nodes. Thus, providing Route Optimization for a Visiting Mobile Node is often out of scope for such a scenario because such interaction would require extensions to the Mobile IPv6 protocol. This scenario is illustrated in Figure 2.
Correspondent Routerの定義は、固定ルータになるようにそれを制限しません。 ここで、私たちはCorrespondent RouterがモバイルRouterであるケースを考えます。 したがって、Route OptimizationはモバイルRouterとその同輩のモバイルRouterの間で開始されて、実行されます。 そのような解決策はネモBasic Supportプロトコルのようにしばしば触れない状態でモバイルNetwork Nodesを残すという要件で引き起こされます、そして、したがって、モバイルRoutersはモバイルNetwork Nodesを代表して最適化管理を扱います。 そのような相互作用はモバイルIPv6プロトコルに拡大を必要とするでしょう、したがって、したがって、VisitingのモバイルNodeにRoute Optimizationを供給するのが、しばしばそのようなシナリオのための範囲からのそうです。 このシナリオは図2で例証されます。
HAofCR ********************************** HAofMR
#*# #*#
#*# #*# +---------------------+
#*# #*# | LEGEND |
#*# #*# +---------------------+
#*# ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
| ############### | | o: Optimized route |
MNN2 MNN1 +---------------------+
HAofCR**********************************HAofMR#*##*##*###*+---------------------+ #*# #*# | 伝説| #*# #*# +---------------------+ #*# ############### #*# | #: トンネル| CR ooooooooooooooo MR| *: ネモBasicルート| | ############### | | o: 最適化されたルート| MNN2 MNN1+---------------------+
Figure 2: MR-MR Optimization
図2: MR-MR最適化
Ng, et al. Informational [Page 7] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [7ページ]情報のRFC4889ネモROスペース分析2007年7月
This form of optimization can carry traffic for both directions identically:
この形式の最適化は同様に両方の指示のための交通を運ぶことができます:
o MNN1 to/from MNN2
o MNN2からの/へのMNN1
The Mobile Router locates the Correspondent Router, establishes a
tunnel with that Correspondent Router, and sets up a route to the
Mobile Network Node via the Correspondent Router over the tunnel.
Traffic to the Mobile Networks Nodes would no longer flow through
the Home Agents.
モバイルRouterはトンネルの上のCorrespondent Routerを通してモバイルNetwork NodeにCorrespondent Routerの場所を見つけて、そのCorrespondent Routerと共にトンネルを確立して、ルートをセットアップします。 モバイルNetworks Nodesへの交通はもうホームのエージェントを通して流れないでしょう。
Examples of this approach include Optimized Route Cache (ORC) [7][8] and Path Control Header (PCH) [9].
このアプローチに関する例はOptimized Route Cache(ORC)[7][8]とPath Control Header(PCH)[9]を含んでいます。
3.2. Nested Mobility Optimization
3.2. 入れ子にされた移動性最適化
Optimization in Nested Mobility targets scenarios where a nesting of mobility management protocols is created (i.e., Mobile IPv6-enabled host inside a mobile network or multiple Mobile Routers that attach behind one another creating a nested mobile network). Note that because Mobile IPv6 defines its own Route Optimization mechanism in its base protocol suite as a standard, collaboration between this and NEMO protocols brings various complexities.
Nested Mobilityの最適化は移動性管理プロトコルの巣篭もりが作成されるシナリオ(入れ子にされたモバイルネットワークを創設しながらお互いの後ろで付くすなわち、モバイルIPv6によって可能にされたホスト内部のモバイルネットワークか複数のモバイルRouters)を狙います。 モバイルIPv6がベースプロトコル群でそれ自身のRoute Optimizationメカニズムを規格と定義するのでこれとネモプロトコルとの共同が様々な複雑さをもたらすことに注意してください。
There are two main aspects in providing optimization for Nested Mobility, and they are discussed in the following sub-sections.
最適化をNested Mobilityに供給するのにおいて2つの主な局面があります、そして、以下の小区分でそれらについて議論します。
3.2.1. Decreasing the Number of Home Agents on the Path
3.2.1. 経路でホームのエージェントの数を減少させます。
The aim is to remove the sub-optimality of paths caused by multiple tunnels established between multiple Mobile Nodes and their Home Agents. Such a solution will seek to minimize the number of Home Agents along the path, by bypassing some of the Home Agent(s) from the original path. Unlike the scenario where no nesting is formed and only a single Home Agent exists along the path, bypassing one of the many Home Agents can still be effective.
目的は複数のモバイルNodesと彼らのホームのエージェントの間で確立された複数のトンネルによって引き起こされた経路のサブの最適を取り除くことです。 そのような解決策は経路に沿ってホームのエージェントの数を最小にしようとするでしょう、元の経路からホームのエージェントを迂回させることによって。 巣ごもらないことが形成されて、独身のホームのエージェントだけが経路に沿って存在するシナリオと異なって、多くのホームのエージェントのひとりを迂回させるのはまだ有効である場合があります。
Solutions for Nested Mobility scenarios can usually be divided into two cases based on whether the nesting involves Mobile IPv6 hosts or only involves Mobile Routers. Since Mobile IPv6 defines its own Route Optimization mechanism, providing an optimal path for such hosts will require interaction with the protocol and may require an altering of the messages exchanged during the Return Routability procedure with the Correspondent Node.
通常、Nested Mobilityシナリオのためのソリューションを巣篭もりがモバイルIPv6ホストにかかわるか、またはモバイルRoutersにかかわるだけであるかに基づく2つのケースに分割できます。 モバイルIPv6がそれ自身のRoute Optimizationメカニズムを定義するので、そのようなホストに最適経路を提供するのは、プロトコルで相互作用を必要として、Correspondent Nodeと共にReturn Routability手順の間に交換されたメッセージの変わることを必要とするかもしれません。
An example of this approach include Reverse Routing Header (RRH) [10].
このアプローチに関する例はReverseルート設定Header(RRH)[10]を含んでいます。
Ng, et al. Informational [Page 8] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [8ページ]情報のRFC4889ネモROスペース分析2007年7月
3.2.2. Decreasing the Number of Tunnels
3.2.2. Tunnelsの数を減少させます。
The aim is to reduce the amplification effect of nested tunnels due to the nesting of tunnels between the Visiting Mobile Node and its Home Agent within the tunnel between the parent Mobile Router and the parent Mobile Router's Home Agent. Such a solution will seek to minimize the number of tunnels, possibly by collapsing the amount of tunnels required through some form of signaling between Mobile Nodes, or between Mobile Nodes and their Home Agents, or by using routing headers to route packets through a discovered path. These limit the consequences of the amplification effect of nested tunnels, and at best, the performance of a nested mobile network will be the same as though there were no nesting at all.
目的はVisitingのモバイルNodeとそのホームのエージェントの間のトンネルの巣篭もりのため親のモバイルRouterと親のモバイルRouterのホームのエージェントの間のトンネルの中で入れ子にされたトンネルの増幅作用を減少させることです。 そのような解決策はトンネルの数を最小にしようとするでしょう、ことによると発見された経路を通してパケットを発送するとモバイルNodesの間、または、モバイルNodesと彼らのホームのエージェントの間、または、ルーティングヘッダーを使用することで合図する何らかのフォームを通して必要であるトンネルの量を潰すことによって。 これらは入れ子にされたトンネルの増幅作用の結果を限ります、そして、まるで巣ごもるのが全くないかのように入れ子にされたモバイルネットワークの性能はせいぜい、同じになるでしょう。
Examples of this approach include the Reverse Routing Header (RRH) [10], Access Router Option (ARO) [11], and Nested Path Info (NPI) [12].
このアプローチに関する例はReverseルート設定Header(RRH)[10]、Access Router Option(ARO)[11]、およびNested Path Info(NPI)[12]を含んでいます。
3.3. Infrastructure-Based Optimization
3.3. インフラストラクチャベースの最適化
An infrastructure-based optimization is an approach where optimization is carried out fully in the infrastructure. One example is to make use of Mobility Anchor Points (MAPs) such as defined in HMIPv6 [13] to optimize routes between themselves. Another example is to make use of proxy Home Agent such as defined in the global Home Agent to Home Agent (HAHA) protocol [14]. A proxy Home Agent acts as a Home Agent for the Mobile Node, and acts as a Mobile Node for the Home Agent, Correspondent Node, Correspondent Router, and other proxies. In particular, the proxy Home Agent terminates the MRHA tunnel and the associated encryption, extracts the packets, and re- encapsulates them to the destination. In this case, proxy Home Agents are distributed in the infrastructure and each Mobile Router binds to the closest proxy. The proxy, in turn, performs a primary binding with a real Home Agent for that Mobile Router. Then, the proxy might establish secondary bindings with other Home Agents or proxies in the infrastructure, in order to improve the end-to-end path. In this case, the proxies discover each other using some form of Next Hop Resolution Protocol, establish a tunnel and exchange the relevant Mobile Network Prefix information in the form of explicit prefix routes.
インフラストラクチャベースの最適化は最適化がインフラストラクチャで完全に行われるところのアプローチです。 1つの例は自分たちの間のルートを最適化するためにHMIPv6[13]で定義されるようにMobility Anchor Points(MAPs)を利用することです。 別の例はグローバルなホームのエージェントでホームのエージェント(HAHA)プロトコル[14]と定義されるようにプロキシホームのエージェントを利用することです。 プロキシホームのエージェントは、モバイルNodeのためにホームのエージェントとして務めて、ホームのエージェント、Correspondent Node、Correspondent Router、および他のプロキシのためにモバイルNodeとして務めます。 プロキシホームのエージェントは、目的地に特に、MRHAトンネルと関連暗号化を終えて、パケットを抽出して、それらを再要約します。 この場合、プロキシホームのエージェントはインフラストラクチャで分配されます、そして、それぞれのモバイルRouterは最も近いプロキシに付きます。 プロキシはそのモバイルRouterのために順番に本当のホームのエージェントとの第一の結合を実行します。 次に、プロキシは他のホームのエージェントかプロキシと共に二次結合をインフラストラクチャに確立するかもしれません、終わりから端への経路を改良するために。 この場合、プロキシは、明白な接頭語ルートの形で何らかのフォームのNext Hop Resolutionプロトコルを使用することで互いを発見して、トンネルを確立して、関連モバイルNetwork Prefix情報を交換します。
Alternatively, another approach is to use prefix delegation. Here, each Mobile Router in a nested mobile network is delegated a Mobile Network Prefix from the access router using DHCP Prefix Delegation [15]. Each Mobile Router also autoconfigures its Care-of Address from this delegated prefix. In this way, the Care-of Addresses of each Mobile Router are all formed from an aggregatable address space
あるいはまた、別のアプローチは接頭語代表団を使用することです。 ここで、入れ子にされたモバイルネットワークにおけるそれぞれのモバイルRouterはDHCP Prefix Delegation[15]を使用するアクセスルータからの代表として派遣されたaモバイルNetwork Prefixです。 また、それぞれのモバイルRouterが自動構成する、それ、Care、-、これからのAddressは接頭語を代表として派遣しました。 このようにCare、-、それぞれのモバイルRouterのAddressesは「集合-可能」アドレス空間からすべて形成されます。
Ng, et al. Informational [Page 9] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [9ページ]情報のRFC4889ネモROスペース分析2007年7月
starting from the access router. This may be used to eliminate the multiple tunnels caused by nesting of Mobile Nodes.
アクセスルータから始めます。 これは、モバイルNodesの巣篭もりで引き起こされた複数のトンネルを排除するのに使用されるかもしれません。
3.4. Intra-NEMO Optimization
3.4. IntraネモOptimization
A Route Optimization solution may seek to improve the communications between two Mobile Network Nodes within a nested mobile network. This would avoid traffic being injected out of the nested mobile network and route them within the nested mobile network. An example is the optimized route taken between MNN1 and MNN2 in Figure 3 below.
Route Optimization解決策は入れ子にされたモバイルネットワークの中の2モバイルNetwork Nodesのコミュニケーションを改良しようとするかもしれません。 これは、入れ子にされたモバイルネットワークから注入される交通を避けて、入れ子にされたモバイルネットワークの中でそれらを発送するでしょう。 例は以下で図3のMNN1とMNN2の間に連れて行かれた最適化されたルートです。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN
+--------+ +--------------+---------------+
|
+----+----+
| MR1 |
+----+----+
|
---+-----------+-----------+---
| | |
+---+---+ +---+---+ +---+---+
| MR5 | | MR2 | | MR4 |
+---+---+ +---+---+ +---+---+
| | |
---+--- +---+---+ ---+---
MNN2 | MR3 | MNN3
+---+---+
|
----+----
MNN1
+--------+ +--------+ +--------+ +--------+ | MR2_、ハ。| | MR3_、ハ。| | MR4_、ハ。| | MR5_、ハ。| +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +------------------------------+ | MR1_、ハ。|----| インターネット|-----CN+--------+ +--------------+---------------+ | +----+----+ | MR1| +----+----+ | ---+-----------+-----------+--- | | | +---+---+ +---+---+ +---+---+ | MR5| | MR2| | MR4| +---+---+ +---+---+ +---+---+ | | | ---+--- +---+---+ ---+--- MNN2| MR3| MNN3+---+---+ | ----+---- MNN1
Figure 3: An Example of a Nested Mobile Network
図3: 入れ子にされたモバイルネットワークに関する例
One may be able to extend a well-designed NEMO Route Optimization for "Nested Mobility Optimization" (see Section 3.2) to provide for such kind of Intra-NEMO optimization, where, for example in Figure 3, MNN1 is treated as a Correspondent Node by MR5/MNN2, and MNN2 is treated as a Correspondent Node by MR3/MNN1.
ちょっとそのようなIntra-ネモ最適化に提供する「入れ子にされた移動性最適化」(セクション3.2を見る)のためによく設計されたネモRoute Optimizationを広げることができるかもしれません。そこでは、例えば、図3では、MNN1がMR5/MNN2によってCorrespondent Nodeとして扱われて、MNN2はMR3/MNN1によってCorrespondent Nodeとして扱われます。
Another possibility is for the "Non-Nested NEMO Route Optimization" technique (see Section 3.1) to be applied here. Using the same example of communication between MNN1 and MNN2, both MR3 and MR2 can
別の可能性は「非入れ子にされたネモ経路最適化」のテクニック(セクション3.1を見る)がここに適用されることです。 MNN1とMNN2とのコミュニケーションに関する同じ例を使用して、MR3とMR2の両方は使用できます。
Ng, et al. Informational [Page 10] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [10ページ]情報のRFC4889ネモROスペース分析2007年7月
treat MR5 as Correspondent Routers for MNN2, and MR5 treats MR3 and MR2 as Correspondent Routers for MNN1. An example of this approach is [16], which has the Mobile Routers announce their Mobile Network Prefixes to other Mobile Routers in the same nested Mobile Network.
MNN2のためにCorrespondent RoutersとしてMR5を扱ってください。そうすれば、MR5はMNN1のためにMR3とMR2をCorrespondent Routersとして扱います。 このアプローチに関する例は[16]です。(その[16]はモバイルRoutersに同じ入れ子にされたモバイルNetworkで彼らのモバイルNetwork Prefixesを他のモバイルRoutersに発表させます)。
Yet another approach is to flatten any nested Mobile Network so that all nested Mobile Network Nodes appear to be virtually on the same link. Examples of such approaches include delegating a single prefix to the nested Mobile Network, having Mobile Routers to perform Neighbor Discovery on behalf of their Mobile Network Nodes, and exposing a single prefix over the entire mobile network using a Mobile Ad-Hoc (MANET) protocol. In particular, it might prove useful to develop a new type of MANET, specialized for the NEMO problem, a MANET for NEMO (MANEMO). The MANEMO will optimize the formation of the nested NEMO and maintain inner connectivity, whether or not a connection to the infrastructure can be established.
すべての入れ子にされたモバイルNetwork Nodesが、さらに別のアプローチがどんな入れ子にされたモバイルNetworkも平らにすることであるので、実際には同じくらいでリンクすることであるように見えます。 そのようなアプローチに関する例は、彼らのモバイルNetwork Nodesと、モバイルAd-Hoc(マネ)プロトコルを使用することで全体のモバイルネットワークの上のただ一つの接頭語を暴露することを代表してNeighborディスカバリーを実行するためにモバイルRoutersを持っていて、入れ子にされたモバイルNetworkへただ一つの接頭語を代表として派遣するのを含んでいます。 特に、ネモ問題によって専門にされた新しいタイプのマネを開発するのが役に立つと判明するかもしれません、ネモ(MANEMO)のためのマネ。 MANEMOは入れ子にされたネモの構成を最適化して、内側の接続性を維持するでしょう、インフラストラクチャとの接続を確立できるか否かに関係なく。
4. Issues of NEMO Route Optimization
4. ネモ経路最適化の問題
Although Route Optimization can bring benefits as described in Section 2, the scenarios described in Section 3 do so with some tradeoffs. This section explores some general issues that may impact a NEMO Route Optimization mechanism.
Route Optimizationはセクション2で説明されるように利益をもたらすことができますが、したがって、セクション3で説明されたシナリオはいくつかの見返りを処理します。 このセクションはネモRoute Optimizationメカニズムに影響を与えるかもしれないいくつかの一般答弁を探ります。
4.1. Additional Signaling Overhead
4.1. 追加シグナリングオーバーヘッド
The nodes involved in performing Route Optimization would be expected to exchange additional signaling messages in order to establish Route Optimization. The required amount of signaling depends on the solution, but is likely to exceed the amount required in the home Binding Update procedure defined in NEMO Basic Support. The amount of signaling is likely to increase with the increasing number of Mobile Network Nodes and/or Correspondent Nodes, and may be amplified with nesting of mobile networks. It may scale to unacceptable heights, especially to the resource-scarce mobile node, which typically has limited power, memory, and processing capacity.
Route Optimizationを実行するのにかかわるノードがRoute Optimizationを設立するために追加シグナリングメッセージを交換すると予想されるでしょう。 必要な量のシグナリングが、ソリューションによりますが、ネモBasic Supportで定義されたホームBinding Update手順による必要額を超えていそうです。 シグナリングの量は、モバイルNetwork Nodes、そして/または、Correspondent Nodesの増加する数に従って増加しそうであって、モバイルネットワークの巣篭もりで増幅されるかもしれません。 それは容認できない高さに比例するかもしれません、特にリソース不十分なモバイルノードに。(それは、パワー、メモリ、および処理容量を通常制限しました)。
This may lead to an issue that impacts NEMO Route Optimization, known as the phenomenon of "Binding Update Storm", or more generally, "Signaling Storm". This occurs when a change in point of attachment of the mobile network is accompanied with a sudden burst of signaling messages, resulting in temporary congestion, packet delays, or even packet loss. This effect will be especially significant for wireless environment where bandwidth is relatively limited.
より一般に、これは「拘束力があるアップデート嵐」の現象として知られているネモRoute Optimizationに影響を与える問題に通じるかもしれませんか、または「シグナリングはどなります」。 モバイルネットワークの接着点の変化がシグナリングメッセージの突然の炸裂で伴われるとき、これは起こります、一時的な混雑、パケット遅れ、またはパケット損失さえもたらして。 この効果は帯域幅が比較的限られているところでワイヤレスの環境に特に重要になるでしょう。
It is possible to moderate the effect of Signaling Storm by incorporating mechanisms such as spreading the transmissions burst of
トランスミッションがはち切れた普及などのメカニズムを組み込むことによってSignaling Stormの効果を加減するのは可能です。
Ng, et al. Informational [Page 11] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [11ページ]情報のRFC4889ネモROスペース分析2007年7月
signaling messages over a longer period of time, or aggregating the signaling messages.
より長い期間、またはシグナリングメッセージに集める上のメッセージに合図します。
Even so, the amount of signaling required might be overwhelming, since large mobile networks (such as those deployed on a train or plane) may potentially have a large number of flows with a large number of Correspondent Nodes. This might suggest a need to have some adaptive behavior that depends on the amount of signaling required versus the effort needed to tunnel home.
たとえそうだとしても、必要であるシグナリングの量は圧倒的であるかもしれません、大きいモバイルネットワーク(列車か飛行機の上で配布されたものなどの)には多くのCorrespondent Nodesがある多くの流れが潜在的にあるかもしれないので。 これは、シグナリングの量に依存する何らかの適応行動を持つ必要性がトンネルホームに必要である取り組みに対して必要であることを示すかもしれません。
4.2. Increased Protocol Complexity and Processing Load
4.2. 増強されたプロトコルの複雑さと処理はロードされます。
It is expected that NEMO Route Optimization will be more complicated than NEMO Basic Support. Thus, complexity of nodes that are required to incorporate new functionalities to support NEMO Route Optimization would be higher than those required to provide NEMO Basic Support.
ネモRoute OptimizationがネモBasic Supportよりさらに複雑になると予想されます。 したがって、それらがネモBasic Supportを提供するのが必要であるというよりもネモRoute Optimizationをサポートするために新しい機能性を取り入れなければならないノードの複雑さは高いでしょう。
Coupled with the increased complexity, nodes that are involved in the establishment and maintenance of Route Optimization will have to bear the increased processing load. If such nodes are mobile, this may prove to be a significant cost due to the limited power and processing resources such devices usually have.
増強された複雑さと結合されています、Route Optimizationの設立とメインテナンスにかかわるノードは増強された処理負荷に堪えなければならないでしょう。 そのようなノードモバイルであるなら、これは通常、そのようなデバイスが持っている限られたパワーと処理リソースによる多大な費用であると判明するかもしれません。
4.3. Increased Delay during Handoff
4.3. 移管の間の増強された遅れ
Due to the diversity of locations of different nodes that Mobile Network Node may signal with and the complexity of NEMO Route Optimization procedure that may cause several rounds of signaling messages, a NEMO Route Optimization procedure may take a longer time to finish its handoff than that in NEMO Basic Support. This may exacerbate the overall delay during handoffs and further cause performance degradation of the applications running on Mobile Network Nodes.
モバイルNetwork Nodeが合図するかもしれない異なったノードの位置の多様性とシグナリングメッセージの数ラウンドを引き起こすかもしれないネモRoute Optimization手順の複雑さのため、ネモRoute Optimization手順は、移管を終えるにはネモBasic Supportのそれより長い時かかるかもしれません。 これはhandoffsとモバイルNetwork Nodesの上で作業するアプリケーションの一層の原因性能退行の間、総合的な遅れを悪化させるかもしれません。
Another NEMO-specific delay during handoff is that in a nested mobile network, a child Mobile Network Node may need to detect or be notified of the handoff of its parent Mobile Router so that it can begin signaling its own Correspondent Entities. Apart from the compromise of mobility transparency and location privacy (see Section 4.7 and Section 4.8), this mechanism also increases the delay during handoffs.
移管の間、別のネモ-詳細を延着させます。それが入れ子にされたモバイルネットワーク、モバイルNetwork Nodeが検出する必要があるかもしれない子供にいるか、またはそれ自身のCorrespondent Entitiesに合図し始めることができるように親のモバイルRouterの移管について通知されてください。 また、移動性透明と位置のプライバシー(セクション4.7とセクション4.8を見る)の感染は別として、このメカニズムはhandoffsの間、遅れを増強します。
Some of the solutions for Mobile IPv6, such as Fast Handovers for Mobile IPv6 [17], may be able to alleviate the increase in handoff delay.
モバイルIPv6[17]のためのFast HandoversなどのモバイルIPv6のためのソリューションのいくつかが移管遅れの増加を軽減できるかもしれません。
Ng, et al. Informational [Page 12] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [12ページ]情報のRFC4889ネモROスペース分析2007年7月
4.4. Extending Nodes with New Functionalities
4.4. 新しい機能性でノードについて敷衍しています。
In order to support NEMO Route Optimization, some nodes need to be changed or upgraded. Smaller number of nodes required to be changed will allow for easier adoption of the NEMO Route Optimization solution in the Internet and create less impact on existing Internet infrastructure. The number and the types of nodes involved with new functionalities also affect how much of the route is optimized. In addition, it may also be beneficial to reuse existing protocols (such as Mobile IPv6) as much as possible.
ネモRoute Optimizationをサポートするために、いくつかのノードが、変えるか、またはアップグレードする必要があります。 変えるのに必要であるより少ない数のノードが、インターネットでネモRoute Optimizationソリューションの、より簡単な採用を考慮して、より少ない影響を既存のインターネット基盤に作成するでしょう。 また、新しい機能性にかかわるノードの数とタイプは、ルートのいくらが最適化されているかに影響します。 また、さらに、既存のプロトコル(モバイルIPv6などの)をできるだけ再利用するのも有益であるかもしれません。
Possible nodes that may be required to change include the following:
変化しなければならないかもしれない可能なノードが以下を含んでいます:
o Local Fixed Nodes
o ローカルの固定ノード
It may prove to be difficult to introduce new functionalities at
Local Fixed Nodes, since by definition, any IPv6 node can be a
Local Fixed Node. This might mean that only those Local Fixed
Nodes that are modified can enjoy the benefits of Route
Optimization.
それはLocal Fixed Nodesで新しい機能性を紹介するのが難しいと判明するかもしれません、どんなIPv6ノードも定義上Local Fixed Nodeであるかもしれないので。 これは、それらの変更されたLocal Fixed NodesだけがRoute Optimizationの利益を持つことができることを意味するかもしれません。
o Visiting Mobile Nodes
o 訪問のモバイルノード
Visiting Mobile Nodes in general should already implement Mobile
IPv6 functionalities, and since Mobile IPv6 is a relatively new
standard, there is still a considerable window to allow mobile
devices to implement new functionalities.
一般に、訪問のモバイルNodesは既にモバイルIPv6の機能性を実装するはずです、そして、モバイルIPv6が比較的新しい規格であるので、モバイル機器が新しい機能性を実装するのを許容するために、かなりの窓がまだあります。
o Mobile Routers
o モバイルルータ
It is expected that Mobile Routers will implement new
functionalities in order to support Route Optimization.
モバイルRoutersがRoute Optimizationをサポートするために新しい機能性を実装すると予想されます。
o Access Routers
o アクセスルータ
Some approaches require access routers, or nodes in the access
network, to implement some new functionalities. It may prove to
be difficult to do so, since access routers are, in general,
standard IPv6 routers.
いくつかのアプローチがアクセスルータを必要とするか、またはアクセスにおけるノードはいくつかの新しい機能性を道具にネットワークでつなぎます。 それは、アクセスルータが一般に標準のIPv6ルータであるので、そうするのが難しいと判明するかもしれません。
o Home Agents
o ホームのエージェント
It is relatively easier for new functionalities to be implemented
in Home Agents.
新しい機能性がホームのエージェントで実装されるのは、比較的簡単です。
Ng, et al. Informational [Page 13] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [13ページ]情報のRFC4889ネモROスペース分析2007年7月
o Correspondent Nodes
o 通信員ノード
It may prove to be difficult to introduce new functionalities at
Correspondent Nodes, since by definition, any IPv6 node can be a
Correspondent Node. This might mean that only those Correspondent
Nodes that are modified can enjoy the benefits of Route
Optimization.
それはCorrespondent Nodesで新しい機能性を紹介するのが難しいと判明するかもしれません、どんなIPv6ノードも定義上Correspondent Nodeであるかもしれないので。 これは、それらの変更されたCorrespondent NodesだけがRoute Optimizationの利益を持つことができることを意味するかもしれません。
o Correspondent Routers
o 通信員ルータ
Correspondent Routers are new entities introduced for the purpose
of Route Optimization, and therefore new functionalities can be
defined as needed.
通信員RoutersはRoute Optimizationの目的のために導入された新しい実体です、そして、したがって、必要に応じて新しい機能性は定義できます。
4.5. Detection of New Functionalities
4.5. 新しい機能性の検出
One issue that is related to the need for new functionalities as described in Section 4.4 is the need to detect the existence of such functionalities. In these cases, a detection mechanism might be helpful to allow the initiator of Route Optimization to detect whether support for the new functionalities is available. Furthermore, it might be advantageous to have a graceful fall back procedure if the required functionalities are unavailable.
セクション4.4で説明されるように新しい機能性の必要性に関連する1冊はそのような機能性の存在を検出する必要性です。 これらの場合では、検出メカニズムは、Route Optimizationの創始者が、新しい機能性のサポートが利用可能であるかどうか検出するのを許容するために役立っているかもしれません。 その上、必要な機能性が入手できないなら優雅な低下に手順を支持させるのは、有利であるかもしれません。
4.6. Scalability
4.6. スケーラビリティ
Given the same number of nodes, the number of Route Optimization sessions would usually be more than the number of NEMO Basic Support tunnels. If all Route Optimization sessions of a mobile network are maintained by a single node (such as the Mobile Router), this would mean that the single node has to keep track of the states of all Route Optimization sessions. This may lead to scalability issues especially when that single node is a mobile device with limited memory and processing resources.
同じ数のノードを考えて、通常、Route Optimizationセッションの数はネモBasic Supportトンネルの数より多いでしょう。 モバイルネットワークのすべてのRoute Optimizationセッションがただ一つのノード(モバイルRouterなどの)によって維持されるなら、これは、ただ一つのノードがすべてのRoute Optimizationセッションの州の動向をおさえなければならないことを意味するでしょう。 特にそのただ一つのノードが限られたメモリと処理リソースがあるモバイル機器であるときに、これはスケーラビリティ問題に通じるかもしれません。
A similar scalability issue may be faced by a Correspondent Entity as well if it maintains many route-optimized sessions on behalf of a Correspondent Node(s) with a large number of Mobile Routers.
多くのモバイルRoutersとCorrespondent Node(s)を代表して多くのルートで最適化されたセッションを維持するなら、同様のスケーラビリティ問題はまた、Correspondent Entityによって直面されるかもしれません。
4.7. Mobility Transparency
4.7. 移動性透明
One advantage of NEMO Basic Support is that the Mobile Network Nodes need not be aware of the actual location and mobility of the mobile network. With some approaches for Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Mobile Network Nodes. This may mean a tradeoff between mobility transparency and Route Optimization.
ネモBasic Supportの1つの利点はモバイルNetwork Nodesがモバイルネットワークの実際の場所と移動性を意識している必要はないということです。 Route Optimizationのためのいくつかのアプローチによって、モバイルRouterの接着点をモバイルNetwork Nodesに明らかにするのが必要であるかもしれません。 これは移動性透明とRoute Optimizationの間の見返りを意味するかもしれません。
Ng, et al. Informational [Page 14] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [14ページ]情報のRFC4889ネモROスペース分析2007年7月
4.8. Location Privacy
4.8. 位置のプライバシー
Without Route Optimization, the Correspondent Nodes are not aware of the actual location and mobility of the mobile network and its Mobile Network Nodes. To achieve Route Optimization, it might be necessary to reveal the point of attachment of the Mobile Router to the Correspondent Nodes. This may mean a tradeoff between location privacy [18] and Route Optimization.
Route Optimizationがなければ、Correspondent NodesはモバイルネットワークとそのモバイルNetwork Nodesの実際の場所と移動性を意識していません。 Route Optimizationを達成するために、モバイルRouterの接着点をCorrespondent Nodesに明らかにするのが必要であるかもしれません。 これは位置のプライバシー[18]とRoute Optimizationの間の見返りを意味するかもしれません。
In Mobile IPv6, a mobile node can decide whether or not to perform Route Optimization with a given Correspondent Node. Thus, the mobile node is in control of whether to trade location privacy for an optimized route. In NEMO Route Optimization, if the decision to perform Router Optimization is made by the Mobile Router, it will be difficult for Mobile Network Nodes to control the decision of having this tradeoff.
モバイルIPv6では、モバイルノードは、与えられたCorrespondent Nodeと共にRoute Optimizationを実行するかどうか決めることができます。 したがって、モバイルノードは位置のプライバシーを最適化されたルートに取り引きするかどうかに関するコントロール中です。 ネモRoute Optimizationでは、Router Optimizationを実行するという決定がモバイルRouterによってされると、モバイルNetwork Nodesがこの見返りを持つ決定を制御するのは、難しいでしょう。
4.9. Security Consideration
4.9. 警備上の配慮
As Mobile Router and Home Agent usually belong to the same administration domain, it is likely that there exists a security association between them, which is leveraged by NEMO Basic Support to conduct the home Binding Update in a secure way. However, NEMO Route Optimization usually involves nodes from different domains (for example, Mobile Router and Correspondent Entity); thus, the existence of such a security association is not a valid assumption in many deployment scenarios. For this reason, the security protection of NEMO Route Optimization signaling message is considered "weaker" than that in NEMO Basic Support. It is expected that some additional security mechanisms are needed to achieve the same or similar level of security as in NEMO Basic Support.
モバイルRouterとホームのエージェントが通常同じ管理ドメインに属すとき、それらの間のセキュリティ協会は存在しそうです。(それは、安全な方法でホームBinding Updateを行うためにネモBasic Supportによって利用されます)。 しかしながら、通常、ネモRoute Optimizationは異なったドメイン(例えば、モバイルRouterとCorrespondent Entity)からのノードにかかわります。 したがって、そのようなセキュリティ協会の存在は多くの展開シナリオで有効な仮定ではありません。 この理由で、ネモRoute Optimizationシグナリングメッセージの機密保持は「ネモBasic Supportのそれより弱い」と考えられます。 いくつかの追加担保メカニズムがネモBasic Supportのように同じであるか同様のレベルのセキュリティを達成するのに必要であると予想されます。
When considering security issues of NEMO Route Optimization, it might be useful to keep in mind some of the security issues considered when Mobile IPv6 Route Optimization was designed as documented in [19].
ネモRoute Optimizationの安全保障問題を考えるとき、安全保障問題のいくつかが、モバイルIPv6 Route Optimizationがいつ[19]に記録されるように設計されたかを考えたのを覚えておくのは役に立つかもしれません。
4.10. Support of Legacy Nodes
4.10. レガシーノードのサポート
NEMO Basic Support is designed so that all legacy Mobile Network Nodes (such as those that are not aware of the mobility of the network they are in, and those that do not understand any mobility protocols) can still reach and be reached from the Internet. Some Route Optimization schemes, however, require that all Mobile Routers implement the same Route Optimization scheme in order for them to operate. Thus, a nested Mobile Router may not be able to achieve Route Optimization if it is attached to a legacy Local Fixed Router.
ネモBasic Supportは、すべてのレガシーのモバイルNetwork Nodes(彼らがいるネットワークの移動性を意識していないものや、どんな移動性プロトコルも理解していないものなどの)がまだ達していて、インターネットから達することができるように、設計されています。 しかしながら、いくつかのRoute Optimization体系が、彼らが操作するようにすべてのモバイルRoutersが同じRoute Optimization体系を実装するのを必要とします。 したがって、それがレガシーLocal Fixed Routerに付けられるなら、入れ子にされたモバイルRouterはRoute Optimizationを達成できないかもしれません。
Ng, et al. Informational [Page 15] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [15ページ]情報のRFC4889ネモROスペース分析2007年7月
5. Analysis of Solution Space
5. ソリューションスペースの分析
As described in Section 3, there are various different approaches to achieve Route Optimization in Network Mobility Support. In this section, we attempt to analyze the vast solution space of NEMO Route Optimization by asking the following questions:
セクション3で説明されるように、Network Mobility SupportでRoute Optimizationを達成するために、様々な異なるアプローチがあります。 このセクションでは、私たちは、以下の質問をすることによってネモRoute Optimizationの広大なソリューションスペースを分析するのを試みます:
1. Which entities are involved?
1. どの実体がかかわりますか?
2. Who initiates Route Optimization? When?
2. だれがRoute Optimizationを開始しますか? いつですか?
3. How is Route Optimization capabilities detected?
3. Route Optimizationはどのように検出された能力ですか?
4. How is the address of the Mobile Network Node represented?
4. モバイルNetwork Nodeのアドレスはどのように表されますか?
5. How is the Mobile Network Node's address bound to location?
5. モバイルNetwork Nodeのアドレスはどのように位置に縛られますか?
6. How is signaling performed?
6. シグナリングはどのように実行されますか?
7. How is data transmitted?
7. データはどのように送られますか?
8. What are the security considerations?
8. セキュリティ問題は何ですか?
5.1. Which Entities Are Involved?
5.1. どの実体がかかわりますか?
There are many combinations of entities involved in Route Optimization. When considering the role each entity plays in Route Optimization, one has to bear in mind the considerations described in Section 4.4 and Section 4.5. Below is a list of combinations to be discussed in the following sub-sections:
Route Optimizationにかかわる実体の多くの組み合わせがあります。 各実体がRoute Optimizationで果たす役割を考えるとき、人はセクション4.4とセクション4.5で説明された問題を覚えておかなければなりません。 以下に、以下の小区分で議論されるべき組み合わせのリストがあります:
o Mobile Network Node and Correspondent Node
o モバイルネットワーク・ノードと通信員ノード
o Mobile Router and Correspondent Node
o モバイルルータと通信員ノード
o Mobile Router and Correspondent Router
o モバイルルータと通信員ルータ
o Entities in the Infrastructure
o インフラストラクチャにおける実体
5.1.1. Mobile Network Node and Correspondent Node
5.1.1. モバイルネットワーク・ノードと通信員ノード
A Mobile Network Node can establish Route Optimization with its Correspondent Node, possibly the same way as a Mobile Node establishes Route Optimization with its Correspondent Node in Mobile IPv6. This would achieve the most optimal route, since the entire end-to-end path is optimized. However, there might be scalability issues since both the Mobile Network Node and the Correspondent Node may need to maintain many Route Optimization sessions. In addition,
モバイルNetwork NodeはCorrespondent Nodeと共にRoute Optimizationを設立できます、ことによるとずっとモバイルNodeがモバイルIPv6のCorrespondent Nodeと共にRoute Optimizationを設立するのと同じです。 終わりから端への全体の経路が最適化されているので、これは最も最適のルートを達成するでしょう。 しかしながら、モバイルNetwork NodeとCorrespondent Nodeの両方が、多くのRoute Optimizationセッションを維持する必要があるかもしれないので、スケーラビリティ問題があるかもしれません。 さらに
Ng, et al. Informational [Page 16] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [16ページ]情報のRFC4889ネモROスペース分析2007年7月
new functionalities would be required for both the Mobile Network Node and Correspondent Node. For the Mobile Network Node, it needs to be able to manage its mobility, and possibly be aware of the mobility of its upstream Mobile Router(s). For the Correspondent Node, it needs to be able to maintain the bindings sent by the Mobile Network Nodes.
新しい機能性がモバイルNetwork NodeとCorrespondent Nodeの両方に必要でしょう。 モバイルNetwork Nodeのために、それは移動性に対処できて、ことによると上流のモバイルRouter(s)の移動性を意識している必要があります。 Correspondent Nodeのために、それは、モバイルNetwork Nodesによって送られた結合を維持できる必要があります。
5.1.2. Mobile Router and Correspondent Node
5.1.2. モバイルルータと通信員ノード
Alternatively, the Mobile Router can establish Route Optimization with a Correspondent Node on behalf of the Mobile Network Node. Since all packets to and from the Mobile Network Node must transit the Mobile Router, this effectively achieves an optimal route for the entire end-to-end path as well. Compared with Section 5.1.1, the scalability issue here may be remedied since it is possible for the Correspondent Node to maintain only one session with the Mobile Router if it communicates with many Mobile Network Nodes associated with the same Mobile Router. Furthermore, with the Mobile Router handling Route Optimization, there is no need for Mobile Network Nodes to implement new functionalities. However, new functionality is likely to be required on the Correspondent Node. An additional point of consideration is the amount of state information the Mobile Router is required to maintain. Traditionally, it has been generally avoided having state information in the routers to increase proportionally with the number of pairs of communicating peers.
あるいはまた、モバイルRouterはモバイルNetwork Nodeを代表してCorrespondent Nodeと共にRoute Optimizationを設立できます。 Network Nodeと、そして、モバイルNetwork NodeからのすべてのパケットがモバイルRouterを通過しなければならないので、事実上、これはまた、終わりから端への全体の経路に最適のルートを達成します。 セクション5.1.1と比べて、同じモバイルRouterに関連している多くのモバイルNetwork Nodesとコミュニケートするなら、Correspondent NodeがモバイルRouterとの1つのセッションだけを維持するのが、可能であるので、ここのスケーラビリティ問題は改善されるかもしれません。 その上、モバイルNetwork Nodesが新しい機能性を実装する必要は全くモバイルRouter取り扱いRoute Optimizationと共にありません。 しかしながら、新しい機能性がCorrespondent Nodeで必要でありそうです。 考慮の追加ポイントはモバイルRouterが保守していなければならない州の情報の量です。 一般に、交信している同輩の組の数に従って比例して増強するルータにおける州の情報を持っていて、伝統的に、それは避けられました。
5.1.3. Mobile Router and Correspondent Router
5.1.3. モバイルルータと通信員ルータ
Approaches involving Mobile Routers and Correspondent Routers are described in Section 3.1. The advantage of these approaches is that no additional functionality is required for the Correspondent Node and Mobile Network Nodes. In addition, location privacy is relatively preserved, since the current location of the mobile network is only revealed to the Correspondent Router and not to the Correspondent Node (please refer to Section 5.8.3 for more discussions). Furthermore, if the Mobile Router and Correspondent Router exchange prefix information, this approach may scale well since a single Route Optimization session between the Mobile Router and Correspondent Router can achieve Route Optimization between any Mobile Network Node in the mobile network, and any Correspondent Node managed by the Correspondent Router.
モバイルRoutersとCorrespondent Routersにかかわるアプローチがセクション3.1で説明されます。 これらのアプローチの利点は追加機能性が全くCorrespondent NodeとモバイルNetwork Nodesに必要でないということです。 さらに、位置のプライバシーは比較的保存されています、モバイルネットワークの現在の位置がCorrespondent Nodeではなく、Correspondent Routerに明らかにされるだけであるので(より多くの議論についてセクション5.8.3を参照してください)。 その上、モバイルRouterとCorrespondent Router交換が情報を前に置くなら、モバイルRouterとCorrespondent Routerとのただ一つのRoute OptimizationセッションがモバイルネットワークにおけるどんなモバイルNetwork Nodeと、Correspondent Routerによって管理されたどんなCorrespondent Nodeの間にもRoute Optimizationを実現できるので、このアプローチはよく比例するかもしれません。
The main concern with this approach is the need for a mechanism to allow the Mobile Router to detect the presence of the Correspondent Router (see Section 5.3 for details), and its security impact. Both the Mobile Router and the Correspondent Router need some means to verify the validity of each other. This is discussed in greater detail in Section 5.8.
このアプローチがある主な関心事は、モバイルRouterがメカニズムでCorrespondent Router(詳細に関してセクション5.3を見る)の存在を検出できる必要性と、そのセキュリティ影響です。 モバイルRouterとCorrespondent Routerの両方が互いの正当性について確かめるいくつかの手段を必要とします。 セクション5.8で詳細によりすばらしいこれについて議論します。
Ng, et al. Informational [Page 17] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [17ページ]情報のRFC4889ネモROスペース分析2007年7月
A deployment consideration with respect to the use of Correspondent Router is the location of the Correspondent Router relative to the Correspondent Node. On one hand, deploying the Correspondent Router nearer to the Correspondent Node would result in a more optimal path. On the other hand, a Correspondent Router that is placed farther away from the Correspondent Node can perform Route Optimization on behalf of more Correspondent Nodes.
Correspondent Routerの使用に関する展開の考慮はCorrespondent Nodeに比例したCorrespondent Routerの位置です。 一方では、Correspondent Nodeにより近いCorrespondent Routerを配布すると、より最適の経路はもたらされるでしょう。 他方では、Correspondent Nodeからより遠くに遠くに置かれるCorrespondent Routerは、より多くのCorrespondent Nodesを代表してRoute Optimizationを実行できます。
5.1.4. Entities in the Infrastructure
5.1.4. インフラストラクチャにおける実体
Approaches using entities in the infrastructure are described in Section 3.3. The advantages of this approach include, firstly, not requiring new functionalities to be implemented on the Mobile Network Nodes and Correspondent Nodes, and secondly, having most of the complexity shifted to nodes in the infrastructure. However, one main issue with this approach is how the Mobile Router can detect the presence of such entities, and why the Mobile Router should trust these entities. This may be easily addressed if such entity is a Home Agent of the Mobile Router (such as in the global Home Agent to Home Agent protocol [14]). Another concern is that the resulting path may not be a true optimized one, since it depends on the relative positions of the infrastructure entities with respect to the mobile network and the Correspondent Node.
インフラストラクチャに実体を使用するアプローチがセクション3.3で説明されます。 このアプローチの利点は、まず第一に新しい機能性がモバイルNetwork NodesとCorrespondent Nodesに、第二に実装されるのが必要であることを含んでいません、インフラストラクチャで複雑さの大部分をノードに移行させて。 しかしながら、このアプローチの1つの本題はモバイルRouterがどのようにそのような実体の存在を検出できるか、そして、モバイルRouterがなぜこれらの実体を信じるはずであるかということです。 これはそのような実体がモバイルRouterのホームのエージェントであるなら容易に扱われるかもしれません。(ホームエージェントプロトコル[14])へのグローバルなホームのエージェントなどのように。 別の関心は結果として起こる経路が本当の最適化されたものでないかもしれないということです、モバイルネットワークとCorrespondent Nodeに関してインフラストラクチャ実体の相対的な位置によるので。
5.2. Who Initiates Route Optimization? When?
5.2. だれが経路最適化を開始しますか? いつですか?
Having determined the entities involved in the Route Optimization in the previous sub-section, the next question is which of these entities should initiate the Route Optimization session. Usually, the node that is moving (i.e., Mobile Network Node or Mobile Router) is in the best position to detect its mobility. Thus, in general, it is better for the mobile node to initiate the Route Optimization session in order to handle the topology changes in any kind of mobility pattern and achieve the optimized route promptly. However, when the mobile node is within a nested mobile network, the detection of the mobility of upstream Mobile Routers may need to be conveyed to the nested Mobile Network Node. This might incur longer signaling delay as discussed in Section 4.3.
前の小区分でRoute Optimizationにかかわる実体を決定したので、次の質問はこれらの実体のどれがRoute Optimizationセッションを開始するべきであるかということです。 通常、移行しているノード(すなわち、モバイルNetwork NodeかモバイルRouter)が移動性を検出する最も良い立場にあります。 このようにして、そして、一般に、モバイルノードがどんな種類の移動パターンにおけるトポロジー変化も扱うためにRoute Optimizationセッションを開始して、即座に最適化されたルートを実現するのは、より良いです。 しかしながら、入れ子にされたモバイルネットワークの中にモバイルノードがあるとき、上流のモバイルRoutersの移動性の検出は、入れ子にされたモバイルNetwork Nodeまで運ばれる必要があるかもしれません。 これはセクション4.3で議論するように、より長いシグナリング遅れを被るかもしれません。
Some solution may enable the node on the correspondent side to initiate the Route Optimization session in certain situations. For instance, when the Route Optimization state that is already established on the Correspondent Entity is about to expire but the communication is still active, depending on the policy, the Correspondent Entity may initiate a Route Optimization request with the mobile node side.
何らかの解決法は、通信員側の上のノードが、ある状況におけるRoute Optimizationセッションを開始するのを可能にするかもしれません。 例えば、Correspondent Entityで既に設置されるRoute Optimization状態が期限が切れようとしていますが、方針によって、コミュニケーションがまだアクティブであるときに、Correspondent Entityはモバイルノード側でRoute Optimization要求を開始するかもしれません。
Ng, et al. Informational [Page 18] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [18ページ]情報のRFC4889ネモROスペース分析2007年7月
There is also the question of when Route Optimization should be initiated. Because Route Optimization would certainly incur tradeoffs of various forms, it might not be desirable for Route Optimization to be performed for any kind of traffic. This is, however, implementation specific and policy driven.
また、Route Optimizationが開始されるべきである時に関する質問があります。 確かに、Route Optimizationは様々なフォームの見返りを被るでしょう、したがって、Route Optimizationがどんな種類のトラフィックのためにも実行されるのが、望ましくないかもしれません。 これは、しかしながら、実装特有であって、方針駆動です。
A related question is how often signaling messages should be sent to maintain the Route Optimization session. Typically, signaling messages are likely to be sent whenever there are topological changes. The discussion in Section 4.1 should be considered. In addition, a Lifetime value is often used to indicate the period of validity for the Route Optimization session. Signaling messages would have to be sent before the Lifetime value expires in order to maintain the Route Optimization session. The choice of Lifetime value needs to balance between different considerations. On one hand, a short Lifetime value would increase the amount of signaling overhead. On the other hand, a long Lifetime value may expose the Correspondent Entity to the risk of having an obsolete binding cache entry, which creates an opportunity for an attacker to exploit.
関連する質問はRoute Optimizationセッションを維持するためにどうしばしばメッセージに合図するのを送るべきであるかということです。 位相的な変化があるときはいつも、通常、シグナリングメッセージは送られそうです。 セクション4.1における議論は考えられるべきです。 さらに、Lifetime値は、Route Optimizationセッションのために正当性の期間を示すのにしばしば使用されます。 Lifetime値がRoute Optimizationセッションを維持するために期限が切れる前にシグナリングメッセージを送らなければならないでしょう。 Lifetime価値の選択は、異なった問題の間でバランスをとる必要があります。 一方では、短いLifetime値はシグナリングオーバーヘッドの量を増強するでしょう。 他方では、長いLifetime値は攻撃者が利用する機会を作成する時代遅れの拘束力があるキャッシュエントリーを持つリスクにCorrespondent Entityを暴露するかもしれません。
5.3. How Is Route Optimization Capability Detected?
5.3. 経路最適化能力はどのように検出されますか?
The question here is how the initiator of Route Optimization knows whether the Correspondent Entity supports the functionality required to established a Route Optimization session. The usual method is for the initiator to attempt Route Optimization with the Correspondent Entity. Depending on the protocol specifics, the initiator may receive (i) a reply from the Correspondent Entity indicating its capability, (ii) an error message from the Correspondent Entity, or (iii) no response from the Correspondent Entity within a certain time period. This serves as an indication of whether or not the Correspondent Entity supports the required functionality to establish Route Optimization. This form of detection may incur additional delay as a penalty when the Correspondent Entity does not have Route Optimization capability, especially when the Route Optimization mechanism is using in-band signaling.
Route Optimizationの創始者が、Correspondent Entityが必要な状態で機能性をサポートするかどうかがRoute Optimizationセッションを確立したのをどのように知っているかという質問がここにあります。 普通のメソッドは創始者がCorrespondent Entityと共にRoute Optimizationを試みることです。 プロトコル詳細によって、創始者はCorrespondent Entityからの(ii)エラーメッセージを示しますが、ある期間以内にCorrespondent Entityから能力、どんな(iii)応答も示さないCorrespondent Entityから(i) 回答を受け取るかもしれません。 これはCorrespondent EntityがRoute Optimizationを証明するために必要な機能性をサポートするかどうかしるしとして機能します。 Correspondent EntityにRoute Optimization能力がないとき、この形式の検出は刑罰として追加遅れを被るかもしれません、特にRoute Optimizationメカニズムがバンドにおけるシグナリングを使用しているとき。
When the Correspondent Entity is not the Correspondent Node but a Correspondent Router, an immediate question is how its presence can be detected. One approach is for the initiator to send an Internet Control Message Protocol (ICMP) message containing the address of the Correspondent Node to a well-known anycast address reserved for all Correspondent Routers [7][8]. Only the Correspondent Router that is capable of terminating the Route Optimization session on behalf of the Correspondent Node will respond. Another way is to insert a Router Alert Option (RAO) into a packet sent to the Correspondent Node [9]. Any Correspondent Router en route will process the Router Alert Option and send a response to the Mobile Router.
Correspondent EntityがCorrespondent Nodeではなく、Correspondent Routerであるときに、当面の問題はどう存在を検出できるかということです。 1つのアプローチは創始者がすべてのCorrespondent Routers[7][8]のために予約されたよく知られるanycastアドレスにCorrespondent Nodeのアドレスを含むインターネット・コントロール・メッセージ・プロトコル(ICMP)メッセージを送ることです。 Correspondent Nodeを代表してRoute Optimizationセッションを終えることができるCorrespondent Routerだけが応じるでしょう。 別の方法はRouter Alert Option(RAO)をCorrespondent Node[9]に送られたパケットに挿入することです。 途中どんなCorrespondent RouterもモバイルRouterにRouter Alert Optionを処理して、応答を送るでしょう。
Ng, et al. Informational [Page 19] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [19ページ]情報のRFC4889ネモROスペース分析2007年7月
Both approaches need to consider the possibility of multiple Correspondent Routers responding to the initiator, and both approaches will generate additional traffic or processing load to other routers. Furthermore, both approaches have yet to consider how the initiator can verify the authenticity of the Correspondent Routers that responded.
追加トラフィックか処理が負荷であると両方のアプローチは、複数のCorrespondent Routersが創始者に応じる可能性を考える必要があって、両方のアプローチは、他のルータに生成するでしょう。 その上、両方のアプローチは、創始者がどうしたら応じたCorrespondent Routersの信憑性について確かめることができるかをまだ考えていません。
5.4. How is the Address of the Mobile Network Node Represented?
5.4. モバイルNetwork Node RepresentedのAddressはいかがでしょうか?
Normally, Route Optimization would mean that a binding between the address of a Mobile Network Node and the location of the mobile network is registered at the Correspondent Entity. Before exploring different ways of binding (see Section 5.5), one must first ask how the address of the Mobile Network Node is represented. Basically, there are two ways to represent the Mobile Network Node's address:
通常、Route Optimizationは、モバイルNetwork Nodeのアドレスとモバイルネットワークの位置の間の結合がCorrespondent Entityに登録されることを意味するでしょう。 結合(セクション5.5を見る)の異なった方法を探る前に、最初に、モバイルNetwork Nodeのアドレスがどのように表されるかを尋ねなければなりません。 基本的に、モバイルNetwork Nodeのアドレスを表す2つの方法があります:
o inferred by the use of the Mobile Network Prefix, or
o またはモバイルNetwork Prefixの使用で推論される。
o explicitly specifying the address of the Mobile Network Node.
o 明らかに、モバイルNetwork Nodeのアドレスを指定します。
Using the Mobile Network Prefix would usually mean that the initiator is the Mobile Router, and has the benefit of binding numerous Mobile Network Nodes with one signaling. However, it also means that if location privacy is compromised, the location privacy of an entire Mobile Network Prefix would be compromised.
モバイルNetwork Prefixを使用するのは、通常、創始者がモバイルRouterであることを意味して、1つが合図している拘束力がある多数のモバイルNetwork Nodesの利益を持っています。 しかしながら、また、それは、位置のプライバシーが感染されるなら、全体のモバイルNetwork Prefixの位置のプライバシーが感染されることを意味します。
On the other hand, using the Mobile Network Node's address would mean that either the initiator is the Mobile Network Node itself or the Mobile Router is initiating Route Optimization on behalf of the Mobile Network Node. Initiation by the Mobile Network Node itself means that the Mobile Network Node must have new functionalities implemented, while initiation by the Mobile Router means that the Mobile Router must maintain some Route Optimization states for each Mobile Network Node.
他方では、モバイルNetwork Nodeのアドレスを使用するのは、創始者がモバイルNetwork Node自身であるかモバイルRouterがモバイルNetwork Nodeを代表してRoute Optimizationを開始していることを意味するでしょう。 モバイルNetwork Node自身による開始は、モバイルNetwork Nodeが新しい機能性を実装させなければならないと言っています、モバイルRouterによる開始は、モバイルRouterがそれぞれのモバイルNetwork NodeのためにいくつかのRoute Optimization州を維持しなければならないと言っていますが。
5.5. How Is the Mobile Network Node's Address Bound to Location?
5.5. モバイルネットワークノードのアドレスはどのように位置に縛られますか?
In order for route to be optimized, it is generally necessary for the Correspondent Entity to create a binding between the address and the location of the Mobile Network Node. This can be done in the following ways:
一般に、ルートが最適化されるために、Correspondent EntityがモバイルNetwork Nodeのアドレスと位置の間で結合を作成するのが必要です。 以下の方法でこれができます:
o binding the address to the location of the parent Mobile Router,
o アドレスを親のモバイルRouterの位置まで縛ります。
o binding the address to a sequence of upstream Mobile Routers, and
o そして上流のモバイルRoutersの系列にアドレスを縛る。
o binding the address to the location of the root Mobile Router.
o アドレスを根のモバイルRouterの位置まで縛ります。
Ng, et al. Informational [Page 20] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [20ページ]情報のRFC4889ネモROスペース分析2007年7月
These are described in the following sub-sections.
これらは以下の小区分で説明されます。
5.5.1. Binding to the Location of Parent Mobile Router
5.5.1. 親のモバイルルータの位置まで付きます。
By binding the address of Mobile Network Node to the location of its parent Mobile Router, the Correspondent Entity would know how to reach the Mobile Network Node via the current location of the parent Mobile Router. This can be done by:
モバイルNetwork Nodeのアドレスを親のモバイルRouterの位置まで縛ることによって、Correspondent Entityは親のモバイルRouterの現在の位置を通ってモバイルNetwork Nodeに達する方法を知っているでしょう。 以下はこれができます。
o Binding Update with Mobile Network Prefix
o モバイルネットワーク接頭語との拘束力があるアップデート
This can be viewed as a logical extension to NEMO Basic Support,
where the Mobile Router would send binding updates containing one
or more Mobile Network Prefix options to the Correspondent Entity.
The Correspondent Entity having received the Binding Update, can
then set up a bi-directional tunnel with the Mobile Router at the
current Care-of Address of the Mobile Router, and inject a route
to its routing table so that packets destined for addresses in the
Mobile Network Prefix would be routed through the bi-directional
tunnel.
論理的な拡大としてネモBasic Supportにおいてこれを見なすことができます。そこでは、モバイルRouterが1つ以上のモバイルNetwork PrefixオプションをCorrespondent Entityに含む拘束力があるアップデートを送るでしょう。 次に、Correspondent EntityがBinding Updateを受けた場合、電流のモバイルRouterと共に双方向のトンネルを設立できる、Care、-、モバイルRouterのAddress、モバイルNetwork Prefixのアドレスのために運命づけられたパケットが双方向のトンネルを通って発送されるように、経路指定テーブルにルートを注入してください。
Note that in this case, the address of the Mobile Network Node is
implied by the Mobile Network Prefix (see Section 5.4).
この場合モバイルNetwork NodeのアドレスがモバイルNetwork Prefixによって含意されることに注意してください(セクション5.4を見てください)。
o Sending Information of Parent Mobile Router
o 親のモバイルルータに関する送付情報
This involves the Mobile Network Node sending the information of
its Mobile Router to the Correspondent Entity, thus allowing the
Correspondent Entity to establish a binding between the address of
the Mobile Network Node to the location of the parent Mobile
Router. An example of such an approach would be [11].
これはモバイルRouterの情報をCorrespondent Entityに送るモバイルNetwork Nodeにかかわります、その結果、Correspondent EntityがモバイルNetwork Nodeのアドレスの間の結合を親のモバイルRouterの位置に確立するのを許容します。 そのようなアプローチに関する例は[11]でしょう。
o Mobile Router as a Proxy
o プロキシとしてのモバイルルータ
Another approach is for the parent Mobile Router to act as a
"proxy" for its Mobile Network Nodes. In this case, the Mobile
Router uses the standard Mobile IPv6 Route Optimization procedure
to bind the address of a Mobile Network Node to the Mobile
Router's Care-of Address. For instance, when the Mobile Network
Node is a Local Fixed Node without Mobile IPv6 Route Optimization
functionality, the Mobile Router may initiate the Return
Routability procedure with a Correspondent Node on behalf of the
Local Fixed Node. An example of such an approach would be
[20][21][22].
別のアプローチは親のモバイルRouterがモバイルNetwork Nodesの「プロキシ」として機能することです。 この場合モバイルRouterがモバイルRouterのものにモバイルNetwork Nodeのアドレスを縛るのに標準のモバイルIPv6 Route Optimization手順を用いる、Care、-、Address。 例えば、モバイルNetwork NodeがモバイルIPv6 Route Optimizationの機能性がなければLocal Fixed Nodeであるときに、モバイルRouterはLocal Fixed Nodeを代表してCorrespondent Nodeと共にReturn Routability手順に着手するかもしれません。 そのようなアプローチに関する例は[20][21][22]でしょう。
On the other hand, if the Mobile Network Node is a Visiting Mobile
Node, it might be necessary for the Visiting Mobile Node to
delegate the rights of Route Optimization signaling to the Mobile
他方では、モバイルNetwork NodeがVisitingのモバイルNodeであるなら、VisitingのモバイルNodeがモバイルに合図するRoute Optimizationの権利を代表として派遣するのが必要であるかもしれません。
Ng, et al. Informational [Page 21] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [21ページ]情報のRFC4889ネモROスペース分析2007年7月
Router (see [23] for an example of such delegation). With this
delegation, either the Visiting Mobile Network Node or the Mobile
Router can initiate the Return Routability procedure with the
Correspondent Node. For the case where the Return Routability
procedure is initiated by the Visiting Mobile Node, the Mobile
Router will have to transparently alter the content of the Return
Routability signaling messages so that packets sent from the
Correspondent Node to the Visiting Node will be routed to the
Care-of Address of the Mobile Router once Route Optimization is
established. The case where the Return Routability procedure is
initiated by the Mobile Router is similar to the case where the
Mobile Network Node is a Local Fixed Node.
ルータ(そのような委譲に関する例のための[23]を見ます)。 この委譲で、VisitingのモバイルNetwork NodeかモバイルRouterのどちらかがCorrespondent Nodeと共にReturn Routability手順に着手できます。 Return Routability手順がVisitingのモバイルNodeによって着手されて、モバイルRouterがCorrespondent NodeからVisiting Nodeに送られたパケットに掘られるように透過的にReturn Routabilityシグナリングメッセージの内容を変更しなければならないケース、Care、-、Address、モバイルRouterでは、一度、Route Optimizationは設立されます。 Return Routability手順がモバイルRouterによって着手されるケースはモバイルNetwork NodeがLocal Fixed Nodeであるケースと同様です。
For all of the approaches listed above, when the Mobile Network Node is deeply nested within a Mobile Network, the Correspondent Entity would need to gather Binding Updates from all the upstream Mobile Routers in order to build the complete route to reach the Mobile Network Node. This increases the complexity of the Correspondent Entity, as the Correspondent Entity may need to perform multiple binding cache look-ups before it can construct the complete route.
モバイルNetwork NodeがモバイルNetworkの中で深く入れ子にされるとき上に記載されたアプローチのすべてのために、Correspondent Entityは、モバイルNetwork Nodeに達するように完全なルートを造るためにすべての上流のモバイルRoutersからBinding Updatesを集める必要があるでしょう。 これはCorrespondent Entityの複雑さを増強します、Correspondent Entityが、完全なルートを構成できる前に複数の拘束力があるキャッシュルックアップを実行する必要があるとき。
Other than increasing the complexity of the Correspondent Entity, these approaches may incur extra signaling overhead and delay for a nested Mobile Network Node. For instance, every Mobile Router on the upstream of the Mobile Network Node needs to send Binding Updates to the Correspondent Entity. If this is done by the upstream Mobile Routers independently, it may incur additional signaling overhead. Also, since each Binding Update takes a finite amount of time to reach and be processed by the Correspondent Entity, the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity will increase proportionally with the number of Mobile Routers on the upstream of the Mobile Network Node (i.e., the level of nesting of the Mobile Network Node).
Correspondent Entityの複雑さを増強するのを除いて、これらのアプローチは入れ子にされたモバイルNetwork Nodeのために付加的なシグナリングオーバーヘッドと遅れを被るかもしれません。 例えば、モバイルNetwork Nodeの上流のあらゆるモバイルRouterが、Binding UpdatesをCorrespondent Entityに送る必要があります。 上流のモバイルRoutersが独自にこれを完了しているなら、それは追加シグナリングオーバーヘッドを被るかもしれません。 また、達して、Correspondent Entityによって処理されるには各Binding Updateが有限時かかるので、モバイルNetwork Node(すなわち、モバイルNetwork Nodeの巣篭もりのレベル)の上流のモバイルRoutersの数に従って、最適化されたルートが変えられる時から変化がCorrespondent Entityに登録される時までの遅れは比例して増加するでしょう。
For "Binding Update with Mobile Network Prefix" and "Sending Information of Parent Mobile Router", new functionality is required at the Correspondent Entity, whereas "Mobile Router as a Proxy" keeps the functionality of the Correspondent Entity the same as a Mobile IPv6 Correspondent Node. However, this is done at an expense of the Mobile Routers, since in "Mobile Router as a Proxy", the Mobile Router must maintain state information for every Route Optimization session its Mobile Network Nodes have. Furthermore, in some cases, the Mobile Router needs to look beyond the standard IPv6 headers for ingress and egress packets, and alter the packet contents appropriately (this may impact end-to-end integrity, see 5.8.2).
「モバイルネットワーク接頭語との拘束力があるアップデート」と「親のモバイルルータに関する情報を送ります」に新しい機能性がCorrespondent Entityで必要ですが、「プロキシとしてのモバイルルータ」はモバイルIPv6 Correspondent Nodeと同じにCorrespondent Entityの機能性を保ちます。 しかしながら、モバイルRoutersの費用でこれをします、「プロキシとしてのモバイルルータ」ではモバイルRouterがモバイルNetwork Nodesが持っているあらゆるRoute Optimizationセッションのための州の情報を保守しなければならないので。 いくつかの場合、その上、モバイルRouterは、イングレスと出口パケットのために標準のIPv6ヘッダーの先を見る必要があります、そして、適切にパケットコンテンツを変更してください。(これが終わらせる終わりの保全に影響を与えてもよい、見る、5.8、.2、)
One advantage shared by all the approaches listed here is that only mobility protocol is affected. In other words, no modification is
ここに記載されたすべてのアプローチで共有された1つの利点は移動性プロトコルだけが影響を受けるということです。 言い換えれば、どんな変更もそうではありません。
Ng, et al. Informational [Page 22] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [22ページ]情報のRFC4889ネモROスペース分析2007年7月
required on other existing protocols (such as Neighbor Discovery). There is also no additional requirement on existing infrastructure (such as the access network).
他の既存のプロトコル(Neighborディスカバリーなどの)では、必要です。 また、既存のインフラストラクチャ(アクセスネットワークなどの)に関するどんな追加要件もありません。
In addition, having upstream Mobile Routers send Binding Updates independently means that the Correspondent Entity can use the same binding cache entries of upstream Mobile Routers to construct the complete route to two Mobile Network Nodes that have common upstream Mobile Routers. This may translate to lower memory consumption since the Correspondent Entity need not store one complete route per Mobile Network Node when it is having Route Optimization sessions with multiple Mobile Network Nodes from the same mobile network.
さらに、上流のモバイルRoutersにBinding Updatesを独自に送らせるのがCorrespondent Entityが一般的な上流のモバイルRoutersを持っている2モバイルNetwork Nodesに完全なルートを構成するのに上流のモバイルRoutersの同じ拘束力があるキャッシュエントリーを使用できることを意味します。 これは、それに同じモバイルネットワークからの複数のモバイルNetwork NodesとのRoute Optimizationセッションがあるとき、Correspondent EntityがモバイルNetwork Nodeあたり1つの完全なルートを保存する必要はないのでメモリ消費を下げるために翻訳されるかもしれません。
5.5.2. Binding to a Sequence of Upstream Mobile Routers
5.5.2. 上流のモバイルルータの系列に付きます。
For a nested Mobile Network Node, it might be more worthwhile to bind its address to the sequence of points of attachment of upstream Mobile Routers. In this way, the Correspondent Entity can build a complete sequence of points of attachment from a single transmission of the binding information. Examples using this approach are [10] and [12].
入れ子にされたモバイルNetwork Nodeに関しては、上流のモバイルRoutersのポイントの付属の系列にアドレスを縛るより価値があるかもしれません。 このように、Correspondent Entityは拘束力がある情報のただ一つの伝達からポイントの付属の完全な配列を築き上げることができます。 このアプローチを使用する例は、[10]と[12]です。
Different from Section 5.5.1, this approach constructs the complete route to a specific Mobile Network Node at the mobile network side, thus offering the opportunity to reduce the signaling overhead. Since the complete route is conveyed to the Correspondent Entity in a single transmission, it is possible to reduce the delay from the time an optimized route is changed till the time the change is registered on the Correspondent Entity to its minimum.
セクション5.5.1と異なります、このアプローチはモバイルネットワーク側の特定のモバイルNetwork Nodeに完全なルートを構成します、その結果、シグナリングオーバーヘッドを下げる機会を提供します。 完全なルートがただ一つのトランスミッションでCorrespondent Entityに伝えられるので、遅れを最適化されたルートが変えられる時から変化がCorrespondent Entityに最小限まで登録される時まで減少させるのは可能です。
One question that immediately comes to mind is how the Mobile Network Node gets hold of the sequence of locations of its upstream Mobile Routers. This is usually achieved by having such information inserted as special options in the Router Advertisement messages advertised by upstream Mobile Routers. To do so, not only must a Mobile Router advertise its current location to its Mobile Network Nodes, it must also relay information embedded in Router Advertisement messages it has received from its upstream Mobile Routers. This might imply a compromise of the mobility transparency of a mobile network (see Section 4.7). In addition, it also means that whenever an upstream Mobile Router changes its point of attachment, all downstream Mobile Network Nodes must perform Route Optimization signaling again, possibly leading to a "Signaling Storm" (see Section 4.1).
すぐに思い浮かぶ1つの質問はモバイルNetwork Nodeがどう上流のモバイルRoutersの位置の系列をつかむかということです。 通常、これは、Router Advertisementメッセージにおける特別なオプションが上流のモバイルRoutersで広告を出したようにそのような情報を挿入させることによって、達成されます。 また、そう単にではなくaモバイルRouterが広告を出す必須にモバイルNetwork Nodesへの現在の位置をするために、それはそれが上流のモバイルRoutersから受け取ったRouter Advertisementメッセージに埋め込まれた情報をリレーしなければなりません。 これはモバイルネットワークの移動性透明の感染を含意するかもしれません(セクション4.7を見てください)。 また、さらに、上流のモバイルRouterが接着点を変えるときはいつも、すべての川下のモバイルNetwork Nodesが再びRoute Optimizationシグナリングを実行しなければならないことを意味します、ことによると「シグナリング嵐」に通じて(セクション4.1を見てください)。
A different method of conveying locations of upstream Mobile Routers is (such as used in [10]) where upstream Mobile Routers insert their current point of attachment into a Reverse Routing Header embedded
上流のモバイルRoutersの位置を運ぶ異なったメソッドがそうである、(上流のモバイルRoutersが彼らの現在の接着点をReverseに挿入するルート設定Headerが埋め込んだ[10])では、使用されます。
Ng, et al. Informational [Page 23] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [23ページ]情報のRFC4889ネモROスペース分析2007年7月
within a packet sent by the Mobile Network Node. This may raise security concerns that will be discussed later in Section 5.8.2.
モバイルNetwork Nodeによって送られたパケットの中で。 これは後でセクション5.8.2で議論する安全上の配慮を上げるかもしれません。
In order for a Correspondent Entity to bind the address of a Mobile Network Node to a sequence of locations of upstream Mobile Routers, new functionalities need to be implemented on the Correspondent Entity. The Correspondent Entity also needs to store the complete sequence of locations of upstream Mobile Routers for every Mobile Network Node. This may demand more memory compared to Section 5.5.1 if the same Correspondent Entity has a lot of Route Optimization sessions with Mobile Network Nodes from the same nested Mobile Network. In addition, some amount of modifications or extension to existing protocols is also required, such as a new type of IPv6 routing header or a new option in the Router Advertisement message.
Correspondent Entityが上流のモバイルRoutersの位置の系列にモバイルNetwork Nodeのアドレスを縛るように、新しい機能性は、Correspondent Entityで実装される必要があります。 また、Correspondent Entityは、あらゆるモバイルNetwork Nodeのために上流のモバイルRoutersの位置の完全な配列を保存する必要があります。 同じCorrespondent Entityに同じ入れ子にされたモバイルNetworkからのモバイルNetwork Nodesとの多くのRoute Optimizationセッションがあるならセクション5.5.1と比べて、これは、より多くのメモリを要求するかもしれません。 また、さらに、既存のプロトコルへのいくらかの量の変更か拡大が必要です、新しいタイプのIPv6ルーティングヘッダーやRouter Advertisementメッセージにおける新しいオプションのように。
5.5.3. Binding to the Location of Root Mobile Router
5.5.3. 根のモバイルルータの位置まで付きます。
A third approach is to bind the address of the Mobile Network Node to the location of the root Mobile Router, regardless of how deeply nested the Mobile Network Node is within a nested Mobile Network. Whenever the Correspondent Entity needs to forward a packet to the Mobile Network Node, it only needs to forward the packet to this point of attachment. The mobile network will figure out how to forward the packet to the Mobile Network Node by itself. This kind of approach can be viewed as flattening the structure of a nested Mobile Network, so that it seems to the Correspondent Entity that every node in the Mobile Network is attached to the Internet at the same network segment.
3番目のアプローチがモバイルNetwork Nodeのアドレスを根のモバイルRouterの位置まで縛ることであり、どれくらい深く入れ子にされるかにかかわらず入れ子にされたモバイルNetworkの中にモバイルNetwork Nodeがあります。 Correspondent Entityが、モバイルNetwork Nodeにパケットを送る必要があるときはいつも、それは、付属についてパケットをこの位まで進める必要があるだけです。 モバイルネットワークはそれ自体でモバイルNetwork Nodeにパケットを送る方法を理解するでしょう。 入れ子にされたモバイルNetworkの構造を平らにするとこの種類のアプローチを見なすことができます、モバイルNetworkのあらゆるノードが同じネットワークセグメントでインターネットに添付されるようにCorrespondent Entityにおいて思えるように。
There are various approaches to achieve this:
これを達成するために、様々なアプローチがあります:
o Prefix Delegation
o 接頭語委譲
Here, each Mobile Router in a nested mobile network is delegated a
Mobile Network Prefix from the access router (such as using
Dynamic Host Configuration Protocol (DHCP) Prefix Delegation
[15]). Each Mobile Router also autoconfigures its Care-of Address
from this delegated prefix. In this way, the Care-of Addresses of
Mobile Routers are all from an aggregatable address space starting
from the access router. A Mobile Network Node with Mobile IPv6
functionality may also autoconfigure its Care-of Address from this
delegated prefix, and use standard Mobile IPv6 mechanism's to bind
its Home Address to this Care-of Address.
入れ子にされたモバイルネットワークにおけるそれぞれのモバイルRouterはアクセスルータからのここの、代表として派遣されたaモバイルNetwork Prefixです。(Dynamic Host Configuration Protocol(DHCP)接頭語Delegation[15])を使用するのなどように。 また、それぞれのモバイルRouterが自動構成する、それ、Care、-、これからのAddressは接頭語を代表として派遣しました。 このようにCare、-、モバイルRoutersのAddressesがすべてアクセスルータから始める「集合-可能」アドレス空間からあります。 また、モバイルIPv6の機能性があるモバイルNetwork Nodeが自動構成するかもしれない、それ、Care、-、これからのAddressが接頭語を代表として派遣して、ホームAddressをこれに縛るのに標準のメカニズムのモバイルIPv6ものを使用する、Care、-、Address。
Examples of this approach include [24], [25], and [26].
このアプローチに関する例は[24]、[25]、および[26]を含んでいます。
This approach has the advantage of keeping the implementations of
Correspondent Nodes unchanged. However, it requires the access
このアプローチには、Correspondent Nodesの実装を変わりがなく保つ利点があります。 しかしながら、それはアクセスを必要とします。
Ng, et al. Informational [Page 24] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [24ページ]情報のRFC4889ネモROスペース分析2007年7月
router (or some other entity within the access network) and Mobile
Router to possess prefix delegation functionality, and also
maintain information on what prefix is delegated to which node.
How to efficiently assign a subset of Mobile Network Prefix to
child Mobile Routers could be an issue because Mobile Network
Nodes may dynamically join and leave with an unpredictable
pattern. In addition, a change in the point of attachment of the
root Mobile Router will also require every nested Mobile Router
(and possibly Visiting Mobile Nodes) to change their Care-of
Addresses and delegated prefixes. These will cause a burst of
Binding Updates and prefix delegation activities where every
Mobile Router and every Visiting Mobile Node start sending Binding
Updates to their Correspondent Entities.
ルータ(または、アクセスネットワークの中のある他の実体)と接頭語委譲の機能性を持って、また情報を保守するモバイルRouterは接頭語が何であるかに関してどのノードに委任したか。 モバイルNetwork Nodesが予測できないパターンと共にダイナミックに接合して、いなくなるかもしれないので、どう効率的にモバイルNetwork Prefixの部分集合を子供のモバイルRoutersに割り当てるかは、問題であるかもしれません。 また、さらに、根のモバイルRouterの接着点の変化が、あらゆる入れ子にされたモバイルRouter(そして、ことによるとVisitingのモバイルNodes)が変化するのを必要とする、彼ら、Care、-、Addressesと代表として派遣された接頭語。 これらは、あらゆるモバイルRouterとあらゆるVisitingのモバイルNodeがBinding Updatesを彼らのCorrespondent Entitiesに送り始めるところにBinding Updatesの炸裂を引き起こして、委譲活動を前に置くでしょう。
o Neighbor Discovery Proxy
o 隣人発見プロキシ
This approach (such as [27] and [28]) achieves Route Optimization
by having the Mobile Router act as a Neighbor Discovery [29] proxy
for its Mobile Network Nodes. The Mobile Router will configure a
Care-of Address from the network prefix advertised by its access
router, and also relay this prefix to its subnets. When a Mobile
Network Node configures an address from this prefix, the Mobile
Router will act as a Neighbor Discovery proxy on its behalf. In
this way, the entire mobile network and its access network form a
logical multilink subnet, thus eliminating any nesting.
これにアプローチします。([27]と[28])としてのそのようなものは、モバイルNetwork NodesのNeighborディスカバリー[29]プロキシとしてモバイルRouter条例を持っていることによって、Route Optimizationを達成します。 モバイルRouterがaを構成する、Care、-、ネットワーク接頭語からのAddressはアクセスルータで広告を出して、また、この接頭語をサブネットにリレーします。 モバイルNetwork Nodeがこの接頭語からのアドレスを構成するとき、モバイルRouterはNeighborディスカバリープロキシとして利益に務めるでしょう。 このように、全体のモバイルネットワークとそのアクセスネットワークは論理的なマルチリンクサブネットを形成して、その結果、どんな巣篭もりも排除します。
This approach has the advantage of keeping the implementations of
Correspondent Nodes unchanged. However, it requires the root
Mobile Router to act as a Neighbor Discovery proxy for all the
Mobile Network Nodes that are directly or indirectly attached to
it. This increases the processing load of the root Mobile Router.
In addition, a change in the point of attachment of the root
Mobile Router will require every nested Mobile Router (and
possibly Visiting Mobile Nodes) to change their Care-of Addresses.
Not only will this cause a burst of Binding Updates where every
Mobile Router and every Visiting Mobile Node start sending Binding
Updates to their Correspondent Entities, it will also cause a
burst of Duplicate Address Discovery messages to be exchanged
between the mobile network and the access network. Furthermore,
Route Optimization for Local Fixed Nodes is not possible without
new functionalities implemented on the Local Fixed Nodes.
このアプローチには、Correspondent Nodesの実装を変わりがなく保つ利点があります。 しかしながら、直接か間接的にそれに取り付けられるすべてのモバイルNetwork NodesのNeighborディスカバリープロキシとして務めるのが根のモバイルRouterを必要とします。 これは根のモバイルRouterの処理荷重を増強します。 さらに、根のモバイルRouterの接着点の変化が、あらゆる入れ子にされたモバイルRouter(そして、ことによるとVisitingのモバイルNodes)が変化するのを必要とする、彼ら、Care、-、Addresses。 また、これはあらゆるモバイルRouterとあらゆるVisitingのモバイルNodeが彼らのCorrespondent EntitiesにBinding Updatesを送り始めるBinding Updatesの炸裂を引き起こすだけではなく、それはモバイルネットワークとアクセスネットワークの間で交換されるべきDuplicate Addressディスカバリーメッセージの炸裂を引き起こすでしょう。 その上、Local Fixed NodesのためのRoute OptimizationはLocal Fixed Nodesで実装された新しい機能性なしで可能ではありません。
o Hierarchical Registrations
o 階層的な登録証明書
Hierarchical Registration involves Mobile Network Nodes (including
nested Mobile Routers) registering themselves with either their
parent Mobile Routers or the root Mobile Router itself. After
registrations, Mobile Network Nodes would tunnel packets directly
階層的なRegistrationは、彼らの親のモバイルRoutersか根のモバイルRouter自身のどちらかに自分たちを登録しながら、モバイルNetwork Nodes(入れ子にされたモバイルRoutersを含んでいる)にかかわります。 登録証明書の後に、モバイルNetwork Nodesは直接パケットにトンネルを堀るでしょう。
Ng, et al. Informational [Page 25] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [25ページ]情報のRFC4889ネモROスペース分析2007年7月
to the upstream Mobile Router they register with. At the root
Mobile Router, packets tunneled from sub-Mobile Routers or Mobile
Network Nodes are tunneled directly to the Correspondent Entities,
thus avoiding nested tunneling.
彼らがともに記名する上流のモバイルRouterに。 根のモバイルRouterでは、サブモバイルのRoutersかモバイルNetwork Nodesからトンネルを堀られたパケットは直接Correspondent Entitiesにトンネルを堀られます、その結果、入れ子にされたトンネリングを避けます。
One form of such an approach uses the principle of Hierarchical
Mobile IPv6 [13], where the root Mobile Router acts as a Mobility
Anchor Point. It is also possible for each parent Mobile Router
to act as Mobility Anchor Points for its child Mobile Routers,
thus forming a hierarchy of Mobility Anchor Points. One can also
view these Mobility Anchor Points as local Home Agents, thus
forming a cascade of mobile Home Agents. In this way, each Mobile
Router terminates its tunnel at its parent Mobile Router. Hence,
although there are equal numbers of tunnels as the level of
nestings, there is no tunnel encapsulated within another.
そのようなアプローチの1つのフォームがHierarchicalのモバイルIPv6[13]の本質を使用します。(そこでは、根のモバイルRouterがMobility Anchor Pointとして機能します)。 また、それぞれの親のモバイルRouterが子供のモバイルRoutersのためのMobility Anchor Pointsとして機能するのも、可能です、その結果、Mobility Anchor Pointsの階層構造を形成します。 また、人は地元のホームのエージェントであるとこれらのMobility Anchor Pointsをみなして、その結果、モバイルホームのエージェントのカスケードを形成できます。 このように、それぞれのモバイルRouterは親のモバイルRouterでトンネルを終えます。 したがって、巣篭もりのレベルとして等しい数のトンネルがありますが、別のものの中でカプセル化されたトンネルは全くありません。
Examples of this approach include [30], [31], [32], and [33].
このアプローチに関する例は[30]、[31]、[32]、および[33]を含んでいます。
An advantage of this approach is that the functionalities of the
Correspondent Nodes are unchanged.
このアプローチの利点はCorrespondent Nodesの機能性が変わりがないということです。
o Mobile Ad-Hoc Routing
o モバイル臨時のルート設定
It is possible for nodes within a mobile network to use Mobile Ad-
hoc routing for packet-forwarding between nodes in the same mobile
network. An approach of doing so might involve a router acting as
a gateway for connecting nodes in the mobile network to the global
Internet. All nodes in the mobile network would configure their
Care-of Addresses from one or more prefixes advertised by that
gateway, while their parent Mobile Routers use Mobile Ad-hoc
routing to forward packets to that gateway or other destinations
inside the mobile network.
モバイルネットワークの中のノードがノードの間のパケット推進に同じモバイルネットワークにモバイルAd- hocルーティングを使用するのは、可能です。 そうするアプローチは接続ノードのためのゲートウェイとしてモバイルネットワークで世界的なインターネットに機能するルータにかかわるかもしれません。 モバイルネットワークにおけるすべてのノードが構成するだろう、それら、Care、-、1つ以上の接頭語からのAddressesはそのゲートウェイのそばに広告を出しました、彼らの親のモバイルRoutersがモバイルネットワークの中でそのゲートウェイか他の目的地にパケットを送るのにモバイルAd-hocルーティングを使用しますが。
One advantage that is common to all the approaches listed above is that local mobility of a Mobile Network Node within a nested mobile network is hidden from the Correspondent Entity.
上に記載されたすべてのアプローチに共通の1つの利点はCorrespondent Entity入れ子にされたモバイルネットワークの中のモバイルNetwork Nodeの地方の移動性を隠されるということです。
5.6. How Is Signaling Performed?
5.6. シグナリングはどのように実行されますか?
In general, Route Optimization signaling can be done either in-plane, off-plane, or both. In-plane signaling involves embedding signaling information into headers of data packets. A good example of in-plane signaling would be Reverse Routing Header [10]. Off-plane signaling uses dedicated signaling packets rather than embedding signaling information into headers of data packets. Proposals involving the sending of Binding Updates fall into this category.
一般に、面内で、飛行機であることでRoute Optimizationシグナリングができる、または、両方。 面内のシグナリングは、シグナリング情報をデータ・パケットのヘッダーに埋め込むことを伴います。 面内のシグナリングの好例はReverseルート設定Header[10]でしょう。 シグナリングが使用するオフ飛行機はシグナリング情報をデータ・パケットのヘッダーに埋め込むよりむしろシグナリングパケットを捧げました。 Binding Updatesの発信にかかわる提案がこのカテゴリになります。
Ng, et al. Informational [Page 26] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [26ページ]情報のRFC4889ネモROスペース分析2007年7月
The advantage of in-plane signaling is that any change in the mobile network topology can be rapidly propagated to the Correspondent Entity as long as there is a continuous stream of data to be transmitted. However, this might incur a substantial overhead on the data packets. Off-plane signaling, on the other hand, sends signaling messages independently from the data packet. This has the advantage of reducing the signaling overhead in situations where there are relatively fewer topological changes to the mobile network. However, data packet transmission may be disrupted while off-plane signaling takes place.
面内のシグナリングの利点は伝えられるためにデータの連続したストリームがある限り、急速にモバイルネットワークトポロジーのどんな変化もCorrespondent Entityに伝播できるということです。 しかしながら、これはデータ・パケットの上でかなりのオーバーヘッドを被るかもしれません。 他方では、合図するオフ飛行機はデータ・パケットからシグナリングメッセージを独自に送ります。 これには、モバイルネットワークへの比較的少ない位相的な変化がある状況におけるシグナリングオーバーヘッドを下げる利点があります。 しかしながら、オフ飛行機シグナリングが行われている間、データ・パケットトランスミッションは中断するかもしれません。
An entirely different method of signaling makes use of upper-layer protocols to establish the bindings between the address of a Mobile Network Node and the location of the mobile network. Such binding information can then be passed down to the IP layer to insert the appropriate entry in the Binding Cache or routing table. An example of such a mechanism is [34], which uses the Session Initiation Protocol (SIP) to relay binding information.
シグナリングの完全に異なったメソッドは、モバイルNetwork Nodeのアドレスとモバイルネットワークの位置の間の結合を証明するのに上側の層のプロトコルを利用します。 そして、適切なエントリーをBinding Cacheか経路指定テーブルに挿入するためにそのような拘束力がある情報をIP層まで通過できます。 そのようなメカニズムに関する例は[34]です。(その[34]は、拘束力がある情報をリレーするのに、Session Initiationプロトコル(SIP)を使用します)。
5.7. How Is Data Transmitted?
5.7. データはどのように送られますか?
With Route Optimization established, one remaining question to be answered is how data packets can be routed to follow the optimized route. There are the following possible approaches:
Route Optimizationが設立されている状態で、答えられる1つの残っている質問は最適化されたルートに従うためにどうしたらデータ・パケットを発送できるかということです。 以下の可能なアプローチがあります:
o Encapsulations
o カプセル化
One way to route packets through the optimized path is to use IP-
in-IP encapsulations [35]. In this way, the original packet can
be tunneled to the location bound to the address of the Mobile
Network Node using the normal routing infrastructure. Depending
on how the location is bound to the address of the Mobile Network
Node, the number of encapsulations required might vary.
最適化された経路を通してパケットを発送する1つの方法はIPにおけるIPカプセル化[35]を使用することです。 このように、正常なルーティングインフラストラクチャを使用することでオリジナルのパケットにモバイルNetwork Nodeのアドレスに縛られた位置までトンネルを堀ることができます。 位置がどうモバイルNetwork Nodeのアドレスに縛られるかによって、必要であるカプセル化の数は異なるかもしれません。
For instance, if the Correspondent Entity knows the full sequence
of points of attachment, it might be necessary for there to be
multiple encapsulations in order to forward the data packet
through each point of attachment. This may lead to the need for
multiple tunnels and extra packet header overhead. It is possible
to alleviate this by using Robust Header Compression techniques
[36][37][38] to compress the multiple tunnel packet headers.
例えば、Correspondent Entityがポイントの付属の完全な系列を知っているなら、複数のカプセル化であることが、各接着点を通してデータ・パケットを送るのにそこに必要であるかもしれません。 これは複数のトンネルと付加的なパケットのヘッダーオーバーヘッドの必要性に通じるかもしれません。 複数のトンネルパケットのヘッダーを圧縮するのにRobust Header Compressionのテクニック[36][37][38]を使用することによってこれを軽減するのは可能です。
o Routing Headers
o ルート設定ヘッダー
A second way to route packets through the optimized path is to use
routing headers. This is useful especially for the case where the
Correspondent Entity knows the sequence of locations of upstream
Mobile Routers (see Section 5.5.2), since a routing header can
最適化された経路を通してパケットを発送する2番目の方法はルーティングヘッダーを使用することです。 これは特にCorrespondent Entityが上流のモバイルRoutersの位置の系列を知っている(セクション5.5.2を見てください)ケースの役に立ちます、ルーティングヘッダーがそうすることができるので
Ng, et al. Informational [Page 27] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [27ページ]情報のRFC4889ネモROスペース分析2007年7月
contain multiple intermediate destinations. Each intermediate
destination corresponds to a point of attachment bound to the
address of the Mobile Network Node.
複数の中間的目的地を含んでください。 それぞれの中間的目的地はモバイルNetwork Nodeのアドレスに縛られた接着点に対応しています。
This requires the use of a new Routing Header type, or possibly an
extension of the Type 2 Routing Header as defined by Mobile IPv6
to contain multiple addresses instead of only one.
これは、新しいルート設定Headerタイプの使用、またはことによるとモバイルIPv6によって定義されるType2ルート設定Headerの拡大が1だけの代わりに複数のアドレスを含むのを必要とします。
o Routing Entries in Parent Mobile Routers
o 親のモバイルルータにおけるルート設定エントリー
Yet another way is for parent Mobile Routers to install routing
entries in their routing table that will route Route Optimized
packets differently, most likely based on source address routing.
This usually applies to approaches described in Section 5.5.3.
For instance, the Prefix Delegation approach [24][25][26] would
require parent Mobile Routers to route packets differently if the
source address belongs to the prefix delegated from the access
network.
しかし、別の方法は親のモバイルRoutersがRoute Optimizedパケットを異なって発送するそれらの経路指定テーブルにルーティングエントリーをインストールすることです、たぶんソースアドレスルーティングに基づいて。 通常、これはセクション5.5.3で説明されたアプローチに適用されます。 例えば、ソースアドレスがアクセスネットワークから代表として派遣された接頭語に属すなら、Prefix Delegationアプローチ[24][25][26]は、親のモバイルRoutersがパケットを異なって発送するのを必要とするでしょう。
5.8. What Are the Security Considerations?
5.8. セキュリティ問題は何ですか?
5.8.1. Security Considerations of Address Binding
5.8.1. アドレス結合のセキュリティ問題
The most important security consideration in Route Optimization is certainly the security risks a Correspondent Entity is exposed to by creating a binding between the address of a Mobile Network Node and the specified location(s) of the mobile network. Generally, it is assumed that the Correspondent Entity and Mobile Network Node do not share any pre-existing security association. However, the Correspondent Entity must have some ways of verifying the authenticity of the binding specified, else it will be susceptible to various attacks described in [19], such as snooping (sending packets meant for a Mobile Network Node to an attacker) or denial-of-service (DoS) (flooding a victim with packets meant for a Mobile Network Node) attacks.
確かに、Route Optimizationで最も重要な警備上の配慮はCorrespondent EntityがモバイルNetwork Nodeのアドレスとモバイルネットワークの指定された位置の間で結合を作成することによって暴露されるセキュリティリスクです。 一般に、Correspondent EntityとモバイルNetwork Nodeがどんな先在のセキュリティ協会も共有しないと思われます。 しかしながら、Correspondent Entityは結合の信憑性について確かめるいくつかの方法を指定させなければならなくて、ほかに、[19]で説明された様々な攻撃に影響されやすくなるでしょう、詮索(モバイルNetwork Nodeのために攻撃者に意味された送付パケット)かサービスの否定(DoS)(パケットをもっている犠牲者がモバイルNetwork Nodeのために言っていた氾濫)攻撃などのように。
When the binding is performed between the address of the Mobile Network Node and one Care-of Address (possibly of the Mobile Router; see Section 5.5.1 and Section 5.5.3), the standard Return Routability procedure specified in Mobile IPv6 might be sufficient to provide a reasonable degree of assurance to the Correspondent Entity. This also allows the Correspondent Entity to re-use existing implementations. But in other situations, an extension to the Return Routability procedure might be necessary.
結合がモバイルNetwork Nodeと1のアドレスの間で実行される、Care、-、Address(ことによるとモバイルRouterについて; セクション5.5.1とセクション5.5.3を見る)、モバイルIPv6で指定された標準のReturn Routability手順は、妥当な度合いを保証をCorrespondent Entityに供給するために十分であるかもしれません。 また、これで、Correspondent Entityは既存の実装を再使用できます。 しかし、他の状況で、Return Routability手順への拡大が必要であるかもしれません。
For instance, consider the case where the Mobile Router sends a Binding Update containing Mobile Network Prefix information to the Correspondent Entity (see Section 5.5.1). Although the Return
例えば、モバイルRouterがモバイルNetwork Prefix情報をCorrespondent Entityに含むBinding Updateを送る(セクション5.5.1を見てください)ケースを考えてください。 リターンです。
Ng, et al. Informational [Page 28] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [28ページ]情報のRFC4889ネモROスペース分析2007年7月
Routability procedure allows the Correspondent Entity to verify that the Care-of and Home Addresses of the Mobile Router are indeed collocated, it does not allow the Correspondent Entity to verify the validity of the Mobile Network Prefix. If the Correspondent Entity accepts the binding without verification, it will be exposed to attacks where the attacker tricks the Correspondent Entity into forwarding packets destined for a mobile network to the attacker (snooping) or victim (DoS); [39] discusses this security threat further.
そして、Correspondent EntityがRoutability手順でそれについて確かめることができる、Care、-、モバイルRouterのホームAddressesは並べて、本当に、Correspondent EntityがそれでモバイルNetwork Prefixの正当性について確かめることができないということです。 Correspondent Entityが検証なしで結合を受け入れると、攻撃者が、Correspondent Entityがモバイルネットワークのために攻撃者(詮索)か犠牲者(DoS)に運命づけられたパケットを進めるようにだますところでそれは攻撃に暴露されるでしょう。 [39]はさらにこの軍事的脅威について議論します。
The need to verify the validity of network prefixes is not constrained to Correspondent Entities. In approaches that involve the Correspondent Routers (see Section 5.1.3), there have been suggestions for the Correspondent Router to advertise the network prefix(es) of Correspondent Nodes that the Correspondent Router is capable of terminating Route Optimization on behalf of to Mobile Network Nodes. In such cases, the Mobile Network Nodes also need a mechanism to check the authenticity of such claims. Even if the Correspondent Routers do not advertise the network prefix, the Mobile Network Nodes also have the need to verify that the Correspondent Router is indeed a valid Correspondent Router for a given Correspondent Node.
ネットワーク接頭語の正当性について確かめる必要性はCorrespondent Entitiesに抑制されません。 を代表してCorrespondent RouterがRoute Optimizationを終えるCorrespondent RouterはできるCorrespondent Nodesのネットワーク接頭語(es)の広告を出すようにCorrespondent Routers(セクション5.1.3を見る)にかかわるアプローチには提案があった、モバイルNetwork Nodesに。 また、そのような場合、モバイルNetwork Nodesは、そのようなクレームの信憑性をチェックするためにメカニズムを必要とします。また、Correspondent Routersがネットワーク接頭語の広告を出さないでも、モバイルNetwork Nodesには本当に、Correspondent Routerが与えられたCorrespondent Nodeのための有効なCorrespondent Routerであることを確かめる必要があります。
In Section 5.5.2, the registration signaling involves sending the information about one or more upstream Mobile Routers. The Correspondent Entity (or Home Agent) must also have the means to verify such information. Again, the standard Return Routability procedure as defined in [3] is inadequate here, as it is not designed to verify the reachability of an address over a series of upstream routers. An extension such as attaching a routing header to the Care-of Test (CoT) message to verify the authenticity of the locations of upstream Mobile Routers is likely to be needed. The risk, however, is not confined to Correspondent Entities. The Mobile Network Nodes are also under the threat of receiving false information from their upstream Mobile Routers, which they might pass to Correspondent Entities (this also implies that Correspondent Entities cannot rely on any security associations they have with the Mobile Network Nodes to establish the validity of address bindings). There are some considerations that this kind of on-path threat exists in the current Internet anyway especially when no (or weak) end-to- end protection is used.
セクション5.5.2に、登録シグナリングは、情報のおよそ1か、より上流のモバイルRoutersを送ることを伴います。 また、Correspondent Entity(または、ホームのエージェント)には、そのような情報について確かめる手段がなければなりません。 一方、[3]で定義される標準のReturn Routability手順はここで不十分です、それが一連の上流のルータに関してアドレスの可到達性について確かめるように設計されていないとき。 ルーティングヘッダーを取り付けなどなどの拡大、Care、-、上流のモバイルRoutersの位置の信憑性について確かめるTest(CoT)メッセージが必要でありそうです。 しかしながら、危険はCorrespondent Entitiesに閉じ込められません。 モバイルNetwork Nodesが彼らがCorrespondent Entitiesに渡すかもしれない自分達の上流のモバイルRoutersから偽情報を受け取る脅威でもあります(また、これは、Correspondent Entitiesが彼らがアドレス結合の正当性を証明するためにモバイルNetwork Nodesと共に持っているどんなセキュリティ協会も当てにすることができないのを含意します)。 いくつかの問題があります。特にノー、そして、(弱い)の終わりから終わりへの保護が使用されているとき、経路におけるこの種類の脅威は現在のインターネットにとにかく存在しています。
All these concerns over the authenticity of addresses might suggest that perhaps a more radical and robust approach is necessary. This is currently under extensive study in various Working Groups of the IETF, and many related documents might be of interest here. For instance, in Secure Neighbor Discovery (SEND) [40], Cryptographically Generated Addresses (CGAs) [41] could be used to establish the
アドレスの信憑性に関するこれらのすべての心配が、恐らく、より急進的で体力を要しているアプローチが必要であると示唆するかもしれません。 現在、これはIETFの様々なWorking Groupsの広範囲な研究であります、そして、多くの関連するドキュメントがここで興味深いかもしれません。 例えば、Secure Neighborディスカバリー(SEND)[40]では、Cryptographically Generated Addresses(CGAs)[41]は設立するのにおいて使用されているかもしれません。
Ng, et al. Informational [Page 29] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [29ページ]情報のRFC4889ネモROスペース分析2007年7月
ownership of Care-of Addresses. [42] employs the Home Agent to check the signaling messages sent by Mobile Routers to provide a way for Correspondent Entities to verify the authenticity of Mobile Network Prefixes specified. [18] documents various proposed enhancements to the Mobile IPv6 Route Optimization mechanism that might be applied to NEMO Route Optimization as well, such as [43], which allows the Correspondent Entity to authenticate a certain operator's Home Agent by verifying the associated certificate. The Host Identity Protocol (HIP) [44] with end-host mobility considerations [45] may be extended for NEMO Route Optimization as well.
所有権、Care、-、Addresses。 [42]は、Correspondent Entitiesが指定されたモバイルNetwork Prefixesの信憑性について確かめる方法を提供するためにモバイルRoutersによって送られたシグナリングメッセージをチェックするためにホームのエージェントを雇います。 [18]はまた、ネモRoute Optimizationに適用されるかもしれないモバイルIPv6 Route Optimizationメカニズムに様々な提案された増進を記録します、[43]などのように。(Correspondent Entityは、[43]で関連証明書について確かめることによって、確信しているオペレータのホームのエージェントを認証できます)。 終わりホスト移動性問題[45]があるHost Identityプロトコル(HIP)[44]はまた、ネモRoute Optimizationのために広げられるかもしれません。
In addition, interested readers might want to refer to [46], which discussed the general problem of making Route Optimization in NEMO secure and explored some possible solution schemes. There is also a proposed mechanism in [23] for Mobile Network Node to delegate some rights to their Mobile Routers, which may be used to allow the Mobile Routers to prove their authenticities to Correspondent Entities when establishing Route Optimization sessions on behalf of the Mobile Network Nodes.
さらに、興味のある読者は[46]について言及したがっているかもしれません。([46]はネモのRoute Optimizationを安全にするという一般的問題について議論して、いくつかの可能な解決策計画について調査しました)。 また、モバイルNetwork NodeがモバイルNetwork Nodesを代表してRoute Optimizationセッションを確立するとき、モバイルRoutersが彼らのCorrespondent Entitiesの信憑性となるのを許容するのに使用されるかもしれないそれらのモバイルRoutersへのいくつかの権利を代表として派遣するように、提案されたメカニズムが[23]にあります。
5.8.2. End-to-End Integrity
5.8.2. 終わりから終わりへの保全
In some of the approaches, such as "Mobile Router as a Proxy" in Section 5.5.1, the Mobile Router sends messages using the Mobile Network Node's address as the source address. This is done mainly to achieve zero new functionalities required at the Correspondent Entities and the Mobile Network Nodes. However, adopting such a strategy may interfere with existing or future protocols, most particularly security-related protocols. This is especially true when the Mobile Router needs to make changes to packets sent by Mobile Network Nodes. In a sense, these approaches break the end-to- end integrity of packets. A related concern is that this kind of approach may also require the Mobile Router to inspect the packet contents sent to/by Mobile Network Nodes. This may prove to be difficult or impossible if such contents are encrypted.
セクション5.5.1における「プロキシとしてのモバイルルータ」などのアプローチのいくつかでは、モバイルRouterは、ソースアドレスとしてモバイルNetwork Nodeのアドレスを使用することでメッセージを送ります。 主にCorrespondent EntitiesとモバイルNetwork Nodesで必要であるどんな新しい機能性も達成しないようにこれをします。 しかしながら、そのような戦略を採用すると、存在か将来のプロトコル、ほとんどの特にセキュリティ関連のプロトコルが妨げられるかもしれません。 モバイルRouterが、モバイルNetwork Nodesにパケットへの変化を送らせる必要があるとき、これは特に本当です。 ある意味で、これらのアプローチは終わりから終わりへのパケットの保全を壊します。 関連する関心はまた、この種類のアプローチが、モバイルRouterがモバイルNetwork Nodesによって/に送られたパケットコンテンツを点検するのを必要とするかもしれないということです。 そのようなコンテンツがコード化されているなら、これは難しいか、または不可能であると判明するかもしれません。
The concern over end-to-end integrity arises for the use of a Reverse Routing Header (see Section 5.5.2) too, since Mobile Routers would insert new contents to the header of packets sent by downstream Mobile Network Nodes. This makes it difficult for Mobile Network Nodes to protect the end-to-end integrity of such information with security associations.
終わりから終わりへの保全に関する心配はReverseルート設定Header(セクション5.5.2を見る)の使用のためにも起こります、モバイルRoutersが川下のモバイルNetwork Nodesによって送られたパケットのヘッダーに新しいコンテンツを挿入するでしょう、したがって。 これで、モバイルNetwork Nodesがセキュリティ関係と共に終わりから終わりへのそのような情報の保全を保護するのが難しくなります。
5.8.3. Location Privacy
5.8.3. 位置のプライバシー
Another security-related concern is the issue of location privacy. This document currently does not consider the location privacy threats caused by an on-path eavesdropper. For more information on
別のセキュリティ関連の関心は位置のプライバシーの問題です。 このドキュメントは、現在、位置のプライバシーが経路の立ち聞きする者によって引き起こされた脅威であると考えません。 詳しい情報において、オンです。
Ng, et al. Informational [Page 30] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [30ページ]情報のRFC4889ネモROスペース分析2007年7月
that aspect, please refer to [18]. Instead, we consider the following three aspects to location privacy:
その局面をお願いします。[18]を参照してください。 代わりに、私たちは以下の3つの局面を位置のプライバシーと考えます:
o Revelation of Location to Correspondent Entity
o 通信員実体への位置の暴露
Route optimization is achieved by creating a binding between the
address of the Mobile Network Node and the current location of the
Mobile Network. It is thus inevitable that the location of the
Mobile Network Node be revealed to the Correspondent Entity. The
concern may be alleviated if the Correspondent Entity is not the
Correspondent Node, since this implies that the actual traffic end
point (i.e., the Correspondent Node) would remain ignorant of the
current location of the Mobile Network Node.
経路最適化は、モバイルNetwork NodeのアドレスとモバイルNetworkの現在の位置の間で結合を作成することによって、達成されます。 その結果、モバイルNetwork Nodeの位置がCorrespondent Entityに明らかにされるのは、必然です。 関心はCorrespondent EntityがCorrespondent Nodeでないなら軽減されるかもしれません、これが、実際の交通エンドポイント(すなわち、Correspondent Node)がモバイルNetwork Nodeの現在の位置に無知なままであることを含意するので。
o Degree of Revelation
o 暴露の度合い
With network mobility, the degree of location exposure varies,
especially when one considers nested mobile networks. For
instance, for approaches that bind the address of the Mobile
Network Node to the location of the root Mobile Router (see
Section 5.5.3), only the topmost point of attachment of the mobile
network is revealed to the Correspondent Entity. For approaches
such as those described in Section 5.5.1 and Section 5.5.2, more
information (such as Mobile Network Prefixes and current locations
of upstream Mobile Routers) is revealed. Techniques such as
exposing only locally-scoped addresses of intermediate upstream
mobile routers to Correspondent Entities may be used to reduce the
degree of revelation.
特に人が入れ子にされたモバイルネットワークを考えるとき、ネットワークの移動性で、位置の露出の度合いは異なります。 例えば、モバイルNetwork Nodeのアドレスを根のモバイルRouter(セクション5.5.3を見る)の位置まで縛るアプローチにおいて、モバイルネットワークの最上の接着点だけがCorrespondent Entityに明らかにされます。 セクション5.5.1とセクション5.5.2で説明されたものなどのアプローチにおいて、詳しい情報(上流のモバイルRoutersのモバイルNetwork Prefixesや現在の位置などの)は明らかにされます。 中間的上流の可動のルータの局所的に見られたアドレスだけをCorrespondent Entitiesに露出などなどのテクニックは、暴露の度合いを減少させるのに使用されるかもしれません。
o Control of the Revelation
o 暴露のコントロール
When Route Optimization is initiated by the Mobile Network Node
itself, it is in control of whether or not to sacrifice location
privacy for an optimized route. However, if it is the Mobile
Router that initiates Route Optimization (e.g., "Binding Update
with Mobile Network Prefix" and "Mobile Router as a Proxy" in
Section 5.5.1), then control is taken away from the Mobile Network
Node. An additional signaling mechanism between the Mobile
Network Node and its Mobile Router can be used in this case to
prevent the Mobile Router from attempting Route Optimization for a
given traffic stream.
Route OptimizationがモバイルNetwork Node自身によって開始されるとき、それは位置のプライバシーを最適化されたルートに犠牲にするかどうかに関するコントロール中です。 しかしながら、Route Optimization(例えば、「モバイルネットワーク接頭語との拘束力があるアップデート」とセクション5.5.1における「プロキシとしてのモバイルルータ」)を開始するのが、モバイルRouterであるなら、モバイルNetwork Nodeからコントロールを持ち去ります。 この場合モバイルRouterが与えられた交通の流れのためにRoute Optimizationを試みるのを防ぐのにモバイルNetwork NodeとそのモバイルRouterの間の追加シグナル伝達機構を使用できます。
6. Conclusion
6. 結論
The problem space of Route Optimization in the NEMO context is multifold and can be split into several work areas. It will be critical, though, that the solution to a given piece of the puzzle be compatible and integrated smoothly with others. With this in mind,
ネモ文脈のRoute Optimizationの問題スペースは、多重であり、いくつかの作業領域に分けることができます。 もっとも、パズルの与えられた片の解決策が他のものについてスムーズに互換性があって統合しているのは、批判的でしょう。 これが念頭にある状態で
Ng, et al. Informational [Page 31] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [31ページ]情報のRFC4889ネモROスペース分析2007年7月
this document attempts to present a detailed and in-depth analysis of the NEMO Route Optimization solution space by first describing the benefits a Route Optimization solution is expected to bring, then illustrating the different scenarios in which a Route Optimization solution applies, and next presenting some issues a Route Optimization solution might face. We have also asked ourselves some of the basic questions about a Route Optimization solution. By investigating different possible answers to these questions, we have explored different aspects to a Route Optimization solution. The intent of this work is to enhance our common understanding of the Route Optimization problem and solution space.
このドキュメントは、詳細で徹底的な分析を提示するのを最初にRoute Optimization解決策が適用される異なったシナリオがその時例証して、もたらすRoute Optimization解決策が予想される利益について説明するのによるネモRoute Optimization解決策スペースを試みて、Route Optimization解決策が直面するかもしれないいくつかの問題を提示して、次に、試みます。 また、私たちはRoute Optimization解決策に関する基本的な質問のいくつかを自分達に尋ねました。 これらの質問の異なった可能な答えを調査することによって、私たちはRoute Optimization解決策に異なった局面を探検しました。 この仕事の意図は私たちのRoute Optimization問題と解決策スペースの一般的な理解を機能アップすることです。
7. Security Considerations
7. セキュリティ問題
This is an informational document that analyzes the solution space of NEMO Route Optimization. Security considerations of different approaches are described in the relevant sections throughout this document. Particularly, please refer to Section 4.9 for a brief discussion of the security concern with respect to Route Optimization in general, and Section 5.8 for a more detailed analysis of the various Route Optimization approaches.
これはネモRoute Optimizationの解決策スペースを分析する情報のドキュメントです。 異なるアプローチのセキュリティ問題はこのドキュメント中の関連セクションで説明されます。 特に、セキュリティ関心の一般に、Route Optimizationに関する簡潔な議論のためのセクション4.9、および様々なRoute Optimizationアプローチの、より詳細な分析のためのセクション5.8を参照してください。
8. Acknowledgments
8. 承認
The authors wish to thank the co-authors of previous versions from which this document is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Felix Wu, and Souhwan Jung. In addition, sincere appreciation is also extended to Jari Arkko, Carlos Jesus Bernardos, Greg Daley, Thierry Ernst, T.J. Kniveton, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for their various contributions.
作者はこのドキュメントが引き出される旧バージョンの共著者に感謝したがっています: マルコのモルテーニ、パクEun-Kyoung、ヒロユキOhnishi、フェリクス・ウー、およびSouhwanユング。 また、さらに、心からの感謝は彼らの様々な貢献のためにヤリArkko、カルロスイエスBernardos、グレッグ・デイリー、ティエリー・エルンスト、T.J.Kniveton、エリックNordmark、Alexandruペトレスク、Heshamソリマン、龍治Wakikawa、およびパトリックWetterwaldに与えられます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility
Route Optimization Problem Statement", RFC 4888, July 2007.
[1] ウンとC.とThubertとP.と亘理、M.とF.チャオ、「ネットワーク移動性経路最適化問題声明」、RFC4888、2007年7月。
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[2]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[4] Ernst, T., "Network Mobility Support Goals and Requirements",
RFC 4886, July 2007.
[4] エルンスト、T.、「ネットワークの移動性は目標と要件を支持する」RFC4886、2007年7月。
Ng, et al. Informational [Page 32] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [32ページ]情報のRFC4889ネモROスペース分析2007年7月
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[5] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[6] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[6] エルンスト、T.、およびH-Y。 ラック、「ネットワーク移動性サポート用語」、RFC4885、2007年7月。
9.2. Informative References
9.2. 有益な参照
[7] Wakikawa, R., Koshiba, S., Uehara, K., and J. Murai, "ORC:
Optimized Route Cache Management Protocol for Network
Mobility", 10th International Conference on Telecommunications,
vol 2, pp 1194-1200, February 2003.
[7]Wakikawa、R.、Koshiba、S.、Uehara、K.、およびJ.村井、「ORC:」 「Network Mobilityのための最適化されたRoute Cache Managementプロトコル」、Telecommunications、vol2、pp1194-1200、2003年2月の第10国際コンファレンス。
[8] Wakikawa, R. and M. Watari, "Optimized Route Cache Protocol
(ORC)", Work in Progress, November 2004.
[8] 「最適化された経路キャッシュプロトコル(ORC)」というWakikawa、R.、およびM.亘理は進歩、2004年11月に働いています。
[9] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Route
Optimization Scheme based on Path Control Header", Work
in Progress, April 2004.
[9] Progress(2004年4月)のNaとJ.とChoとS.とキムとC.とリーとS.とカン、H.とC.クー、「Path Control Headerに基づいたルートOptimization Scheme」Work。
[10] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks", Work in Progress,
February 2007.
[10]はThubertします、P.、M.はモルテーニと、「IPv6 Reverseルート設定HeaderとモバイルNetworksへのそのアプリケーション」をP.です、ProgressのWork、2007年2月。
[11] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization
with Access Router Option", Work in Progress, July 2004.
[11] 「アクセスルータオプションとの入れ子にされたTunnels Optimizationを保証し」て、ウン、C.、およびT.田中は進歩、2004年7月に働いています。
[12] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo,
"Secure Nested Tunnels Optimization using Nested Path
Information", Work in Progress, September 2003.
[12] Na、J.、町、S.、キム、C.、リー、S.、カン、H.、およびC.クーは「入れ子にされた経路情報を使用して、入れ子にされたTunnels Optimizationを保証します」、処理中の作業、2003年9月。
[13] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)",
RFC 4140, August 2005.
[13] ソリマン、H.、Castelluccia、C.、高架鉄道Malki、K.、およびL.Bellier、「階層的なモバイルIPv6移動性管理(HMIPv6)」、RFC4140 2005年8月。
[14] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA to HA
protocol", Work in Progress, September 2006.
[14]ThubertとP.とWakikawa、R.とV.Devarapalli、「HAへのグローバルなHAは議定書を作る」Progress、2006年9月のWork。
[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[15]TroanとO.とR.Droms、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
[16] Baek, S., Yoo, J., Kwon, T., Paik, E., and M. Nam, "Routing
Optimization in the same nested mobile network", Work
in Progress, October 2005.
[16] Baek、S.、ユー、J.、Kwon、T.、パク、E.、およびM.Nam、「同じくらいのルート設定Optimizationはモバイルネットワークを入れ子にしました」、ProgressのWork、2005年10月。
[17] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[17] Koodli(R.)は「速く、モバイルIPv6"、RFCのために、4068、2005年7月を引き渡します」。
Ng, et al. Informational [Page 33] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [33ページ]情報のRFC4889ネモROスペース分析2007年7月
[18] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of Enhancements
to Mobile IPv6 Route Optimization", RFC 4651, February 2007.
[18] フォークト、C.、およびJ.Arkko、「モバイルIPv6への増進の分類学と分析は最適化を発送します」、RFC4651、2007年2月。
[19] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005.
[19]Nikander、P.、Arkko、J.、香気、T.、モンテネグロ、G.、およびE.Nordmark、「モバイルIPバージョン6経路最適化セキュリティはバックグラウンドを設計します」、RFC4225、2005年12月。
[20] Bernardos, C., Bagnulo, M., and M. Calderon, "MIRON: MIPv6
Route Optimization for NEMO", 4th Workshop on Applications and
Services in Wireless Network,
Online: http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf,
August 2004.
[20]Bernardos、C.、Bagnulo、M.、およびM.カルデロン、「MIRON:」 「ネモのためのMIPv6経路最適化」、アプリケーションに関する第4ワークショップ、および無線電信でのサービスはオンラインで以下をネットワークでつなぎます。 2004年8月の http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf 。
[21] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A.
Oliva, "Design and Experimental Evaluation of a Route
Optimisation Solution for NEMO", IEEE Journal on Selected Areas
in Communications (J-SAC), vol 24, no 9, September 2006.
[21] カルデロン、M.、Bernardos、C.、Bagnulo、M.、ソト、I.、およびA.オリバ、「ネモのためのルート最適化解決のデザインと実験的な評価」(Communications(J-SAC)のSelected Areasの上のIEEE Journal)は24をvolします、いいえ9、2006年9月。
[22] Bernardos, C., Bagnulo, M., Calderon, M., and I. Soto, "Mobile
IPv6 Route Optimisation for Network Mobility (MIRON)", Work
in Progress, July 2005.
[22] C.、Bagnulo、M.、カルデロン、M.、およびI.ソト、「ネットワークの移動性(MIRON)のためのモバイルIPv6ルート最適化」というBernardosは進行中(2005年7月)で働いています。
[23] Ylitalo, J., "Securing Route Optimization in NEMO", Workshop
of 12th Network and Distributed System Security Syposuim, NDSS
Workshop 2005, online: http://www.isoc.org/isoc/conferences/
ndss/05/workshop/ylitalo.pdf, February 2005.
[23]YlitaloオンラインJ.と「ネモで経路最適化を保証します」と第12NetworkのWorkshopとDistributed System Security Syposuim、NDSS Workshop2005: 2005年2月の http://www.isoc.org/isoc/conferences/ ndss/05/ワークショップ/ylitalo.pdf。
[24] Perera, E., Lee, K., Kim, H., and J. Park, "Extended Network
Mobility Support", Work in Progress, July 2003.
2003年7月のペレラとE.とリーとK.とキム、H.とJ.公園、「拡大ネットワーク移動性サポート」が進行中で扱う[24]。
[25] Lee, K., Park, J., and H. Kim, "Route Optimization for Mobile
Nodes in Mobile Network based on Prefix Delegation", 58th IEEE
Vehicular Technology Conference, vol 3, pp 2035-2038,
October 2003.
[25] リー、K.、Park(J.、およびH.キム)は「Prefix Delegationに基づくモバイルNetworkのモバイルNodesのためにOptimizationを発送します」、第58IEEE車両技術部会コンファレンス、vol3、pp2035-2038、2003年10月。
[26] Lee, K., Jeong, J., Park, J., and H. Kim, "Route Optimization
for Mobile Nodes in Mobile Network based on Prefix Delegation",
Work in Progress, February 2004.
[26] リー、K.、Jeong(J.、Park、J.、およびH.キム)は「Prefix Delegationに基づくモバイルNetworkのモバイルNodesのためにOptimizationを発送します」、ProgressのWork、2004年2月。
[27] Jeong, J., Lee, K., Park, J., and H. Kim, "Route Optimization
based on ND-Proxy for Mobile Nodes in IPv6 Mobile Network",
59th IEEE Vehicular Technology Conference, vol 5, pp 2461-2465,
May 2004.
[27] Jeong(J.、リー、K.、Park、J.、およびH.キム)は「IPv6のモバイルNetworkのモバイルNodesのためにノースダコタ-プロキシに基づくOptimizationを発送します」、第59IEEE車両技術部会コンファレンス、vol5、pp2461-2465、2004年5月。
[28] Jeong, J., Lee, K., Kim, H., and J. Park, "ND-Proxy based Route
Optimization for Mobile Nodes in Mobile Network", Work
in Progress, February 2004.
[28] Jeong、J.、リー、K.、キム、H.、およびJ.Park、「ノースダコタ-プロキシはモバイルNetworkのモバイルNodesのためのRoute Optimizationを基礎づけました」、ProgressのWork、2004年2月。
Ng, et al. Informational [Page 34] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [34ページ]情報のRFC4889ネモROスペース分析2007年7月
[29] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[29]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[30] Kang, H., Kim, K., Han, S., Lee, K., and J. Park, "Route
Optimization for Mobile Network by Using Bi-directional Between
Home Agent and Top Level Mobile Router", Work in Progress,
June 2003.
[30] カン、H.、キム、K.、ハン、S.、リー、K.、およびJ.公園は「モバイルネットワークのためにホームのエージェントとトップ平らなモバイルルータの間の双方向の使用で最適化を発送します」、処理中の作業、2003年6月。
[31] Lee, D., Lim, K., and M. Kim, "Hierarchical FRoute Optimization
for Nested Mobile Network", 18th Int'l Conf on Advance
Information Networking and Applications, vol 1, pp 225-229,
2004.
[31] リー、D.、リム、K.、およびM.キム、「入れ子にされたモバイルネットワークのための階層的なFRoute最適化」、Advance情報NetworkingとApplications、vol1、pp225-229の第18Int'l Conf、2004。
[32] Takagi, Y., Ohnishi, H., Sakitani, K., Baba, K., and S.
Shimojo, "Route Optimization Methods for Network Mobility with
Mobile IPv6", IEICE Trans. on Comms, vol E87-B, no 3, pp 480-
489, March 2004.
[32] 高木、Y.、Ohnishi、H.、Sakitani、K.、馬場、K.、およびS.Shimojo、「ネットワークの移動性のためにモバイルIPv6"と共に最適化方法を発送してください、IEICE、移-. Comms、vol E87-B、3がない、pp480- 489、2004インチ年3月に。
[33] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route
optimization method in a mobile network", Work in Progress,
October 2003.
[33] Ohnishi、H.、Sakitani、K.、およびY.高木、「HMIPはモバイルネットワークでRoute最適化方法を基礎づけました」、ProgressのWork、2003年10月。
[34] Lee, C., Zheng, J., and C. HUang, "SIP-based Network Mobility
(SIP-NEMO) Route Optimization (RO)", Work in Progress,
October 2006.
[34] リー、C.、ツェン、J.、およびC.HUang、「一口ベースのネットワーク移動性(ネモをちびちび飲みます)の経路最適化(RO)」が進歩、2006年10月に働いています。
[35] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998.
[35] コンタとA.とS.デアリング、「IPv6仕様による一般的なパケットトンネリング」、RFC2473、1998年12月。
[36] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001.
[36] ボルマン、C.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
[37] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology
and Channel Mapping Examples", RFC 3759, April 2004.
[37] イェンソン、L-E.、「体力を要しているヘッダー圧縮(ROHC):」 「用語とチャンネルの写像している例」、RFC3759、2004年4月。
[38] Minaburo, A., Paik, E., Toutain, L., and J. Bonnin, "ROHC
(Robust Header Compression) in NEMO network", Work in Progress,
July 2005.
Progress(2005年7月)の[38]Minaburo、A.、パク、E.、トゥータン、L.、およびJ.Bonnin、「ネモネットワークにおけるROHC(強健なHeader Compression)」Work。
[39] Ng, C. and J. Hirano, "Extending Return Routability Procedure
for Network Prefix (RRNP)", Work in Progress, October 2004.
[39] 「ネットワーク接頭語(RRNP)のためにリターンRoutability手順を広げ」て、ウン、C.、およびJ.平野は進歩、2004年10月に働いています。
[40] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[40]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
Ng, et al. Informational [Page 35] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [35ページ]情報のRFC4889ネモROスペース分析2007年7月
[41] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[41] 香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
[42] Zhao, F., Wu, F., and S. Jung, "Extensions to Return
Routability Test in MIP6", Work in Progress, February 2005.
[42] チャオとF.とウー、F.とS.ユング、「2005年2月にMIP6"でのRoutabilityテスト、進行中の仕事を返す拡大。」
[43] Bao, F., Deng, R., Qiu, Y., and J. Zhou, "Certificate-based
Binding Update Protocol (CBU)", Work in Progress, March 2005.
[43] バオ、F.、?、R.、Qiu、Y.、およびJ.周、「証明書ベースの拘束力があるアップデートプロトコル(CBU)」は進歩、2005年3月に働いています。
[44] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", Work in Progress, April 2007.
2007年4月のマスコウィッツとR.とNikanderとP.とJokela、P.とT.ヘンダーソン、「ホストアイデンティティプロトコル」が進行中で扱う[44]。
[45] Henderson, T., "End-Host Mobility and Multihoming with the Host
Identity Protocol", Work in Progress, March 2007.
[45] ヘンダーソン、「ホストアイデンティティプロトコルがある終わりホストの移動性とマルチホーミング」というT.は進歩、2007年3月に働いています。
[46] Calderon, M., Bernardos, C., Bagnulo, M., and I. Soto,
"Securing Route Optimization in NEMO", Third International
Symposium on Modeling and Optimization in Mobile, Ad Hoc, and
Wireless Networks, WIOPT 2005, pages 248-254, April 2005.
[46] カルデロン(M.とBernardosとC.とBagnuloとM.とI.ソトと「ネモで経路最適化を保証します」とModelingの上のThirdの国際Symposiumとモバイル、Ad Hoc、およびWireless Networks、WIOPT2005のOptimization)は、248-254を呼び出します、2005年4月。
Ng, et al. Informational [Page 36] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [36ページ]情報のRFC4889ネモROスペース分析2007年7月
Authors' Addresses
作者のアドレス
Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate, Singapore 534415 SG
チェン-バーウンパナソニックシンガポール研究所Pte Ltd Blk1022のタイSeng Ave#06-3530タイSeng Industrial Estate、シンガポール534415SG
Phone: +65 65505420 EMail: chanwah.ng@sg.panasonic.com
以下に電話をしてください。 +65 65505420はメールされます: chanwah.ng@sg.panasonic.com
Fan Zhao University of California Davis One Shields Avenue Davis, CA 95616 US
ファンチャオカリフォルニア大学のデイヴィス・1つのシールズ・Avenueカリフォルニア95616デイヴィス(米国)
Phone: +1 530 752 3128 EMail: fanzhao@ucdavis.edu
以下に電話をしてください。 +1 3128年の530 752メール: fanzhao@ucdavis.edu
Masafumi Watari KDDI R&D Laboratories Inc. 2-1-15 Ohara Fujimino, Saitama 356-8502 JAPAN
株式会社2-1-15Oharaふじみ野、Masafumi KDDI研究開発研究所埼玉日本亘理356-8502
EMail: watari@kddilabs.jp
メール: watari@kddilabs.jp
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3, Biot - Sophia Antipolis 06410 FRANCE
パスカルThubertシスコシステムズVillage d'EntreprisesグリーンSide400、アベニューdeルーマニーユBatiment T3、Biot--ソフィアAntipolis06410フランス
EMail: pthubert@cisco.com
メール: pthubert@cisco.com
Ng, et al. Informational [Page 37] RFC 4889 NEMO RO Space Analysis July 2007
ウン、他 [37ページ]情報のRFC4889ネモROスペース分析2007年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ng, et al. Informational [Page 38]
ウン、他 情報[38ページ]
一覧
スポンサーリンク
