RFC1223 日本語訳
1223 OSI CLNS and LLC1 protocols on Network Systems HYPERchannel. J.M.Halpern. May 1991. (Format: TXT=29601 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Halpern
Request for Comments: 1223 NSC
May 1991
コメントを求めるワーキンググループJ.アルペルンの要求をネットワークでつないでください: 1223 NSC1991年5月
OSI CLNS and LLC1 Protocols on Network Systems HYPERchannel
ネットワーク・システムHYPERchannelの上のオウシCLNSとLLC1プロトコル
Status of this Memo
このMemoの状態
The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment. This document is intended for network planners and implementers who are already familiar with the OSI protocol suite and the techniques used to carry OSI traffic on standard networks such as 802.3.
このドキュメントの意図がプロトコルの完全な議論を提供することであり、テクニックは以前は、Network Systems社のHYPERchannel設備の上でよくOSI CLNSとLLC1データグラム(そして、どんな関連より高い平らなプロトコルも)を送っていました。 このドキュメントは802.3などの標準のネットワークで既にOSIトラフィックを運ぶのに使用されるOSIプロトコル群とテクニックに詳しいネットワーク立案者とimplementersのために意図します。
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Table of Contents
目次
Goals of this Document . . . . . . . . . . . . . . . . . . . . . 1
HYPERchannel Network Messages . . . . . . . . . . . . . . . . . . 2
Message Proper Header . . . . . . . . . . . . . . . . . . . . . 3
TO Addresses and Open Driver Architecture . . . . . . . . . . . 8
Broadcasting . . . . . . . . . . . . . . . . . . . . . . . . . . 9
ES-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Security Considerations . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
このDocument. . . . . . . . . . . . . . . . . . . . . 1HYPERchannel Network Messages. . . . . . . . . . . . . . . . . . 2Message Proper Header. . . . . . . . . . . . . . . . . . . . . 3TO AddressesとオープンDriver Architecture. . . . . . . . . . . 8Broadcastingの目標…; 9、ES存在、.9、-、.11の参照箇所. . . . . . . . . . . . . . . . . . . . . . . . . . 12のセキュリティ問題. . . . . . . . . . . . . . . . . . . . 12作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 12
Goals of this Document
このDocumentの目標
In this document, we have three major technical objectives:
本書では、私たちには、3つの主要な技術的目標があります:
1. To standardize the encapsulation of LLC1 packets over
HYPERchannel. The format will be used for OSI CLNS and for
any other protocols using LLC1 over HYPERchannel. (Note
that if one desires to use the LLC1/SNAP combination for
TCP/IP, this is the format to use. This represents an
alternative to the native mode for TCP/IP over HYPERchannel,
allowing for sharing the medium at the LLC1 layer.)
1. HYPERchannelの上でLLC1パケットのカプセル化を標準化するために。 形式は、OSI CLNSといかなる他のプロトコルにもHYPERchannelの上でLLC1を使用することで使用されるでしょう。 (人が、TCP/IPにLLC1/SNAP組み合わせを使用することを望んでいるなら、これが使用する形式であることに注意してください。 これはHYPERchannelの上のTCP/IPのためにネイティブモードへの代替手段を表します、LLC1層で媒体を共有すると考慮して。)
Halpern [Page 1] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[1ページ]RFC1223OSIとLLC1
2. To describe how multicast protocols such as ES-IS and IS-IS shall
operate over HYPERchannel. As a medium, HYPERchannel does not
support either broadcast or multicast. Therefore, special
techniques are needed to handle these protocols. Note that these
techniques do not allow general multicast, although any specific
problem may be solved by a generalization of these methods.
2. そして、その方法を説明する、マルチキャストプロトコル、ある、ES-、HYPERchannelの上で作動するでしょう。 媒体として、HYPERchannelは放送かマルチキャストのどちらかをサポートしません。 したがって、特殊技術が、これらのプロトコルを扱うのに必要です。 これらのテクニックが一般的なマルチキャストを許容しないことに注意してください、どんな特定の問題もこれらのメソッドの一般化で解決されるかもしれませんが。
3. To make use of a standardized "message type" field in bytes
8 and 9 of the HYPERchannel network message. To permit better
interoperability, NSC maintains a "network protocol registry"
where any interested party may obtain a unique value in byte 8
(or bytes 8 and 9) for their own public, private, commercial or
proprietary protocol. Lists of assigned protocol type numbers
and their "owners" would be periodically published by NSC and
are available to interested parties.
3. 標準化された「メッセージタイプ」を利用するには、バイトで、8と9つのHYPERchannelネットワークメッセージをさばいてください。 より良い相互運用性を可能にするために、NSCはどんな利害関係者もバイト8(または、バイト8と9)におけるユニークな値をそれら自身の公共の、そして、個人的なコマーシャルか固有のプロトコルに得るかもしれない「ネットワーク・プロトコル登録」を維持します。 割り当てられたプロトコル形式数のリストとそれらの「所有者」は、定期的にNSCによって発行されて、利害関係者にとって、利用可能です。
HYPERchannel Network Messages
HYPERchannelネットワークメッセージ
Unlike most datagram delivery systems, the HYPERchannel network message consists of two parts:
ほとんどのデータグラム配信システムと異なって、HYPERchannelネットワークメッセージは2つの部品から成ります:
Message Proper
+--------------------+
| |
| |
| |
| 16-64 bytes |
| |
| |
| |
+--------------------+
メッセージ適切な+--------------------+ | | | | | | | 16-64バイト| | | | | | | +--------------------+
Associated Data
+----------------------------------------------------+
| |
| |
| |
| |
| |
| |
| Unlimited length |
| |
| |
| |
| |
| |
| |
+----------------------------------------------------+
関連データ+----------------------------------------------------+ | | | | | | | | | | | | | 無制限な長さ| | | | | | | | | | | | | +----------------------------------------------------+
Halpern [Page 2] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[2ページ]RFC1223OSIとLLC1
The first part is a message header that can be up to 64 bytes in length. The first 16 bytes contain information required for the delivery of the entire message, and the remainder can be used by higher level protocols. The second part of the message, the "Associated Data," can be optionally included with the message proper. In most cases (transmission over HYPERchannel-50 trunks) the length of the associated data is literally unlimited. Others (such as HYPERchannel-10 or transmission within a local HYPERchannel-50 A400 adapter) limit the size of the Associated Data to 4K bytes. If the information sent can be contained within the Message Proper, then the Associated Data need not be sent.
最初の部分は長さが最大64バイトであるかもしれないメッセージヘッダーです。 最初の16バイトは全体のメッセージの配送に必要である情報を含んでいます、そして、より高い平らなプロトコルは残りを使用できます。 メッセージが適切な状態で任意に、「関連データ」というメッセージの第二部を含むことができます。 多くの場合(HYPERchannel-50トランクスの上のトランスミッション)、関連データの長さは文字通り無制限です。 他のもの(地方のHYPERchannel-50 A400アダプターの中のHYPERchannel-10かトランスミッションなどの)はAssociated Dataのサイズを4Kのバイトに制限します。 Message Properの中に送られた情報を含むことができるなら、Associated Dataを送る必要はありません。
HYPERchannel lower link protocols treat messages with and without Associated Data quite differently; "Message only" transmissions are sent using abbreviated protocols and can be queued in the receiving network adapter, thus minimizing the elapsed time needed to send and receive the messages. When associated data is provided, the HYPERchannel-50 adapters free their logical resources towards driving the host interface and coaxial trunks at maximum speed, so that data can flow through the transmitting channel, the coaxial cable, and the receiving channel concurrently. Thus HYPERchannel-50 can approach the nominal burst speed of the computer host interface when sending large data blocks over an extended period.
HYPERchannelの低いリンク・プロトコルはAssociated Dataのあるなしにかかわらずメッセージを全く異なって扱います。 「メッセージ専用」トランスミッションを簡略化されたプロトコルを使用させて、受信ネットワークアダプターに列に並ばせることができます、その結果、メッセージを送って、受け取るのに必要である経過時間を最小にします。 関連データを提供するとき、最高回転数でホスト・インターフェースと同軸トランクスを運転することに向かってHYPERchannel-50アダプターはそれらの論理的なリソースを解放します、データが同時に伝えるチャンネル、同軸ケーブル、および受信チャンネルで流れることができるように。 長期間の間大きいデータ・ブロックを送るとき、したがって、HYPERchannel-50はコンピュータホスト・インターフェースの名目上の炸裂速度にアプローチできます。
Message Proper Header
メッセージの適切なヘッダー
The first 16 bytes of the network Message Proper are examined by the network adapters to control delivery of the network message. The message format is as follows:
ネットワークMessage Properの最初の16バイトはネットワークアダプターによって調べられて、ネットワークメッセージの配送を制御します。 メッセージ・フォーマットは以下の通りです:
Halpern [Page 3] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[3ページ]RFC1223OSIとLLC1
byte Message Proper
+------------------------------------------------------------+
0 | Trunks to Try | Message Flags |
| TO trunks | FROM trunks | |A/D|
+--------------+---------------+-------------------------+---+
2 | TO Domain # | TO Network # |
| | |
+------------------------------+-----------------------------+
4 | TO Unit # | Logical To |
| | (port number) |
+------------------------------+-----------------------------+
6 | From Unit # | Logical From |
| | (port number) |
+------------------------------+-----------------------------+
8 | Message type |
| 0x0B01 |
+------------------------------+-----------------------------+
10 | FROM Domain # | FROM Network # |
| | |
+------------------------------+-----------------------------+
12 | True Unit | age count |
| | |
+------------------------------+-----------------------------+
14 | Header End Offset | Next Header Offset |
| (16) | (16) |
+------------------------------+-----------------------------+
16 | LLC1 destination SAP | LLC1 source SAP |
| (0xFE for CLNP) | (0xFE for CLNP) |
+------------------------------+-----------------------------+
18 | LLC1 function code | |
| (0x03 for normal data) |Start of upper layer protocol|
+------------------------------+ +
20 | from bytes 19-63 of the message proper |
| and continuing in the associated data |
| (For OSI this is CLNP, then transport etc.) |
+------------------------------+-----------------------------+
バイトメッセージ適切な+------------------------------------------------------------+ 0 | 試すトランクス| メッセージ旗| | TOトランクス| FROMトランクス| |/D| +--------------+---------------+-------------------------+---+ 2 | ドメイン#に| ネットワーク#に| | | | +------------------------------+-----------------------------+ 4 | ユニット#に| 当然| | | (ポートナンバー) | +------------------------------+-----------------------------+ 6 | ユニット#から| 当然| | | (ポートナンバー) | +------------------------------+-----------------------------+ 8 | メッセージタイプ| | 0x0B01| +------------------------------+-----------------------------+ 10 | ドメイン#から| ネットワーク#から| | | | +------------------------------+-----------------------------+ 12 | 本当のユニット| 時代カウント| | | | +------------------------------+-----------------------------+ 14 | ヘッダー終わりのオフセット| 次のヘッダーは相殺しました。| | (16) | (16) | +------------------------------+-----------------------------+ 16 | LLC1の目的地SAP| LLC1ソースSAP| | (CLNPのための0xFE) | (CLNPのための0xFE) | +------------------------------+-----------------------------+ 18 | LLC1機能コード| | | (正常なデータのための0×03) |上側の層のプロトコルの始まり| +------------------------------+ + 20 | メッセージ自体のバイト19-63から| | そして、関連データでは続くこと。| | (OSIに関して、これは輸送の当時のCLNPですなど) | +------------------------------+-----------------------------+
Trunks to Try
試すトランクス
Consists of two four bit masks indicating which of four possible HYPERchannel-50 coaxial data trunks are to be used to transmit the message and to return it. If a bit in the mask is ON, then the adapter firmware will logically AND it with the mask of installed trunk interfaces and use the result as a candidate list of interfaces.
4個の可能なHYPERchannel-50同軸データトランクスのどれがメッセージを送って、それを返すのに使用されることになっていたらよいかを示す4ビットの2個のマスクから成ります。 ONがマスクに少しあると、アダプターファームウェアは論理的に使用になるでしょう、そして、インストールされたトランクのマスクに接続します、そして、インタフェースの候補リストとして結果を使用してください。
Whenever one of the internal "frames" are sent to communicate with
いつ、「フレーム」がコミュニケートするために送られる内部の1つ
Halpern [Page 4] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[4ページ]RFC1223OSIとLLC1
the destination adapter, the transmission hardware electronically selects the first non-busy trunk out of the list of candidates. Thus selection of a data trunk is best performed by the adapter itself rather than by the host. Dedicating trunks to specific applications only makes sense in very critical real time applications such as streaming data directly from high speed overrunable peripherals.
目的地アダプターであり、トランスミッションハードウェアは候補のリストから最初の非忙しいトランクを電子的に選択します。 したがって、データトランクの選択はホストでというよりむしろアダプター自体によって最も上手に実行されます。 特定のアプリケーションにトランクスを捧げるのが直接高速オーバラン可能周辺機器からのストリーミングのデータなどの非常に重要なリアルタイムのアプリケーションで理解できるだけです。
A second Trunk mask is provided for the receiving adapter when it sends frames back to the transmitter, as it is possible to build asymmetric configurations of data trunks where trunk 1 on one box is connected to the trunk 3 interface of a second. Such configurations are strongly discouraged, but the addressing structure supports it if needed.
フレームを送信機に送り返すとき、2番目のTrunkマスクを受信アダプターに提供します、1個の箱のトランク1が1秒のトランク3インタフェースに接続されるデータトランクスの非対称の構成を築き上げるのが可能であるときに。 そのような構成は強くがっかりしていますが、必要であるなら、アドレシング構造はそれをサポートします。
The "trunks to try" field is only used by HYPERchannel-50. To assure maximum interoperability, a value of 0xFF should be placed in this field to assure delivery over any technology. The newer DX series units determine the trunk mask on their own, but this field is preserved for use with A series equipment.
「試すトランクス」分野はHYPERchannel-50によって使用されるだけです。 最大限のインターオペラビリティを保証するなら、0xFFの値は、どんな技術の上の配送を保証するためにこの分野に置かれるべきです。 より新しいDXシリーズ単位は一人でトランクマスクを決定しますが、この分野はAシリーズ設備による使用のために保持されます。
Message Flags
メッセージ旗
Contains options in message delivery. There are several bits defined by the hardware. However, only the A/D bit will be described here. Other bits are used only for special diagnostic or management purposes. If there is a need to set them, check the specific Network Systems manuals on their meanings. In the absence of such need, all bits other than A/D shall be set to zero on transmission, and not examined upon receipt of a message.
メッセージ配送におけるオプションを含んでいます。 ハードウェアによって定義された数ビットがあります。 しかしながら、A/Dビットだけがここで説明されるでしょう。 他のビットは特別な病気の特徴か管理目的にだけ使用されます。 それらを設定する必要があれば、それらの意味の特定のNetwork Systemsマニュアルをチェックしてください。 そのような必要性がないとき、A/D以外のすべてのビットが、トランスミッションのゼロに設定されて、メッセージを受け取り次第調べられるというわけではないものとします。
ASSOCIATED DATA PRESENT (A/D) is ON if an Associated Data block follows the Message Proper. 0 if only a message proper is present in the network message. The value of this bit is enforced by the network adapter firmware.
Associated DataブロックがMessage Properに続くなら、ASSOCIATED DATA PRESENT(/D)はONです。 0 メッセージ自体がネットワークメッセージに存在してさえいる場合、よかったでしょう。 このビットの価値はネットワークアダプターファームウェアによって励行されます。
TO Domain Number
ドメイン番号に
This is the most significant byte of the four byte hyperchannel address. It selects an NSC addressing domain, among a set of domains. If this and the network number both refer to the local domain and network, they may be set to 0.
これは4バイトの「超-チャンネル」アドレスの最も重要なバイトです。 それはドメインのセットの中でNSCアドレス指定領域を選択します。 これとネットワーク・ナンバーがともに局所領域とネットワークを示すなら、それらは0に設定されるかもしれません。
TO Network Number
ネットワーク・ナンバーに
This is the destination network number. It identifies the network within the selected domain, where the destination unit resides. If the destination is in the local domain and network, both the TO domain and TO network numbers may be set to zero.
これは目的地ネットワーク・ナンバーです。 それは選択されたドメインの中でネットワークを特定します。そこでは、目的地ユニットがあります。 局所領域とネットワークに目的地があるなら、TOドメインとTOネットワーク・ナンバーの両方がゼロに設定されるかもしれません。
Halpern [Page 5] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[5ページ]RFC1223OSIとLLC1
TO Unit
ユニットに
Upon arrival at the destination domain and network, this is the unit number of the destination HYPERchannel adapter. The combination of Domain, Network, and Unit uniquely identify a single adapter in a HYPERchannel network. For compatibility with existing HYPERchannel equipment, when sending a message to a destination outside the local domain and network, set this byte to 0, and store the actual destination unit number in the True Unit field.
目的地ドメインとネットワークへの到着のときに、これは目的地HYPERchannelアダプターのユニット番号です。 Domainの組み合わせ、Network、およびUnitはHYPERchannelネットワークで唯一単一のアダプターを特定します。 既存のHYPERchannel設備との互換性には、局所領域とネットワークの外でメッセージを目的地に送るときにはこのバイトを0に設定してください、そして、True Unit分野に実際の目的地ユニット番号を保存してください。
Logical To
当然
This field further identifies which process the message is intended for. With some hardware, the bottom bits select a machine from among several. When sending a message to an N400, the bottom two bits of this field select which of four attached hosts the message is destined for. Within a host, the logical to field selects a destination process. This is used in conjunction with the Message Type field to insure that messages are delivered to the correct place. The Logical TO field identifies a process, which then checks the Message Type to insure that it understands the message. This also allows for running two processes, both of which understand the same protocol.
この分野は、メッセージがどのプロセスに関して意図するかをさらに特定します。 何らかのハードウェアで、下部ビットは数個からマシンを選択します。 メッセージを送るときには、N400、この2ビットがさばく下部に、メッセージが4人の付属ホストのどれにおいて運命づけられているかを選択してください。 ホストの中では、さばく論理型は目的地プロセスを選択します。 これは、メッセージが正しい場所に提供されるのを保障するのにMessage Type分野に関連して使用されます。 Logical TO分野はプロセスを特定します。(次に、それは、メッセージを理解しているのを保障するためにMessage Typeをチェックします)。 また、これは、2つのプロセスを実行すると考慮します。その両方が同じプロトコルを理解しています。
From Unit
ユニットから
This identifies the Unit number from which this message was sent.
これはこのメッセージが送られたUnit番号を特定します。
Logical From
当然
This identifies the host and process who originated this message.
これはこのメッセージを溯源したホストとプロセスを特定します。
Message Type
メッセージタイプ
The following two bytes are reserved for NSC. Users have been encouraged to put a zero in byte 8 and anything at all in byte 9 so as to not conflict with internal processing of messages by NSC firmware. In the past, this field has been loosely defined as carrying information of interest to NSC equipment carrying the message and not as a formal protocol type field. For example, an 0xFF00 in bytes 8 and 9 of the message will cause the receiving adapter to loop back the message without delivering it to the attached host.
以下の2バイトはNSCのために予約されます。 ユーザがNSCファームウェアでメッセージの内部の処理と衝突しないようにバイト9におけるバイト8ととにかく何にでもゼロを入れるよう奨励されました。 過去に、この分野は緩く正式なプロトコルタイプ分野ではなく、メッセージを伝えながらNSC設備まで興味がある情報を運ぶと定義されました。 例えば、付属ホストにそれを提供しないで、メッセージのバイト8と9で表現される0xFF00は受信アダプターにメッセージを輪にし返させるでしょう。
NSC now uses both bytes 8 and 9 as a formal "protocol type" designator. Major protocols will be assigned a unique value in byte 8 that will (among good citizens) not duplicate a value generated by a different protocol. Minor protocols will have 16 bit values
NSCは現在、正式な「プロトコルタイプ」指示子として両方のバイト8と9を使用します。 異なったプロトコルによって生成された値をコピーしない(善良な市民の中で)バイト8におけるユニークな値は主要なプロトコルに割り当てられるでしょう。 小さい方のプロトコルには、16ビットの値があるでしょう。
Halpern [Page 6] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[6ページ]RFC1223OSIとLLC1
assigned to them so that we won't run out when 256 protocols turn up. Any interested party could obtain a protocol number or numbers by application to NSC. In this document, protocol types specific to OSI LLC1 are assigned. Specifically, the sixteen bit value 0x0B01 in bytes 8 and 9 shall identify LLC1 packets.
256のプロトコルが現れるとき、私たちが走るつもりでないように、それらに割り当てられます。 どんな利害関係者もNSCへのアプリケーションでプロトコル番号か数を得ることができるでしょう。 本書では、OSI LLC1に特定のプロトコルタイプは選任されます。 明確に、バイト8と9で表現される16ビットの値の0x0B01はLLC1パケットを特定するものとします。
True Unit
本当のユニット
This field is used to handle addressing outside of the local domain and network. For compatibility with previous NSC hardware, one may not put the destination unit number in the TO Unit field if the destination domain or network are not the local ones. In that case, one puts zero in the TO Unit field, and puts the destination Unit number into the TRUE unit field. NSC Link devices will adjust the message when it arrives at the destination domain and network so that the destination unit number appears in the TO Unit field.
この分野は、局所領域とネットワークの外でアドレシングを扱うのに使用されます。 前のNSCハードウェアとの互換性のために、目的地ドメインかネットワークが地方のものでないなら目的地ユニット番号をTO Unit分野に置かないかもしれません。 その場合、1つは、TO Unit分野にゼロを置いて、TRUEユニット分野に目的地Unit番号を入れます。 目的地ドメインとネットワークに到着するとNSC Linkデバイスがメッセージを調整するので、目的地ユニット番号はTO Unit分野に現れます。
Age Count
時代カウント
This field serves as a "time to live" in that it prevents datagrams from endlessly circulating about in an improperly configured network. Each time a message with this format passes through a bridge, the Age Count is decremented by one. When the result is zero, the message is discarded by the bridge. Therefore, this byte should be set to 255 when a message is originated, and ignored when a message is received.
この分野は「生きる時間」として周囲で不適切に構成されたネットワークで際限なく循環するのからのデータグラムを防ぐという点で機能します。 この形式があるメッセージがブリッジを通り抜けるたびにAge Countは1つ減少します。 結果がゼロであるときに、メッセージはブリッジによって捨てられます。 したがって、メッセージが受信されているとき、メッセージが溯源されて、無視されるとき、このバイトは255に設定されるべきです。
Next Header Offset and Header End Offset
次のヘッダーは相殺しました、そして、ヘッダーエンドは相殺されました。
These fields are used by the hardware to determine if any special addressing is present. No special addressing forms are permitted in conjunction with LLC1. Therefore, these fields shall always be set to 16. Receivers may count on the LLC1 information beginning at offset 16 in the message proper.
これらの分野はハードウェアによって使用されて、何か特別なアドレシングが存在しているかどうか決定します。 どんな特別なアドレシングフォームもLLC1に関連して受入れられません。 したがって、これらの分野はいつも16に設定されるものとします。 受信機は、LLC1情報がメッセージ自体のオフセット16時に始まるのを頼りにするかもしれません。
LLC1 Data
LLC1データ
The LLC1 Information begins at byte 16 of the message, for 3 bytes. The contains the LLC1 destination and source SAPs, followed by the LLC1 type identifier (usually 03 for unnumbered information.)
LLC1情報はメッセージの3バイトバイト16で始まります。 LLC1の目的地とソースSAPsを含んでいます、続いて、LLC1タイプ識別子を含みます。(無数の情報のための通常03。)
Higher Layer Protocol Data
より高い層のプロトコルデータ
Higher layer protocol information follows immediately after the LLC1 header in the message proper, and flows into the associated data. For purposes of this document, this is OSI CLNP, but it may be any protocol which uses LLC1.
より高い層のプロトコル情報は、LLC1ヘッダー直後メッセージ自体で続いて、関連データに流れます。 このドキュメントの目的のために、これはOSI CLNPですが、それはLLC1を使用するどんなプロトコルであるかもしれません。
Halpern [Page 7] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[7ページ]RFC1223OSIとLLC1
TO Addresses and Open Driver Architecture
アドレスと開いているドライバーアーキテクチャに
Since not all 16 bits of the TO address are used for the physical delivery of the network message, the remainder are considered "logical" in that their meaning is physically determined by host computer software or (in cases such as the FIPS data channel) by hardware in the host interface.
TOアドレスのすべての16ビットがネットワークメッセージの物理的な配送に使用されるというわけではないとき、それらの意味が物理的にハードウェア的にホストコンピュータソフトウェアか(FIPSデータなどのケースが向けるコネ)決定しているので、残りはホスト・インターフェースで「論理的である」と考えられます。
Since HYPERchannel is and will be used to support a large variety of general and special purpose protocols, it is desirable that several independent protocol servers be able to independently share the HYPERchannel network interface. The implementation of many of NSC's device drivers as well as those of other parties (such as Cray Research) support this service. Each protocol server that wishes to send or receive HYPERchannel network messages logically connects to a HYPERchannel device driver by specifying the complete 16 bit TO address it will own in the sense that any network message with that TO address will be delivered to that protocol server.
HYPERchannelがあって、さまざまな一般的で特別な目的がプロトコルであるとサポートするのに使用されるので、いくつかの独立しているプロトコルサーバが独自にHYPERchannelネットワーク・インターフェースを共有できるのは、望ましいです。 相手(クレイリサーチなどの)のものと同様にNSCのデバイスドライバの多くの実装はこのサービスをサポートします。 HYPERchannelネットワークメッセージを送りたいか、または受け取りたがっているそれぞれのプロトコルサーバが、HYPERchannelデバイスドライバにそれがそのTOアドレスがあるどんなネットワークメッセージもそのプロトコルサーバに提供されるという意味で所有している16ビットの完全なTOアドレスを指定することによって、論理的に接続します。
The logical TO field serves a function similar to the TYPE byte in the Ethernet message header, but differs from it in that the width of the logical TO field varies from host to host, and that no values of the logical TO address are reserved for particular protocols. On the other hand, it is possible to have several "identical" protocols (such as two independent copies of OSI with different HYPERchannel addresses) sharing the same physical HYPERchannel interface. This makes NSC's addressing approach identical to the OSI concept that the protocol server to reach is embedded within the address, rather than the IP notion of addressing a "host" and identifying a server through a message type.
論理的なTO分野は、イーサネットメッセージヘッダーでTYPEバイトと同様の機能を果たしますが、ホストによって論理的なTO分野の幅が異なるという点においてそれと異なっています、そして、論理的なTOアドレスの値は全く特定のプロトコルのために予約されません。 他方では、いくつかの「同じ」プロトコル(異なったHYPERchannelアドレスがあるOSIの独立しているコピー2部などの)を持っているのは、同じ物理的なHYPERchannelインタフェースを共有しながら、可能です。 これで、NSCがアプローチを扱うのが達するプロトコルサーバが「ホスト」を扱って、メッセージタイプでサーバを特定するというIP概念よりむしろアドレスの中で埋め込まれているというOSI概念と同じになります。
Since the HYPERchannel header also has a "message type" field, there is some ambiguity concerning the respective roles of the message type and logical TO fields:
また、HYPERchannelヘッダーには「メッセージタイプ」分野があるので、メッセージタイプと論理的なTO分野のそれぞれの役割に関して何らかのあいまいさがあります:
o The logical TO field is always used to identify the protocol server
which will receive the message. Once a server has specified the
complete TO address for the messages it wishes to receive, the
message will not be delivered to a different protocol server
regardless of the contents of the message type field.
o 論理的なTO分野は、メッセージを受け取るプロトコルサーバを特定するのにいつも使用されます。 サーバがいったんそれが受け取りたがっているメッセージのための完全なTOアドレスを指定すると、メッセージはメッセージタイプ分野のコンテンツにかかわらず異なったプロトコルサーバに提供されないでしょう。
o Although the type field cannot change the protocol server at the
final destination of the message, the type field can be used by
intermediate processes on the network to process the message
before it reaches the server destination. An obvious example
is the 0xFF00 message loopback type function, where network
processing to loop back the message results in nondelivery to
the TO address. In the future, intermediate nodes may process
o タイプ分野はメッセージの最終的な目的地でプロトコルサーバを変えることができませんが、タイプ分野はネットワークの中間的プロセスによって使用されて、サーバの目的地に達する前にメッセージを処理できます。 明白な例はTOアドレスへのメッセージを輪にし返すネットワーク処理が不着損害をもたらすところの0xFF00メッセージループバックタイプ機能です。 将来、中間的ノードは処理するかもしれません。
Halpern [Page 8] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[8ページ]RFC1223OSIとLLC1
in transit messages based on the message type only for purposes
such as security validation, aging of certain datagrams, and
network management.
セキュリティ合法化などの目的のためだけにメッセージに基づいたトランジットメッセージにタイプしてください、あるデータグラム、およびネットワークマネージメントでは、古いです。
Broadcasting
放送
NSC message forwarding protocols use low level link protocols to negotiate transmission of a message to its next destination on the network. Furthermore, NSC network boxes often fan out so that several hosts share the same network transmission equipment as in the A400 adapter. Both these characteristics mean that providing a genuine broadcast capability is not a trivial task, and in fact no NSC technology supports a broadcast capability.
NSCメッセージ推進プロトコルは、ネットワークに関して次の目的地とメッセージの伝達を交渉するのに低い平らなリンク・プロトコルを使用します。 その上、NSCネットワーク箱がしばしば四方八方に広がるので、数人のホストがA400アダプターのように同じネットワーク送信設備を共有します。 これらの特性の両方が、本物の放送能力を提供するのが、些細なタスクでなく、また事実上、どんなNSC技術も放送能力をサポートしないことを意味します。
However, the OSI ES-IS and IS-IS protocols require a broadcast capability to operate. Therefore, in order to support these protocols, some form of broadcast emulation must be used.
そして、しかしながら、ある、OSI ES-、プロトコル、作動する放送能力を必要としてください。 したがって、これらのプロトコルをサポートするために、何らかのフォームの放送エミュレーションを使用しなければなりません。
ES-IS
ES存在
The End System to Intermediate System routing protocol is used by end systems to decide where to send packets. In the specified protocol, multicast messages are used so that end systems learn about intermediate systems, and intermediate systems learn about end systems. End systems normally then transmit any packets, whose correct mac destination is unknown, to a random intermediate system which then forwards the packet and tells the originator where to send future packets.
Intermediate Systemルーティング・プロトコルへのEnd Systemはエンドシステムによって使用されて、パケットをどこに送るかを決めます。 次に、通常、エンドシステムはどんなパケットも伝えます、次に、パケットを送って、将来のパケットをどこに送るかを創始者に言う無作為の中間システムに。指定されたプロトコルマルチキャストメッセージが使用されているので、エンドシステムは中間システムに関して学びます、そして、中間システムはエンドシステムに関して学びます。(パケットの正しいmacの目的地は未知です)。
There are two situations which are distinct but related for support of this protocol over HYPERchannel. These are distinguished by whether or not there are any real intermediate systems on the HYPERchannel network.
異なって、このプロトコルのサポートのためにHYPERchannelの上に関係づけられる2つの状況があります。 いくつかの実際の中間システムがHYPERchannelネットワークにあるかどうかによってこれらは区別されます。
ES-IS with Intermediate Systems
中間システムによるES存在
If there are one or more intermediate systems on the HYPERchannel,
then the behavior is simply to emulate multicast.
1個以上の中間システムがHYPERchannelにあれば、振舞いは単にマルチキャストを見習うことです。
END SYSTEM SUPPORT Each end system is profiled with a list of
intermediate systems on the HYPERchannel. It is desirable but not
necessary that this list be complete, as the future support for
IS-IS will forward the necessary information to all the
intermediate systems. Given the profiled list, whenever the end
system wishes to originate an ESH packet (End System Hello), it
will send individual copies to each intermediate system it knows
about.
END SYSTEM SUPPORT EachエンドシステムはHYPERchannelの上の中間システムのリストで輪郭を描かれます。 すべての中間システムに必要事項を転送するでしょう。それが望ましいのですが、今後のサポートとして完全である必要はない、このリスト-、輪郭を描かれたリストを考えて、エンドシステムがESHパケット(終わりのSystem Hello)を溯源したがっているときはいつも、それは知っている各中間システムに個々のコピーを送るでしょう。
Halpern [Page 9] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[9ページ]RFC1223OSIとLLC1
On most systems, these individual packets should be spaced out in
time so as not to interfere with the normal transmission of OSI
and other HYPERchannel messages. For end systems, an inter-packet
time of 0.1 seconds is probably appropriate.
ほとんどのシステムの上では、これらの個々のパケットは、時間内に、OSIと他のHYPERchannelメッセージの通常の伝達を妨げないように間をおかれるべきです。 エンドシステムにおいて、0.1秒の相互パケット時間はたぶん適切です。
Note that if the End System receives ISH packets (Intermediate
System Hello) from an IS on HYPERchannel not in its static list,
it should add that to the list of systems it will send ESH packets
to. The address of the new intermediate system should be
remembered for the holding time in the ISH, just as with the
normal operation of ES-IS.
End SystemがISHパケット(中間的System Hello)を受けるならそれに注意してください、静的なリストでないところのHYPERchannelでは、それはそれがパケットをESHに送るために望んでいるシステムのリストにそれを追加するべきです。 新しい中間システムのアドレスはISHで把持時間に覚えていられるべきです、ちょうど通常操作のようにES存在
INTERMEDIATE SYSTEMS Intermediate systems on the HYPERchannel
shall also be profiled with the addresses of all the other
intermediate systems on the HYPERchannel. This list is used here
and in the IS-IS protocol. For the IS-IS protocol operation, it
is important that the list be complete.
また、HYPERchannelの上のINTERMEDIATE SYSTEMS IntermediateシステムはHYPERchannelの上の他のすべての中間システムのアドレスで輪郭を描かれるものとします。 このリストが中でここで使用される、-、議定書を作ってください。 -、操作について議定書の中で述べてください、そして、リストが完全であることは、重要です。
The list of intermediate systems is used, with ES-IS, by an
intermediate system only in that it probably is also an end
system. As such, it must send ESH packets to all the other
intermediate systems. (The presumption that an IS is also an ES
is driven by the long term requirements for network management.
If you have an upper layer stack, such as is required for CMIP,
you are an end system.)
中間システムのリストが使用されている、ES存在、それだけの中間システムで、また、それはたぶんエンドシステムです。 そういうものとして、それは他のすべての中間システムへのパケットをESHに送らなければなりません。(推定、それ、また、ESもネットワークマネージメントのための要件という長い期間までに駆動です。 CMIPに必要であるような上側の層のスタックがありましたら、あなたはエンドシステムです。)
Each intermediate system will keep a list of the end systems it
knows about. These are the systems it has received ESH packets
from. Whenever the IS sends ISH packets, it sends them
individually to each ES it has heard from. In addition, it sends
the ISH to any end systems which it believes, on the basis of IS-
IS or other methods, are on the HYPERchannel.
各中間システムはそれが知っているエンドシステムのリストを保つでしょう。 これらはそれがESHパケットを受けたシステムです。 いつ、発信、ISHパケットであり、それは個別に連絡をいただいた各ESにそれらを送るか。 さらに、ベースで信じているどんなエンドシステムにもISHを送る、存在、何らかの、メソッドはHYPERchannelのそうです。
Note that these packets must also be spread out in time to avoid
causing congestion. However, given that the number of these is
much higher than the number generated by End Systems, the time
between transmissions should be selected by the IS developer to
fit the sustainable I/O rates of the system. Make sure you can
get at the very least one, and preferably two or three, useful
packets in between each ISH copy being sent.
また、時間内に混雑を引き起こすのを避けるためにこれらのパケットを広げなければならないことに注意してください。 しかしながら、それを考えて、これらの数がトランスミッションの間のEnd Systems、時間までに発生している数が選択されるべきであるよりはるかに大きい、開発者はシステムの持続可能な入出力率に合うことになっていますか? 1と、望ましくは2か3を必ず少なくとも得ることができてください、送られるそれぞれのISHコピーの間の役に立つパケット。
ES-IS without an Intermediate System
中間システムのないES存在
When there is no intermediate system, one or more systems must
serve as address managers. These are referred to in draft ISO OSI
documents as SNARE, for SubNetwork Address Resolution Entities.
中間システムが全くないとき、1台以上のシステムがアドレスのマネージャとして勤めなければなりません。 これらは草稿ISO OSIドキュメントでSubNetwork Address Resolution EntitiesのためのSNAREに言及されます。
END SYSTEM SUPPORT As in the previous case, each end system must
先の事件、それぞれのエンドシステムのEND SYSTEM SUPPORT Asはそうしなければなりません。
Halpern [Page 10] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[10ページ]RFC1223OSIとLLC1
be profiled with a list of intermediate systems. This list must
contain all of the systems which will be serving as address
managers on this network. The reason for this is that, since the
address managers are not true intermediate systems, they are not
running IS-IS and will not be exchanging lists of end systems they
know about. There may well be several systems for redundancy and
reliability.
中間システムのリストで輪郭を描かれてください。このリストはこのネットワークのアドレスのマネージャとして勤めるシステムのすべてを含まなければなりません。 この理由がアドレスのマネージャが本当の中間システムでないので走っていないということである、-、そして、彼らが知っているエンドシステムのリストを交換しないことである意志。 たぶん、冗長と信頼性の数個のシステムがあるでしょう。
SNARE The systems selected as address managers must appear, to the
other end systems, as intermediate systems. This means that each
one must send out ISH packets to all the end systems which it
hears from. Each of these systems must record all the information
from the ESH packets they receive. When a packet for an End
System is received at a SNARE, it must behave as an IS.
Specifically, it must forward the packet to the correct
destination end system, and send a redirect message back to the
originator, informing the originator of the correct SNPA
(HYPERchannel address) for the end system.
アドレスのマネージャが現れなければならないもう一方の端までシステムはシステムを選択しました、中間システムとして。SNARE、これは、各々がそれが聞くすべてのエンドシステムにISHパケットを出さなければならないことを意味します。 それぞれのこれらのシステムは彼らが受けるESHパケットからすべての情報を記録しなければなりません。 いつとしてSNAREにEnd Systemのためのパケットを受け取って、反応しなければならないか、あります。 明確に、正しい目的地エンドシステムにパケットを送って、創始者への再直接のメッセージ後部を送らなければなりません、エンドシステムのために正しいSNPA(HYPERchannelアドレス)について創始者に知らせて。
Note that these systems are certainly end systems as well, and
must send ESH packets to all the intermediate systems on the IS
list, which must be complete.
これらのシステムが確かにまた、エンドシステムであり、すべての中間システムにオンなパケットをESHに送らなければならないことに注意してください、リスト(完全であるに違いないもの)です。
ES-IS FORMAT SPECIFICATION
ES存在、書式仕様
All ES-IS PDUS shall be formatted as specified in ISO 9542. They
are then sent using LLC1 and the encapsulation specified earlier
in this document for transmitting LLC1 over HYPERchannel.
すべてのES-IS PDUSがISO9542で指定されるようにフォーマットされるものとします。 そして、彼らにより早く本書ではHYPERchannelの上にLLC1を伝えるのに指定されたLLC1とカプセル化を使用させます。
RD PDUS When generating Redirect pdus, which contain HYPERchannel
SNPAs (addresses), the SNPA shall be represented in four bytes.
This shall be used even on a small HYPERchannel network containing
only one domain and one network number.
RD PDUS WhenがRedirect pdus(HYPERchannel SNPAs(アドレス)を含んでいる)を発生させる場合、SNPAは4バイトで表されるものとします。 1つのドメインと1つのネットワーク・ナンバーだけを含んでいて、これは小さいHYPERchannelネットワークでさえ使用されるものとします。
QC FUNCTION There is no support for the ES-IS query configuration
capability when using HYPERchannel. All systems must have at
least one configured intermediate system, which shall be either a
true IS or a SNARE.
QC FUNCTION Thereがサポートでない、ES存在、HYPERchannelを使用するときには構成能力について質問してください。 すべてのシステムには少なくとも1個の構成された中間システムがなければならなくて、どれが本当にaになるかがあります。または、SNARE。
IS-IS
IS-IS
The proposed IS-IS protocol for OSI (DP 10589) when run on a LAN requires broadcast capability. Because of the nature of the process for nominating the designated IS on a LAN, and other special features of this protocol, it is important never to partition the set of intermediate systems on a HYPERchannel network.
提案、-、LANを走ると、OSI(DP10589)のためのプロトコルは放送能力を必要とします。 指名のための過程の本質のために、指定がLAN、およびこのプロトコルの他の特徴にあって、中間システムのセットをHYPERchannelネットワークに決して仕切らないのは重要です。
The implementation therefore is very simple. An intermediate system
したがって、実現は非常に簡単です。 中間システム
Halpern [Page 11] RFC 1223 OSI and LLC1 on HYPERchannel May 1991
HYPERchannel1991年5月のアルペルン[11ページ]RFC1223OSIとLLC1
on HYPERchannel runs the IS-IS protocol directly. However, when it goes to send a message, it consults the profiled list of all level 1 ISs on the HYPERchannel or of all level 2 ISs on the HYPERchannel, and then sends individual copies of the message to each destination. This multiple transmission should be transparent to the IS-IS protocol itself.
HYPERchannel走行、-、直接議定書を作ってください。 しかしながら、メッセージを送りに行くとき、それは、HYPERchannelに関してHYPERchannelの上のレベル1ISsかレベル2ISsの輪郭を描かれたリストに相談して、次に、メッセージの個々のコピーを各目的地に送ります。 この複駆動動力伝達装置がわかりやすいはずである、-、それ自体について議定書の中で述べてください。
Note that as with ES-IS on an intermediate system, it is important to space out the individual message transmissions. On most networks, spacing of 0.1 seconds will work well.
それに注意する、ES存在、中間システムの上では、個々のメッセージ送信の間をおくのは重要です。 ほとんどのネットワークでは、0.1秒のスペースはうまくいくでしょう。
References
参照
+1+ ISO IS 9542 - End system to intermediate system routing
exchange protocol
+1+ISO IS9542--中間システムルーティング交換プロトコルへのエンドシステム
+2+ ISO DP 10589 - Intermediate system to Intermediate system
Infra-Domain routing exchange protocol
+2+ISO DP10589--IntermediateシステムInfra-ドメインルーティング交換プロトコルへの中間システム
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Joel M. Halpern Principal Engineer Network Systems Corporation MS033 7600 Boone Avenue North Brooklyn Park, AN 55428
ジョエル・M.アルペルンPrincipalの技術者ネットワーク・システムの社のMS033 7600のブーンのアベニューの北のブルックリン・パーク、55428
Phone: (612) 424-1606
以下に電話をしてください。 (612) 424-1606
Email: jmh@anubis.network.com
メール: jmh@anubis.network.com
Halpern [Page 12]
アルペルン[12ページ]
一覧
スポンサーリンク
