RFC1683 日本語訳
1683 Multiprotocol Interoperability In IPng. R. Clark, M. Ammar, K.Calvert. August 1994. (Format: TXT=28201 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Clark
Request for Comments: 1683 M. Ammar
Category: Informational K. Calvert
Georgia Institute of Technology
August 1994
コメントを求めるワーキンググループR.クラークの要求をネットワークでつないでください: 1683年のM.Ammarカテゴリ: 情報のK.カルバートジョージア工科大学1994年8月
Multiprotocol Interoperability In IPng
IPngのMultiprotocol相互運用性
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 IETF 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.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
1. Executive Summary
1. 要約
The two most commonly cited issues motivating the introduction of IPng are address depletion and routing table growth in IPv4. Further motivation is the fact that the Internet is witnessing an increasing diversity in the protocols and services found in the network. When evaluating alternatives for IPng, we should consider how well each alternative addresses the problems arising from this diversity. In this document, we identify several features that affect a protocol's ability to operate in a multiprotocol environment and propose the incorporation of these features into IPng.
2は最も一般的にIPv4でのIPngがアドレス減少であり、テーブルの成長を発送する導入を動機づける問題を引用しました。 さらなる動機はインターネットがネットワークで見つけられたプロトコルとサービスにおける増加する多様性を目撃しているという事実です。 IPngのために選択肢を検討するとき、私たちは、各選択肢がこの多様性から起こることにおけるその問題をどれくらいよく訴えるかを考えるべきです。 本書では、私たちは、「マルチ-プロトコル」環境で作動するプロトコルの能力に影響するいくつかの特徴を特定して、これらの特徴の編入をIPngに提案します。
Our thesis, succinctly stated, is: The next generation Internet Protocol should have features that support its use with a variety of protocol architectures.
私たちの簡潔に述べられた論文は以下の通りです。 次世代インターネットプロトコルには、さまざまなプロトコルアーキテクチャで使用をサポートする特徴があるべきです。
2. Introduction
2. 序論
The Internet is not a single protocol network [4]. While TCP/IP remains the primary protocol suite, other protocols (e.g., IPX, AppleTalk, OSI) exist either natively or encapsulated as data within IP. As new protocols continue to be developed, we are likely to find that a significant portion of the traffic in future networks is not from single-protocol communications. It is important to recognize that multiprotocol networking is not just a transition issue. For instance, we will continue to see tunneling used to carry IPX traffic
インターネットはただ一つのプロトコルネットワーク[4]ではありません。 TCP/IPはプライマリプロトコル群のままで残っていましたが、他のプロトコル(例えば、IPX、AppleTalk、OSI)は、ネイティブに存在したか、またはデータとしてIPの中で要約されました。 新しいプロトコルが、開発され続けているとき、私たちは将来のネットワークにおけるトラフィックの重要な部分がただ一つのプロトコルコミュニケーションから来ていないのがわかりそうです。 「マルチ-プロトコル」ネットワークが変遷問題であるだけではないと認めるのは重要です。 例えば、私たちは、トンネリングがIPXトラフィックを運ぶのに使用されるのをずっと見るでしょう。
Clark, Ammar & Calvert [Page 1] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[1ページ]RFC1683Multiprotocol相互運用性
over the Internet between two Novell networks. Furthermore, the introduction of IPng is not going to result in a near term elimination of IPv4. Even when IPng becomes the primary protocol used in the Internet, there will still be IPv4 systems in use. We should consider such multiprotocol uses of the network as we design future protocols that can efficiently handle mixed protocol traffic.
2つのノベルネットワークの間のインターネットの上で。 その上、IPngの導入はIPv4の短期間除去をもたらさないでしょう。 IPngがインターネットで使用されるプライマリプロトコルになるときさえ、それでも、使用中のIPv4システムがあるでしょう。 効率的に複雑なプロトコルトラフィックを扱うことができる将来のプロトコルを設計するとき、私たちはネットワークのそのような「マルチ-プロトコル」用途を考えるべきです。
We have identified several issues related to the way in which protocols operate in a multiprotocol environment. Many of these issues have traditionally been deemed "less important" by protocol designers since their goal was to optimize for the case where all systems supported the same protocol. With the increasing diversity of network protocols, this approach is no longer practical. By addressing the issues outlined in this paper, we can simplify the introduction of IPng to the Internet and reduce the risk for network managers faced with the prospect of supporting a new protocol. This will result in a faster, wider acceptance of IPng and increased interoperability between Internet hosts. In addition, by designing IPng to address these issues, we will make the introduction of future protocols (IPng2) even easier.
私たちはプロトコルが「マルチ-プロトコル」環境で作動する方法に関連するいくつかの問題を特定しました。 すべてのシステムが同じプロトコルをサポートしたケースのために最適化して以来、彼らの目標がことであるこれらの問題の多くが「それほど重要でない」とプロトコルデザイナーによって伝統的に考えられています。 ネットワーク・プロトコルの増加する多様性では、このアプローチはもう実用的ではありません。 この紙に概説された問題を扱うことによって、私たちは、IPngの導入をインターネットに簡素化して、新しいプロトコルをサポートするという見通しに直面していたネットワークマネージャのために危険を減少させることができます。 これはインターネット・ホストの間のIPngと増強された相互運用性の、より速くて、より広い承認をもたらすでしょう。 さらに、これらの問題を扱うようにIPngを設計することによって、私たちは将来のプロトコル(IPng2)の導入をさらに簡単にするつもりです。
The outline for this document is as follows. In Section 3 we motivate the issues of multiprotocol networking with a discussion of an example system. In Section 4 we describe three main techniques for dealing with multiple protocols. This is followed in Section 5 by a description of the various protocol features that are important for implementing these three techniques. We conclude in Section 6 with a summary of the issues raised.
このドキュメントのためのアウトラインは以下の通りです。 セクション3では、私たちは例のシステムの議論で「マルチ-プロトコル」ネットワークの問題を動機づけます。 セクション4では、私たちは複数のプロトコルに対処するための3つの主なテクニックについて説明します。 これらの3つのテクニックを実装するのに、重要な様々なプロトコル機能の記述はセクション5でこれのあとに続いています。 問題の概要が提起されている状態で、私たちはセクション6で結論を下します。
3. Multiprotocol Systems
3. Multiprotocolシステム
Consider the multiprotocol architecture depicted in Figure 1. A system supporting this architecture provides a generic file-transfer service using either the Internet or OSI protocol stacks. The generic service presents the user with a consistent interface, regardless of the actual protocols used. The user can transfer files between this host and hosts supporting either of the single protocol stacks presented in Figures 2a and 2b. To carry out this file transfer, the user is not required to decide which protocols to use or to adjust between different application interfaces.
「マルチ-プロトコル」が図1に表現されたアーキテクチャであると考えてください。 このアーキテクチャをサポートするシステムは、インターネットかOSIプロトコル・スタックを使用することでジェネリックファイル転送サービスを提供します。 ジェネリックサービスは使用される実際のプロトコルにかかわらず一貫したインタフェースをユーザに与えます。 ユーザは図の2aと2bで贈られた単一のプロトコル・スタックのどちらかをサポートするこのホストとホストの間にファイルを移すことができます。 このファイル転送を行うために、ユーザは、どのプロトコルを使用したらよいか、または異なったアプリケーション・インターフェースの間で調整したらよいかを決める必要はありません。
Clark, Ammar & Calvert [Page 2] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[2ページ]RFC1683Multiprotocol相互運用性
+-----------------------------------+
| File Transfer Service |
+-----------+-----------------------+
| | FTAM |
| +-----------------------+
| FTP | ISO 8823 |
| +-----------------------+
| | ISO 8327 |
| +-----------+-----------+
| |TP0/RFC1006| TP4 |
+-----------+-----------+ |
| TCP | |
+-----------+-----------+-----------+
| IP | CLNP |
+-----------+-----------------------+
+-----------------------------------+ | ファイル転送サービス| +-----------+-----------------------+ | | FTAM| | +-----------------------+ | FTP| ISO8823| | +-----------------------+ | | ISO8327| | +-----------+-----------+ | |TP0/RFC1006| TP4| +-----------+-----------+ | | TCP| | +-----------+-----------+-----------+ | IP| CLNP| +-----------+-----------------------+
Figure 1: Multiprotocol architecture providing file-transfer service
図1: ファイル転送サービスを提供するMultiprotocolアーキテクチャ
+-----------+ +-----------+ +-----------+ +-----------+
| FTP | | FTAM | | FTAM | | FTP |
+-----------+ +-----------+ +-----------+ +-----------+
| TCP | | ISO 8823 | | ISO 8823 | | TCP |
+-----------+ +-----------+ +-----------+ +-----------+
| IP | | ISO 8327 | | ISO 8327 | | CLNP |
+-----------+ +-----------+ +-----------+ +-----------+
| TP4 | |TP0/RFC1006|
+-----------+ +-----------+
| CLNP | | TCP |
+-----------+ +-----------+
| IP |
+-----------+
+-----------+ +-----------+ +-----------+ +-----------+ | FTP| | FTAM| | FTAM| | FTP| +-----------+ +-----------+ +-----------+ +-----------+ | TCP| | ISO8823| | ISO8823| | TCP| +-----------+ +-----------+ +-----------+ +-----------+ | IP| | ISO8327| | ISO8327| | CLNP| +-----------+ +-----------+ +-----------+ +-----------+ | TP4| |TP0/RFC1006| +-----------+ +-----------+ | CLNP| | TCP| +-----------+ +-----------+ | IP| +-----------+
a) TCP/IP b) OSI c) RFC 1006 d) TUBA
a) TCP/IP b) OSI c) RFC1006d) チューバ
Figure 2: Protocol stacks providing file-transfer service.
図2: プロトコルは、ファイル転送サービスを提供しながら、積み重ねられます。
Figure 2c depicts a mixed stack architecture that provides the upper layer OSI services using the Internet protocols. This is an example of a "transition architecture" for providing OSI applications without requiring a full OSI implementation. Figure 2d depicts a mixed stack architecture that provides the upper layer Internet applications using the OSI network protocol. In addition to communicating with the two previous simple protocol stacks, the multiprotocol system of Figure 1 includes all the protocols necessary to communicate with these two new, mixed protocol stacks.
図2cはインターネットプロトコルを使用することでOSIの上側の層にサービスを供給する複雑なスタック・アーキテクチャについて表現します。 これは完全なOSI実装を必要としないで利用をOSIに供給するための「変遷アーキテクチャ」に関する例です。 図2dはOSIネットワーク・プロトコルを使用することで上側の層のインターネット利用を提供する複雑なスタック・アーキテクチャについて表現します。 前の2個の簡単なプロトコル・スタックで交信することに加えて、図1の「マルチ-プロトコル」システムはこれらの2と新しい状態でコミュニケートするのに必要なすべてのプロトコルを含んでいます、混ぜられたプロトコル・スタック。
Clark, Ammar & Calvert [Page 3] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[3ページ]RFC1683Multiprotocol相互運用性
It is likely that many future network systems will be configured to support multiple protocols including IPng. As the IPng protocol is deployed, it is unreasonable to expect that users will be willing to give up any aspect of their current connectivity for the promise of a better future. In reality, most IPng installations will be made "in addition to" the current protocols. The resulting systems will resemble Figure 1 in that they will be able to communicate with systems supporting several different protocols.
多くの将来のネットワーク・システムが、IPngを含む複数のプロトコルをサポートするために構成されそうでしょう。 IPngプロトコルが配布されるので、ユーザが、何かより良い未来の約束のための彼らの現在の接続性の局面をあきらめても構わないと思うと予想するのは無理です。 現在のプロトコル「に加えて」でほとんどのIPngインストールをほんとうは、するでしょう。 結果として起こるシステムは彼らがいくつかの異なったプロトコルをサポートするシステムとコミュニケートできるという点で図1に類似するでしょう。
Unfortunately, in most current examples, the architecture of Figure 1 is implemented as independent protocol stacks. This means that even though both TCP and CLNP exist on the system, there is no way to use TCP and CLNP in the same communication. The problem with current implementations of architectures like Figure 1 is that they are designed as co-existence architectures and are not integrated interoperability systems. We believe future systems should include mechanisms to overcome this traditional limitation. By integrating the components of multiple protocol stacks in a systematic way, we can interoperate with hosts supporting any of the individual stacks as well as those supporting various combinations of the stacks.
残念ながら、ほとんどの現在の例では、図1のアーキテクチャは独立しているプロトコル・スタックとして実装されます。 これは、TCPとCLNPの両方がシステムの上に存在していますが、同じコミュニケーションでTCPとCLNPを使用する方法が全くないことを意味します。 図1のようなアーキテクチャの現在の実装に関する問題はそれらが共存アーキテクチャとして設計されていて、統合相互運用性システムでないということです。私たちは、将来のシステムがこの伝統的な限界を克服するためにメカニズムを含んでいるはずであると信じています。 系統立った方法的に複数のプロトコル・スタックの部品を統合することによって、ホストが個々のスタックのどれかを支えていて、ものがスタックの様々な組み合わせをサポートしていて、私たちは共同利用できます。
In order to effectively use multiple protocols, a system must identify which of the available protocols to use for a given communication task. We call this the Protocol Determination [2] task. In performing this task, a system determines the combination of protocols necessary to provide the needed service. For achieving interoperability, protocols are selected from the intersection of those supported on the systems that must communicate.
事実上、複数のプロトコルを使用するために、システムは、与えられたコミュニケーションタスクに利用可能なプロトコルのどれを使用したらよいかを特定しなければなりません。 私たちは、これをプロトコルDetermination[2]タスクと呼びます。 このタスクを実行する際に、システムは必要なサービスを提供するのに必要なプロトコルの組み合わせを決定します。 相互運用性を達成するのにおいて、プロトコルは交信しなければならないシステムの上でサポートされたものの交差点から選択されます。
4. Multiprotocol Techniques
4. Multiprotocolのテクニック
In this section we identify three main techniques to dealing with multiprotocol networks that are in use today and will continue to be used in the Internet. The first two techniques, tunneling and conversion, are categorized as intermediate-system techniques in that they are designed to achieve multiprotocol support without changing the end-systems. The third technique explicitly calls for the support of multiple protocols in end-systems. By describing these techniques here, we can motivate the need for the specific protocol features described in Section 5.
このセクションで、私たちは、今日使用中の「マルチ-プロトコル」ネットワークと取り引きすることへの3つの主なテクニックを特定して、インターネットで使用され続けるつもりです。 それらがエンドシステムを変えないで「マルチ-プロトコル」サポートを達成するように設計されているので、最初の2つのテクニック(トンネリングと変換)が、中間システムのテクニックとして分類されます。3番目のテクニックは明らかにエンドシステムにおける、複数のプロトコルのサポートを求めます。ここでこれらのテクニックについて説明することによって、私たちはセクション5で説明された特定のプロトコル機能の必要性を動機づけることができます。
4.1 Encapsulation/Tunneling
4.1 カプセル化/トンネリング
Encapsulation or tunneling is commonly used when two networks that support a common protocol must be connected using a third intermediate network running a different protocol. Protocol packets from the two end networks are carried as data within the protocol of the intermediate network. This technique is only appropriate when
異なったプロトコルを実行しながら3番目の中間ネットワークを使用することで一般的なプロトコルをサポートする2つのネットワークを接続しなければならないとき、カプセル化かトンネリングが一般的に使用されます。 2つの終わりのネットワークからのプロトコルパケットはデータとして中間ネットワークのプロトコルの中で運ばれます。 このテクニックはいつを当てるだけであるかことです。
Clark, Ammar & Calvert [Page 4] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[4ページ]RFC1683Multiprotocol相互運用性
both end-systems support the same protocol stack. It does not provide interoperability between these end systems and systems that only support the protocol stack in the intermediate network. Some examples of this technique are: a mechanism for providing the OSI transport services on top of the Internet protocols [13], encapsulating IEEE 802.2 frames in IPX network packets [5], tunneling IPX [10] and AppleTalk traffic over the Internet backbone. We expect IPng to be used for tunneling other network protocols over IPng and to be encapsulated.
両方のエンドシステムは同じプロトコル・スタックを支えます。 それは中間ネットワークでプロトコル・スタックを支えるだけであるこれらのエンドシステムとシステムの間に相互運用性を供給しません。 このテクニックに関するいくつかの例は以下の通りです。 インターネットプロトコル[13]の上でOSI輸送サービスを提供するためのメカニズム、IEEE802.2をカプセル化するのはIPXネットワークパケット[5]で縁どられます、インターネットの基幹の上でIPX[10]とAppleTalkトラフィックにトンネルを堀って。 私たちは、IPngがIPngの上で他のネットワーク・プロトコルにトンネルを堀るのに使用されて、カプセル化されると予想します。
4.2 Translation/Conversion
4.2 翻訳/変換
Despite their known limitations [8], translation or conversion gateways are another technique for handling multiple protocols [11, 12]. These gateways perform direct conversion of network traffic from one protocol to another. The most common examples of conversion gateways are the many electronic mail gateways now in use in the Internet. In certain cases it may also be feasible to perform conversion of lower layer protocols such as the network layer. This technique has been suggested as part of the transition plan for some of the current IPng proposals [3, 15].
彼らの知られている制限[8]にもかかわらず、翻訳か変換ゲートウェイが、複数のプロトコル[11、12]を扱うための別のテクニックです。 これらのゲートウェイはネットワークトラフィックの1つのプロトコルから別のプロトコルまでの直接変換を実行します。 変換ゲートウェイの最も一般的な例は現在インターネットで使用中の多くの電子メールゲートウェイです。 ある場合には、また、ネットワーク層などの下位層プロトコルの変換を実行するのも可能であるかもしれません。 このテクニックは現在のIPng提案[3、15]のいくつかの変遷プランの一部として示されました。
4.3 Multiprotocol End-Systems
4.3 Multiprotocolエンドシステム
We expect that IPng will be introduced as an additional protocol in many network systems. This means that IPng should be able to coexist with other protocols on both end- and intermediate-systems. Specifically, IPng should be designed to support the Protocol Determination task described in Section 3.
私たちは、多くのネットワーク・システムこれの追加議定書が、IPngが終わりと中間システムの両方に他のプロトコルと共存するはずであることができることを意味するときIPngが導入されると予想します。明確に、IPngは、セクション3で説明されたプロトコルDeterminationタスクをサポートするように設計されるべきです。
One technique that we consider for solving the Protocol Determination problem is to employ a directory service in distributing system protocol configuration information. We have developed and implemented mechanism for using the Internet Domain Name System (DNS) [6, 7] to distribute this protocol information [2]. Using this mechanism, a multiprotocol host can determine the protocol configuration of a desired host when it retrieves the network address for that host. Then the multiprotocol host can match the configuration of the desired host to its own configuration and determine which protocols should be used to carry out the requested communication service.
私たちがプロトコルDetermination問題を解決するために考える1つのテクニックはシステムプロトコル設定情報を分配しながらディレクトリサービスを雇用することです。 私たちには、このプロトコル情報[2]を分配するのにインターネットドメインネームシステム(DNS)[6、7]を使用するための開発されて実装しているメカニズムがあります。 そのホストのためにネットワーク・アドレスを検索するとき、このメカニズムを使用して、「マルチ-プロトコル」ホストは必要なホストのプロトコル構成を決定できます。 次に、「マルチ-プロトコル」ホストは、必要なホストの構成をそれ自身の構成に合わせて、どのプロトコルが要求された通信サービスを行うのに使用されるべきであるかを決心できます。
Another alternative to determining protocol information about another host is Protocol Discovery. Using this approach, a host determines which protocols to use by trial-and-error with the protocols currently available. The initiating host monitors successive attempts to communicate and uses the information gained from that monitoring to build a knowledge base of the possible protocols of the
別のホストに関するプロトコル情報を決定することへの別の代替手段はプロトコルディスカバリーです。 このアプローチを使用して、ホストは、プロトコルが現在利用可能な状態で試行錯誤でどのプロトコルを使用するかを決心しています。 開始しているホストは、交信する連続した試みをモニターして、可能なプロトコルの知識ベースを体格にモニターするそれから獲得された情報を使用します。
Clark, Ammar & Calvert [Page 5] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[5ページ]RFC1683Multiprotocol相互運用性
remote system.
リモートシステム。
This knowledge is used to determine whether or not a communication link can be established and if it can, which protocol should be used.
この知識は通信リンクを確立できるかどうか決定するのに使用されます、そして、そうすることができるなら、どれが議定書を作るかは使用されるべきです。
An important aspect of the Protocol Discovery approach is that it requires an error and control feedback system similar to ICMP [9], but with additional functionality (See Section 5).
ICMP[9]と同様の誤りと制御期間方式を必要とするということですが、プロトコルディスカバリーアプローチの重要な一面は追加機能性でことです(セクション5を見てください)。
5. Protocol Features
5. プロトコル機能
In this section we identify features that affect a protocol's ability to support the multiprotocol techniques described in the previous section. These features indicate specific areas that should be considered when comparing proposed protocols. We present two different types of protocol features: those that should be included as part of the IPng protocol standard, and those that should be considered as part of the implementation and deployment requirements for IPng.
このセクションで、私たちは前項で説明された「マルチ-プロトコル」のテクニックをサポートするプロトコルの能力に影響する特徴を特定します。 これらの特徴は、比較するとき考えられるべきである特定の領域がプロトコルを提案したのを示します。 私たちはプロトコル機能の2つの異なったタイプを提示します: IPngの一部として含まれるべきであるものはIPngのための実装と展開要件の一部であるとみなされるべきである規格、およびものについて議定書の中で述べます。
5.1 Protocol Standard Features
5.1 プロトコル標準装備
o Addressing
o アドレシング
A significant problem in dealing with multiprotocol networks is
that most of the popular network protocols use different
addressing mechanisms. The problem is not just with different
lengths but also with different semantics (e.g., hierarchical vs.
flat addresses). In order to accommodate these multiple formats,
IPng should have the flexibility to incorporate many address
formats within its addressing mechanism.
「マルチ-プロトコル」ネットワークと取り引きすることにおける重大な問題はポピュラーなネットワーク・プロトコルの大部分が異なったアドレシングメカニズムを使用するということです。問題が異なった長さと共にあるだけではなく、異なった意味論(例えば、アパートに対して階層的なアドレス)と共にもあります。 これらの複数の形式を収容するために、IPngはアドレシングメカニズムの中に多くのアドレス形式を取り入れる柔軟性を持っているはずです。
A specific example might be for IPng to have the ability to
include an IPv4 or IPX address as a subfield of the IPng address.
This would reduce the complexity of performing address conversion
by limiting the number of external mechanisms (e.g., lookup
tables) needed to convert an address. This reduction in
complexity would facilitate both tunneling and conversion. It
would also simplify the task of using IPng with legacy
applications which rely on a particular address format.
特定の例はIPngにはIPngアドレスの部分体としてIPv4かIPXアドレスを含む能力があることであるかもしれません。 これはアドレスを変換するのが必要である外部のメカニズム(例えば、ルックアップ表)の数を制限することによってアドレス変換を実行する複雑さを減少させるでしょう。 複雑さのこの減少はトンネリングと変換の両方を容易にするでしょう。 また、それは特定のアドレス形式を当てにするレガシーアプリケーションでIPngを使用するタスクを簡素化するでしょう。
o Header Option Handling
o ヘッダーオプション取り扱い
In any widely used protocol, it is advantageous to define option
mechanisms for including header information that is not required
in all packets or is not yet defined. This is especially true in
multiprotocol networks where there is wide variation in the
requirements of protocol users. IPng should provide efficient,
どんな広く使用されたプロトコルでも、すべてのパケットで必要でない、またはまだ定義されていないヘッダー情報を含むようにオプションメカニズムを定義するのは有利です。 これはプロトコルユーザの要件の広い変化がある「マルチ-プロトコル」ネットワークで特に本当です。 IPngは効率的な状態で提供するはずです。
Clark, Ammar & Calvert [Page 6] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[6ページ]RFC1683Multiprotocol相互運用性
flexible support for future header options. This will better
accommodate the different user needs and will facilitate
conversion between IPng and other protocols with different
standard features.
今後のヘッダーオプションの可動支持。 これは、異なったユーザの必要性をよりよく収容して、異なった標準装備でIPngと他のプロトコルの間の変換を容易にするでしょう。
As part of the support for protocol options, IPng should include a
mechanism for specifying how a system should handle unsupported
options. If a network system adds an option header, it should be
able to specify whether another system that does not support the
option should drop the packet, drop the packet and return an
error, forward it as is, or forward it without the option header.
The ability to request the "forward as is" option is important
when conversion is used. When two protocols have different
features, a converter may introduce an option header that is not
understood by an intermediate node but may be required for
interpretation of the packet at the ultimate destination. On the
other hand, consider the case where a source is using IPng with a
critical option like encryption. In this situation the user would
not want a conversion to be performed where the option was not
understood by the converter. The "drop the packet" or "drop and
return error" options would likely be used in this scenario.
プロトコルオプションのサポートの一部として、IPngはシステムがどう非サポート・オプションを扱うはずであるかを指定するためのメカニズムを含んでいるはずです。 オプションをサポートしない別のシステムがパケットを下げるはずであるか否かに関係なく、それはネットワーク・システムがオプションヘッダーを加えるなら、パケットを下げて、誤りを返すか、そのままでそれを進めるか、またはオプションヘッダーなしでそれを進めるように指定できるべきです。 変換が使用されているとき、「そのままなフォワード」オプションを要求する能力は重要です。 2つのプロトコルに異なった特徴があるとき、コンバータは中間的ノードに解釈されませんが、パケットの解釈に最終仕向地で必要であるかもしれないオプションヘッダーを紹介するかもしれません。 他方では、ソースが暗号化のような重要なオプションがあるIPngを使用しているケースを考えてください。 この状況で、ユーザはオプションがコンバータに解釈されなかったところで変換を実行して欲しくないでしょう。 「パケットを下げてください」か「誤りを下げて、返してください」というオプションはこのシナリオでおそらく使用されるでしょう。
o Multiplexing
o マルチプレクシング
The future Internet protocol should support the ability to
distinguish between multiple users of the network. This includes
the ability to handle traditional "transport layer" protocols like
TCP and UDP, as well as other payload types such as encapsulated
AppleTalk packets or future real-time protocols. This kind of
protocol multiplexing can be supported with an explicit header
field as in IPv4 or by reserving part of the address format as is
done with OSI NSEL's.
将来のインターネットプロトコルはネットワークの複数のユーザを見分ける能力をサポートするべきです。 これはTCPとUDPのような伝統的な「トランスポート層」プロトコルを扱う能力を含んでいます、AppleTalkパケットか将来のリアルタイムのプロトコルであるとカプセル化されるような他のペイロードタイプと同様に。 この種類のプロトコルマルチプレクシングがIPv4のように明白なヘッダーフィールドでサポートするか、またはOSI NSELのものと共にそのままでアドレス形式の一部を予約することによって、できます。
In a multiprotocol network there will likely be a large number of
different protocols running atop IPng. It should not be necessary
to use a transport layer protocol for the sole purpose of
providing multiplexing for the various network users. The cost of
this additional multiplexing is prohibitive for future high-speed
networks [14]. In order to avoid the need for an additional level
of multiplexing, the IPng should either use a payload selector
larger than the 8-bits used in IPv4 or provide an option for
including additional payload type information within the header.
「マルチ-プロトコル」ネットワークには、IPngの上で稼働する多くの異なったプロトコルがおそらくあるでしょう。 提供が様々なネットワーク利用者のために多重送信される唯一の目的にトランスポート層プロトコルを使用するのは必要であるべきではありません。 将来の高速ネットワーク[14]に、この追加マルチプレクシングの費用はひどく高いです。 追加レベルのマルチプレクシングの必要性を避けるために、IPngはIPv4で使用される8ビットより大きいペイロードセレクタを使用するはずであるか、またはヘッダーの中に追加ペイロードタイプ情報を含むためのオプションを提供するはずです。
o Status/Control Feedback
o 状態/コントロールフィードバック
With multiple protocols, the correct transmission of a packet
might include encapsulation in another protocol and/or multiple
conversions to different protocols before the packet finally
複数のプロトコルで、パケットの正しいトランスミッションは別のプロトコル、そして/または、複数の変換に最終的にパケットの前の異なったプロトコルにカプセル化を含むかもしれません。
Clark, Ammar & Calvert [Page 7] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[7ページ]RFC1683Multiprotocol相互運用性
reaches its destination. This means that there are many different
places the transmission can fail and determining what went wrong
will be a challenge.
目的地に到着します。 これは、トランスミッションが失敗できる多くの異なった場所があることを意味します、そして、何が支障をきたしたかを決定するのは、挑戦でしょう。
In order to handle this situation, a critical protocol feature in
multiprotocol networks is a powerful error reporting mechanism.
この状況を扱うために、「マルチ-プロトコル」ネットワークにおけるきわどいプロトコル機能は強力な誤り報告メカニズムです。
In addition to reporting traditional network level errors, such as
those reported by ICMP [9], the IPng error mechanism should
include feedback on tunneling and conversion failures. Also,
since it is impossible to know exactly which part of a packet is
an encapsulated header, it is important that the feedback
mechanism include as much of the failed packet as possible in the
returned error message.
それらなどの伝統的ネットワークレベル誤りがICMP[9]で報告したと報告することに加えて、IPng誤りメカニズムはトンネリングと変換失敗のフィードバックを含んでいるはずです。 また、パケットのどの部分がカプセル化されたヘッダーであるかをまさに知るのが不可能であるので、フィードバック・メカニズムが返されたエラーメッセージのできるだけ多量の失敗したパケットを含んでいるのも、重要です。
In addition to providing new types of feedback, this mechanism
should support variable resolution such that a transmitting system
can request limited feedback or complete information about the
communication process. This level of control would greatly
facilitate the Protocol Discovery process described in Section
4.3. For example, a multiprotocol system could request maximal
feedback when it sends packets to a destination it has not
communicated with for some time. After the first few packets to
this "new" destination, the system would revert back to limited
feedback, freeing up the resources used by the network feedback
mechanisms.
新しいタイプのフィードバックを提供することに加えて、このメカニズムは、伝えるシステムがコミュニケーション・プロセスの限られたフィードバックか完全な情報を要求できるように、可変解決をサポートするはずです。 この管理水準はセクション4.3で説明されたプロトコルディスカバリープロセスを大いに容易にするでしょう。 しばらくと伝えていない目的地にパケットを送るとき、例えば、「マルチ-プロトコル」システムは最大限度のフィードバックを要求するかもしれません。 この「新しい」目的地へのわずかな最初のパケットの後に、システムは限られたフィードバックに戻って戻るでしょう、ネットワークフィードバック・メカニズムで運用資金を開けて。
Finally, it is important that the information provided by the
feedback mechanism be available outside the IPng implementation.
In multiprotocol networks it is often the case that the solution
to a communication problem requires an adjustment in one of the
protocols outside the network layer. In order for this to happen,
the other protocols must be able to access and interpret these
feedback messages.
最終的に、フィードバック・メカニズムによって提供された情報がIPng実装の外で利用可能であることは、重要です。 「マルチ-プロトコル」ネットワークでは、しばしば、意思疎通の問題への解決はネットワーク層の外でプロトコルの1つにおける調整を必要とします。 これが起こるように、他のプロトコルは、これらのフィードバックメッセージにアクセスして、解釈できなければなりません。
o MTU Discovery or Fragmentation
o MTU発見か断片化
A form of multiprotocol support that has long been a part of
networking is the use of diverse data link and physical layers.
One aspect of this support that affects the network layer is the
different Maximum Transmission Units (MTU) used by various media
formats. For efficiency, many protocols will attempt to avoid
fragmentation at intermediate nodes by using the largest packet
size possible, without exceeding the minimum MTU along the route.
To achieve this, a network protocol performs MTU discovery to find
the smallest MTU on a path.
長い間ネットワークの一部である「マルチ-プロトコル」サポートのフォームはさまざまのデータ・リンクと物理的な層の使用です。 ネットワーク層に影響するこのサポートの1つの局面が様々なメディア形式によって使用される異なったMaximum Transmission Units(MTU)です。 効率のために、多くのプロトコルが、中間的ノードで可能な最も大きいパケットサイズを使用することによって断片化を避けるのを試みるでしょう、ルートに沿って最小のMTUを超えていなくて。 これを達成するなら、ネットワーク・プロトコルは、経路で最も小さいMTUを見つけるためにMTU発見を実行します。
Clark, Ammar & Calvert [Page 8] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[8ページ]RFC1683Multiprotocol相互運用性
The choice of mechanism for dealing with differing MTUs is also
important when doing conversion or tunneling with multiple
protocols. When tunneling is performed by an intermediate node,
the resulting packets may be too large to meet the MTU
requirements. Similarly, if conversion at an intermediate node
results in a larger protocol header, the new packets may also be
too large. In both cases, it may be desirable to have the source
host reduce the transmission size used in order to prevent the
need for additional fragmentation. This information could be sent
to the source host as part of the previously described feedback
mechanism or as an additional MTU discovery message.
また、変換するか、または複数のプロトコルでトンネルを堀るとき、異なったMTUsに対処するためのメカニズムの選択も重要です。 トンネリングが中間的ノードによって実行されるとき、結果として起こるパケットはMTU必要条件を満たすことができないくらい大きいかもしれません。 また、同様に、中間的ノードでの変換が、より大きいプロトコルヘッダーをもたらすなら、新しいパケットも大き過ぎるかもしれません。 どちらの場合も、送信元ホストに追加断片化の必要性を防ぐのに使用されるトランスミッションサイズを減少させるのは、望ましいかもしれません。 以前に説明されたフィードバック・メカニズムの一部として、または、追加MTU発見メッセージとしてこの情報を送信元ホストに送ることができました。
5.2 Implementation/Deployment Features
5.2 実装/展開機能
o Switching
o 切り換え
We define switching in a protocol as the capability to
simultaneously use more than one different underlying protocol
[1]. In network layer protocols, this implies using different
datalink layers. For example, it may be necessary to select
between the 802.3 LLC and traditional Ethernet interfaces when
connecting a host to an "ethernet" network. Additionally, in some
systems IPng will not be used directly over a datalink layer but
will be encapsulated within another network protocol before being
transmitted. It is important that IPng be designed to support
different underlying datalink services and that it provide
mechanisms allowing IPng users to specify which of the available
services should be used.
私たちは同時に1つ以上の異なった基本的なプロトコル[1]を使用する能力とプロトコルにおける切り換えを定義します。 ネットワーク層プロトコルで、これは、異なったデータリンクを使用するのが層にされるのを含意します。 「イーサネット」ネットワークにホストを接続するとき、例えば、802.3LLCと伝統的なイーサネットの間でインタフェースを選択するのが必要であるかもしれません。 さらに、IPngはいくつかのシステムでは、データリンク層の直接上で使用されませんが、伝えられる前に別のネットワーク・プロトコルの中でカプセル化されるでしょう。 IPngが異なった基本的なデータリンクサービスをサポートするように設計されていて、IPngユーザが、営業品目のどれが使用されるべきであるかを指定できるメカニズムを提供するのは、重要です。
o Directory Service Requirements
o ディレクトリサービス要件
While not specifically a part of the IPng protocol, it is clear
that the future Internet will include a directory service for
obtaining address information for IPng. In light of this, there
are some features of the directory service that should be
considered vis-a-vis their support for multiple protocols.
明確にIPngプロトコルの一部でない間、将来のインターネットがIPngのためのアドレス情報を得るためのディレクトリサービスを含んでいるのは、明確です。 これの観点から、彼らの複数のプロトコルのサポートと向かいあって考えられるべきであるディレクトリサービスのいくつかの特徴があります。
First, the directory service should be able to distribute address
formats for several different protocol families, not just IPng and
IPv4. This is necessary for the use of tunneling, conversion, and
the support of multiprotocol systems. Second, the directory
service should include support for distributing protocol
configuration information in addition to addressing information
for the network hosts. This feature will support the protocol
determination task to be carried out by multiprotocol systems [2].
まず最初に、ディレクトリサービスはIPngとIPv4だけではなく、いくつかの異なったプロトコルファミリーのためにアドレス形式を分配するはずであることができます。 これがトンネリングの使用、変換、および「マルチ-プロトコル」システムのサポートに必要です。2番目に、ディレクトリサービスはネットワークホストのために情報を扱うことに加えてプロトコル設定情報を分配するサポートを含めるはずです。 「マルチ-プロトコル」システム[2]によって行われるように、この特徴はプロトコル決断タスクをサポートするでしょう。
Clark, Ammar & Calvert [Page 9] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[9ページ]RFC1683Multiprotocol相互運用性
6. Conclusion
6. 結論
Future networks will incorporate multiple protocols to meet diverse user requirements. Because of this, we are likely to find that a significant portion of the traffic in the Internet will not be from single-protocol communications (e.g., TCPng/IPng). This will not just be true of near term, transitional networks but will remain as a reality for most of the Internet. As we pursue the selection of IPng, we should consider the special needs of multiprotocol networks. In particular, IPng should include mechanisms to handle mixed protocol traffic that includes tunneling, conversion, and multiprotocol end-systems.
将来のネットワークは、さまざまのユーザ要件を満たすために複数のプロトコルを取り入れるでしょう。 これのために、私たちはインターネットのトラフィックの重要な部分がただ一つのプロトコルコミュニケーション(例えば、TCPng/IPng)から来ていないのがわかりそうです。 これは、短期間、過渡的なネットワークに関してただ本当ではありませんが、インターネットの大部分の現実のものとして残るでしょう。 IPngの選択を追求するとき、私たちは「マルチ-プロトコル」ネットワークの特別な必要性を考えるべきです。 特に、IPngは、トンネルを堀るのを含んでいる複雑なプロトコルトラフィック、変換、および「マルチ-プロトコル」エンドシステムを扱うためにメカニズムを含んでいるはずです。
7. Acknowledgments
7. 承認
The authors would like to acknowledge the support for this work by a grant from the National Science Foundation (NCR-9305115) and the TRANSOPEN project of the Army Research Lab (formerly AIRMICS) under contract number DAKF11-91-D-0004.
作者は契約番号DAKF11-91-D-0004の下で交付金で陸軍Research Lab(以前AIRMICS)の国立科学財団(NCR-9305115)とTRANSOPENプロジェクトからこの仕事のサポートを承諾したがっています。
8. References
8. 参照
[1] Clark, R., Ammar, M., and K. Calvert, "Multi-protocol
architectures as a paradigm for achieving inter-operability", In
Proceedings of IEEE INFOCOM, April 1993.
[1] クラーク、R.、Ammar、M.、およびK.カルバート、「相互運用性を達成するためのパラダイムとしてのマルチプロトコル構造」、IEEE INFOCOM(1993年4月)のIn Proceedings。
[2] Clark, R., Calvert, K. and M. Ammar, "On the use of directory
services to support multiprotocol interoperability", To appear in
proceedings of IEEE INFOCOM, 1994. Technical Report GIT-CC-93/56,
College of Computing, Georgia Institute of Technology, ATLANTA,
GA 30332-0280, August 1993.
[2] クラークとR.とカルバートとK.とM.Ammar、「「マルチ-プロトコル」相互運用性を支持する電話番号案内の使用」、ToはIEEE INFOCOM、1994年の議事に載っています。 技術報告書GIT CC93/56、コンピューティングの大学、ジョージア工科大学、アトランタ、ジョージア30332-0280 1993年8月。
[3] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: the SIPP
Interoperability and Transition Mechanism, Work in Progress,
November 1993.
[3] ギリガン、R.、Nordmark、E.、およびB.Hinden、「IPAE:」 SIPP相互運用性と変遷メカニズム、処理中の作業、1993年11月。
[4] Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC
1560, USRA, IBM, December 1993.
[4] Leiner、B.とY.Rekhter、「Multiprotocolインターネット」RFC1560、USRA、IBM、1993年12月。
[5] McLaughlin, L., "Standard for the Transmission of 802.2 Packets
over IPX Networks", RFC 1132, The Wollongong Group, November
1989.
[5] マクラフリン、L.、「IPXネットワークの上の802.2のパケットのトランスミッションの規格」、RFC1132、ウォロンゴンは1989年11月に分類されます。
[6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[6]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
Clark, Ammar & Calvert [Page 10] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[10ページ]RFC1683Multiprotocol相互運用性
[7] Mockapetris, P., "Domain Names - Implementation and
Specification. STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[7]Mockapetris、P.、「ドメイン名--、実現と仕様、」 STD13、USC/情報科学が1987年11月に設けるRFC1035。
[8] Padlipsky, M., Gateways, Architectures, and Heffalumps", RFC 875,
MITRE, September 1982.
「[8]Padlipsky、M.、ゲートウェイ、構造、およびHeffalumps」、RFC875、斜め継ぎ、9月1982
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[9] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、科学が1981年9月に設けるUSC/情報。
[10] Provan, D., "Tunneling IPX Traffic Through IP Networks", RFC
1234, Novell, Inc., June 1991.
[10]Provan、D.、「IPネットワークを通したトンネリングIPX交通」、RFC1234、ノベルInc.、1991年6月。
[11] Rose, M., "The Open Book", Prentice-Hall, Englewood Cliffs, New
Jersey, 1990.
[11] ローズ、M.、「ざっくばらんな人」、新米のホール、イングルウッドがけ、ニュージャージー、1990。
[12] Rose, M., "The ISO Development Environment User's Manual -
Version 7.0.", Performance Systems International, July 1991.
[12] ローズ、M.、「ISO開発環境ユーザマニュアル--、バージョン、7.0」、国際言語運用機構、7月1991
[13] Rose, M., and D. Cass, "ISO Transport Services on top of the
TCP", STD 35, RFC 1006, Northrop Research and Technology Center,
May 1987.
[13] ローズ、M.とD.キャス、「TCPの上のISO Transport Services」STD35とRFC1006、ノースロップResearchとTechnologyセンター(1987年5月)。
[14] Tennenhouse, D., "Layered multiplexing considered harmful", In
IFIP Workshop on Protocols for High-Speed Networks. Elsevier, May
1989.
[14]Tennenhouse、D.、「有害であると考えられた層にされたマルチプレクシング」、High-速度NetworksのためのプロトコルのIn IFIP Workshop。 1989年5月のElsevier。
[15] Ullmann, R., "CATNIP: Common architecture technology for next-
generation internet protocol", Work in Progress, October 1993.
[15] ウルマン、R.、「キャットニップ:」 「次の世代インターネットプロトコルのための一般的な構造技術」、Progress、1993年10月のWork。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Clark, Ammar & Calvert [Page 11] RFC 1683 Multiprotocol Interoperability In IPng August 1994
クラーク、IPng1994年8月のAmmarとカルバート[11ページ]RFC1683Multiprotocol相互運用性
10. Authors' Addresses
10. 作者のアドレス
Russell J. Clark College of Computing Georgia Institute of Technology Atlanta, GA 30332-0280
ジョージア工科大学アトランタ、ジョージア30332-0280を計算するラッセルJ.クラーク大学
EMail: rjc@cc.gatech.edu
メール: rjc@cc.gatech.edu
Mostafa H. Ammar College of Computing Georgia Institute of Technology Atlanta, GA 30332-0280
ジョージア工科大学アトランタ、ジョージア30332-0280を計算するMostafa H.Ammar大学
EMail: ammar@cc.gatech.edu
メール: ammar@cc.gatech.edu
Kenneth L. Calvert College of Computing Georgia Institute of Technology Atlanta, GA 30332-0280
ジョージア工科大学アトランタ、ジョージア30332-0280を計算するケネスL.カルバート大学
EMail: calvert@cc.gatech.edu
メール: calvert@cc.gatech.edu
Clark, Ammar & Calvert [Page 12]
クラーク、Ammar、およびカルバート[12ページ]
一覧
スポンサーリンク
