RFC2103 日本語訳
2103 Mobility Support for Nimrod : Challenges and Solution Approaches.R. Ramanathan. February 1997. (Format: TXT=41352 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Ramanathan Request for Comments: 2103 BBN Systems and Technologies Category: Informational February 1997
Ramanathanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2103台のBBNシステムと技術カテゴリ: 情報の1997年2月
Mobility Support for Nimrod : Challenges and Solution Approaches
ニムロデの移動性サポート: 挑戦とソリューションアプローチ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support. We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol.
私たちはニムロデで移動性の問題について議論します。 移動性解決策はニムロデ構造の一部ではありませんが、ニムロデは、解決策には、ある特性があるのを必要とします。 私たちはニムロデが持っている移動性サポートのどんな解決策の要件も特定します。 私たちは、また、インターネットワークの中で移動性を支持するための既存のアプローチを分類して、比較して、それらの利点と損失について議論します。 最終的に、例として、私たちはIETFの中で開発されながらニムロデで現在計画を使用することで移動性を支持するためにメカニズムについて概説します--すなわち、モバイルIPプロトコル。
Table of Contents
目次
1 Introduction................................................... 1
2 Mobility : A Modular Perspective.............................. 2
3 Effects of Mobility............................................ 4
4 Approaches..................................................... 6
5 Solution using IETF Mobile-IP.................................. 10
5.1 Overview .................................................. 10
5.2 Protocol Details........................................... 11
6 Security Considerations........................................ 15
7 Summary........................................................ 16
8 Acknowledgements............................................... 16
9 Author's Address............................................... 17
1つの序論… 1 2の移動性: モジュールの見解… 移動性の2 3の効果… 4 4のアプローチ… IETFのモバイルIPを使用する6 5ソリューション… 10 5.1概観… 10 5.2 詳細について議定書の中で述べてください… 11 6 セキュリティ問題… 15 7概要… 16 8つの承認… 16 9作者のアドレス… 17
1 Introduction
1つの序論
The nature of emerging applications makes the support for mobility essential for any future routing architecture. It is the intent of Nimrod to allow physical devices as well as networks to be mobile.
アプリケーションとして現れる自然で、移動性のサポートはどんな今後のルーティング建築にも不可欠になります。 ニムロデはネットワークと同様にフィジカル・デバイスモバイルであることを許容する意図です。
Nimrod, as a routing and addressing architecture, does not directly concern itself with mobility. That is, Nimrod does not propose a solution for the mobility problem. There are two chief reasons for
ルーティングとアドレッシング体系として、ニムロデは直接移動性に携わりません。 すなわち、ニムロデは移動性問題の解決を提案しません。 チーフが推論する2があります。
Ramanathan Informational [Page 1] RFC 2103 Nimrod Mobility Support February 1997
[1ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
this. First, mobility is a non-trivial problem whose implications and requirements are still not well understood and will perhaps be understood only when a mobile internetwork is deployed on a large scale. Second, a number of groups (for instance the Mobile-IP working group of the IETF) are studying the problem by itself and it is not our intention to duplicate those efforts.
これ。 可動のインターネットワークが大規模に配備されるとき、まず最初に、移動性は含意と要件がまだよく理解されていなくて、恐らく理解されている重要な問題専用です。 2番目に、多くのグループ(例えば、IETFのモバイルIPワーキンググループ)自体が問題を研究しています、そして、それはそれらの努力をコピーするという私たちの意志ではありません。
This attitude towards mobility is consistent with Nimrod's general philosophy of flexibility, adaptability and incremental change.
移動性に対するこの態度はニムロデの柔軟性、適応性、および漸進的変化の一般的な哲学と一致しています。
While a mobility solution is not part of the "core" Nimrod architecture, Nimrod does require that the solution have certain characteristics. It is the purpose of this document to discuss some of these requirements and evaluate approaches towards meeting them.
移動性解決策は「コア」ニムロデ構造の一部ではありませんが、ニムロデは、解決策には、ある特性があるのを必要とします。 これらの要件のいくつかについて議論して、それらに会うことに向かったアプローチを評価するのは、このドキュメントの目的です。
We begin by identifying the precise nature of the functionality needed to accommodate mobile entities (section 2). Following that, we discuss the effects of mobility on Nimrod (section 3). Next, we classify current and possible approaches to a solution for mobility (section 4) and finally (in section 5) we describe how mobility can be implemented using the IETF's Mobile-IP protocol.
私たちは、可動の実体(セクション2)を収容するのに必要である機能性の正確な本質を特定することによって、始めます。 それに続いて、私たちはニムロデ(セクション3)への移動性の効果について検討します。 次に、移動性(セクション4)の解決策への現在の、そして、可能なアプローチを分類します、そして、最終的に(セクション5で)私たちはIETFのモバイルIPプロトコルを使用することでどう移動性を実行できるかを説明します。
This document uses many terms and concepts from the Nimrod Architecture document [CCS96] and some terms and concepts (in section 5) from the Nimrod Functionality document [RS96]. Much of the discussion assumes that you have read at least the Nimrod Architecture document [CCS96].
このドキュメントはニムロデFunctionalityドキュメント[RS96]からのいくつかのニムロデArchitectureドキュメントからの多くの用語と概念[CCS96]、用語、および概念(セクション5の)を使用します。 議論の多くが、あなたが少なくともニムロデArchitectureドキュメント[CCS96]を読んだと仮定します。
2 Mobility : A Modular Perspective
2の移動性: モジュールの見解
Nimrod has a basic feature that helps accommodate mobility in a graceful and natural manner, namely, the separation of the endpoint naming space from the locator space. The Nimrod architecture [CCS96] associates an endpoint with a globally unique endpoint identifier (EID) and an endpoint label (EL). The location of the endpoint within the Internetwork topology is given by its locator. When an endpoint moves, its EID and EL remain the same, but its locator might change. Nimrod can route a packet to the endpoint after the move, provided it is able to obtain its new locator.
ニムロデには、優雅で生まれながらの方法で移動性を収容するのを助ける基本的特徴、すなわち、ロケータスペースからスペースを命名する終点の分離があります。 ニムロデ構造[CCS96]はグローバルにユニークな終点識別子(EID)と終点ラベル(EL)に終点を関連づけます。 ロケータはInternetworkトポロジーの中の終点の位置を与えます。 終点が動くとき、そのEIDとELは同じままで残っていますが、ロケータは変化するかもしれません。 新しいロケータを得ることができるなら、ニムロデは移動の後にパケットを終点に発送できます。
Ramanathan Informational [Page 2] RFC 2103 Nimrod Mobility Support February 1997
[2ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
Thus, providing a solution to mobility in the context of Nimrod may be perceived as one of maintaining a dynamic association between the endpoints and the locators. Extending this viewpoint further, one can think of mobility-capable Nimrod as essentially consisting of two "modules": the Nimrod routing module and the dynamic association module (DAM). The DAM is an abstraction, embodying the functionality pertinent to maintaining the dynamic association. This is a valuable paradigm because it facilitates the comparison of various mobility schemes from a common viewpoint. Our discussion will be structured based on the DAM abstraction and will be in two parts, the themes of which are :
したがって、ニムロデの文脈の移動性の解決法を提供するのは終点とロケータとのダイナミックな協会を維持するものとして知覚されるかもしれません。 さらにこの観点を広げていて、人は2「モジュール」から同じくらい本質的には成る移動性有能なニムロデを思うことができます: ニムロデルーティングモジュールとダイナミックな協会モジュール(DAM)。 ダイナミックな協会を維持するのに適切な機能性を具体化して、DAMは抽象化です。 一般的な観点から様々な移動性計画の比較を容易にするので、これは貴重なパラダイムです。 私たちの議論は、DAM抽象化に基づいて構造化されて、2つの部品にあるでしょう。そのテーマはことです:。
o What constitutes mobility for the DAM and Nimrod? Is the
realization of mobility as a mobility "module" that interacts
with Nimrod viable? What then are the interactions between
Nimrod and such a module? These points will be discussed in
section 3.
o 何がDAMとニムロデのために移動性を構成しますか? ニムロデと対話する移動性「モジュール」としての移動性の実現は実行可能ですか? 次は何、ニムロデとそのようなモジュールとの相互作用はそうですか? セクション3でこれらのポイントについて議論するでしょう。
o What are some of the approaches one can take in engineering the DAM
functionality? We classify some approaches and compare them in
section 4.
o DAMの機能性を設計する1つが中に入れることができるアプローチのいくつかが何ですか? 私たちは、いくつかのアプローチを分類して、セクション4でそれらを比較します。
A word of caution: the DAM should not be thought of as something equivalent to the current day Domain Name Service (DNS) - the DAM is a more general concept than that. For instance, consider a mobility solution for Nimrod similar to the scheme described in [Sim94]. Very roughly, this approach is as follows: Every endpoint is associated with a "home" locator. If the endpoint moves, it tells a "home representative" about its new locator. Packets destined for the endpoint sent to the old locator are picked up by the home representative and sent to the new locator. In this scheme, the DAM embodies the functionalities implemented by all of the home representatives in regard to tracking the mobile hosts. The point is that the association maintenance, while required in some form or other, may not be an explicitly distinct part, but implicit in the way mobility is handled.
警告の単語: 現在の日Domain Name Service(DNS)に何か同等なものとしてDAMを考えるべきではありません--DAMはそれより一般的な概念です。 例えば、移動性が[Sim94]で説明された計画と同様のニムロデの解決策であると考えてください。 非常におよそ、このアプローチは以下の通りです: あらゆる終点が「家」ロケータに関連しています。 終点が動くなら、それは新しいロケータに関して「家代表」について話します。 古いロケータに送られた終点に運命づけられたパケットを、家代表が拾って、新しいロケータに送ります。 この計画では、DAMは家代表のすべてによってモバイルホストを追跡することに関して実行された機能性を具体化します。 ポイントは協会維持が何らかのフォームで必要である間明らかに異なった部分であって、しかし、移動性が扱われる方法で暗黙でないかもしれないということです。
Thus, the DAM is merely an abstraction useful to our discussion and should not be construed as dictating a design.
したがって、DAMを単に私たちの議論の役に立つ抽象化であり、デザインを書き取るのに理解するべきではありません。
In summary, we view the Nimrod architecture as carrying a functional "stub" for mobility, the details of the stub being deferred for later. The stub will be elaborated when a solution that meets the requirements of Nimrod becomes available (for instance from the IETF Mobile-IP research). We do not, however, preclude the modification of any such solutions to meet the Nimrod requirements or preclude the development of an independent solution within Nimrod.
概要では、私たちは機能的な「スタッブ」を運ぶと移動性のためにニムロデ構造をみなします、延期されるスタッブの細部、後で。 ニムロデの必要条件を満たす解決策が利用可能に(例えばIETFモバイルIP研究から)なるとき、スタッブは練られるでしょう。 しかしながら、私たちは、ニムロデの中でニムロデ必要条件を満たすか、または独自の解決策の開発を排除するためにどんなそのような解決策の変更も排除しません。
Ramanathan Informational [Page 3] RFC 2103 Nimrod Mobility Support February 1997
[3ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
3 Effects of Mobility
移動性の3つの効果
One consequence of mobility is the change in the locator of an endpoint. However, not all instances of mobility result in a locator change (for instance, there is no locator change if a host moves within a LAN) and a change in the locator is not the only possible effect of mobility. Mobility might also cause a change in the topology map. This typically happens when entire networks move (e.g., an organization relocates, a wireless network in a train or plane moves between cells, etc.). If the network is a Nimrod network, we might have a change in the connectivity of the node representing the network and hence a change in the map.
移動性の1つの結果が終点のロケータで変化です。 しかしながら、ロケータの移動性結果のすべての例が変化するというわけではありません、そして、(例えば、ホストがLANの中で移るなら、ロケータ変化が全くありません)ロケータにおける変化は移動性の唯一の可能な効果ではありません。 また、移動性はトポロジー地図における変化を引き起こすかもしれません。 全体のネットワークが動くと(例えば組織は移動して、列車か飛行機のワイヤレス・ネットワークはセルなどの間を動きます)、これは通常起こります。 私たちは、ネットワークがニムロデネットワークであるなら、地図でネットワークを代表して、したがって、変化を代表しながら、ノードの接続性に変化を持っているかもしれません。
In this section, we consider the effects of mobility on the two "modules" identified above: Nimrod, which provides routing to a locator, and a hypothetical instantiation of the DAM, which provides a dynamic endpoint-locator association, for use by Nimrod. We consider four scenarios based on whether or not the topology and an endpoint's locator changes and comment on the effect of the scenarios on Nimrod and the DAM.
このセクションでは、私たちは以下の上で特定された2「モジュール」への移動性の効果を考えます。 (彼はルーティングをロケータに提供します)。ニムロデとDAMの仮定している具体化。(それは、ダイナミックな終点ロケータ協会をニムロデによる使用に提供します)。 私たちはニムロデとDAMへのシナリオの効果のトポロジーと終点のロケータが変化するかどうか基づく4つのシナリオとコメントを考えます。
Scenario 1. Neither the locator nor the topology changes. This
is the trivial case and affects neither the DAM nor Nimrod. An
example of this scenario is when a workstation is moved to a new
interface on the same local area network(This is not true for all
LANs, only those in which all interfaces are part of the same
Nimrod node) or when mobility is handled transparently
(by lower layers).
シナリオ1。 ロケータもトポロジーも変化しません。 これは、些細なケースであり、DAMもニムロデも影響しません。 このシナリオに関する例はワークステーションがいつ同じローカル・エリア・ネットワークで新しいインタフェースに動かされるか、そして、(すべてのLANには、これが本当ではありません、すべてのインタフェースが同じニムロデノードの一部であるそれらだけ)または移動性がいつ透明(下層で)に扱われるかということです。
Scenario 2. The locator changes but the topology remains the same.
This is the case when an endpoint moves from one node to another,
thereby changing its locator. The DAM is affected in this case,
since it has to note the new endpoint-locator association and
indicate this to Nimrod if necessary. The effect on Nimrod is
related to obtaining this change from the DAM. For instance,
Nimrod may be informed of this change or ask for the association
if and when it finds out that the mobile host cannot be reached.
シナリオ2。 ロケータは変化しますが、トポロジーは同じままで残っています。 終点が1つのノードから別のノードまで動くとき、これはそうであって、その結果、ロケータを変えます。 DAMはこの場合影響を受けます、新しい終点ロケータ協会に注意して、必要ならこれをニムロデに示さなければならないので。 ニムロデへの効果はDAMからのこの変化を得ると関連します。 例えば、モバイルホストに連絡できないのが見つけられるなら、ニムロデは、この変化において知識があるか、または協会を求めるかもしれません。
Scenario 3. The locator does not change but the topology changes.
One way this could happen is if a network node moves and changes
its neighbors (topology change) but remains within the same
enclosing node. The DAM is not affected because the
endpoint-locator association has not changed. Nimrod is affected
in the sense that the topology map would now have to be updated.
シナリオ3。 ロケータは変化ではなく、トポロジーに変化させます。 これが起こることができた1つの方法はネットワーク・ノードが動いて、隣人(トポロジー変化)を変えますが、ノードを同封しながら同じくらい残っているかどうかということです。 終点ロケータ協会が変化していないので、DAMは影響を受けません。 ニムロデは現在トポロジー地図をアップデートしなければならないだろうという意味で影響を受けます。
Ramanathan Informational [Page 4] RFC 2103 Nimrod Mobility Support February 1997
[4ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
Scenario 4. Both the locator and the topology change. If a network
node moves out of its enclosing node, we have a change both in
the map and in the locators of the devices in the network. In
this case, both Nimrod and the DAM are affected.
シナリオ4。 ロケータとトポロジーの両方が変化します。 ネットワーク・ノードが、ノードを同封するのを引っ越すなら、私たちはネットワークで地図と装置のロケータにおける変化を持っています。 この場合、ニムロデとDAMの両方が影響を受けます。
In scenarios 3 and 4, it may not be sufficient to simply let Nimrod handle the topological change using the update mechanisms described in [RS96]. These mechanisms are likely to be optimized for relatively slow changes.
シナリオ3と4では、ニムロデに[RS96]で説明されたアップデートメカニズムを使用することで位相的な変化を単に扱わせるのは、十分でないかもしれません。 これらのメカニズムは比較的遅い変化のために最適化されそうです。
Mobile wireless networks (in trains and cars for instance) are likely to produce more frequent changes in topology. Therefore, it might be necessary that topological updates caused by mobility be handled using additional mechanisms. For instance, one might send specific updates to appropriate node representatives, so that packets entering that node can be routed using the new topology. We observe that accommodating mobility of networks, especially the fast moving ones, might require a closer interaction between Nimrod and the DAM than required for endpoint mobility. It is beyond the scope of this document to specify the nature of this interaction; however, we note that a solution to mobility should handle the case when a network as a whole moves. Current trends [WJ92] indicate that such situations are likely to be common in future when wireless networks will be present in trains, airplanes, cars, ships, etc.
モバイルワイヤレス・ネットワーク(列車と例えば、車の)はトポロジーの、より頻繁な変化を発生させそうです。 したがって、移動性によって引き起こされた位相的なアップデートが追加メカニズムを使用することで扱われるのが必要であるかもしれません。例えば、1つはノード代表を当てるために特定のアップデートを送るかもしれません、新しいトポロジーを使用することでそのノードを入力するパケットを発送できるように。 私たちは、ネットワークの親切な移動性(特に速い感動的な方)がニムロデとDAMとの終点の移動性のために必要とされるより近い相互作用を必要とするかもしれないのを観測します。 それはこの相互作用の自然を指定するためにこのドキュメントの範囲を超えています。 しかしながら、私たちは、ネットワークが全体で動くとき、移動性の解決策がケースを扱うべきであることに注意します。 現在の傾向[WJ92]は、ワイヤレス・ネットワークが列車、飛行機、車、船などで存在するとき、そのような状況がこれから一般的である傾向があることを示します。
In summary, if we discount the movement of networks, i.e., assume no topology changes, it appears that the mobility solution can be kept fairly independent of Nimrod and in fact can be accommodated by an implementation of the DAM. However, to accommodate network mobility (scenarios 3 and 4), it might be necessary for Nimrod routing/routers to get involved with mobility.
すなわち、私たちがネットワークの動きを無視するなら、概要では、トポロジー変化を全く仮定しないでください、そして、移動性解決策をニムロデから独立しているように公正に保つことができて、DAMの実現で事実上、対応できるように見えます。 しかしながら、ネットワークの移動性(シナリオ3と4)を収容するために、ニムロデルーティング/ルータが移動性にかかわるのが必要であるかもしれません。
Beyond the constraints imposed by the interaction with Nimrod, it is desirable that the mobility solution have some general features. By general, we mean that these are not Nimrod specific. However, their paramount importance in future applications makes them worth mentioning in this document. The desirable features are :
ニムロデとの相互作用によって課された規制を超えて、移動性解決策にはいくつかの一般的な特徴があるのは、望ましいです。 一般で、私たちは、これらがニムロデ特有でないと言っています。 しかしながら、将来のアプリケーションにおける自己の最高の重要性で、それらは本書では言及する価値があるようになります。 望ましい特徴は以下の通りです。
o Support of both off-line and on-line mobility. Off-line mobility
(or portability) refers to the situation in which a session is
torn down during the move, while on-line mobility refers to the
situation in which the session stays up during the move. While
currently much of the mobility is off-line, trends indicate that
a large part of mobility in the future is likely to be on-line. A
solution that only supports off-line mobility would probably have
limited applications in future.
o オフラインの、そして、オンラインの両方の移動性のサポート。 オフライン移動性(または、携帯性)は移動の間セッションが取りこわされる状況について言及します、オンライン移動性が移動の間セッションが残っている状況について言及しますが。 現在の移動性の多くがオフラインである間、傾向は、移動性のかなりの部分が将来オンラインである傾向があることを示します。 オフライン移動性を支持するだけである解決策はこれから、たぶんアプリケーションを制限したでしょう。
Ramanathan Informational [Page 5] RFC 2103 Nimrod Mobility Support February 1997
[5ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
o Scalability. One of the primary goals of Nimrod is scalability,
and it would be contrary to our design goals if the mobility
solution does not scale. The Internet is rapidly growing and with
the advent of Personal Communication Systems (PCS) [WJ92], the
number and rapidity of mobile components in the Internet is also
likely to increase. Thus, there are three directions in which
scalability is important : size of the network, number of mobile
entities and the frequency of movement of the mobile entities.
o スケーラビリティ。 ニムロデの第一の目標の1つはスケーラビリティです、そして、移動性解決策が比例しないなら、それは私たちのデザイン目標とは逆にあるでしょう。 インターネットも、急速に成長していて、また、可動のコンポーネントのパーソナルCommunication Systems(PCS)[WJ92]の到来、数、および急速がインターネットにある状態で、増加しそうです。 したがって、スケーラビリティが重要である3つの方向があります: ネットワークのサイズ、可動の実体の数、および可動の実体の動きの頻度。
Note that for any given system with minimum response time (to a
move) of o seconds, if the mobile entity changes attachment points
faster than 1=o changes per second, the system will fail to track
the entity. Augmenting traditional location tracking mechanisms
with special techniques such as predictive routing might be
necessary in this case. Hooks in the mobility solution for such
augmentation is a desirable feature.
可動の実体が1=oが1秒単位で変化するより速く付着点を変えると、o秒の最小の応答時間(移動への)があるどんな与えられたシステムのためにも、システムが実体を追跡しないことに注意してください。 予言のルーティングなどの特殊技術で伝統的な位置の追跡メカニズムを増大させるのがこの場合必要であるかもしれません。 そのような増大の移動性解決策のフックは望ましい特徴です。
o Security. It is likely that in the future, there will be increased
demand for secure communications. Apart from the non-mobility
specific security mechanisms, the solution should address the
following :
o セキュリティ。 将来、安全なコミュニケーションを求める需要増がありそうでしょう。 非の移動性の特定のセキュリティー対策は別として、解決策は以下を記述するべきです:
- Authentication. The information sent by a mobile host about its location should be authenticated to prevent impersonation. Additionally, there should be mechanisms to decide if a mobile user who wishes to join a network has the privileges to do so or not.
- 認証。 位置に関してモバイルホストによって送られた情報は、ものまねを防ぐために認証されるべきです。 さらに、そうするためにネットワークに加わりたがっている可動のユーザが特権を持っているかどうか決めるメカニズムがあるはずです。
- Denial of service. The schemes employed for handling mobility in general could be a drain on the resources if not controlled carefully. Specifically, the resource intensive portions of the protocol should be guarded so that inappropriate use of them does not cause excessive load on the network.
- サービスの否定。 取り扱いの移動性に使われた計画は、一般にリソースへの負担であるかもしれないか慎重に制御されました。 明確に、プロトコルのリソースの徹底的な部分が用心深いはずであるので、それらの誤用はネットワークで負担過重を引き起こしません。
4 Approaches
4つのアプローチ
As discussed in section 2, the problem of mobility in the context of Nimrod may be viewed as one of maintaining a dynamic association (DAM) and communicating this association and changes therein to Nimrod. Approaches to mobility may be classified based on how different aspects of the DAM are addressed.
セクション2で議論するように、ニムロデの文脈の移動性の問題は、ダイナミックな協会(DAM)を維持して、この協会を伝えるものとして見なされるかもしれなくて、そこにニムロデに変わらせます。 DAMの異なった局面がどう記述されるかに基づいて移動性へのアプローチは分類されるかもしれません。
Ramanathan Informational [Page 6] RFC 2103 Nimrod Mobility Support February 1997
[6ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
Our classification identifies two aspects to the mobility solution :
私たちの分類は移動性解決策に2つの局面を特定します:
1. How and where to maintain the dynamic association between
endpoints and locators? This may be perceived as a problem of
database maintenance. The database may be maintained in a
centralized fashion, wherein a single entity maintains the
association and updates are sent to it by the mobile host or in
a distributed fashion, wherein there are a number of entities
that store the associations.
1. どのように、どこで終点の間のダイナミックな協会を維持するか、そして、ロケータ? これはデータベース維持の問題として知覚されるかもしれません。 (単一体はそれで協会を維持します)。集結されたファッションでデータベースを維持するかもしれません、そして、モバイルホストか分配されたファッションでアップデートをそれに送ります。(それには、協会を格納する多くの実体があります)。
A (distributed) database that stores the endpoint-locator
mapping is required by Nimrod even in the absence of mobility. If
this service can accommodate dynamic update and retrieval requests
at the rate produced by mobility, this service is a candidate for a
solution. However, we note that the availability of such a system
should not be a requirement for the mobility solution.
終点ロケータマッピングを格納する(分配される)のデータベースは移動性がないときでさえニムロデによって必要とされます。 このサービスが移動性によって生産されたレートでダイナミックなアップデートと検索要求に対応できるなら、このサービスは解決策の候補です。 しかしながら、私たちは、そのようなシステムの有用性が移動性解決策のための要件であるべきでないことに注意します。
2. Where to do the remapping between the endpoint and locator, in
case of a change in association? By remapping, we mean associate
a new locator with the endpoint. Some candidates are : the
source, the "home" location of the host that has moved and any
router (say, between the source and the destination) in the network.
2. どこで協会における変化の場合に終点とロケータの間で再写像しますか? 再写像することによって、私たちは、新しいロケータを終点に関連づけると言っています。 何人かの候補は以下の通りです。 ソース、移ったホストの「家」位置、およびネットワークにおけるどんなルータ(たとえばソースと目的地の間で)。
Many of the existing approaches and perhaps some new approaches to the problem of mobile internetworking may be seen to be instantiations of a combination of a dynamic association method and a remapping method. We
存在の多くにアプローチします、そして、恐らく可動のインターネットワーキングの問題へのいくつかの新しいアプローチがダイナミックな協会方法と再写像方法の組み合わせの具体化であると考えられるかもしれません。 私たち
(Re-mapping location)
|
v
-----------------------------------------
| |Source | Home | Routers |
-----------------------------------------
(Assoc. |Centralized | A1 | X | X |
maint)-> ----------------------------------------
|Distributed | X | A2 | A3 |
----------------------------------------
(位置を再写像します)| v----------------------------------------- | |ソース| ホーム| ルータ| ----------------------------------------- (Assoc。 |集結されます。| A1| X| X| maint)->。---------------------------------------- |分配されます。| X| A2| A3| ----------------------------------------
Table 1 : Classification of approaches based on how the association
is maintained and where the remapping is done.
テーブル1: どのように協会を維持するか、そして、どこで再写像するかに基づくアプローチの分類。
Ramanathan Informational [Page 7] RFC 2103 Nimrod Mobility Support February 1997
[7ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
consider some combinations as illustrated in Table 1. We discuss three combinations (marked A1 - A3 in the table) and examine their advantages and disadvantages in the context of our requirements. The other combinations (marked X in the table) are possible, but do not represent a substantially different class of solutions from the ones discussed and hence are not considered here.
Table1で例証されるようにいくつかの組み合わせを考えてください。 私たちは、3つの組み合わせ(著しいA1--テーブルのA3)について議論して、私たちの要件の文脈におけるそれらの利点と損失を調べます。 他の組み合わせ(テーブルのXであるとマークされる)は、可能ですが、議論したものから実質的に異なったクラスの解決策を表さないで、またしたがって、ここで考えられません。
Note that this is but one classsification of mobility schemes and that the remapping and endpoint-locator maintenance strategies mentioned in the table are not exhaustive. The main intention is to help understand better the kinds of approaches that would be most suitable for Nimrod.
これが移動性計画の1classsificationであるにすぎなく、テーブルで言及された再写像と終点ロケータ維持戦略が徹底的でないことに注意してください。 主な意志はニムロデに最も適当なアプローチの種類をより理解しているのを助けることです。
In the following, we use the term source to refer to the endpoint that is attempting to communicate with or sending packets to a mobile endpoint. The source could be static or mobile. We use the term mobile destination to refer to the endpoint that is the intended destination of the source's packets.
以下では、私たちは、可動の終点に交信するのを試みるか、またはパケットを送る終点について言及するのにソースという用語を使用します。 ソースは、静的であるか、または可動であるかもしれません。 私たちは、ソースのパケットの意図している目的地である終点について言及するのに用語の可動の目的地を使用します。
A1. In this approach, all endpoint-locator mappings are maintained
at a centralized location. The source queries the database to
get the locator of the mobile destination. Alternatively, the
database can send updates to the source when the mobile
destination moves. The main advantage of this scheme is its
simplicity. Also, no modification to routers is required, and the
route from the source to a mobile destination is direct.
A1。 このアプローチでは、すべての終点ロケータマッピングが集結された位置で維持されます。 ソースは、可動の目的地のロケータを得るためにデータベースについて質問します。 可動の目的地が動くとき、あるいはまた、データベースはアップデートをソースに送ることができます。 この計画の主な利点はその簡単さです。 また、ルータへの変更は全く必要ではありません、そして、ソースから可動の目的地までのルートはダイレクトです。
The main disadvantage of this scheme is vulnerability - if the
centralized location goes down, all information is lost. While
this scheme may be sufficient for small networks with low
mobility, it does not scale adequately to be a long term solution
for Nimrod.
この計画の主な不都合は脆弱性です--集結された位置が落ちるなら、すべての情報が無くなっています。 この計画が小さいネットワークに低い移動性に十分であるかもしれない間、それは、ニムロデの長期解決策になるように適切に比例しません。
A2. This approach uses distributed association maintenance with
remapping done at the home. This is the approach that is being
used by the Mobile-IP working group of the IETF for the draft
proposal and by the Cellular Digital Packet Data (CDPD)
consortium. In this approach, every mobile endpoint is associated
with a "home" and a "home representative" keeps track of the
location of every mobile endpoint associated with it. A protocol
between a mobile endpoint and the home representative is used to
keep the information up-to-date. The source sends the packet
using the home locator of the mobile destination, and the home
representative forwards the packet to the mobile destination. The
advantage of this scheme is that it is fairly simple and does not
involve either the source or the routers in the network.
Furthermore, the mobile destination can keep its location secret
(known only to the home representative) - this is likely to be a
A2。 このアプローチは家にする再写像と共に分配された協会維持を使用します。 これは試案のためのIETFのモバイルIPワーキンググループとアナログ式の携帯電話通信網を利用してパケット交換方式のデジタル無線データ通信を提供するサービス(CDPD)共同体によって使用されているアプローチです。 このアプローチでは、あらゆる可動の終点が「家」に関連しています、そして、「家代表」はそれに関連しているあらゆる可動の終点の位置の動向をおさえます。 可動の終点と家代表の間のプロトコルは、情報を最新に保つのに使用されます。 ソースは可動の目的地の家のロケータを使用することでパケットを送ります、そして、家代表は可動の目的地にパケットを送ります。 この計画の利点は、それがかなり簡単であるということであり、ソースかルータのどちらかにネットワークにかかわりません。 その上、可動の目的地は位置を秘密にすることができます(家代表だけにおいて、知られています)--これはaである傾向があります。
Ramanathan Informational [Page 8] RFC 2103 Nimrod Mobility Support February 1997
[8ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
desirable feature for mobile hosts in some applications. Finally,
most of the control information is confined to the node containing
the home representative and the mobile host and this is a plus for
scalability. The main disadvantage is a problem often referred to
as triangular routing. That is, the packets have to go from the
source to the home representative first before going to the mobile
destination. This is especially inefficient if, for instance,
both the source and mobile destination are in, say, England and
the home representative is in, say, Australia. Also, there is
still some vulnerability, since if the home representative becomes
unreachable, the location of all of the mobile hosts it tracks is
lost and communication from most sources to the mobile host is
cut-off. It is also not clear how well this scheme will scale to
mobile internetworks of the future.
いくつかのアプリケーションにおけるモバイルホストにとって、望ましい特徴。 最終的に、制御情報の大部分は家代表とモバイルホストを含むノードに限定されます、そして、これはスケーラビリティのためのプラスです。 主な不都合はしばしば三角形のルーティングと呼ばれた問題です。 すなわち、パケットは最初に、可動の目的地に行く前に、ソースから家代表まで行かなければなりません。 例えば、中にソースと可動の目的地の両方があるならこれが特に効率が悪い、たとえば、イギリスと家代表はたとえば、オーストラリアにいます。 また、まだ、何らかの脆弱性があります、家代表が手が届かなくなるなら、それが追跡するモバイルホストのすべての位置が無くなって、ほとんどのソースからモバイルホストまでのコミュニケーションが締切りであるので。 また、この計画が未来の可動のインターネットワークに比例するのも、どれくらいよく明確でないか。
Nevertheless, we feel that this approach or a modification thereof
might be a viable first-cut mobility solution for Nimrod.
それにもかかわらず、私たちは、このアプローチかそれの変更がニムロデの実行可能な最初に、カット移動性対策であるかもしれないと感じます。
A3. In each of the previous cases, the routers in the network were
not involved in tracking the location of the mobile host. In
this approach, state is maintained in the routers. An example
is the approach proposed in [TYT91] wherein the packets sent by
a mobile host are snooped and state is created. The packets
contain the mobile host's home location and its new location.
This mapping is maintained at some routers in the network. When
a packet intended for the mobile host addressed to its home
location enters such a router, a translation is made and the
packet is redirected to the new location.
A3。 それぞれの先の事件では、ネットワークにおけるルータはモバイルホストの位置を追跡するのにかかわりませんでした。 このアプローチでは、状態はルータで維持されます。 例はモバイルホストによって送られたパケットが詮索されて、状態が創設される[TYT91]で提案されたアプローチです。 パケットはモバイルホストの家の位置とその新しい位置を含んでいます。 このマッピングはネットワークにおけるいくつかのルータで維持されます。 家の位置に宛てられたモバイルホストのために意図するパケットがそのようなルータに入るとき、翻訳をします、そして、新しい位置にパケットを向け直します。
An alternate mechanism is to maintain the mapping in all of the
border routers (e.g., forwarding agents) in the node within which
the movement took place. A packet from outside the node intended
for a destination within the node would typically enter the node
through one of the border routers. Using the mapping, the border
router could figure out the most recent locator of the mobile
destination and send the packet directly to that locator. If most
of the movements are within low level nodes, this would scale to
large numbers of movements. Furthermore, the packet takes an
optimal path (or as optimal as one can get with a hierarchical
network) to the new location within the time it takes for the node
representative to get the new information, which is typically
quite small for low-level nodes.
交互のメカニズムは動きが起こったノードの境界ルータ(例えば、小口運送業者)のすべてでマッピングを維持することです。 ノードの中の目的地に意図するノードの外からのパケットは境界ルータの1つを通してノードを通常入力するでしょう。 マッピングを使用して、境界ルータは、可動の目的地の最新のロケータを見積もって、直接そのロケータにパケットを送るかもしれません。 少ない平らなノードの中に動きの大部分があるなら、これは多くの動きに比例するでしょう。 その上、パケットはわざわざノード代表がそれが低レベルであるノードには、通常、かなり小さい新情報を得る中に最適経路(1つは階層的なネットワークと共に最適になることができますが)を新しい位置に取ります。
Ramanathan Informational [Page 9] RFC 2103 Nimrod Mobility Support February 1997
[9ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
The main disadvantage of this scheme is that routers have to be
involved. However, future requirements in regard to scalability and
response time might necessitate such an approach. Furthermore, this
solution has closer ties with Nimrod routing and is better suited to
handling scenarios 3 and 4 where the topology changes as a result of
mobility.
この計画の主な不都合はルータがかかわらなければならないということです。 しかしながら、スケーラビリティと応答時間に関する将来の要件はそのようなアプローチを必要とするかもしれません。 その上、この解決策は、ニムロデルーティングとの、より密な結びつきを持って、トポロジーが移動性の結果、変化する取り扱いシナリオ3と4に合うほうがよいです。
All of these approaches seem potentially capable of handling scenarios 1 and 2 of the previous section. Scenarios 3 and 4 are best handled by an approach similar to A3. However, approaches like A3 are more complex and involve more Nimrod entities (e.g., routers) than may be desirable.
これらのアプローチのすべてが前項の取り扱いシナリオ1と2が潜在的にできるように思えます。 A3と同様のアプローチでシナリオ3と4を扱うのは最も良いです。 しかしながら、A3のようなアプローチは、より複雑であり、望ましいかもしれないより多くのニムロデ実体(例えば、ルータ)にかかわります。
We have tried to bring out the various issues governing mobility in Nimrod. In the final analysis, the tradeoffs between the various options will have to be examined vis-a-vis our particular requirements (for instance, the need to support network mobility) in adopting a solution. It is likely that general requirements such as scalability and security will also influence the direction of the approach to mobility in Nimrod.
私たちはニムロデで移動性を決定する様々な問題を持ち出そうとしました。 最終分析で、様々なオプションの間の見返りは解決策を採用することにおける私たちの特定の要件(例えば、ネットワークの移動性を支持する必要性)と向かいあって調べられなければならないでしょう。 また、スケーラビリティやセキュリティなどの一般的な要件はニムロデで移動性へのアプローチの指示に影響を及ぼしそうでしょう。
5 A Solution using IETF Mobile-IP
5 IETFのモバイルIPを使用するソリューション
The Mobile-IP Working Group of the IETF is in the process of standardizing a protocol that allows an IPv4 capable network to support mobile hosts. In this section, we outline how mobility can be implemented within Nimrod using the same mechanism and indeed, the same protocol headers defined in [Sim94]. Not all functionality described in [Sim94] are covered - only those that form the "core" of mobility support.
IPv4のできるネットワークがモバイルホストを支持できるプロトコルを標準化することの途中にIETFのモバイルIP作業部会があります。 このセクションで、私たちはニムロデの中で同じメカニズムと本当に[Sim94]で定義された同じプロトコルヘッダーを使用することでどう移動性を実行できるかを概説します。 機能性が説明したというわけではないすべてが[Sim94]で覆われています--移動性サポートの「コア」を形成するものだけ。
In order to follow this section, the reader is required to have some familiarity with the IETF Mobile-IP protocol (see [Sim94]).
このセクションに従うために、読者はIETFモバイルIPプロトコルに何らかの親しみを持たなければなりません([Sim94]を見てください)。
5.1 Overview
5.1 概観
The general scheme employed by the IETF Mobile-IP protocol is as follows. A Mobile Host (MH) has a predefined Home Agent (HA) that is responsible for the MH's whereabouts. Typically, the MH spends most of its time in the network containing the HA. Let us assume that the MH wanders to a new network. The MH then contacts a Foreign Agent (FA) at the new network that will act on its behalf and sends a registration request to the HA via the FA. This serves the purpose of informing the HA of the MH's new whereabouts and also is a means of verification of the MH's authenticity. It also contains the address of the FA as the new Care-of-Address. A correspondent host (CH) wishing to send a message to the MH uses the MH's Home IP address. This message is captured by the HA and tunnelled using encapsulation
IETFモバイルIPプロトコルによって使われた一般的な計画は以下の通りです。 モバイルHost(MH)には、MHの居場所に責任がある事前に定義されたホームエージェント(HA)があります。 HAを含んでいて、通常、MHは時間の大部分をネットワークで、過ごします。 MHが新しいネットワークまでさまようと仮定しましょう。 MHは次に、利益に影響する新しいネットワークでForeignエージェント(FA)に連絡して、FAを通して登録要求をHAに送ります。 これは、MHの新しい居場所についてHAに知らせる目的に役立って、また、MHの信憑性の検証の手段です。 また、それはアドレスの新しいCareとしてFAのアドレスを含んでいます。 メッセージをMHに送りたがっている通信員ホスト(CH)はMHのホームIPアドレスを使用します。 カプセル化を使用することで、このメッセージは、HAによって捕らえられて、トンネルを堀られます。
Ramanathan Informational [Page 10] RFC 2103 Nimrod Mobility Support February 1997
[10ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
to the FA whereupon the FA decapsulates and sends the original message to the MH.
そして、するとFA、FA decapsulates、オリジナルのメッセージをMHに送ります。
If the MH can get itself a new transient address then there is no need for a Foreign Agent. The transient address will be sent as the Care-of-Address. The packets will be tunnelled directly to this address by the Home Agent. Note, however, that some networks may require that a mobile host go through a Foreign Agent.
MH自身が新しい一時アドレスを得ることができるなら、Foreignエージェントの必要は全くありません。 アドレスのCareとして一時アドレスを送るでしょう。 パケットは直接ホームのエージェントによるこのアドレスにトンネルを堀られるでしょう。 しかしながら、いくつかのネットワークが、モバイルホストがForeignエージェントを通るのを必要とするかもしれないことに注意してください。
A fundamental difference between IP and Nimrod is that in the latter an endpoint has both a (topologically sensitive) locator and a (topologically insensitive) endpoint-id (EID). In IP, the IP address serves as both the EID and the locator. Thus, it should be possible to use the Mobile-IP protocol for providing mobility support in Nimrod by simply using the EID of the MH wherever its Home IP Address was being used and by appropriately using the EID and locator of the FA and HA in place of their IP addresses (An issue is the format and length compatibility between EIDs and IP addresses. For the discussion here, we assume that an EID can fit into an IP (v4 or v6) address given in Figure 1). We give below the details of the protocol fields and the actions taken by the MH, FA and HA to show that this is possible and that it is quite simple.
IPとニムロデの基本的な違いが後者では、終点が両方を持っているということである、(位相的である、敏感である、)、ロケータとa、(位相的である、神経の鈍さ、)、終点イド(EID)。 IPでは、IPアドレスはEIDとロケータの両方として機能します。 したがって、ホームIP Addressがどこで使用されていたとしても単にMHのEIDを使用して、適切に彼らのIPアドレスに代わってFAとHAのEIDとロケータを使用することによって移動性サポートをニムロデに提供するのにモバイルIPプロトコルを使用するのは可能であるべきです。(問題は、EIDsとIPアドレスとの形式と長さの互換性です。 ここでの議論のために、私たちは、EIDが図1で与えられたIP(v4かv6)アドレスに収まることができると思います。). 私たちはプロトコルの詳細の下でこれが可能であり、それがかなり簡単であることを示すためにMH、FA、およびHAによって出られたグラウンドと行動を与えます。
5.2 Protocol Details
5.2 プロトコルの詳細
There are two kinds of protocol headers relevant to our discussion - the Mobile-IP Protocol (MIPP headers) and the headers for data packets transported by Nimrod (NP headers). It is our intent that Nimrod use, as much as possible, the next generation IP (IPv6) header. The NP header contains as a subset fields that would eventually be present in the IPv6 header.
私たちの議論に関連しているプロトコルヘッダーには2種類があります--モバイルIPプロトコル(MIPPヘッダー)とニムロデによって輸送されたデータ・パケットのためのヘッダー(NPヘッダー)。 ニムロデが次世代IP(IPv6)ヘッダーをできるだけ使用するのは、私たちの意図です。 NPヘッダーは部分集合として結局IPv6ヘッダーに存在している分野を含んでいます。
In the scheme given below, the MIPP header is enclosed within the NP packet (i.e., MIPP operates over NP). The details of the fields constituting the NP header are beyond the scope of this document. However, without venturing into bit lengths, etc., we identify below a few fields that are relevant to our discussion:
以下に与えられた計画では、MIPPヘッダーはNPパケットの中に同封されます(すなわち、MIPPはNPの上で作動します)。 NPヘッダーを構成する分野の詳細はこのドキュメントの範囲を超えています。 しかしながら、噛み付いている長さなどに冒険しないで、私たちは以下で私たちの議論に関連しているいくつかの分野を特定します:
o Source EID (S-EID) : The endpoint ID of the source entity
originating the packet.
o ソースEID(S-EID): パケットを溯源するソース実体の終点ID。
o Destination EID (D-EID) : The endpoint ID of the destination.
o 目的地EID(D-EID): 目的地の終点ID。
o Source locator (S-LOC) : Locator of the entity originating the
packet.
o ソースロケータ(S-LOC): パケットを溯源する実体のロケータ。
o Destination locator (D-LOC) : Locator of the destination.
o 目的地ロケータ(D-LOC): 目的地のロケータ。
Ramanathan Informational [Page 11] RFC 2103 Nimrod Mobility Support February 1997
[11ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
The MIPP header fields are described in [Sim94].
MIPPヘッダーフィールドは[Sim94]で説明されます。
In what follows, we describe the values that must be assigned to the relevant NP and MIPP fields in order for Nimrod to work with Mobile- IP. There are three phases we must consider : agent discovery, registration and forwarding [Sim94]. A pictorial summary of the control and data packets is given in Figure 1.
続くことでは、私たちはニムロデがモバイルIPと共に扱うように関連NPとMIPP分野に割り当てなければならない値について説明します。 私たちが考えなければならない三相があります: エージェント発見、登録、および推進[Sim94]。 図1でコントロールとデータ・パケットの絵の概要をします。
Agent Discovery: In this phase, the MH discovers the foreign agent, if any, that will act on its behalf. In MIPP, this is done using the ICMP Router Discovery messages.
エージェント発見: このフェーズでは、MHはもしあれば利益に影響する外国人のエージェントを発見します。 MIPPでは、これはICMP Routerディスカバリーメッセージを使用し終わっています。
When an MH attaches to a Nimrod network (node), foreign agent discovery is done as follows. We assume that a link-level connection is established between the MH and a node N belonging to the network. For instance, this node could be a wireless equipped base station that establishes a signalling channel for communication with the MH.
MHがニムロデネットワーク(ノード)に付くとき、以下の通り外国エージェント発見をします。 私たちは、リンク・レベル接続がネットワークへのMHとノードN属の間で確立されると思います。 例えば、このノードはMHとのコミュニケーションのために合図チャンネルを確立する無線の備えられている基地局であるかもしれません。
If the MH is itself a node then N and the MH execute an arc formation procedure between themselves as described in [RS96]. This results in a locator being assigned to the MH and to the arcs between N and MH.
MHがそれ自体でノードであるなら、NとMHは[RS96]で説明されるように自分たちの間のアーク構成手順を実行します。 これはNとMHの間でMHと、そして、アークに割り当てられるロケータをもたらします。
If the MH is not a node but only an endpoint, then MH initiates locator acquisition procedure as described in [RS96]. This results in a locator being assigned to the MH.
MHがノードではなく、終点にすぎないなら、MHは[RS96]で説明されるようにロケータ獲得手順に着手します。 これはMHに割り当てられるロケータをもたらします。
The MH then sends a Foreign Agent Request message to N. This message contains, amongst other information, the EID and locator of the MH. If N is not itself the foreign agent, then we assume that it knows of and has the ability to reach a foreign agent.
次に、MHはForeignエージェントRequestメッセージをメッセージが含むN.Thisに送ります、MHの他の情報、EID、およびロケータの中で。 Nがそれ自体で外国人のエージェントでないなら、私たちは、それが外国人のエージェントに届く能力を知っていて、持っていると思います。
The foreign agent (FA) notes the EID of the MH in its Visitor List and sends a Foreign Agent Reply to the MH. This contains the EID and the locator of the FA and will be used as the "Care-of-Address" (COA) of the MH for a prespecified period.
外国人のエージェント(FA)は、Visitor ListでMHのEIDに注意して、ForeignエージェントReplyをMHに送ります。 これは、FAのEIDとロケータを含んでいて、MH「アドレスの注意」(COA)として前指定された期間、使用されるでしょう。
Registration: In the registration phase, infomation is exchanged between the MH and the Home Agent (HA). The HA could, for instance, be the endpoint representative of the endpoint in its home location. The registration procedure is used to create a mobility binding which the HA uses to forward data packets intended for the MH. Another purpose of registration is to verify the authenticity of the MH.
登録: 登録フェーズでは、MHとホームのエージェント(HA)の間でinfomationを交換します。 例えば、HAは家の位置の終点を代表している終点であるかもしれません。 登録手順は、HAがMHのために意図するデータ・パケットを進めるのに使用する移動性結合を作成するのに用いられます。 登録の別の目的はMHの信憑性について確かめることです。
There are four parts to the registration. We describe the values assigned to the relevant fields. Recall that there are two headers we must create - the Nimrod Protocol (NP) header and the Mobile-IP Protocol (MIPP) header. The NP fields are as described above and the MIPP fields are as in [Sim94]. The fields mh-eid(mh-loc), fa-
登録への4つの部品があります。 私たちは関連分野に割り当てられた値について説明します。 私たちが創造しなければならない2個のヘッダーがあったと思い出してください--ニムロデプロトコル(NP)ヘッダーとモバイルIPプロトコル(MIPP)ヘッダー。 説明されるとして分野があって、MIPP分野が[Sim94]にあるNP。 分野mh-eid(mh-loc)、ファ
Ramanathan Informational [Page 12] RFC 2103 Nimrod Mobility Support February 1997
[12ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
eid(fa-loc), ha-eid(ha-loc) are used to refer to the EID (locator) of the mobile host, foreign agent and home agent respectively.
eid(ファ-loc)、ハ、-eid、(ハ、-loc、)、それぞれモバイルホスト、外国人のエージェント、および家のエージェントのEID(ロケータ)について言及するために、使用されます。
1. The MH sends a Registration Request to the prospective Foreign
Agent to begin the registration process.
1. MHは、登録手続を始めるために将来のForeignエージェントにRegistration Requestを送ります。
o NP fields : S-EID = mh-eid; D-EID = fa-eid; S-LOC = mh-loc ; D-LOC
= fa-loc.
o NP分野: S-EIDはmh-eidと等しいです。 D-EIDはファ-eidと等しいです。 S-LOCはmh-locと等しいです。 D-LOCはファ-locと等しいです。
o MIPP fields : Home Agent = ha-eid; Home Address = mh-eid;
Care-of-Address = fa-eid.
o MIPP分野: ホームのエージェント=、ハ、-eid、。 ホームAddressはmh-eidと等しいです。 アドレスの注意はファ-eidと等しいです。
Note that the mh-loc is known to the MH by virtue of the locator acquisition (see paragraph on "Agent Discovery") and that the fa-eid is known to the MH from the Foreign Agent Reply. The FA caches the mh-eid for future reference.
mh-locがロケータ獲得によってMHにおいて知られていて(「エージェント発見」にパラグラフを見てください)、ファ-eidがForeignエージェントReplyからMHにおいて知られていることに注意してください。 FAは後日のためにmh-eidをキャッシュします。
2. The Foreign Agent relays the request by sending a Registration
Request to the Home Agent, to ask the Home Agent to provide the
requested service.
2. Foreignエージェントは、要求されたサービスを提供するようにホームのエージェントに頼むためにホームのエージェントにRegistration Requestを送ることによって、要求をリレーします。
o NP fields : S-EID = fa-eid; D-EID = ha-eid; S-LOC = fa-loc; D-LOC
= ha-loc.
o NP分野: S-EIDはファ-eidと等しいです。 D-EIDが等しい、ハ、-eid、。 S-LOCはファ-locと等しいです。 D-LOCが等しい、ハ、-loc。
o MIPP fields : Same as in (copied from) (1) above.
o MIPP分野: 上の(模造します)(1)と同じです。
The HA caches the (Home Address, Care-of-Address) as a mobility binding. Optionally, for efficiency, it may also cache fa-loc.
HAがキャッシュする、(ホームAddress、アドレスのCare) 移動性結合として。 また、任意に、効率のために、それはファ-locをキャッシュするかもしれません。
3. The Home Agent sends a Registration Reply to the Foreign Agent to
grant or deny service.
3. ホームのエージェントは、サービスを承諾するか、または否定するためにForeignエージェントにRegistration Replyを送ります。
o NP fields : S-EID = ha-eid; D-EID = fa-eid; S-LOC = ha-loc; D-LOC
= fa-loc.
o NP分野: S-EIDが等しい、ハ、-eid、。 D-EIDはファ-eidと等しいです。 S-LOCが等しい、ハ、-loc、。 D-LOCはファ-locと等しいです。
o MIPP fields : Home Address = mh-eid; code = as in [Sim94].
o MIPP分野: ホームAddressはmh-eidと等しいです。 [Sim94]のように=をコード化してください。
The S-EID and D-EID fields are taken from the Request and swapped, as are the S-LOC and D-LOC fields. The Home Address in the MIPP is the same as the Home Address in the Request. The code indicates whether or not permission was granted by the Home Agent.
S-EIDとD-EIDグラウンドは、Requestから出られて、S-LOCとD-LOC分野のように交換されます。 MIPPのホームAddressはRequestでホームAddressと同じです。 コードは、許可がホームのエージェントによって与えられたかどうかを示します。
4. The Foreign Agent sends a copy of the Registration Reply to the MH
to inform it of the disposition of its request.
4. Foreignエージェントは、要求の気質についてそれを知らせるためにRegistration ReplyのコピーをMHに送ります。
o NP fields : S-EID = fa-eid; D-EID = mh-eid; S-LOC = fa-loc; D-LOC
= mh-loc.
o NP分野: S-EIDはファ-eidと等しいです。 D-EIDはmh-eidと等しいです。 S-LOCはファ-locと等しいです。 D-LOCはmh-locと等しいです。
Ramanathan Informational [Page 13] RFC 2103 Nimrod Mobility Support February 1997
[13ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
o MIPP fields : Same as (copied from) (3) above.
o MIPP分野: 上の(模造します)(3)と同じです。
At this point the MH is registered with the HA (provided the registration request is approved by the HA) and packets can be forwarded to the MH.
ここに、HAにMHを登録します、そして、(登録要求がHAによって承認されるなら)パケットをMHに送ることができます。
+--------+
| CH |
+--------+
V
V
#--------------#
|mh-eid | data | = P(orig)
#--------------#
V
+--------+ *----------------* +--------+ *--------------* +------+
| | |fa-eid | mh-eid | | | | ha-eid|mh-eid| | |
| | *----------------* | | *--------------* | |
| HA |------<-REG REQ-<------| FA |----<-REG REQ-<---| MH |
| | 2 | | 1 | |
| mh-eid | 3 | mh-eid | 4 | |
| | |------>-REG REPL->-----| | |---->-REG REPL->--| |
| v | *----------------* | v | *--------------* | |
| fa-eid | |mh-eid | yes/no | | mh-loc | |mh-eid|yes/no | | |
| | *----------------* | | *--------------* | |
| | #------------------# | | #---------# | |
| |>>| #--------# |>| |>| P (orig)|>>>>> | |
+--------+5 |fa-eid | P(orig)| | +--------+ #---------# 6 +------+
| #--------# |
#------------------#
+--------+ | CH| +--------+ V V#--------------# |mh-eid| データ| = P(orig)#--------------# +に対して--------+ *----------------* +--------+ *--------------* +------+ | | |ファ-eid| mh-eid| | | | ハ、-eid。|mh-eid| | | | | *----------------* | | *--------------* | | | ハ|、-、-、-、-、--、<。レッジREQ-<。------| ファ|、-、-、--、<。レッジREQ-<。---| MH| | | 2 | | 1 | | | mh-eid| 3 | mh-eid| 4 | | | | |、-、-、-、-、--、>。レッジREPL->。-----| | |、-、-、--、>。レッジREPL->--| | | v| *----------------* | v| *--------------* | | | ファ-eid| |mh-eid| はい/いいえ| | mh-loc| |mh-eid|はい/いいえ| | | | | *----------------* | | *--------------* | | | | #------------------# | | #---------# | | | | >>| #--------# | >| | >| P(orig)| >>>>>|、| +--------+5 |ファ-eid| P(orig)| | +--------+ #---------# 6 +------+ | #--------# | #------------------#
Figure 1 : The control and data packets for mobility handling using
the Mobile-IP protocol. The packets bordered as # denote
data packets and those bordered * denote control packets.
Only the crucial information conveyed in each message is
shown (i.e., locators and EIDs in packet headers are not
shown. The associations maintained at HA and FA are shown.
図1: モバイルIPを使用する移動性取り扱いのためのコントロールとデータ・パケットは議定書を作ります。 #データ・パケットを指示してください。そうすれば、ものが*に接していたので接されていたパケットはコントロールパケットを指示します。 情報が各メッセージを運んだ重要は示されるだけです。すなわち、ロケータとパケットのヘッダーのEIDsは見せられません。(HAとFAで維持された協会は見せられます。
Forwarding Data: We describe the manner in which a packet from the correspondent host (CH) intended for the MH is encapsulated and forwarded by the HA.
推進データ: 私たちはMHのために意図する通信員ホスト(CH)からのパケットがHAによってカプセルに入れられて、進められる方法を説明します。
o At HA : Suppose that a packet P intended for MH arrives at HA. For instance, P first comes to the router for the local network and the router finds that MH is unreachable. The router then forwards P to the HA for possible redirection.
o ハ: MHのために意図するパケットPがHAに到着すると仮定してください。 例えば、Pは最初に企業内情報通信網にルータに来ます、そして、ルータによって、MHが手が届かないのがわかります。 そして、ルータは可能なリダイレクションのためにPをHAに送ります。
Ramanathan Informational [Page 14] RFC 2103 Nimrod Mobility Support February 1997
[14ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
The HA extracts the destination EID from the NP header for P. If no match is found in its mobility binding, then the MH is deemed as unreachable. If a match is found, the corresponding fa-eid is extracted. A new header is prepended to P. For this header, S-EID = ha-eid, D-EID = fa-eid, S-LOC = ha-loc and D-LOC = fa-loc. The fa- loc may be obtained from the Association Database [CCS96]. Alternatively, if it was cached in (2) above, it could be obtained from the cache.
HAはマッチが全く移動性結合で見つけられないP.IfのためにNPヘッダーから目的地EIDを抽出して、次に、MHは手の届かないとして考えられます。 マッチが見つけられるなら、対応するファ-eidは抽出されます。 新しいヘッダーがそう、P.Forへのこのヘッダー、S-EID=をprependedした、ハ、-eid、D-EIDはファ-eidと等しいです、S-LOC=、ハ、-loc、そして、D-LOC=ファ-loc。 Association Database[CCS96]からファlocを入手するかもしれません。 あるいはまた、上で(2)でそれをキャッシュするなら、キャッシュからそれを得ることができるでしょうに。
o At FA: By looking at the next header field in the Nimrod Protocol packet header, the FA knows that the packet is an encapsulated one. It removes the wrapping and looks at the EID in P. If that EID is found in the Visitor List then the FA knows the locator of the MH and can deliver the packet to the MH. Otherwise, the packet is discarded and an error message is returned to HA.
o ファで: ニムロデプロトコルパケットのヘッダーで次のヘッダーフィールドを見ることによって、FAは、パケットが要約のものであることを知っています。 EIDがVisitor Listで見つけられるのが、P.Ifで包装紙を取って外して、EIDを見て、次に、FAはMHのロケータを知って、パケットをMHに渡すことができます。 さもなければ、パケットは捨てます、そして、エラーメッセージをHAに返します。
Other Issues: We have not addressed a number of issues such as deregistration, authentication, etc. The mobility specific portion of authentication can be adapted from the specification in [Sim94]; deregistration can be done in a manner similar to registration.
他の問題: 私たちは反登録、認証などの多くの問題を記述していません。 [Sim94]の仕様から認証の移動性特定部位を適合させることができます。 登録と同様の方法で反登録できます。
The protocol in [Sim94] describes a registration scheme without the involvement of the Foreign Agent. This is done when the MH obtains a transient IP address using some link-level protocol (e.g. PPP). A similar scheme can be given in the context of Nimrod. In this case, the MH obtains its locator (typically inherited from the node to which it attaches) and sends this locator as its Care-of-Address in the Registration Request. The HA, while forwarding, uses this as the locator in the outer NP header and thus the encapsulated packet is delivered directly to the MH which then decapsulates it. No Foreign Agent Discovery is needed. Apart from this, the fields used are as described for the scheme with the FA.
[Sim94]のプロトコルはForeignエージェントのかかわり合いなしで登録計画について説明します。 MHが何らかのリンク・レベルプロトコル(例えば、PPP)を使用することで一時的なIPアドレスを得るとき、これをします。 ニムロデの文脈で同様の計画を与えることができます。 この場合、MHはロケータ(それが付くノードから通常世襲する)を得て、アドレスのCareとしてRegistration Requestでこのロケータを送ります。 外側のNPヘッダーとその結果、要約のパケットのロケータを直接それがその時decapsulatesされるMHに渡すとき、HAは進めている間、これを使用します。 Foreignエージェントディスカバリーは全く必要ではありません。 これは別として、使用される分野が計画のためにFAと共に説明されるようにあります。
We note however that many networks may require that the registration be through a Foreign Agent, for purposes of security, billing etc.
しかしながら、私たちは、多くのネットワークが、Foreignエージェントを通して登録があるのを必要とするかもしれないことに注意します、支払いセキュリティなどの目的のために
6 Security Considerations
6 セキュリティ問題
The registration protocol between a mobile host and the network (for instance, in the mobile-ip protocol, the MH and the HA) contains security mechanisms to validate access, prevent impersonation etc.
モバイルホストとネットワーク(例えば可動のipプロトコル、MH、およびHAで)の間の登録プロトコルはアクセスを有効にするセキュリティー対策を含んで、ものまねなどを防いでください。
This document is not a protocol specification and therefore does not contain a description of security mechanisms for Nimrod.
このドキュメントは、プロトコル仕様でなく、またしたがって、ニムロデのためのセキュリティー対策の記述を含んでいません。
Ramanathan Informational [Page 15] RFC 2103 Nimrod Mobility Support February 1997
[15ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
7 Summary
7概要
o Nimrod permits physical devices to be mobile, but does not specify a particular solution for routing in the face of mobility.
o ニムロデは、フィジカル・デバイスモバイルであることを許可しますが、移動性に直面してルーティングの特殊解を指定しません。
o The fact that the endpoint naming (EID) space and the locator space are separated in Nimrod helps in accommodating mobility in a graceful and natural manner. Mobility may be percieved, essentially, as dynamism in the endpoint - locator association.
o (EID)をスペースと命名する終点とロケータスペースがニムロデで切り離されるという事実は、優雅で生まれながらの方法で移動性を収容するのを手伝います。 移動性は本質的には力動説として終点でpercievedされるかもしれません--ロケータ協会。
o Nimrod allows two kinds of mobility:
o ニムロデは2種類の移動性を許します:
- Endpoint mobility. For example, when a host in a network moves.
This might cause a change in the locator associated with the host,
but does not cause a change in the topology map for Nimrod.
- 終点の移動性。 ネットワークのホストが例えば移ると。 これは、ホストに関連しているロケータで変化を引き起こすかもしれませんが、ニムロデのためにトポロジー地図で変化は引き起こしません。
- Network mobility. For example, when a router or an entire network
moves. This might cause a change in the topology in addition to
the locator.
- 移動性をネットワークでつないでください。 ルータか全体のネットワークが例えば動くと。 これはロケータに加えてトポロジーの変化を引き起こすかもしれません。
o Endpoint mobility may be handled by maintaining a dynamic association between endpoints and locators. However, network mobility requires addressing the topology change problem as well.
o 終点の移動性は、終点とロケータとのダイナミックな協会を維持することによって、扱われるかもしれません。 しかしながら、ネットワークの移動性は、また、そのトポロジー変化問題を訴えるのを必要とします。
o Apart from the ability to handle network mobility, it is desirable that the mobility solution be scalable to large networks and large numbers of mobile devices and provide security mechanisms.
o ネットワークの移動性を扱う能力は別として、移動性解決策が多くのモバイル機器にスケーラブルであり、セキュリティー対策を供給するのは、望ましいです。
o There are a number of existing and emerging solutions to mobility. In particular, adaptation of solutions developed by the IETF is a first cut possibility for Nimrod. As the description given in section 5 shows, it is relatively easy to implement the scheme being designed by the Mobile-IP working group in the context of Nimrod.
o 多くの存在と移動性の解決策として現れるのがあります。 IETFによって見いだされた解決策の適合は特に、ニムロデのための最初のカットの可能性です。 セクション5で与えられた記述が目立っているように、ニムロデの文脈のモバイルIPワーキンググループによって設計されている計画を実行するのは比較的簡単です。
8 Acknowledgements
8つの承認
We thank Isidro Castineyra (BBN), Charles Lynn (BBN), Martha Steenstrup (BBN) and other members of the Nimrod Working Group for their comments and suggestions on this memo.
私たちはこのメモの上で彼らのコメントと提案についてイシドロCastineyra(BBN)、チャールズリン(BBN)、マーサ・ステーンストルプ(BBN)、およびニムロデ作業部会の他のメンバーに感謝します。
Ramanathan Informational [Page 16] RFC 2103 Nimrod Mobility Support February 1997
[16ページ]RFC2103ニムロデ移動性サポート1997年2月の情報のRamanathan
9 Author's Address
9作者のアドレス
Ram Ramanathan BBN Systems and Technologies 10 Moulton Street Cambridge, MA 02138
牡羊座Ramanathan BBN系と技術10モールトン・通りケンブリッジ、MA 02138
Phone : (617) 873-2736 Email : ramanath@bbn.com
以下に電話をしてください。 (617) 873-2736 メールしてください: ramanath@bbn.com
References
参照
[CCS96] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod
Routing Architecture", RFC 1992, August 1996.
1996年8月の[CCS96]CastineyraとI.とChiappa、N.とM.ステーンストルプ、「ニムロデルート設定構造」RFC1992。
[RS96] Ramanathan, S., and M. Steenstrup. Nimrod functional and
protocol specifications, Work in Progress.
[RS96] Ramanathan、S.、およびM.ステーンストルプ。 ニムロデ機能的、そして、プロトコル仕様、ProgressのWork。
[Sim94] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[Sim94] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[TYT91] F. Teraoka, Y. Yokote, and M. Tokoro. A network architecture
providing host migration transparency. In Proceedings of ACM
SIGCOMM, 1991.
[TYT91] F.Teraoka、Y.横手、およびM.常呂。 ネットワークアーキテクチャの提供しているホスト移動透過性。 ACM SIGCOMM、1991年の議事で。
[WJ92] K. A. Wimmer and J. B. Jones. Global development of pcs. IEEE
Communications Magazine, pages 22--27, Jun 1992.
[WJ92]K.A.ウィンマーとJ.B.ジョーンズ。 pcsのグローバルな開発。 IEEE Communications Magazine、22--27ページ、1992年6月。
Ramanathan Informational [Page 17]
Ramanathan情報です。[17ページ]
一覧
スポンサーリンク
