RFC4888 日本語訳
4888 Network Mobility Route Optimization Problem Statement. C. Ng, P.Thubert, M. Watari, F. Zhao. July 2007. (Format: TXT=56756 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Ng
Request for Comments: 4888 Panasonic Singapore Labs
Category: Informational P. Thubert
Cisco Systems
M. Watari
KDDI R&D Labs
F. Zhao
UC Davis
July 2007
コメントを求めるワーキンググループC.ウン要求をネットワークでつないでください: 4888年のパナソニックシンガポール研究室カテゴリ: 情報のP.の研究室F.チャオUCデイヴィスThubertシスコシステムズM.亘理KDDI研究開発2007年7月
Network Mobility Route Optimization Problem Statement
ネットワーク移動性経路最適化問題声明
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 bi-directional tunnel established between the Mobile Router and Home Agent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of Mobile Networks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind Route Optimization (RO) for NEMO.
現在のNetwork Mobility(ネモ)の基本的なSupportと共に、Network NodesとモバイルNetwork Nodesからのコミュニケーションが双方向のトンネルを通って行かせなければならないすべてが、モバイルRouterとホームのエージェントの間でモバイルネットワークがいつ離れているかを確証しました。 このサブ最適ルーティングはパケット配信に関連している様々な非能率をもたらします、トラフィック混雑につながる増強された遅れやボトルネックリンクなどのように。混雑は結局、Network Nodesと、そして、モバイルNetwork Nodesからすべての通信システムを遮断できます。 さらに、モバイルNetworksの巣篭もりによって、これらの非能率は合成されます、そして、手詰まりの状態は特定の気質で現れるかもしれません。 このドキュメントは、ネモのためにRoute Optimization(RO)の後ろにそのような問題を調査して、動機を供給します。
Ng, et al. Informational [Page 1] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [1ページ]情報のRFC4888ネモRO問題声明2007年7月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12
6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12
Appendix A. Various Configurations Involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . 13
A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13
A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15
A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19
A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
Appendix B. Example of How a Stalemate Situation Can Occur . . . 22
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 ネモ経路最適化問題声明. . . . . . . . . . 3 2.1。 ネモが基本的のサブの最適サポート. . . . . . . . . . 4 2.2。 ホームネットワーク. . . . . . . . . . . . . . 6 2.3では、隘路となってください。 入れ子にされたモバイルネットワーク. . . . 6 2.4でサブの最適を増幅しました。 結合したモバイルIPv6経路最適化. . . . . . . . . . . . . . . . . . . . . . . 8 2.5でサブ最適です。 訪問ノード. 9 2.6からトラフィックを禁じる安全保障政策。 入れ子にされたモバイルネットワーク. . . . . . . . . . . . . . . . . . . . . . . . . 9 2.7の中のコミュニケーションの不安定性。 ホームのエージェントがいる手詰まりはモバイルネットワーク. . 10 3を巣造りしました。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 10 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 5。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 6.2。 入れ子にされたモバイルネットワーク. . . . . . . . . . . . . . . . . . . . . . 13A.1にかかわる有益な参照. . . . . . . . . . . . . . . . . . 12の付録のA.の様々な構成。 CNは固定インフラストラクチャ. . . . . . . . . . 13A.1.1で場所を見つけました。 ケースA: LFNと標準のIPv6 CN. . . . . . . . . . . 14A.1.2。 ケースB: VMNとMIPv6 CN. . . . . . . . . . . . . . . 14A.1.3。 ケースC: VMNと標準のIPv6 CN. . . . . . . . . . . 14A.2。 CNは異なった入れ子にされたNEMOs. . . . . . . . . . . 15A.2.1で場所を見つけました。 ケースD: LFNと標準のIPv6 CN. . . . . . . . . . . 16A.2.2。 ケースE: VMNとMIPv6 CN. . . . . . . . . . . . . . . 16A.2.3。 ケースF: VMNと標準のIPv6 CN. . . . . . . . . . . 16A.3。 MNNとCNは同じ入れ子にされたネモ.17A.3.1で場所を見つけました。 ケースG: LFNと標準のIPv6 CN. . . . . . . . . . . 18A.3.2。 ケースH: VMNとMIPv6 CN. . . . . . . . . . . . . . . 18A.3.3。 ケースI: VMNと標準のIPv6 CN. . . . . . . . . . . 19A.4。 CNは同じ入れ子にされたMR. . . . . . . . . . . 19A.4.1の後ろで場所を見つけました。 ケースJ: LFNと標準のIPv6 CN. . . . . . . . . . . 20A.4.2。 ケースK: VMNとMIPv6 CN. . . . . . . . . . . . . . . 20A.4.3。 ケースL: 手詰まりの状況がどう.22に起こることができるかに関するVMNと標準のIPv6 CN. . . . . . . . . . . 21付録B.の例
Ng, et al. Informational [Page 2] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [2ページ]情報のRFC4888ネモRO問題声明2007年7月
1. Introduction
1. 序論
With current Network Mobility (NEMO) Basic Support [1], all communications to and from nodes in a mobile network must go through the bi-directional tunnel established between the Mobile Router and its Home Agent (also known as the MRHA tunnel) when the mobile network is away. Although such an arrangement allows Mobile Network Nodes to reach and be reached by any node on the Internet, limitations associated to the base protocol degrade overall performance of the network and, ultimately, can prevent all communications to and from the Mobile Network Nodes.
現在のNetwork Mobility(ネモ)の基本的なSupport[1]と共に、ノードとモバイルネットワークにおけるノードからのすべてのコミュニケーションがモバイルネットワークが離れているときモバイルRouterとそのホームのエージェント(また、MRHAがトンネルを堀るので、知っている)の間で確立された双方向のトンネルを通らなければなりません。 そのようなアレンジメントは、モバイルNetwork Nodesが達して、インターネットのどんなノードでも達するのを許容しますが、ベースプロトコルに関連づけられた制限は、ネットワークの総合的な性能を下げて、結局、Network Nodesと、そして、モバイルNetwork Nodesからすべてのコミュニケーションを防ぐことができます。
Some of these concerns already exist with Mobile IPv6 [4] and were addressed by the mechanism known as Route Optimization, which is part of the base protocol. With Mobile IPv6, Route Optimization mostly improves the end-to-end path between the Mobile Node and Correspondent Node, with an additional benefit of reducing the load of the Home Network, thus its name.
これらの関心のいくつかが、モバイルIPv6[4]と共に既に存在して、ベースプロトコルの一部であるRoute Optimizationとして知られているメカニズムによって扱われました。 モバイルIPv6と共に、Route OptimizationはモバイルNodeとCorrespondent Nodeの間の終わりから端への経路をほとんど改良します、その結果、ホームNetwork、名前の負荷を減少させる追加利益で。
NEMO Basic Support presents a number of additional issues, making the problem more complex, so it was decided to address Route Optimization separately. In that case, the expected benefits are more dramatic, and a Route Optimization mechanism could enable connectivity that would be broken otherwise. In that sense, Route Optimization is even more important to NEMO Basic Support than it is to Mobile IPv6.
ネモBasic Supportは多くの追加設定を提示します、問題をより複雑にしてそれが別々にRoute Optimizationを扱うために決められて。 その場合、期待される利益は、より劇的です。そうでなければ、Route Optimizationメカニズムは壊れている接続性を可能にするかもしれません。 その意味で、Route OptimizationはモバイルIPv6にはそれがあるよりネモBasic Supportにさらに重要です。
This document explores limitations inherent in NEMO Basic Support, and their effects on communications between a Mobile Network Node and its corresponding peer. This is detailed in Section 2. It is expected that readers are familiar with general terminologies related to mobility in [4][2], NEMO-related terms defined in [3], and NEMO goals and requirements [5].
このドキュメントはモバイルNetwork Nodeとその対応する同輩の間でネモBasic Supportに固有の制限、およびコミュニケーションへのそれらの効果について調査します。 これはセクション2で詳細です。 読者が[4][2]、[3]で定義された、ネモ関連の用語、ネモ目標、および要件[5]で移動性に関連する一般的な用語に詳しいと予想されます。
2. NEMO Route Optimization Problem Statement
2. ネモ経路最適化問題声明
Given the NEMO Basic Support protocol, all data packets to and from Mobile Network Nodes must go through the Home Agent, even though a shorter path may exist between the Mobile Network Node and its Correspondent Node. In addition, with the nesting of Mobile Routers, these data packets must go through multiple Home Agents and several levels of encapsulation, which may be avoided. This results in various inefficiencies and problems with packet delivery, which can ultimately disrupt all communications to and from the Mobile Network Nodes.
ネモBasic Supportプロトコルを考えて、Network NodesとモバイルNetwork Nodesからのすべてのデータ・パケットがホームのエージェントを通らなければなりません、より短い経路はモバイルNetwork NodeとそのCorrespondent Nodeの間に存在するかもしれませんが。 さらに、モバイルRoutersの巣篭もりで、これらのデータ・パケットは複数のホームのエージェントといくつかのレベルのカプセル化に直面しなければなりません。(それは、避けられるかもしれません)。 これはパケット配信に関する様々な非能率と問題をもたらします。(パケット配信は結局、Network Nodesと、そして、モバイルNetwork Nodesからすべての通信システムを遮断できます)。
In the following sub-sections, we will describe the effects of a pinball route with NEMO Basic Support, how it may cause a bottleneck to be formed in the Home Network, and how these get amplified with
以下の小区分では、私たちはネモBasic Supportがあるピンボールルートの効果と、これらがホームNetworkでそれでどうボトルネックを形成するかもしれないか、そして、どう増幅されるかを説明するつもりです。
Ng, et al. Informational [Page 3] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [3ページ]情報のRFC4888ネモRO問題声明2007年7月
nesting of mobile networks. Closely related to nesting, we will also look into the sub-optimality even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. This is followed by a description of security policy in the Home Network that may forbid transit traffic from Visiting Mobile Nodes in mobile networks. In addition, we will explore the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network. We will also provide additional motivations for Route Optimization by considering the potential stalemate situation when a Home Agent is part of a mobile network.
モバイルネットワークの巣篭もり。 モバイルIPv6 Route OptimizationがネモBasic Supportの上で使用さえされるとき、密接に巣篭もりに関係づけられて、また、私たちはサブの最適を調べるつもりです。 VisitingのモバイルNodesからモバイルネットワークでトランジットトラフィックを禁じるかもしれないホームNetworkにおける、安全保障政策の記述はこれのあとに続いています。 さらに、私たちは同じモバイルネットワークの異なったリンクの上の2モバイルNetwork NodesのコミュニケーションのMRHAトンネルの影響について調査するつもりです。 また、私たちは、ホームのエージェントがモバイルネットワークの一部であるときに潜在的手詰まりの状況を考えることによって、Route Optimizationに関する追加動機を提供するつもりです。
2.1. Sub-Optimality with NEMO Basic Support
2.1. ネモが基本的のサブの最適サポート
With NEMO Basic Support, all packets sent between a Mobile Network Node and its Correspondent Node are forwarded through the MRHA tunnel, resulting in a pinball route between the two nodes. This has the following sub-optimal effects:
ネモBasic Supportと共に、MRHAトンネルを通ってモバイルNetwork NodeとそのCorrespondent Nodeの間に送られたすべてのパケットを進めます、2つのノードの間のピンボールルートをもたらして。 これには、以下のサブ最適の効果があります:
o Longer Route Leading to Increased Delay and Additional
Infrastructure Load
o より長い間、増強された遅れに通じて、追加インフラストラクチャ負荷を発送してください。
Because a packet must transit from a mobile network to the Home
Agent then to the Correspondent Node, the transit time of the
packet is usually longer than if the packet were to go straight
from the mobile network to the Correspondent Node. When the
Correspondent Node (or the mobile network) resides near the Home
Agent, the increase in packet delay can be very small. However,
when the mobile network and the Correspondent Node are relatively
near to one another but far away from the Home Agent on the
Internet, the increase in delay is very large. Applications such
as real-time multimedia streaming may not be able to tolerate such
increase in packet delay. In general, the increase in delay may
also impact the performance of transport protocols such as TCP,
since the sending rate of TCP is partly determined by the round-
trip time (RTT) perceived by the communication peers.
パケットが通過しなければならないのでモバイルネットワークからホームまで、通常、そして、Correspondent Nodeのエージェント、パケットのトランジット時間が、より長い、パケットがモバイルネットワークからCorrespondent Nodeまでまっすぐ行くつもりであったなら。 Correspondent Node(または、モバイルネットワーク)がホームのエージェントの近くに住んでいるとき、パケット遅れの増加は非常に小さい場合があります。 しかしながら、モバイルネットワークとCorrespondent Nodeがインターネットでお互いには比較的近いのですが、ホームのエージェントからほど遠いときに、遅れの増加は非常に大きいです。 リアルタイムのマルチメディアストリーミングなどのアプリケーションはパケット遅れのそのような増加を許容できないかもしれません。 また、一般に、遅れの増加はTCPなどのトランスポート・プロトコルの性能に影響を与えるかもしれません、TCPの送付レートがコミュニケーション同輩によって知覚された丸い旅行時間(RTT)までに一部決定しているので。
Moreover, by using a longer route, the total resource utilization
for the traffic would be much higher than if the packets were to
follow a direct path between the Mobile Network Node and
Correspondent Node. This would result in additional load in the
infrastructure.
そのうえ、より長いルートを使用することによって、トラフィックのための総リソース利用はパケットがモバイルNetwork Nodeの間の直接路に続くつもりであったか、そして、Correspondent Nodeよりはるかに高いでしょう。 これはインフラストラクチャで追加負荷をもたらすでしょう。
o Increased Packet Overhead
o 増強されたパケットオーバーヘッド
The encapsulation of packets in the MRHA tunnel results in
increased packet size due to the addition of an outer header.
This reduces the bandwidth efficiency, as an IPv6 header can be
MRHAトンネルのパケットのカプセル化は外側のヘッダーの追加のため増強されたパケットサイズをもたらします。 IPv6ヘッダーが減少できるようにこれは帯域幅効率を減少させます。
Ng, et al. Informational [Page 4] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [4ページ]情報のRFC4888ネモRO問題声明2007年7月
quite substantial relative to the payload for applications such as
voice samples. For instance, given a voice application using an 8
kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
(as in RFC 1889 [6]), the packet transmission rate will be 50
packets per second. Each additional IPv6 header is an extra 320
bits per packet (i.e., 16 kbps), which is twice the actual
payload!
声のサンプルなどの塗布のためのペイロードに比例してかなり実質的です。 例えば、8キロビット毎秒アルゴリズム(例えば、G.729)を使用することで音声アプリケーションを与えて、声を取ると、20ms毎が抽出されます。(パケット伝送レートがRFC1889[6])で1秒あたり50のパケットになるので。 パケット(すなわち、16キロビット毎秒)あたりそれぞれの追加IPv6ヘッダーは付加的な320ビットです!(それは、実際のペイロードの2倍です)。
o Increased Processing Delay
o 遅れを処理しながら、増加します。
The encapsulation of packets in the MRHA tunnel also results in
increased processing delay at the points of encapsulation and
decapsulation. Such increased processing may include encryption/
decryption, topological correctness verifications, MTU
computation, fragmentation, and reassembly.
また、MRHAトンネルのパケットのカプセル化はカプセル化と被膜剥離術のポイントで増強された処理遅れをもたらします。 そのような増強された処理は暗号化/復号化、位相的な正当性検証、MTU計算、断片化、および再アセンブリを含むかもしれません。
o Increased Chances of Packet Fragmentation
o パケット断片化の増強された機会
The augmentation in packet size due to packet encapsulation may
increase the chances of the packet being fragmented along the MRHA
tunnel. This can occur if there is no prior path MTU discovery
conducted, or if the MTU discovery mechanism did not take into
account the encapsulation of packets. Packet fragmentation will
result in a further increase in packet delays and further
reduction of bandwidth efficiency.
パケットカプセル化によるパケットサイズにおける増大はMRHAトンネルに沿って断片化されるパケットの可能性を増強するかもしれません。 MTU発見メカニズムがパケットのカプセル化を考慮に入れなかったなら行われたどんな先の経路MTU探索もなければ、これは起こることができます。 パケット断片化はパケット遅れのさらなる増加と帯域幅効率の一層の減少をもたらすでしょう。
o Increased Susceptibility to Link Failure
o 失敗をリンクする感受性増大
Under the assumption that each link has the same probability of
link failure, a longer routing path would be more susceptible to
link failure. Thus, packets routed through the MRHA tunnel may be
subjected to a higher probability of being lost or delayed due to
link failure, compared to packets that traverse directly between
the Mobile Network Node and its Correspondent Node.
各リンクにはリンクの故障の同じ確率があるという仮定で、失敗をリンクすることでは、より長いルーティング経路は、より影響されやすいでしょう。 したがって、MRHAトンネルを通って発送されたパケットは、失われるというより高い確率にかけられるか、またはリンクの故障のため遅れるかもしれません、それがモバイルNetwork NodeとそのCorrespondent Nodeの直接間で横断するパケットと比べて。
Ng, et al. Informational [Page 5] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [5ページ]情報のRFC4888ネモRO問題声明2007年7月
2.2. Bottleneck in the Home Network
2.2. ホームネットワークでは、隘路となってください。
Apart from the increase in packet delay and infrastructure load, forwarding packets through the Home Agent may also lead to either the Home Agent or the Home Link becoming a bottleneck for the aggregated traffic from/to all the Mobile Network Nodes. A congestion at home would lead to additional packet delay, or even packet loss. In addition, Home Agent operations such as security check, packet interception, and tunneling might not be as optimized in the Home Agent software as plain packet forwarding. This could further limit the Home Agent capacity for data traffic. Furthermore, with all traffic having to pass through the Home Link, the Home Link becomes a single point of failure for the mobile network.
また、パケット遅れとインフラストラクチャ負荷の増加は別として、ホームのエージェントを通してパケットを進めるのは/からモバイルすべてのNetwork Nodesまで集められたトラフィックのためのボトルネックになるホームのエージェントかホームLinkのどちらかに通じるかもしれません。 ホームでの混雑は追加パケット遅れ、またはパケット損失にさえつながるでしょう。 さらに、セキュリティチェック、パケット妨害、およびトンネリングがないかもしれないホームエージェント操作は明瞭なパケット推進としてホームエージェントソフトウェアで最適化されました。 これはさらにホームエージェント容量をデータ通信量に制限するかもしれません。 その上、ホームLinkを通り抜けなければならないすべてのトラフィックで、ホームLinkはモバイルネットワークのための1ポイントの失敗になります。
Data packets that are delayed or discarded due to congestion at the Home Network would cause additional performance degradation to applications. Signaling packets, such as Binding Update messages, that are delayed or discarded due to congestion at the Home Network may affect the establishment or update of bi-directional tunnels, causing disruption of all traffic flow through these tunnels.
混雑のためホームNetworkで遅らせられるか、または捨てられるデータ・パケットは追加性能退行をアプリケーションに引き起こすでしょう。 混雑のためホームNetworkで遅らせられるか、または捨てられるBinding Updateメッセージなどのシグナリングパケットは双方向のトンネルの設立かアップデートに影響するかもしれません、これらのトンネルを通るすべての交通の流れの分裂を引き起こして。
A NEMO Route Optimization mechanism that allows the Mobile Network Nodes to communicate with their Correspondent Nodes via a path that is different from the MRHA tunneling and thereby avoiding the Home Agent may alleviate or even prevent the congestion at the Home Agent or Home Link.
MRHAトンネリングと異なった経路とその結果、ホームのエージェントを避けることを通してモバイルNetwork Nodesと彼らのCorrespondent NodesとコミュニケートするネモRoute Optimizationメカニズムは、ホームのエージェントかホームLinkで混雑を軽減するか、または防ぎさえするかもしれません。
2.3. Amplified Sub-Optimality in Nested Mobile Networks
2.3. 入れ子にされたモバイルネットワークでサブ最適であるのに、増幅されます。
By allowing other mobile nodes to join a mobile network, and in particular mobile routers, it is possible to form arbitrary levels of nesting of mobile networks. With such nesting, the use of NEMO Basic Support further amplifies the sub-optimality of routing. We call this the amplification effect of nesting, where the undesirable effects of a pinball route with NEMO Basic Support are amplified with each level of nesting of mobile networks. This is best illustrated by an example shown in Figure 1.
他のモバイルノードがモバイルネットワーク、および特にモバイルルータに加わるのを許容することによって、任意のレベルのモバイルネットワークの巣篭もりを形成するのは可能です。 そのような巣篭もりで、ネモBasic Supportの使用はさらにルーティングのサブの最適を増幅します。 私たちは、これを巣篭もりの増幅作用と呼びます、ネモBasic Supportがあるピンボールルートの望ましくない効果がそれぞれのレベルのモバイルネットワークの巣篭もりで増幅されるところで。 図1に示された例でこれを例証するのは最も良いです。
Ng, et al. Informational [Page 6] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [6ページ]情報のRFC4888ネモRO問題声明2007年7月
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN2
+--------+ +--------+ +--------+ +--------+ | MR2_、ハ。| | MR3_、ハ。| | MR4_、ハ。| | MR5_、ハ。| +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +------------------------------+ | MR1_、ハ。|----| インターネット|-----CN1+--------+ +------------------------------+ | +---+---+ 根-MR| MR1| +-------+ | | +-------+ +-------+ サブMR| MR2| | MR4| +---+---+ +---+---+ | | +---+---+ +---+---+ サブMR| MR3| | MR5| +---+---+ +---+---+ | | ----+---- ----+---- MNN CN2
Figure 1: An Example of a Nested Mobile Network
図1: 入れ子にされたモバイルネットワークに関する例
Using NEMO Basic Support, the flow of packets between a Mobile Network Node, MNN, and a Correspondent Node, CN1, would need to go through three separate tunnels, illustrated in Figure 2 below.
ネモBasic Supportを使用して、モバイルNetwork Nodeと、MNNと、Correspondent Nodeの間のパケットの流れ(CN1)は、3つの別々のトンネルを通る必要があるでしょう、以下の図2では、イラスト入りです。
----------.
---------/ /----------.
-------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA
MR1---------MR1_HA
----------. ---------/ /----------. -------/ | | /------- MNN-----( - - | - - - | - - - | - - - | - - (------ CN1 MR3-------\ | | \-------MR3_HA MR2--------\ \----------MR2_HA MR1---------MR1_HA
Figure 2: Nesting of Bi-Directional Tunnels
図2: 双方向のTunnelsの巣篭もり
Ng, et al. Informational [Page 7] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [7ページ]情報のRFC4888ネモRO問題声明2007年7月
This leads to the following problems:
これは以下の問題を引き起こします:
o Pinball Route
o ピンボールルート
Both inbound and outbound packets will flow via the Home Agents of
all the Mobile Routers on their paths within the mobile network,
with increased latency, less resilience, and more bandwidth usage.
Appendix A illustrates in detail the packets' routes under
different nesting configurations of the Mobile Network Nodes.
本国行きの、そして、外国行きの両方のパケットはモバイルネットワークの中を彼らの経路のすべてのモバイルRoutersのホームのエージェントを通して流れるでしょう、増強された潜在、より少ない弾力、および、より多くの帯域幅用法で。 付録Aは詳細にモバイルNetwork Nodesの異なった巣篭もり構成の下のパケットのルートを例証します。
o Increased Packet Size
o 増強されたパケットサイズ
An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [7] cannot be
applied because both the source and destination (the intermediate
Mobile Router and its Home Agent) are different hop to hop.
付加的なIPv6ヘッダーはすべてのパケットに巣ごもるレベル単位で加えられます。 ソースと目的地の両方(中間的モバイルRouterとそのホームのエージェント)が飛び越す異なったホップであるので、[7]に示されたヘッダー圧縮は適用できません。
Nesting also amplifies the probability of congestion at the Home Networks of the upstream Mobile Routers. In addition, the Home Link of each upstream Mobile Router will also be a single point of failure for the nested Mobile Router.
また、巣篭もりは上流のモバイルRoutersのホームNetworksで混雑の確率を増幅します。 また、さらに、それぞれの上流のモバイルRouterのホームLinkは入れ子にされたモバイルRouterのために1ポイントの失敗になるでしょう。
2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization
2.4. 結合したモバイルIPv6経路最適化でサブ最適です。
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting Mobile Node of the mobile network. Packets sent to and from the Visiting Mobile Node will have to be routed not only via the Home Agent of the Visiting Mobile Node, but also via the Home Agent of the Mobile Router in the mobile network. This suffers the same amplification effect of nested mobile network mentioned in Section 2.3.
モバイルIPv6ホストがモバイルネットワークに加わるとき、それはモバイルネットワークのVisitingのモバイルNodeになります。 Nodeと、そして、VisitingのモバイルNodeから送られたパケットはVisitingのモバイルNodeのホームのエージェントを通して発送されるだけではなく、モバイルネットワークにおけるモバイルRouterのホームのエージェントを通しても発送されなければならないでしょう。 これはセクション2.3で言及された入れ子にされたモバイルネットワークの同じ増幅作用を受けます。
In addition, although Mobile IPv6 [4] allows a mobile host to perform Route Optimization with its Correspondent Node in order to avoid tunneling with its Home Agent, the "optimized" route is no longer optimized when the mobile host is attached to a mobile network. This is because the route between the mobile host and its Correspondent Node is subjected to the sub-optimality introduced by the MRHA tunnel. Interested readers may refer to Appendix A for examples of how the routes will appear with nesting of Mobile IPv6 hosts in mobile networks.
さらに、モバイルIPv6[4]はモバイルホストにホームのエージェントと共にトンネルを堀るのを避けるためにCorrespondent Nodeと共にRoute Optimizationを実行させますが、モバイルホストがモバイルネットワークに配属されるとき、「最適化された」ルートはもう最適化されません。 これはモバイルホストとそのCorrespondent Nodeの間のルートがMRHAトンネルによって導入されたサブの最適にかけられるからです。 興味のある読者はルートがモバイルネットワークにおける、モバイルIPv6ホストの巣篭もりでどう現れるかに関する例についてAppendix Aについて言及するかもしれません。
The readers should also note that the same sub-optimality would apply when the mobile host is outside the mobile network and its Correspondent Node is in the mobile network.
また、読者は、モバイルホストがモバイルネットワークの外にいて、モバイルネットワークにCorrespondent Nodeがあるとき、同じサブの最適が適用されることに注意するべきです。
Ng, et al. Informational [Page 8] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [8ページ]情報のRFC4888ネモRO問題声明2007年7月
2.5. Security Policy Prohibiting Traffic from Visiting Nodes
2.5. 訪問ノードからトラフィックを禁じる安全保障政策
NEMO Basic Support requires all traffic from visitors to be tunneled to the Mobile Router's Home Agent. This might represent a breach in the security of the Home Network (some specific attacks against the Mobile Router's binding by rogue visitors have been documented in [8][9]). Administrators might thus fear that malicious packets will be routed into the Home Network via the bi-directional tunnel. As a consequence, it can be expected that in many deployment scenarios, policies will be put in place to prevent unauthorized Visiting Mobile Nodes from attaching to the Mobile Router.
ネモBasic Supportは、訪問者からのすべてのトラフィックがモバイルRouterのホームのエージェントにトンネルを堀られるのを必要とします。 これはホームNetworkのセキュリティにおける不履行を表すかもしれません。(悪党訪問者によるモバイルRouterの結合に対するいくつかの特定の攻撃が[8][9])に記録されました。 その結果、管理者は、悪意があるパケットが双方向のトンネルを通ってホームNetworkに発送されると恐れるかもしれません。 結果として、多くの展開シナリオでは、方針が付くのからモバイルRouterまで権限のないVisitingモバイルNodesを防ぐために適所に置かれると予想できます。
However, there are deployment scenarios where allowing unauthorized Visiting Mobile Nodes is actually desirable. For instance, when Mobile Routers attach to other Mobile Routers and form a nested NEMO, they depend on each other to reach the Internet. When Mobile Routers have no prior knowledge of one another (no security association, Authentication, Authorization, and Accounting (AAA), Public-Key Infrastructure (PKI), etc.), it could still be acceptable to forward packets, provided that the packets are not tunneled back to the Home Networks.
しかしながら、展開シナリオが権限のないVisitingモバイルNodesを許容するのが実際に望ましいところにあります。 例えば、モバイルRoutersが他のモバイルRoutersに付いて、入れ子にされたネモを形成するとき、彼らは、インターネットに達するように互いに頼ります。 モバイルRoutersにお互い(セキュリティ協会がなく、Authentication、Authorization、およびAccounting(AAA)、公開鍵基盤(PKI)など)に関するどんな先の知識もないとき、パケットを進めるのはまだ許容できているかもしれません、パケットがホームNetworksにトンネルを堀って戻されなければ。
A Route Optimization mechanism that allows traffic from Mobile Network Nodes to bypass the bi-directional tunnel between a Mobile Router and its Home Agent would be a necessary first step towards a Tit for Tat model, where MRs would benefit from a reciprocal altruism, based on anonymity and innocuousness, to extend the Internet infrastructure dynamically.
モバイルNetwork NodesからのトラフィックがモバイルRouterとそのホームのエージェントの間の双方向のトンネルを迂回させることができるRoute OptimizationメカニズムはMRsがダイナミックにインターネット基盤を広げるために匿名と無害に基づく相互的な利他主義の利益を得るだろうTatモデルのためのTitに向かった必要な第一歩でしょう。
2.6. Instability of Communications within a Nested Mobile Network
2.6. 入れ子にされたモバイルネットワークの中のコミュニケーションの不安定性
Within a nested mobile network, two Mobile Network Nodes may communicate with each other. Let us consider the previous example illustrated in Figure 1 where MNN and CN2 are sharing a communication session. With NEMO Basic Support, a packet sent from MNN to CN2 will need to be forwarded to the Home Agent of each Mobile Router before reaching CN2, whereas, a packet following the direct path between them need not even leave the mobile network. Readers are referred to Appendix A.3 for detailed illustration of the resulting routing paths.
入れ子にされたモバイルネットワークの中では、2モバイルNetwork Nodesが互いにコミュニケートするかもしれません。 前の例が、図1でMNNとCN2がどこでコミュニケーションセッションを共有しているかを例証したと考えましょう。 ネモBasic Supportと共に、MNNからCN2に送られたパケットは、CN2に達する前にそれぞれのモバイルRouterのホームのエージェントに送られる必要があるでしょうが、それらの間の直接路に続くパケットはモバイルネットワークを出る必要さえありません。 読者は結果として起こるルーティング経路の詳細なイラストについてAppendix A.3を参照されます。
Apart from the consequences of increased packet delay and packet size, which are discussed in previous sub-sections, there are two additional effects that are undesirable:
前の小区分で議論する増強されたパケット遅れとパケットサイズの結果は別として、2つの望ましくない追加効果があります:
o when the nested mobile network is disconnected from the Internet
(e.g., MR1 loses its egress connectivity), MNN and CN2 can no
o 入れ子にされたモバイルネットワークいつインターネットから切断されるか、そして、(例えば、MR1は出口の接続性を失います)MNNとCN2缶のノー
Ng, et al. Informational [Page 9] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [9ページ]情報のRFC4888ネモRO問題声明2007年7月
longer communicate with each other, even though the direct path
from MNN to CN2 is unaffected;
より長い間、MNNからCN2までの直接路は影響を受けないのですが、互いにコミュニケートしてください。
o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a
bottleneck for all the traffic that is coming in and out of the
nested mobile network.
o 根のモバイルRouter(すなわち、MR1)の出口のリンクは出入りしている入れ子にされたモバイルネットワークのすべてのトラフィックのためのボトルネックになります。
A Route Optimization mechanism could allow traffic between two Mobile Network Nodes nested within the same mobile network to follow a direct path between them, without being routed out of the mobile network. This may also off-load the processing burden of the upstream Mobile Routers when the direct path between the two Mobile Network Nodes does not traverse these Mobile Routers.
同じモバイルネットワークの中で入れ子にされた2モバイルNetwork Nodesの間のトラフィックはRoute Optimizationメカニズムで彼らの間の直接路に続くことができるかもしれません、モバイルネットワークから発送されないで。 また、2モバイルNetwork Nodesの間の直接路がこれらのモバイルRoutersを横断しないとき、これは上流のモバイルRoutersの処理負担を積み下ろすかもしれません。
2.7. Stalemate with a Home Agent Nested in a Mobile Network
2.7. ホームのエージェントがいる手詰まりはモバイルネットワークを巣造りしました。
Several configurations for the Home Network are described in [10]. In particular, there is a mobile home scenario where a (parent) Mobile Router is also a Home Agent for its mobile network. In other words, the mobile network is itself an aggregation of Mobile Network Prefixes assigned to (children) Mobile Routers.
ホームNetworkのためのいくつかの構成が[10]で説明されます。 特に、移動住宅シナリオがまた(親)モバイルRouterがモバイルネットワークのホームのエージェントであるところにあります。 言い換えれば、モバイルネットワークはそれ自体で(子供)モバイルRoutersに割り当てられたモバイルNetwork Prefixesの集合です。
A stalemate situation exists in the case where the parent Mobile Router visits one of its children. The child Mobile Router cannot find its Home Agent in the Internet and thus cannot establish its MRHA tunnel and forward the visitor's traffic. The traffic from the parent is thus blocked from reaching the Internet, and it will never bind to its own (grandparent) Home Agent. Appendix B gives a detailed illustration of how such a situation can occur.
手詰まりの状況は親のモバイルRouterが子供のひとりを訪問する場合で存在しています。 その結果、子供のモバイルRouterはインターネットでホームのエージェントを見つけることができないで、MRHAトンネルを確立して、訪問者のトラフィックを進めることができません。 親からのトラフィックはインターネットに達するのがこのようにして妨げられます、そして、それはそれ自身の(祖父)ホームのエージェントに決して付かないでしょう。 付録Bはそのような状況がどう起こることができるかに関する詳細なイラストを与えます。
Then again, a Route Optimization mechanism that bypasses the nested tunnel might enable the parent traffic to reach the Internet and let it bind. At that point, the child Mobile Router would be able to reach its parent and bind in turn. Additional nested Route Optimization solutions might also enable the child to locate its Home Agent in the nested structure and bind regardless of whether or not the Internet is reachable.
そして、一方、入れ子にされたトンネルを迂回させるRoute Optimizationメカニズムは、親トラフィックがインターネットに達して、それを縛るのを可能にするかもしれません。 その時、子供のモバイルRouterは順番に親に届いて、付くことができるでしょう。 また、追加入れ子にされたRoute Optimizationソリューションは、子供が入れ子構造でホームのエージェントの居場所を見つけて、インターネットが届いているかどうかにかかわらず付くのを可能にするかもしれません。
3. Conclusion
3. 結論
With current NEMO Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in various inefficiencies associated with packet delivery. This document investigates such inefficiencies and provides the motivation behind Route Optimization for NEMO.
モバイルネットワークが離れているとき、現在のネモBasic Supportと共に、Network Nodesと、そして、モバイルNetwork NodesからのすべてのコミュニケーションがMRHAトンネルを通らなければなりません。 これはパケット配信に関連している様々な非能率をもたらします。 このドキュメントは、ネモのためにそのような非能率を調査して、Route Optimizationの後ろに動機を供給します。
Ng, et al. Informational [Page 10] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [10ページ]情報のRFC4888ネモRO問題声明2007年7月
We have described the sub-optimal effects of pinball routes with NEMO Basic Support, how they may cause a bottleneck to be formed in the Home Network, and how they get amplified with nesting of mobile networks. These effects will also be seen even when Mobile IPv6 Route Optimization is used over NEMO Basic Support. In addition, other issues concerning the nesting of mobile networks that might provide additional motivation for a NEMO Route Optimization mechanism were also explored, such as the prohibition of forwarding traffic from a Visiting Mobile Node through an MRHA tunnel due to security concerns, the impact of the MRHA tunnel on communications between two Mobile Network Nodes on different links of the same mobile network, and the possibility of a stalemate situation when Home Agents are nested within a mobile network.
私たちはネモBasic Supportがあるピンボールルートのサブ最適の効果と、それらがモバイルネットワークの巣篭もりでそれらがホームNetworkでボトルネックをどう形成させるかもしれないか、そして、どう増幅されるかを説明しました。 また、モバイルIPv6 Route OptimizationがネモBasic Supportの上で使用されるとき、これらの効果は見られさえするでしょう。 また、さらに、ネモRoute Optimizationメカニズムに関する追加動機を提供するかもしれないモバイルネットワークの巣篭もりに関する他の問題は探られました、安全上の配慮のためVisitingのモバイルNodeからMRHAトンネルまでトラフィックを進める禁止などのように; 同じモバイルネットワークの異なったリンクの上の2モバイルNetwork NodesのコミュニケーションのMRHAトンネルの影響、およびホームのエージェントがモバイルネットワークの中で入れ子にされる手詰まりの状況の可能性。
4. Security Considerations
4. セキュリティ問題
This document highlights some limitations of NEMO Basic Support. In particular, some security concerns could prevent interesting applications of the protocol, as detailed in Section 2.5.
このドキュメントはネモBasic Supportのいくつかの限界を強調します。 特に、何らかの安全上の配慮がセクション2.5で詳しく述べられるようにプロトコルのおもしろい応用を防ぐかもしれません。
Route Optimization for RFC 3963 [1] might introduce new threats, just as it might alleviate existing ones. This aspect will certainly be a key criterion in the evaluation of the proposed solutions.
ちょうど既存のものを軽減するかもしれないようにRFC3963[1]のためのルートOptimizationは新しい脅威を導入するかもしれません。 確かに、この局面は提案されたソリューションの評価で主要な評価基準になるでしょう。
5. Acknowledgments
5. 承認
The authors wish to thank the co-authors of previous versions from which this document is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by Masafumi Watari on the extracted appendix was written while still at Keio University. In addition, sincere appreciation is also extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa, and Patrick Wetterwald for their various contributions.
作者はこのドキュメントが引き出される旧バージョンの共著者に感謝したがっています: マルコのモルテーニ、パクEun-Kyoung、ヒロユキOhnishi、ティエリー・エルンスト、フェリクス・ウー、およびSouhwanユング。 まだ慶応義塾大学にある間、抽出された付録の上のMasafumi亘理による早めの仕事は書かれました。 また、さらに、心からの感謝は彼らの様々な貢献のためにヤリArkko、カルロスBernardos、グレッグ・デイリー、T.J.Kniveton、Henrik Levkowetz、エリックNordmark、Alexandruペトレスク、Heshamソリマン、龍治Wakikawa、およびパトリックWetterwaldに与えられます。
Ng, et al. Informational [Page 11] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [11ページ]情報のRFC4888ネモRO問題声明2007年7月
6. References
6. 参照
6.1. Normative Reference
6.1. 引用規格
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[1]Devarapalli、V.、Wakikawa、R.、ペトレスク、A.、およびP.Thubert、「ネットワークの移動性(ネモ)の基本的なサポートプロトコル」、RFC3963、2005年1月。
[2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[2] 方法とJ.とM.Kojo、「移動性関連用語」、RFC3753、2004年6月。
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
RFC 4885, July 2007.
[3] エルンストとT.とH.ラック、「ネットワーク移動性サポート用語」、RFC4885、2007年7月。
6.2. Informative Reference
6.2. 有益な参照
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[5] Ernst, T., "Network Mobility Support Goals and Requirements",
RFC 4886, July 2007.
[5] エルンスト、T.、「ネットワークの移動性は目標と要件をサポートする」RFC4886、2007年7月。
[6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
RFC 1889, January 1996.
[6]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[7] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
[7] デアリング、S.、およびB.Zill、「余分なAddress Deletion、IPv6"のEncapsulating IPv6、ProgressのWork、2001インチ年11月とき。
[8] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
"Threats for Basic Network Mobility Support (NEMO threats)",
Work in Progress, January 2004.
[8] ペトレスク、A.、Olivereau、A.、Janneteau、C.、およびH-Y。 ラック、「Basic Network Mobility Support(ネモの脅威)のための脅威」、ProgressのWork、2004年1月。
[9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
Analysis on NEMO Basic Operations", Work in Progress,
July 2004.
[9] ユング、S.、チャオ、F.、ウー、S.、キム、H-G.、およびS-W。 ソン、「ネモBasicの操作の脅威分析」は進歩、2004年7月に働いています。
[10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
Mobility Home Network Models", RFC RFC4887, July 2007.
[10]Thubert、P.、Wakikawa、R.、および「ネットワーク移動性ホームネットワークモデル」、RFC RFC4887、2007年7月対Devarapalli
[11] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[11]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
Ng, et al. Informational [Page 12] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [12ページ]情報のRFC4888ネモRO問題声明2007年7月
Appendix A. Various Configurations Involving Nested Mobile Networks
入れ子にされたモバイルネットワークにかかわる付録のA.の様々な構成
In the following sections, we try to describe different communication models that involve a nested mobile network and to clarify the issues for each case. We illustrate the path followed by packets if we assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms. Different cases are considered where a Correspondent Node is located in the fixed infrastructure, in a distinct nested mobile network as the Mobile Network Node, or in the same nested mobile network as the Mobile Network Node. Additionally, cases where Correspondent Nodes and Mobile Network Nodes are either standard IPv6 nodes or Mobile IPv6 nodes are considered. As defined in [3], standard IPv6 nodes are nodes with no mobility functions whatsoever, i.e., they are not Mobile IPv6 or NEMO enabled. This means that they cannot move around keeping open connections and that they cannot process Binding Updates sent by peers.
以下のセクションでは、私たちは、入れ子にされたモバイルネットワークにかかわる異なったコミュニケーションモデルについて説明して、各ケースのために問題をはっきりさせようとします。 私たちは私たちが、ノードがモバイルIPv6とネモBasic Supportメカニズムを使用するだけであると思うならパケットがあとに続いた経路を例証します。異なったケースはCorrespondent Nodeが固定インフラストラクチャで位置しているところ、モバイルNetwork Nodeとしての異なった入れ子にされたモバイルネットワーク、またはモバイルNetwork Nodeと同じ入れ子にされたモバイルネットワークで考えられます。 さらに、Correspondent NodesとモバイルNetwork Nodesが標準のIPv6ノードかモバイルIPv6ノードのどちらかであるケースは考えられます。 標準のIPv6ノードが[3]で定義されるように全く移動性機能がなければノードである、彼らは、すなわち、モバイルIPv6でなくて、またまたは有効にされたネモでもありません。 これは彼らがオープンな接続を保ちながら動き回ることができないで、同輩によって送られたBinding Updatesは処理できないことを意味します。
A.1. CN Located in the Fixed Infrastructure
A.1。 固定インフラストラクチャで位置するCN
The most typical configuration is the case where a Mobile Network Node communicates with a Correspondent Node attached in the fixed infrastructure. Figure 3 below shows an example of such topology.
最も典型的な構成はモバイルNetwork Nodeが固定インフラストラクチャで取り付けられたCorrespondent Nodeとコミュニケートするケースです。 以下の図3はそのようなトポロジーに関する例を示しています。
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
+--------+ +--------+ +--------+ | MR1_、ハ。| | MR2_、ハ。| | MR3_、ハ。| +---+----+ +---+----+ +---+----+ | | | +-------------------------+ | インターネット|----+ CN+-------------------------+ | | +---+---+ +--+-----+ 根-MR| MR1| | VMN_、ハ。| +---+---+ +--------+ | +---+---+ サブMR| MR2| +---+---+ | +---+---+ サブMR| MR3| +---+---+ | ----+---- MNN
Figure 3: CN Located at the Infrastructure
図3: インフラストラクチャで位置するCN
Ng, et al. Informational [Page 13] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [13ページ]情報のRFC4888ネモRO問題声明2007年7月
A.1.1. Case A: LFN and Standard IPv6 CN
A.1.1。 ケースA: LFNと標準のIPv6 CN
The simplest case is where both MNN and CN are fixed nodes with no mobility functions. That is, MNN is a Local Fixed Node, and CN is a standard IPv6 node. Packets are encapsulated between each Mobile Router and its respective Home Agent (HA). As shown in Figure 4, in such a case, the path between the two nodes would go through:
最も簡単なケースはノードが移動性機能なしでMNNとCNの両方に固定されているところです。 すなわち、MNNはLocal Fixed Nodeです、そして、CNは標準のIPv6ノードです。 パケットはそれぞれのモバイルRouterとそのそれぞれのホームエージェント(HA)の間でカプセルに入れられます。 図4に示されるように、このような場合には、2つのノードの間の経路は通られるでしょう:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
1 2 3 4 3 2 1MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3_、ハ。--- CN LFN IPv6ノード
The digits represent the number of IPv6 headers.
ケタはIPv6ヘッダーの数を表します。
Figure 4: MNN and CN Are Standard IPv6 Nodes
図4: MNNとCNは標準のIPv6ノードです。
A.1.2. Case B: VMN and MIPv6 CN
A.1.2。 ケースB: VMNとMIPv6 CN
In this second case, both end nodes are Mobile IPv6-enabled mobile nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 Route Optimization may thus be initiated between the two and packets would not go through the Home Agent of the Visiting Mobile Node or the Home Agent of the Correspondent Node (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent, in both directions. As shown in Figure 5, the path between MNN and CN would go through:
この2番目の場合では、両方のエンドノードがモバイルIPv6によって可能にされたモバイルノードである、すなわち、MNNはVisitingのモバイルNodeです。 その結果、モバイルIPv6 Route Optimizationは2つの間で開始されるかもしれません、そして、パケットはVisitingのモバイルNodeのホームのエージェントかCorrespondent Node(図では、目立たない)のホームのエージェントを通らないでしょう。 しかしながら、それでも、パケットはそれぞれのモバイルRouterとそのそれぞれのホームのエージェントの間で両方の方向にトンネルを堀られるでしょう。 図5に示されるように、MNNとCNの間の経路は通られるでしょう:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
1 2 3 4 3 2 1MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3_、ハ。--- CN VMN MIPv6
Figure 5: MNN and CN Are MIPv6 Mobile Nodes
図5: MNNとCNはMIPv6のモバイルノードです。
A.1.3. Case C: VMN and Standard IPv6 CN
A.1.3。 ケースC: VMNと標準のIPv6 CN
When the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. Therefore, MNN would establish a bi-directional tunnel with its HA, which causes the flow to go out the nested NEMO. Packets between MNN and CN would thus go through MNN's own Home Agent (VMN_HA). The path would therefore be as shown in Figure 6:
コミュニケーションがVisitingのモバイルNodeとして、または、Correspondent NodeとしてモバイルIPv6ノードにかかわるとき、標準のIPv6 Correspondent NodeがモバイルIPv6シグナリングを処理できないので、モバイルIPv6 Route Optimizationを実行できません。 したがって、MNNはHAと共に双方向のトンネルを確立するでしょう。(HAは入れ子にされたネモから流れを行かせます)。 その結果、MNNとCNの間のパケットはMNNの自己のホームエージェント(VMN_HA)を通るでしょう。 したがって、経路が図6に示されるようにあるでしょう:
Ng, et al. Informational [Page 14] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [14ページ]情報のRFC4888ネモRO問題声明2007年7月
2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN |
| 3
1 2 |
CN --- VMN_HA --- MR3_HA
IPv6 Node
2 3 4 5 4MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2、_ハ、VMN| | 3 1 2 | CN--- VMN_、ハ。--- MR3、_ハ、IPv6、ノード
Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図6: MNNはMIPv6のモバイルNodeです、そして、CNはStandard IPv6 Nodeです。
Providing Route Optimization involving a Mobile IPv6 node may require optimization among the Mobile Routers and the Mobile IPv6 node.
モバイルIPv6ノードにかかわるRoute Optimizationを提供するのはモバイルRoutersとモバイルIPv6ノードの中で最適化を必要とするかもしれません。
A.2. CN Located in Distinct Nested NEMOs
A.2。 異なった入れ子にされたNEMOsに位置するCN
The Correspondent Node may be located in another nested mobile network, different from the one MNN is attached to, as shown in Figure 7. We define such configuration as "distinct nested mobile networks".
Correspondent Nodeは別の入れ子にされたモバイルネットワークで位置するかもしれません、MNNが付けているものと異なります、図7に示されるように。 私たちは「異なった入れ子にされたモバイルネットワーク」のような構成を定義します。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
+--------+ +--------+ +--------+ +--------+ | MR2_、ハ。| | MR3_、ハ。| | MR4_、ハ。| | MR5_、ハ。| +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_、ハ。|----| インターネット|----| VMN_、ハ。| +--------+ +-------------------------+ +--------+ | | +---+---+ +---+---+ 根-MR| MR1| | MR4| +---+---+ +---+---+ | | +---+---+ +---+---+ サブMR| MR2| | MR5| +---+---+ +---+---+ | | +---+---+ ----+---- サブMR| MR3| CN+---+---+ | ----+---- MNN
Figure 7: MNN and CN Located in Distinct Nested NEMOs
図7: 異なった入れ子にされたNEMOsに位置するMNNとCN
Ng, et al. Informational [Page 15] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [15ページ]情報のRFC4888ネモRO問題声明2007年7月
A.2.1. Case D: LFN and Standard IPv6 CN
A.2.1。 ケースD: LFNと標準のIPv6 CN
Similar to Case A, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network, decapsulated by the Home Agents, and then encapsulated again on their way down the nested mobile network.
Case Aと同様であることで、私たちは両方のエンドノードがどんな移動性機能も持っていないケースで始めます。 パケットは、ホームのエージェントによってdecapsulatedされた入れ子にされたモバイルネットワークからの途中であらゆるモバイルRouterでカプセルに入れられて、次に、再び途中で入れ子にされたモバイルネットワークの下側にカプセルに入れられます。
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
1 2 3 4 3 2MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、LFN| | 1 1 2 3 2 | CN--- MR5--- MR4--- MR4_、ハ。--- MR5、_ハ、IPv6、ノード
Figure 8: MNN and CN Are Standard IPv6 Nodes
エイト環: MNNとCNは標準のIPv6ノードです。
A.2.2. Case E: VMN and MIPv6 CN
A.2.2。 ケースE: VMNとMIPv6 CN
Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Again, packets will not go through the Home Agent of the MNN or the Home Agent of the Mobile IPv6 Correspondent Node (not shown in the figure). However, packets will still be tunneled for each Mobile Router to its Home Agent and vice versa. Therefore, the path between MNN and CN would go through:
Case Bと同様です、両方のエンドノードがモバイルIPv6ノードであるときに、2つのノードがモバイルIPv6 Route Optimizationを開始するかもしれません。 一方、パケットはMNNのホームのエージェントかモバイルIPv6 Correspondent Nodeのホームのエージェント(図では、目立たない)を通らないでしょう。 しかしながら、それでも、パケットはそれぞれのモバイルRouterのために逆もまた同様にホームのエージェントにトンネルを堀られるでしょう。 したがって、MNNとCNの間の経路は通られるでしょう:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node
1 2 3 4 3 2MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、VMN| | 1 1 2 3 2 | CN--- MR5--- MR4--- MR4_、ハ。--- MR5、_ハ、MIPv6、ノード
Figure 9: MNN and CN Are MIPv6 Mobile Nodes
図9: MNNとCNはMIPv6のモバイルノードです。
A.2.3. Case F: VMN and Standard IPv6 CN
A.2.3。 ケースF: VMNと標準のIPv6 CN
Similar to Case C, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 Route Optimization cannot be performed because the standard IPv6 Correspondent Node cannot process Mobile IPv6 signaling. MNN would
Case Cと同様です、コミュニケーションがVisitingのモバイルNodeとして、または、Correspondent NodeとしてモバイルIPv6ノードにかかわるとき、標準のIPv6 Correspondent NodeがモバイルIPv6シグナリングを処理できないので、MIPv6 Route Optimizationを実行できません。 MNNはそうするでしょう。
Ng, et al. Informational [Page 16] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [16ページ]情報のRFC4888ネモRO問題声明2007年7月
therefore establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent as shown in Figure 10:
したがって、ホームのエージェントと共に双方向のトンネルを確立してください。 その結果、MNNとCNの間のパケットは図10に示されるようにMNNの自己のホームのエージェントを通るでしょう:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node
2 3 4 5 4 3MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、VMN| | 2 1 2 3 2 1 | CN--- MR5--- MR4--- MR4_、ハ。--- MR5_、ハ。--- VMN、_ハ、IPv6、ノード
Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図10: MNNはMIPv6のモバイルNodeです、そして、CNはStandard IPv6 Nodeです。
A.3. MNN and CN Located in the Same Nested NEMO
A.3。 同じ入れ子にされたネモに位置するMNNとCN
Figure 11 below shows the case where the two communicating nodes are connected behind different Mobile Routers that are connected in the same nested mobile network, and thus behind the same root Mobile Router. Route Optimization can avoid packets being tunneled outside the nested mobile network.
以下の図11は、2つの交信ノードが同じ入れ子にされたモバイルネットワークで接続される異なったモバイルRoutersの後ろと、そして、その結果、同じ根のモバイルRouterの後ろでどこに接続されるかをケースに示します。 ルートOptimizationは入れ子にされたモバイルネットワークの外でトンネルを堀られるパケットを避けることができます。
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
+--------+ +--------+ +--------+ +--------+ | MR2_、ハ。| | MR3_、ハ。| | MR4_、ハ。| | MR5_、ハ。| +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_、ハ。|----| インターネット|----| VMN_、ハ。| +--------+ +-------------------------+ +--------+ | +---+---+ 根-MR| MR1| +-------+ | | +-------+ +-------+ サブMR| MR2| | MR4| +---+---+ +---+---+ | | +---+---+ +---+---+ サブMR| MR3| | MR5| +---+---+ +---+---+ | | ----+---- ----+---- MNN CN
Ng, et al. Informational [Page 17] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [17ページ]情報のRFC4888ネモRO問題声明2007年7月
Figure 11: MNN and CN Located in the Same Nested NEMO
図11: 同じ入れ子にされたネモに位置するMNNとCN
A.3.1. Case G: LFN and Standard IPv6 CN
A.3.1。 ケースG: LFNと標準のIPv6 CN
Again, we start off with the case where both end nodes do not have any mobility functions. Packets are encapsulated at every Mobile Router on the way out of the nested mobile network via the root Mobile Router, decapsulated and encapsulated by the Home Agents, and then make their way back to the nested mobile network through the same root Mobile Router. Therefore, the path between MNN and CN would go through:
一方、私たちは両方のエンドノードがどんな移動性機能も持っていないケースで始めます。 パケットは、ホームのエージェントによってdecapsulatedされて、カプセル化された根のモバイルRouterを通して途中であらゆるモバイルRouterで入れ子にされたモバイルネットワークからカプセル化されて、次に同じ根を通した入れ子にされたモバイルネットワークへの彼らの道をモバイルRouterにします。 したがって、MNNとCNの間の経路は通られるでしょう:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
1 2 3 4 3 2MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、LFN| | 1 1 2 3 4 3 2 | CN--- MR5--- MR4--- MR1--- MR1_、ハ。--- MR4_、ハ。--- MR5、_ハ、IPv6、ノード
Figure 12: MNN and CN Are Standard IPv6 nodes
図12: MNNとCN Are Standard IPv6ノード
A.3.2. Case H: VMN and MIPv6 CN
A.3.2。 ケースH: VMNとMIPv6 CN
Similar to Case B and Case E, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization, which will avoid the packets going through the Home Agent of MNN or the Home Agent of the Mobile IPv6 CN (not shown in the figure). However, packets will still be tunneled between each Mobile Router and its respective Home Agent in both directions. Therefore, the path would be the same as with Case G and go through:
Case BとCase Eと同様です、両方のエンドノードがモバイルIPv6ノードであるときに、2つのノードがモバイルIPv6 Route Optimizationを開始するかもしれません。(IPv6 Route OptimizationはMNNのホームのエージェントかモバイルIPv6 CNのホームのエージェント(図では、目立たない)を通るパケットを避けるでしょう)。 しかしながら、それでも、パケットはそれぞれのモバイルRouterとそのそれぞれのホームのエージェントの間で両方の方向にトンネルを堀られるでしょう。 したがって、経路は、Case Gと同じであり、通られるでしょう:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node
1 2 3 4 3 2MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、LFN| | 1 1 2 3 4 3 2 | CN--- MR5--- MR4--- MR1--- MR1_、ハ。--- MR4_、ハ。--- MR5、_ハ、MIPv6、ノード
Figure 13: MNN and CN Are MIPv6 Mobile Nodes
図13: MNNとCNはMIPv6のモバイルノードです。
Ng, et al. Informational [Page 18] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [18ページ]情報のRFC4888ネモRO問題声明2007年7月
A.3.3. Case I: VMN and Standard IPv6 CN
A.3.3。 ケースI: VMNと標準のIPv6 CN
As for Case C and Case F, when the communication involves a Mobile IPv6 node either as a Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, MNN will establish a bi-directional tunnel with its Home Agent. Packets between MNN and CN would thus go through MNN's own Home Agent. The path would therefore be as shown in Figure 14:
コミュニケーションがVisitingのモバイルNodeとして、または、Correspondent NodeとしてモバイルIPv6ノードにかかわるとき、Case CとCase Fに関して、モバイルIPv6 Route Optimizationを実行できません。 したがって、MNNはホームのエージェントと共に双方向のトンネルを確立するでしょう。 その結果、MNNとCNの間のパケットはMNNの自己のホームのエージェントを通るでしょう。 したがって、経路が図14に示されるようにあるでしょう:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
2 3 4 5 4 3MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、VMN| | 2 | VMN_、ハ。| | 1 1 2 3 4 3 2 | CN--- MR5--- MR4--- MR1--- MR1_、ハ。--- MR4_、ハ。--- MR5、_ハ、IPv6、ノード
Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図14: MNNはMIPv6のモバイルNodeです、そして、CNはStandard IPv6 Nodeです。
A.4. CN Located Behind the Same Nested MR
A.4。 同じ入れ子にされたMRの後ろに位置するCN
Figure 15 below shows the case where the two communicating nodes are connected behind the same nested Mobile Router. The optimization is required when the communication involves MIPv6-enabled nodes.
図15 ショーの下では、2つの交信ノードが同じように後ろに接続されるこの件はモバイルRouterを入れ子にしました。 コミュニケーションがMIPv6によって可能にされたノードにかかわるとき、最適化が必要です。
Ng, et al. Informational [Page 19] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [19ページ]情報のRFC4888ネモRO問題声明2007年7月
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
+--------+ +--------+ +--------+ +--------+ | MR2_、ハ。| | MR3_、ハ。| | MR4_、ハ。| | MR5_、ハ。| +------+-+ +---+----+ +---+----+ +-+------+ \ | | / +--------+ +-------------------------+ +--------+ | MR1_、ハ。|----| インターネット|----| VMN_、ハ。| +--------+ +-------------------------+ +--------+ | +---+---+ 根-MR| MR1| +---+---+ | +-------+ サブMR| MR2| +---+---+ | +---+---+ サブMR| MR3| +---+---+ | -+--+--+MNN CN
Figure 15: MNN and CN Located Behind the Same Nested MR
図15: 同じ入れ子にされたMRの後ろに位置するMNNとCN
A.4.1. Case J: LFN and Standard IPv6 CN
A.4.1。 ケースJ: LFNと標準のIPv6 CN
If both end nodes are Local Fixed Nodes, no special function is necessary for optimization of their communications. The path between the two nodes would go through:
両方のエンドノードがLocal Fixed Nodesであるなら、どんな特別な機能も彼らのコミュニケーションの最適化に必要ではありません。 2つのノードの間の経路は通られるでしょう:
1
MNN --- CN
LFN IPv6 Node
1 MNN--- CN LFN IPv6ノード
Figure 16: MNN and CN Are Standard IPv6 Nodes
図16: MNNとCNは標準のIPv6ノードです。
A.4.2. Case K: VMN and MIPv6 CN
A.4.2。 ケースK: VMNとMIPv6 CN
Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two nodes may initiate Mobile IPv6 Route Optimization. Although few packets would go out the nested mobile network for the Return Routability initialization, however, unlike Case B and Case E, packets will not get tunneled outside the nested mobile network. Therefore, packets between MNN and CN would eventually go through:
Case Hと同様です、両方のエンドノードがモバイルIPv6ノードであるときに、2つのノードがモバイルIPv6 Route Optimizationを開始するかもしれません。 しかしながら、わずかなパケットしかReturn Routability初期化のためにCase BとCase Eと異なって入れ子にされたモバイルネットワークから進んでいないでしょうが、パケットは入れ子にされたモバイルネットワークの外でトンネルを堀られないでしょう。 したがって、MNNとCNの間のパケットは結局、通られるでしょう:
Ng, et al. Informational [Page 20] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [20ページ]情報のRFC4888ネモRO問題声明2007年7月
1
MNN --- CN
VMN MIPv6 Node
1 MNN--- CN VMN MIPv6ノード
Figure 17: MNN and CN are MIPv6 Mobile Nodes
図17: MNNとCNはMIPv6のモバイルNodesです。
If the root Mobile Router is disconnected while the nodes exchange keys for the Return Routability procedure, they may not communicate even though they are connected on the same link.
ノードがReturn Routability手順とキーを交換している間、根のモバイルRouter切断されるなら、同じリンクに接続されますが、それらは交信しないかもしれません。
A.4.3. Case L: VMN and Standard IPv6 CN
A.4.3。 ケースL: VMNと標準のIPv6 CN
When the communication involves a Mobile IPv6 node either as a Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Route Optimization cannot be performed. Therefore, even though the two nodes are on the same link, MNN will establish a bi-directional tunnel with its Home Agent, which causes the flow to go out the nested mobile network. The path between MNN and CN would require another Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
コミュニケーションがVisitingのモバイルNetwork Nodeとして、または、Correspondent NodeとしてモバイルIPv6ノードにかかわるとき、モバイルIPv6 Route Optimizationを実行できません。 したがって、同じリンクの上に2つのノードがありますが、MNNはホームのエージェントと共に双方向のトンネルを確立するでしょう。(そのエージェントは、入れ子にされたモバイルネットワークから流れを行かせます)。 MNNとCNの間の経路は、別のホームエージェント(VMN_HA)がこのモバイルIPv6ノードのために通るのを必要とするでしょう:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node
2 3 4 5 4 3MNN--- MR3--- MR2--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、VMN| | 2 | VMN_、ハ。| | 1 1 2 3 4 3 2 | CN--- MR5--- MR4--- MR1--- MR1_、ハ。--- MR2_、ハ。--- MR3、_ハ、IPv6、ノード
Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
図18: MNNはMIPv6のモバイルNodeです、そして、CNはStandard IPv6 Nodeです。
However, MNN may also decide to use its Care-of Address (CoA) as the source address of the packets, thus avoiding the tunneling with the MNN's Home Agent. This is particularly useful for a short-term communications that may easily be retried if it fails. Default Address Selection [11] provides some mechanisms for controlling the choice of the source address.
しかしながら、使用する、また、MNNが、決めるかもしれないそれ、Care、-、その結果MNNのホームのエージェントと共にトンネリングを避けるパケットのソースアドレスとしてのAddress(CoA)。 これは特に失敗するなら容易に再試行されるかもしれない短期的なコミュニケーションの役に立ちます。 デフォルトAddress Selection[11]はソースアドレスの選択を制御するのにいくつかのメカニズムを提供します。
Ng, et al. Informational [Page 21] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [21ページ]情報のRFC4888ネモRO問題声明2007年7月
Appendix B. Example of How a Stalemate Situation Can Occur
手詰まりの状況がどう起こることができるかに関する付録B.の例
Section 2.7 describes the occurrence of a stalemate situation where a Home Agent of a Mobile Router is nested behind the Mobile Router. Here, we illustrate a simple example where such a situation can occur.
セクション2.7はモバイルRouterのホームのエージェントがモバイルRouterの後ろで入れ子にされる手詰まりの状況の発生について説明します。 ここで、私たちはそのような状況が起こることができる簡単な例を例証します。
Consider a mobility configuration depicted in Figure 19 below. MR1 is served by HA1/BR and MR2 is served by HA2. The 'BR' designation indicates that HA1 is a border router. Both MR1 and MR2 are at home in the initial step. HA2 is placed inside the first mobile network, thus representing a "mobile" Home Agent.
以下の図19に表現された移動性構成を考えてください。 MR1はHA1/BRによって役立たれています、そして、MR2はHA2によって役立たれています。 'BR'名称は、HA1が境界ルータであることを示します。 MR1とMR2の両方が初期段階のホームにあります。 HA2は最初のモバイルネットワークの中に置かれて、その結果、「モバイル」のホームのエージェントの代理をします。
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
/-----CN+----------+ ホームのリンク1+--------+ | | ----+-----------------| HA1/Br|---| インターネット| | +--------+ | | | +----------+ +--+--+ +-----+ | MR1| | HA2| +--+--+ +--+--+ | | -+--------+--モバイルネットの1/ホームのリンク2| +--+--+ +--+--+ | MR2| | LFN| +--+--+ +--+--+ | | -+--------+ モバイルネットの2
Figure 19: Initial Deployment
図19: 初期の展開
In Figure 19 above, communications between CN and LFN follow a direct path as long as both MR1 and MR2 are positioned at home. No encapsulation intervenes.
上の図19では、MR1とMR2の両方がホームに置かれる限り、CNとLFNとのコミュニケーションは直接路に続きます。 カプセル化に全く介入しません。
In the next step, consider that the MR2's mobile network leaves home and visits a foreign network, under Access Router (AR) like in Figure 20 below.
次のステップでは、MR2のモバイルネットワークがホームと訪問を外国ネットワークに出て、(AR)が以下の図20でAccess Routerの下では、好きであると考えてください。
Ng, et al. Informational [Page 22] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [22ページ]情報のRFC4888ネモRO問題声明2007年7月
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
/-----CN+----------+ 家のリンク1+--------+ | | --+-----------| HA1/Br|---| インターネット| | +--------+ | | +--+--+ +-----+ +----------+ | MR1| | HA2| \ +--+--+ +--+--+ +-----+ | | | アルゴン| -+--------+可動のネットの1 +--+--+ 家のリンク2| +--+--+ +-----+ | MR2| | LFN| +--+--+ +--+--+ | | 可動のネットの2-+--------+-
Figure 20: Mobile Network 2 Leaves Home
図20: モバイルネットワーク2は家を出ます。
Once MR2 acquires a Care-of Address under AR, the tunnel setup procedure occurs between MR2 and HA2. MR2 sends a Binding Update to HA2 and HA2 replies with a Binding Acknowledgement to MR2. The bi- directional tunnel has MR2 and HA2 as tunnel endpoints. After the tunnel MR2HA2 has been set up, the path taken by a packet from CN towards LFN can be summarized as:
一度、MR2がaを取得する、Care、-、ARの下のAddressであり、トンネルセットアップ手順はMR2とHA2の間に起こります。 MR2はHA2へのBinding UpdateとBinding AcknowledgementとのMR2へのHA2回答を送ります。 両性愛者の方向のトンネルには、トンネル終点としてMR2とHA2があります。 トンネルMR2HA2がセットアップされた後に、以下としてパケットによってCNからLFNに向かって取られた経路はまとめることができます。
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
->>HA2=MR1は>Br=>アルゴン=>MR2->と等しいです。CN、-、>Br->、MR1、LFN。
Non-encapsulated packets are marked "->" while encapsulated packets are marked "=>".
要約のパケットは「=>」であるとマークされますが、非要約のパケットは"->"であるとマークされます。
Consider next the attachment of the first mobile network under the second mobile network, like in Figure 21 below.
次に、以下の図21などのような2番目のモバイルネットワークの下で最初のモバイルネットワークの付属を考えてください。
After this movement, MR1 acquires a Care-of Address valid in the second mobile network. Subsequently, it sends a Binding Update (BU) message addressed to HA1. This Binding Update is encapsulated by MR2 and sent towards HA2, which is expected to be placed in mobile net 1 and expected to be at home. Once HA1/BR receives this encapsulated BU, it tries to deliver to MR1. Since MR1 is not at home, and a tunnel has not yet been set up between MR1 and HA1, HA1 is not able to route this packet and drops it. Thus, the tunnel establishment procedure between MR1 and HA1 is not possible, because the tunnel between MR2 and HA2 had been previously torn down (when the mobile net 1 moved from home). The communications between CN and LFN stops, even though both mobile networks are connected to the Internet.
この動きの後にMR1がaを取得する、Care、-、2番目のモバイルネットワークで有効なAddress。 次に、それはHA1に記述されたBinding Update(BU)メッセージを送ります。 このBinding UpdateをMR2は要約して、HA2に向かって送ります。HA2は可動のネットの1に置かれると予想されて、家にあると予想されます。 HA1/BRがいったんこの要約のBUを受けると、それはMR1に配送しようとします。 MR1が家になくて、またトンネルがMR1とHA1の間でまだセットアップされていないので、HA1はこのパケットを発送できないで、それを落とします。 したがって、MR1とHA1の間のトンネル設立手順は可能ではありません、以前にMR2とHA2の間のトンネルを取りこわしたので(可動のネットであるときに、1は家から動きました)。 両方のモバイルネットワークはインターネットに接続されますが、CNとLFN停止とのコミュニケーション。
Ng, et al. Informational [Page 23] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [23ページ]情報のRFC4888ネモRO問題声明2007年7月
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
/-----CN+----------+ +--------+ | | | HA1/Br|---| インターネット| +--------+ | | +----------+ \ +-----+ | アルゴン| +--+--+ | +--+--+ +-----+ | MR2| | LFN| +--+--+ +--+--+ | | 可動のネットの2-+--------+- | +--+--+ +-----+ | MR1| | HA2| +--+--+ +--+--+ | | 可動のネットの1-+--------+-
Figure 21: Stalemate Situation Occurs
図21: 手詰まりの状況は起こります。
If both tunnels between MR1 and HA1, and between MR2 and HA2, were up simultaneously, they would have "crossed over" each other. If the tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be noticed that the path of the tunnel MR1-HA1 includes only one endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels are crossing over each other if the IP path between two endpoints of one tunnel includes one and only one endpoint of the other tunnel (assuming that both tunnels are up). When both endpoints of one tunnel are included in the path of the other tunnel, then tunnels are simply encapsulating each other.
MR1とHA1と、MR2とHA2の間の両方のトンネルが同時に上がったなら、それらは互いを「越えたでしょう」。 トンネルのMR1-HA1とMR2-HA2が図21に描かれるなら、トンネルMR1-HA1の経路がトンネルMR2-HA2(MR2終点)の1つの終点だけを含んでいるのに気付くことができるでしょうに。 1つのトンネルの2つの終点の間のIP経路がもう片方のトンネルの唯一無二の1つの終点を含んでいるなら(両方のトンネルが上がっていると仮定して)、2つのMR-HAトンネルが互いを越えています。 1つのトンネルの両方の終点がもう片方のトンネルの経路に含まれていると、トンネルは単に互いを要約しています。
Ng, et al. Informational [Page 24] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [24ページ]情報のRFC4888ネモ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
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
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
Fan Zhao UC Davis One Shields Avenue Davis, CA 95616 US
ファンチャオ・UCデイヴィス・1つのシールズ・Avenueカリフォルニア95616デイヴィス(米国)
Phone: +1 530 752 3128 EMail: fanzhao@ucdavis.edu
以下に電話をしてください。 +1 3128年の530 752メール: fanzhao@ucdavis.edu
Ng, et al. Informational [Page 25] RFC 4888 NEMO RO Problem Statement July 2007
ウン、他 [25ページ]情報のRFC4888ネモ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 26]
ウン、他 情報[26ページ]
一覧
スポンサーリンク
