RFC1688 日本語訳
1688 IPng Mobility Considerations. W. Simpson. August 1994. (Format: TXT=19151 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Simpson Request for Comments: 1688 Daydreamer Category: Informational August 1994
コメントを求めるワーキンググループW.シンプソン要求をネットワークでつないでください: 1688年の空想家カテゴリ: 情報の1994年8月
IPng Mobility Considerations
IPng移動性問題
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
要約
This document was submitted to the IPng Area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng Area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP.
RFC1550に対応してこのドキュメントをIPng Areaに提出しました。 このドキュメントの公表は中で言い表された状態でどんな考えのIPng Areaによる承認も含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。 このRFCはIPのNext Generationのデザインと選択における考慮に移動性に関連する評価基準を指定します。
Table of Contents
目次
1. Introduction .......................................... 2
2. Addressing ............................................ 2
2.1 Ownership ....................................... 2
2.2 Topology ........................................ 3
2.3 Manufacturer .................................... 3
2.4 Numbering ....................................... 3
2.5 Configuration ................................... 3
3. Communication ......................................... 3
3.1 Topological Changes ............................. 4
3.2 Routing Updates ................................. 4
3.3 Path Optimization ............................... 5
3.4 At Home ......................................... 5
3.5 Away From Home .................................. 5
4. Security .............................................. 5
4.1 Authentication .................................. 5
4.2 Anonymity ....................................... 6
4.3 Location Privacy ................................ 6
4.4 Content Privacy ................................. 6
5. Bandwidth ............................................. 6
5.1 Administrative Messages ......................... 7
5.2 Response Time ................................... 7
5.3 Header Prediction ............................... 8
6. Processing ............................................ 8
6.1 Fixed Location .................................. 8
1. 序論… 2 2. 記述します。 2 2.1所有権… 2 2.2トポロジー… 3 2.3メーカー… 3 2.4 付番します。 3 2.5構成… 3 3. コミュニケーション… 3 3.1 位相的な変化… 4 3.2 ルート設定アップデート… 4 3.3 経路最適化… 5 3.4 ホームで… 5 3.5 ホームから遠くへ… 5 4. セキュリティ… 5 4.1認証… 5 4.2匿名… 6 4.3 位置のプライバシー… 6 4.4 満足しているプライバシー… 6 5. 帯域幅… 6 5.1の管理メッセージ… 7 5.2応答時間… 7 5.3 ヘッダー予測… 8 6. 処理… 8 6.1 位置を修理します… 8
Simpson [Page 1] RFC 1688 IPng Mobility August 1994
シンプソン[1ページ]RFC1688IPng移動性1994年8月
6.2 Simple Fields ................................... 9
6.3 Simple Tests .................................... 9
6.4 Type, Length, Value ............................. 9
Acknowledgements ............................................. 9
Security Considerations ...................................... 9
Author's Address ............................................. 9
6.2 純真なフィールズ… 9 6.3 簡単なテスト… 9 6.4 タイプ、長さ、値… 9つの承認… 9 セキュリティ問題… 9作者のアドレス… 9
1. Introduction
1. 序論
Current versions of the Internet Protocol make an implicit assumption that a node's point of attachment remains fixed. Datagrams are sent to a node based on the location information contained in the node's IP address.
インターネットプロトコルの最新版はノードの接着点が修理されたままで残っているという暗黙の仮定をします。 ノードのIPアドレスに含まれた位置情報に基づくノードにデータグラムを送ります。
If a node moves while keeping its IP address unchanged, its IP network number will not reflect its new point of attachment. The routing protocols will not be able to route datagrams to it correctly.
ノードがIPアドレスを変わりがなく保管している間、動くと、IPネットワーク・ナンバーは新しい接着点を反映しないでしょう。 ルーティング・プロトコルは正しくデータグラムをそれに発送できないでしょう。
A number of considerations arise for routing these datagrams to a Mobile Node.
多くの問題が、これらのデータグラムをモバイルNodeに発送するために起こります。
2. Addressing
2. アドレシング
Each Mobile Node must have at least one Home-Address which identifies it to other nodes. This Home-Address must be globally unique.
それぞれのモバイルNodeには、他のノードにそれを特定する少なくとも1つのホームアドレスがなければなりません。 このホームアドレスはグローバルにユニークでなければなりません。
2.1. Ownership
2.1. 所有権
The presence of ownership information in the Home-Address would be beneficial. A Mobile Node will be assigned a Home-Address by the organization that owns the machine, and will be able to use that Home-Address regardless of the current point of attachment.
ホームアドレスでの所有権情報の存在は有益でしょう。 モバイルNodeはホームアドレスがマシンを所有している組織によって割り当てられて、現在の接着点にかかわらずそのホームアドレスを使用できるでしょう。
The ownership information must be organized in such a fashion to facilitate "inverse" lookup in the Domain Name Service, and other future services.
Domain Name Serviceで「逆」のルックアップを容易にするそのようなファッション、および他の今後のサービスで所有権情報を組織化しなければなりません。
Ownership information could be used by other nodes to ascertain the current topological location of the Mobile Node.
所有権情報は他のノードによって使用されて、モバイルNodeの現在の位相的な位置を確かめることができました。
Ownership information could also be used for generation of accounting records.
また、会計帳簿の世代に所有権情報を使用できました。
Simpson [Page 2] RFC 1688 IPng Mobility August 1994
シンプソン[2ページ]RFC1688IPng移動性1994年8月
2.2. Topology
2.2. トポロジー
There is no requirement that the Home-Address contain topological information. Indeed, by the very nature of mobility, any such topological information is irrelevant.
ホームアドレスが位相的な情報を含んでいるという要件が全くありません。 本当に、移動性のまさしくその本質で、そのようなどんな位相的な情報も無関係です。
Topological information in the Home-Address must not hinder mobility, whether by prevention of relocation, or by wasting bandwidth or processing efficiency.
再配置の防止か、帯域幅か処理効率を浪費することにかかわらずホームアドレスの位相的な情報は移動性を妨げてはいけません。
2.3. Manufacturer
2.3. メーカー
There is no requirement that the Home-Address contain manufacturer information.
ホームアドレスがメーカー情報を含んでいるという要件が全くありません。
Manufacturer information in the Home-Address must not hinder mobility, whether by prevention of relocation, or by wasting bandwidth or processing efficiency.
再配置の防止か、帯域幅か処理効率を浪費することにかかわらずホームアドレスのメーカー情報は移動性を妨げてはいけません。
2.4. Numbering
2.4. 付番
The number of mobile nodes is expected to be constrained by the population of users within the lifetime of the IPng protocol. The maximum world-wide sustainable population is estimated as 16e9, although during the lifetime of IPng the population is not expected to exceed 8e9.
IPngプロトコルの生涯中にユーザの人口によって可動のノードの数が抑制されると予想されます。 最大の世界的な持続可能な人口は16e9として見積もられています、IPngの生涯人口が8e9を超えていないと予想されますが。
Each user is assumed to be mobile, and to have a maximum combined personal mobile and home network(s) on the order of 4e3 nodes.
各ユーザが可動であると思われて、最大を持っているのは4e3ノードの注文のときに可動、そして、ホームネットワークの個人的な(s)を結合しました。
The expectation is that only 46 bits will be needed to densely number all mobile and home nodes.
期待は46ビットだけが密にすべてのモバイルと家のノードに付番するのに必要であるということです。
The size of addressing elements is also constrained by bandwidth efficiency and processing efficiency, as described later.
また、アドレシング要素のサイズは後で説明されるように帯域幅効率と処理効率によって抑制されます。
2.5. Configuration
2.5. 構成
Since the typical user would be unlikely to be aware of or willing and able to maintain 4e3 nodes, the assignment of Home-Addresses must be automatically configurable. Registration of the nodes must be dynamic and transparent to the user, both at home and away from home.
典型的なユーザはありそうもないでしょう、したがって、ホームアドレスで意識するか望んでいて4e3ノード、課題を維持できるのが、自動的に構成可能でなければなりません。 ユーザにとって、ノードの登録は、家からともにホーム・アンド・アウェーでダイナミックであって、わかりやすいに違いありません。
3. Communication
3. コミュニケーション
A Mobile Node must continue to be capable of communicating directly with other nodes which do not implement mobility functions.
モバイルNodeは移動性機能を実行しない他のノードと共にずっと直接伝達できなければなりません。
Simpson [Page 3] RFC 1688 IPng Mobility August 1994
シンプソン[3ページ]RFC1688IPng移動性1994年8月
No protocol enhancements are required in hosts or routers that are not serving any of the mobility functions. Similarly, no additional protocols are needed by a router (that is not acting as a Home Agent or a Foreign Agent) to route datagrams to or from a Mobile Node.
プロトコル増進は全く移動性機能のいずれも果たしていないホストかルータで必要ではありません。 同様に、追加議定書は、全くNode、または、モバイルNodeからデータグラムを発送するためにルータ(すなわち、ホームのエージェントかForeignエージェントとして、務めない)によって必要とされません。
A Mobile Node using its Home-Address must be able to communicate with other nodes after having been disconnected from the Internet, and then reconnected at a different point of attachment.
ホームアドレスを使用するモバイルNodeは次に、インターネットから外されて、異なった接着点で再接続された後に、他のノードとコミュニケートできなければなりません。
A Mobile Node using its Home-Address must be able to communicate with other nodes while roaming between different points of attachment, without loss of transport connections.
ホームアドレスを使用するモバイルNodeは付属の異なったポイントの間を移動している間、他のノードとコミュニケートできなければなりません、輸送の接続の損失なしで。
3.1. Topological Changes
3.1. 位相的な変化
In order that transport connections be maintained while roaming, topological changes must not affect transport connections.
輸送の接続が移動している間、維持されて、位相的な変化は輸送の接続に影響してはいけません。
For correspondent nodes which do not implement mobility functions, topological changes should not be communicated to the correspondent.
移動性機能を実行しない通信員ノードに関しては、位相的な変化を通信員に伝えるべきではありません。
For correspondent nodes which implement mobility functions, the correspondent should be capable of determining topological changes.
移動性機能を実行する通信員ノードに関しては、通信員は位相的な変化を決定できるべきです。
Topological change information must be capable of insertion and removal by routers in the datagram path, as well as by the correspondent and Mobile Node.
位相的な変化情報はデータグラム経路のルータ、通信員、およびモバイルNodeによる挿入と取り外しができなければなりません。
3.2. Routing Updates
3.2. ルート設定アップデート
Mobile Nodes are expected to be able to change their point of attachment no more frequently than once per second.
モバイルNodesが1秒あたりの一度よりどんな頻繁にも彼らの接着点を変えることができないと予想されます。
Changes in topology which occur more frequently must be handled at the link layer transparently to the internetwork layer. It is further noted that engineering margins may require the link layer to handle all changes at a frequency in the neighborhood of 10 seconds.
リンクレイヤで、より頻繁に透明にトポロジーの起こる変化をインターネットワーク層に扱わなければなりません。 工学マージンが10秒の近所で頻度ですべての変化を扱うためにリンクレイヤを必要とするかもしれないことにさらに注意されます。
Changes in topology which occur less frequently must be immediately reflected in the mobility updates. This may preclude the use of the Domain Name Service as the repository of mobility topological information.
すぐに、どんなより頻繁にもトポロジーの起こる変化を移動性アップデートに反映してはいけません。 これは移動性の位相的な情報の倉庫としてDomain Name Serviceの使用を排除するかもしれません。
It must be noted that global routing updates do not operate at this frequency. As old topological information may be obsoleted faster than global routing updates, access to the repository of mobility topological information must be independent of prior topological information.
グローバルなルーティングアップデートがこの頻度で作動しないことに注意しなければなりません。 古い位相的な情報がグローバルなルーティングアップデートより速く時代遅れにされるかもしれないので、移動性の位相的な情報の倉庫へのアクセスは先の位相的な情報から独立しているに違いありません。
Simpson [Page 4] RFC 1688 IPng Mobility August 1994
シンプソン[4ページ]RFC1688IPng移動性1994年8月
The mobility specific repository should use ownership information in the Home-Address for access to the repository.
移動性の特定の倉庫は倉庫へのアクセスにホームアドレスで所有権情報を使用するはずです。
3.3. Path Optimization
3.3. 経路最適化
Optimization of the path from a correspondent to a mobile node is not required. However, such optimization is desirable.
経路の通信員から可動のノードまでの最適化は必要ではありません。 しかしながら、そのような最適化は望ましいです。
For correspondent nodes which implement mobility functions, the correspondent should be capable of determining the optimal path.
移動性機能を実行する通信員ノードに関しては、通信員は最適経路を決定できるべきです。
The optimization mechanism is also constrained by security, bandwidth efficiency and processing efficiency, as described later.
また、最適化メカニズムは後で説明されるようにセキュリティ、帯域幅効率、および処理効率によって抑制されます。
3.4. At Home
3.4. ホームで
Mobile Nodes do not require special "virtual" home network addresses. The assumption that extra addresses or multiple routers are available is unwarranted in small networks.
モバイルNodesは特別な「仮想」のホームネットワークアドレスを必要としません。 余分なアドレスか複数のルータが利用可能であるという仮定は小さいネットワークにおいて保証がありません。
Mobile Nodes must operate without special assistance from routers in order to communicate directly with other nodes on the home subnetwork link.
モバイルNodesは、家のサブネットワークリンクの上に他のノードがある状態で直接伝達するためにルータから特別な支援なしで作動しなければなりません。
3.5. Away From Home
3.5. ホームから、離れています。
When a router is present, and the correspondent does not implement mobility functions, the router must be capable of redirecting the correspondent to communicate directly with the Mobile Node.
ルータが存在していて、通信員が移動性機能を実行しないとき、ルータは、モバイルNodeと共に直接伝達するために通信員を向け直すことができなければなりません。
When no router is present, Mobile Nodes must be capable of communicating directly with other nodes on the same link.
どんなルータも存在していないとき、同じリンクの上に他のノードがある状態で、モバイルNodesは直接伝達できなければなりません。
Mobility must not create an environment which is less secure than the current Internet.
移動性は現在のインターネットほど安全でない環境を作成してはいけません。
Changes in topology must not affect internode security mechanisms.
トポロジーの変化は節間セキュリティー対策に影響してはいけません。
4. Security
4. セキュリティ
4.1. Authentication
4.1. 認証
Mobility registration messages must be authenticated between the home topological repository and Mobile Node.
家の位相的な倉庫とモバイルNodeの間で移動性登録メッセージを認証しなければなりません。
When the correspondent implements mobility functions, redirection or path optimization must be authenticated between the correspondent and Mobile Node.
通信員が移動性機能を実行するとき、通信員とモバイルNodeの間でリダイレクションか経路最適化を認証しなければなりません。
Simpson [Page 5] RFC 1688 IPng Mobility August 1994
シンプソン[5ページ]RFC1688IPng移動性1994年8月
4.2. Anonymity
4.2. 匿名
The capability to attach to a foreign administrative domain without the awareness of the foreign administration is not prohibited. However, any mobility mechanism must provide the ability to prevent such attachment.
対外支配の認識なしで外国管理ドメインに付く能力は禁止されていません。 しかしながら、どんな移動性メカニズムもそのような付属を防ぐ能力を提供しなければなりません。
4.3. Location Privacy
4.3. 位置のプライバシー
The capability to attach to a foreign administrative domain without the awareness of correspondents is not prohibited. However, any mobility mechanism must provide the ability for the home administration to trace the current path to the point of attachment.
通信員の認識なしで外国管理ドメインに付く能力は禁止されていません。 しかしながら、どんな移動性メカニズムも内政が付属まで現在の経路をたどる能力を提供しなければなりません。
4.4. Content Privacy
4.4. 満足しているプライバシー
Security mechanisms which provide content privacy must not obscure or have a dependency on the topological location of Mobile Nodes.
満足しているプライバシーを提供するセキュリティー対策は、モバイルNodesの位相的な位置に依存をあいまいにしてはいけませんし、また持ってはいけません。
5. Bandwidth
5. 帯域幅
Mobility must operate in the current link environment, and must not be dependent on bandwidth improvements. The Mobile Node's directly attached link is likely to be bandwidth limited.
移動性は、現在のリンク環境で運転しなければならなくて、帯域幅進歩に依存しているはずがありません。 モバイルNodeの直接付属しているリンクは制限された帯域幅である傾向があります。
In particular, radio frequency spectrum is already a scarce commodity. Higher bandwidth links are likely to continue to be scarce in the mobile environment.
無線周波数スペクトルは既に特に、不足している商品です。 より高い帯域幅リンクは変わりやすい環境でずっと不十分である傾向があります。
Current applications of mobility using radio links include HF links which are subject to serious fading and noise constraints, VHF and UHF line of sight radio between ships or field sites, and UHF Satellite Communications links.
ラジオリンクを使用する移動性の現在のアプリケーションは船か分野サイトと、UHF Satellite Communicationsリンクの間に重大な色あせを受けることがあるHFリンク、雑音規制、VHF、およびUHF照準線ラジオを含んでいます。
The HF radio bandwidth is fixed at 1200 or 2400 bps by international treaty, statute, and custom, and is not likely to change.
HFラジオ帯域幅は、国際協定、法令、および習慣によって1200か2400ビーピーエスで固定されていて、変化しそうにはありません。
The European standard for cellular radio is 2400 bps GSM.
セルラーのラジオのヨーロッパの規格は2400年のビーピーエスGSMです。
The most prevalent deployed analog cellular and land-line modulation used by mobile nodes is 2400 bps.
セルと地上通信線の可動のノードによって使用される中で最も一般的な配備されたアナログの変調は2400年のビーピーエスです。
Current digital cellular deployment is 19,200 bps CDPD shared among many users. At early installations, under light loads, effective FTP throughput has been observed as low as 200 bps.
現在のデジタルセル展開はビーピーエスCDPDが多くのユーザの中で共有した1万9200です。 早めのインストールのときに、軽い荷の下で、有効なFTPスループットは200ビーピーエスと同じくらい低く観測されました。
Future digital cellular deployment is 9,600 and 14,400 bps CDMA, which is shared between voice and data on a per user basis.
今後のデジタルセル展開は9,600であり、1万4400はビーピーエスCDMAです。(そのCDMAは間にaに関するユーザ基礎あたりの声でデータに共有されています)。
Simpson [Page 6] RFC 1688 IPng Mobility August 1994
シンプソン[6ページ]RFC1688IPng移動性1994年8月
Effective FTP throughput has been measured as low as 7,200 bps.
有効なFTPスループットは7,200ビーピーエスと同じくらい低く測定されました。
Future Personal Communications Services (PCS) will also have relatively little bandwidth. In industrialized nations, the bandwidth available to each user is constrained by the density of deployment, and is commensurate with planned digital cellular deployment.
また、将来のパーソナルCommunications Services(PCS)には、比較的小さい帯域幅があるでしょう。 先進国では、各ユーザにとって、利用可能な帯域幅は、展開の密度によって抑制されて、計画されたデジタルセル展開について等しいです。
It appears likely that satellite-based PCS will be widely deployed for basic telephony communications in many newly-industrialized and lesser-developed countries. There is already significant PCS interest in East and SouthEast Asia, India, and South America.
多くにおける基本の電話コミュニケーションのために広く新たに工業化されていた状態で配備されていてその衛星ベースのPCSがなるより少ない先進国がありそうに見えます。 既に、重要なPCS関心が東洋、SouthEastアジア、インド、および南米にあります。
Van Jacobson header prediction is widely used, and essential to making the use of such links viable.
ヴァンジェーコブソンヘッダー予測は、そのようなリンクの使用を実行可能にするのに広く使用されていて、不可欠です。
5.1. Administrative Messages
5.1. 管理メッセージ
The number of administrative mobility messages sent or received by the Mobile Node must be limited to as few as possible. In order to meet the frequency requirement of changing point of attachment once per second, registration of changes must not require more than a single request and reply.
モバイルNodeが送ったか、または受け取った管理移動性メッセージの数をできるだけわずかに制限しなければなりません。 1秒に一度変化接着点の頻度必要条件を満たすために、変化の登録はただ一つの要求と回答以上を必要としてはいけません。
The size of administrative mobility messages must be kept as short as possible. In order to meet the frequency requirement of changing point of attachment once per second, the registration messages must not total more than 120 bytes for a complete transaction, including link and internet headers.
できるだけ短いのを管理移動性メッセージのサイズを保たなければなりません。 1秒に一度変化接着点の頻度必要条件を満たして、登録メッセージは完全な取引のために合計で120バイト以上になってはいけません、リンクとインターネットヘッダーを含んでいて。
5.2. Response Time
5.2. 応答時間
For most mobile links in current use, the typical TCP/IPv4 datagram overhead of 40 bytes is too large to maintain an acceptable typing response of 200 milliseconds round trip time.
現在の使用でのほとんどの可動のリンクに関しては、40バイトの典型的なTCP/IPv4データグラムオーバーヘッドは200ミリセカンドの周遊旅行時間の許容できるタイプ応答を維持できないくらい大きいです。
Therefore, the criteria for IPng mobility is that the response time not be perceptably worse than IPv4.
したがって、IPngの移動性が応答時間がないということであるので、評価基準はIPv4よりひどくperceptablyされます。
This allows no more than 6 bytes of additional overhead per datagram to be added by IPng.
IPngによって加えられるように、これは1データグラムあたりの6バイト未満の追加オーバーヘッドを許容します。
This was a primary concern in the design of mobility forwarding
headers. Larger headers were rejected outright, and negotiation
is provided for smaller headers than the default method.
Topological headers are removed by the Foreign Agent prior to
datagram transmission over the slower link to the Mobile Node,
which also aids header prediction, as described below.
これは移動性推進ヘッダーのデザインでプライマリ関心でした。 より大きいヘッダーを完全に拒絶しました、そして、デフォルトメソッドより小さいヘッダーに交渉を提供します。 位相的なヘッダーはデータグラムトランスミッションの前にForeignエージェントによってモバイルNodeへの、より遅いリンクの上に移されます、以下で説明されるように。また、Nodeはヘッダー予測を支援します。
Simpson [Page 7] RFC 1688 IPng Mobility August 1994
シンプソン[7ページ]RFC1688IPng移動性1994年8月
5.3. Header Prediction
5.3. ヘッダー予測
Header prediction can be useful in reducing bandwidth usage on multiple related datagrams. It requires a point-to-point peer relationship between nodes, so that a header history can be maintained between the peers.
ヘッダー予測は複数の関連するデータグラムで帯域幅用法を減少させる際に役に立つ場合があります。ノードの間の二地点間同輩関係を必要とします、同輩の間でヘッダー歴史を維持できるように。
Header prediction is less effective in mobile environments, as the header history is lost each time a Mobile Node changes its point of attachment. The new Foreign Agent will not have the same history as the previous Agent.
ヘッダー予測はモバイル環境でそれほど有効ではありません、ヘッダー歴史がモバイルNodeが接着点を変える各回無くなるとき。 新しいForeignエージェントには、前のエージェントと同じ歴史がないでしょう。
In order for header prediction to operate successfully, changing topological information must be removed from datagram overhead prior to transmission of the datagram on any final hop's directly attached link. This applies to both the Mobile Node peering with a Foreign Agent, and also the final link to a Correspondent. Otherwise, header prediction cannot be relied upon to improve bandwidth utilization on low-speed Mobile and Correspondent links.
首尾よく操作するヘッダー予測において整然とします、どんな最終的なホップの直接付属しているリンクにおけるデータグラムのトランスミッションの前にデータグラムオーバーヘッドから位相的な情報を変えるのを取り除かなければなりません。 これはForeignエージェントと共にじっと見るモバイルNodeとCorrespondentへの最終的なリンクについても両方に適用されます。 さもなければ、モバイルとCorrespondentの低速リンクで帯域幅利用を改良するためにヘッダー予測を当てにすることができません。
Since the changing topological information cannot be removed in the forwarding path of the datagram, header prediction will also be affected at any other pair of routers in the datagram path. Each time that a Mobile Node moves, the topological portion of the header will change, and header history used at those routers will be updated. Unless topological information is limited to as few headers as possible, this may render header prediction ineffective as more Mobile Nodes are deployed.
データグラムの推進経路で変化の位相的な情報を取り除くことができないので、また、ヘッダー予測はデータグラム経路でルータのいかなる他の組でも影響を受けるでしょう。 モバイルNodeが移行する各回、ヘッダーの位相的な部分は変化するでしょう、そして、それらのルータで費やされたヘッダー歴史をアップデートするでしょう。 位相的な情報ができるだけわずかなヘッダーに制限されない場合、よりモバイルのNodesが配布されるとき、これはヘッダー予測を効力がなくするかもしれません。
6. Processing
6. 処理
Mobility must operate in the current processor environment, and must not be dependent on hardware improvements.
移動性は、現在のプロセッサ環境で運転しなければならなくて、ハードウェア進歩に依存しているはずがありません。
Common hardware implementations of Mobile Nodes include lower speed processors, and highly integrated components. These are not readily upgradable.
モバイルNodesの一般的なハードウェア実装は下側の速度プロセッサ、および高集積度なコンポーネントを含んでいます。 これらは容易にアップグレード可能ではありません。
The most prevalent mobile platform is a low speed i86, i286 or i386.
最も一般的なモバイルプラットホームは、低い速度i86、i286またはi386です。
The most common ASIC processor is a low speed i186.
最も一般的なASICプロセッサは低い速度i186です。
6.1. Fixed Location
6.1. 固定ロケーション
The processing limitations require that datagram header fields which are frequently examined by Mobile Nodes, or used for datagram forwarding to or from Mobile Nodes, are in a fixed location and do not require lengths and offsets.
処理制限は、頻繁にモバイルNodesによって調べられるか、またはデータグラム推進にNodes、または、モバイルNodesから使用されるデータグラムヘッダーフィールドが固定ロケーションにあるのが必要であり、長さとオフセットは必要としません。
Simpson [Page 8] RFC 1688 IPng Mobility August 1994
シンプソン[8ページ]RFC1688IPng移動性1994年8月
Varied number of fields was explicitly rejected in the design of
mobility registration and forwarding headers.
様々な数の分野が、移動性登録のデザインで明らかに拒絶されて、ヘッダーを進めていました。
6.2. Simple Fields
6.2. 簡単な分野
The processing limitations require that datagram header fields which are frequently examined by Mobile Nodes, or used for datagram forwarding to or from Mobile Nodes, are simple and fixed size.
処理制限は、頻繁にモバイルNodesによって調べられるか、またはデータグラム推進にNodes、または、モバイルNodesから使用されるデータグラムヘッダーフィールドが簡単で固定されたサイズであることを必要とします。
Varied length of fields was explicitly rejected in the design of
mobility forwarding headers.
様々な長さの分野は移動性推進ヘッダーのデザインで明らかに拒絶されました。
6.3. Simple Tests
6.3. 単純なテスト
Because the most prevalent processors are "little-endian", while network protocols are in practice "big-endian", the field processing must primarily use simple equality tests, rather than variable shifts and prefix matches.
最も一般的なプロセッサが「リトルエンディアン」ですが、ネットワーク・プロトコルが習慣「ビッグエンディアン」であるので、フィールド処理は主として可変シフトと接頭語マッチよりむしろ簡単な平等テストを使用しなければなりません。
6.4. Type, Length, Value
6.4. タイプ、長さ、値
Fields which are not frequently examined, whether due to infrequent transmission or content that is not relevant in every message, must be of the Type, Length, Value format.
あらゆるメッセージで関連するというわけではない珍しいトランスミッションか内容にかかわらず頻繁に調べられない分野はTypeのものであるに違いありません、Length、Value形式。
Acknowledgements
承認
This compilation is primarily based on the work in progress of the IETF Mobile IP Working Group.
この編集は主としてIETFのモバイルIP作業部会の処理中の作業に基づいています。
Security Considerations
セキュリティ問題
Security issues are discussed in section 4.
セクション4で安全保障問題について議論します。
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071
EMail: Bill.Simpson@um.cc.umich.edu or
bsimpson@MorningStar.com
メール: Bill.Simpson@um.cc.umich.edu かbsimpson@MorningStar.com
Simpson [Page 9]
シンプソン[9ページ]
一覧
スポンサーリンク
