RFC1374 日本語訳
1374 IP and ARP on HIPPI. J. Renwick, A. Nicholson. October 1992. (Format: TXT=100903 bytes) (Obsoleted by RFC2834) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Renwick
Request for Comments: 1374 A. Nicholson
Cray Research, Inc.
October 1992
IP and ARP on HIPPI
コメントを求めるワーキンググループJ.レンウィックの要求をネットワークでつないでください: HIPPIの上の1374のA.ニコルソンクレイ・リサーチ1992年10月のIPとARP
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks.
ANSI X3T9.3委員会はIEEEのカプセル化のための提案を作成しました。802.2LLC PDUsとHIPPIの上の含意によるIP。 別のX3T9.3草稿はHIPPIの物理的なスイッチの操作について説明します。 X3T9.3は、HIPPIがそれらの規格の範囲の主に外で問題をネットワークでつないでいるままにするのを選びました。 このドキュメントはインターネットの文脈のANSI規格HIPPIハードウェアとプロトコルの使用のメソッドについて議論します、他のネットワークがあるLANとinteroperationとしてHIPPIスイッチの使用を含んでいて。
Table of Contents
目次
Introduction 2
Scope 2
Definitions 3
Equipment 4
Protocol 6
範囲2つの序論2定義3設備4プロトコル6
Packet Format 6
48 bit Universal LAN MAC addresses 10
I-Field Format 11
Rules For Connections 13
MTU 15
Format6 48ビットのパケットUniversal LAN MACは10I-分野Format11Rules Forコネクションズ13MTU15を扱います。
Camp-on 16
Address Resolution 16
陣営進行中の16アドレス解決16
ARP and RARP Message Format 17
ARP Procedure 21
ARP Implementation Methods 22
ARPとRARPメッセージ・フォーマット17ARP手順21ARP実装メソッド22
Renwick & Nicholson [Page 1] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[1ページ]RFC1374IPとARP
ARP Example 23
Discovery of One's Own Switch Address 25
自分自身のスイッチアドレス25のARPの例23の発見
Path MTU Discovery 27
Channel Data Rate Discovery 27
Performance 29
Sharing the Switch 31
Appendix A -- HIPPI Basics 31
Appendix B -- How to Build a Practical HIPPI LAN 37
References 41
Security Considerations 42
Authors' Addresses 42
スイッチ31付録Aを共有する経路MTU発見27チャンネルデータ信号速度発見27パフォーマンス29--HIPPI基礎31付録B--参照41セキュリティ問題42作者のアドレス42を実用的なHIPPI LAN37に造る方法
Introduction
序論
The ANSI High-Performance Parallel Interface (HIPPI) is a simplex data channel. Configured in pairs, HIPPI can send and receive data simultaneously at nearly 800 megabits per second. (HIPPI has an equally applicable 1600 megabit/second option.) Between 1987 and 1991, the ANSI X3T9.3 HIPPI working group drafted four documents that bear on the use of HIPPI as a network interface. They cover the physical and electrical specification (HIPPI-PH [1]), the framing of a stream of octets (HIPPI-FP [2]), encapsulation of IEEE 802.2 LLC (HIPPI-LE [3]), and the behavior of a standard physical layer switch (HIPPI-SC [4]). HIPPI-LE also implies the encapsulation of Internet Protocol[5]. The reader should be familiar with the ANSI HIPPI documents, copies of which are archived at the site "nsco.network.com" in the directory "hippi," and may be obtained via anonymous FTP until they become published standards.
ANSI High-パフォーマンスParallel Interface(HIPPI)はシンプレクスデータ・チャンネルです。 組で構成されていて、HIPPIは同時に、1秒あたりおよそ800のメガビットでデータを送って、受け取ることができます。 (HIPPIには、1600年の等しく適切なメガビット/の2番目のオプションがあります。) 1987年と1991年の間に、ANSI X3T9.3 HIPPIワーキンググループはネットワーク・インターフェースとしてHIPPIの使用を圧迫する4通のドキュメントを作成しました。 標準の物理的な層の動きは切り替わります。そして、彼らが物理的で電気の仕様をカバーする、(HIPPI-ペーハー[1])、八重奏のストリームの縁どり、(HIPPI-FP[2])、IEEE802.2LLCのカプセル化、(HIPPI-LE[3])、(HIPPI-サウスカロライナ[4])。 また、HIPPI-LEはインターネットプロトコル[5]のカプセル化を含意します。 読者はANSI HIPPIドキュメントに詳しいはずです。"hippi"というディレクトリのサイト"nsco.network.com"では、格納されます。公開FTPで発行された規格になるまでそのコピーをそれを入手するかもしれません。
HIPPI switches can be used to connect a variety of computers and peripheral equipment for many purposes, but the working group stopped short of describing their use as Local Area Networks. This memo takes up where the working group left off, using the guiding principle that except for length and hardware header, Internet datagrams sent on HIPPI should be identical to the same datagrams sent on a conventional network, and that any datagram sent on a conventional 802 network[6] should be valid on HIPPI.
多くの目的のためにさまざまなコンピュータと周辺装置を接続するのにHIPPIスイッチを使用できましたが、ワーキンググループは、彼らの使用をローカル・エリア・ネットワークとして記述するまでには至りませんでした。 このメモはワーキンググループがやめられたところに取って、長さとハードウェアヘッダー、インターネットデータグラムを除いて、HIPPIが従来のネットワークで送られた同じデータグラムと同じであるべきであることを転送して、どんなデータグラムも従来の802ネットワーク[6]で送った指導原理を使用するのはHIPPIで有効であるべきです。
Scope
範囲
This memo describes the HIPPI interface between a host and a crosspoint switch that complies with the HIPPI-SC draft standard. Issues that have no impact on host implementations are outside the scope of this memo. Host implementations that comply with this memo are believed to be interoperable on a network composed of a single HIPPI-SC switch. They are also interoperable on a simple point-to- point, two-way HIPPI connection with no switch between them. They
このメモはホストと交差点スイッチとのHIPPI-サウスカロライナ草稿規格に従うHIPPIインタフェースについて説明します。 このメモの範囲の外に影響力を全くホスト導入に持っていない問題があります。 このメモに従うホスト導入が単一のHIPPI-サウスカロライナスイッチで構成されたネットワークで共同利用できさせると信じられています。 また、それらも簡単なポイントからポイント、それらの間のスイッチのない両用HIPPI接続のときに共同利用できます。 それら
Renwick & Nicholson [Page 2] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[2ページ]RFC1374IPとARP
may as well be interoperable on more complex networks, depending on the internals of the switches and how they are interconnected; however, these details are implementation dependent and outside the scope of this memo. To the extent that a gateway acts as a host on a HIPPI-SC LAN, its behavior is within the scope of this memo.
より複雑なネットワークで共同利用できるほうがよいです、スイッチとそれらがどうインタコネクトされるかに関するインターナルによって。 しかしながら実装に依存していて、このメモの範囲の外でこれらの詳細。 ゲートウェイがホストとしてHIPPI-サウスカロライナLANに務めるという範囲には、このメモの範囲の中に振舞いがあります。
Within the scope of this memo are:
このメモの範囲の中に、以下があります。
1. Packet format and header contents, including HIPPI-FP, HIPPI-LE,
IEEE 802.2 LLC[7], SNAP and ARP
1. HIPPI-FP、HIPPI-LE、IEEE802.2LLC[7]、SNAP、およびARPを含むパケット・フォーマットとヘッダーコンテンツ
2. I-Field contents
2. I-分野コンテンツ
3. HIPPI switch address resolution, including self discovery
3. 自己発見を含むHIPPIスイッチアドレス決議
4. Rules for the use of connections.
4. 接続の使用のための規則。
Outside of the scope are
範囲の外に、あります。
1. Vendor dependent solutions for multicast or third party ARP
1. マルチキャストか第三者ARPのためのベンダーに依存するソリューション
2. Network configuration and management
2. ネットワーク・コンフィギュレーションと管理
3. Host internal optimizations
3. 内部の最適化を主催してください。
4. The interface between a host and an outboard protocol processor.
4. ホストと船外のプロトコルプロセッサとのインタフェース。
Definitions
定義
Conventional
Used with respect to networks, this refers to Ethernet, FDDI and
802 LAN types, as distinct from HIPPI-SC LANs.
従来のUsed、ネットワークに関して、これはイーサネット、FDDI、および802のLANタイプをHIPPI-サウスカロライナLANと異なるのに差し向けます。
Destination
The HIPPI implementation that receives data from a HIPPI Source.
目的地、HIPPI Sourceからデータを受け取るHIPPI実装。
Node
An entity consisting of one HIPPI Source/Destination pair that is
connected by parallel or serial HIPPI to a HIPPI-SC switch and
that transmits and receives ARP and IP datagrams. A node may be
an Internet host, bridge, router or gateway. This memo uses the
term node in place of the usual "host" to indicate that a host
might be connected to the HIPPI LAN not directly, but through an
external adaptor that does some of the protocol processing for the
host.
平行であるか連続のHIPPIによってHIPPI-サウスカロライナスイッチとそれに接続される1HIPPI Source/目的地組のノードAn実体の成るのは、ARPとIPデータグラムを送信して、受けます。ノードは、インターネット・ホスト、ブリッジ、ルータまたはゲートウェイであるかもしれません。 このメモは、ホストが直接で接続されるのではなく、ホストのためのプロトコル処理のいくつかをする外部のアダプターを通してHIPPI LANに接続されるかもしれないのを示すのに普通の「ホスト」に代わってノードという用語を使用します。
Renwick & Nicholson [Page 3] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[3ページ]RFC1374IPとARP
Serial HIPPI
An implementation of HIPPI in serial fashion on coaxial cable or
optical fiber, informally standardized by implementor's agreement
in the Spring of 1991.
1991年のSpringでの作成者の同意で非公式に標準化された同軸ケーブルか光ファイバにおける連続のファッションによるHIPPIの連続のHIPPI An実装。
Switch Address
A value used as the address of a node on a HIPPI-SC network. It
is transmitted in the I-field. HIPPI-SC switches may map Switch
Addresses to physical port numbers.
HIPPI-サウスカロライナネットワークのノードのアドレスとして使用されるAddress A価値を切り換えてください。 それはI-分野で伝えられます。 HIPPI-サウスカロライナスイッチは物理的なポートナンバーにSwitch Addressesを写像するかもしれません。
Source
The HIPPI implementation that generates data to send to a HIPPI
Destination.
データを生成するHIPPI実装がHIPPI Destinationに発信すると出典を明示してください。
Universal LAN Address (ULA)
A 48 bit globally unique address, administered by the IEEE,
assigned to each node on an Ethernet, FDDI, 802 network or HIPPI-
SC LAN.
IEEEによって管理された48の噛み付いているグローバルにユニークなアドレスがイーサネット、FDDI、802ネットワークまたはHIPPIサウスカロライナLANの各ノードに割り当てた普遍的なLAN Address(ULA)。
Equipment
設備
A HIPPI network can be composed of nodes with HIPPI interfaces, HIPPI cables or serial links, HIPPI-SC switches, gateways to other networks and, possibly, proprietary equipment that multicasts or responds to ARP requests on behalf of the real nodes.
HIPPIネットワークは、HIPPIインタフェース、HIPPIケーブルまたは連続のリンクにノードを落ち着かせて、HIPPI-サウスカロライナが切り替わって、他のネットワークとことによると特許設備へのゲートウェイがそのマルチキャストであるということであることができるか本当のノードを代表してARP要求に応じます。
Each HIPPI interconnection between a node and a switch shall consist of a pair of HIPPI links, one in each direction.
ノードとスイッチの間のそれぞれのHIPPIインタコネクトは1組のHIPPIリンクから成るものとして、あるコネが各方向です。
If a link between a node and the switch is capable of the 1600 Megabit/second data rate option (i.e. Cable B installed for 64 bit wide operation) in either direction, the node's HIPPI-PH implementation shall also be capable of 32 bit operation (Cable B data suppressed) and shall be able to select or deselect the 1600Mb/s data rate option at the establishment of each new connection.
ノードとスイッチとのリンクは1600年のMegabit/秒データ信号速度オプション(すなわち、幅64ビットの操作のためにインストールされたCable B)がどちらかの方向にできるなら、ノードのHIPPI-ペーハー実装が、それぞれの新しい接続の設立のときに1600Mb/sのデータ信号速度オプションをまた、32ビット演算(抑圧されたケーブルBデータ)ができて、選択するか、または反選択できるでしょう。
The following figure shows a sample HIPPI switch configuration.
以下の図はサンプルHIPPIスイッチ構成を示しています。
Renwick & Nicholson [Page 4] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[4ページ]RFC1374IPとARP
+-----+
| | H 4 |
| +--+--+
| +----+ +----+ +----+ |
| | H1 | | H2 | | H3 | +-++
| +--+ +-++-+ +-++-+ +-++-+ |PP|
+---+H5| || || || ++++
| +--+ || || || ||
| +---++--------++--------++------++----+
| | | +---+
| +----+ | HIPPI-SC +----+ARP|
+---+ G1 +--------+ +----+ |
| | +--------+ Switch | +---+
| +----+ | |
| +---++--------++--------++------++----+
| +--+ || || || ||
+---+H6| || ++++
| +--+ +-++-+ |PP|
| | | +-++
| | G2 | |
| | | +--+--+
| +--+-+ | H 7 |
| | +-----+
|
-----+------------+-------+-----------+-------------+------
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H 8 | | H 9 | | H10 | | H11 |
+-----+ +-----+ +-----+ +-----+
+-----+ | | H4| | +--+--+ | +----+ +----+ +----+ | | | H1| | H2| | H3| +-++ | +--+ +-++-+ +-++-+ +-++-+ |pp| +---+ H5| || || || ++++ | +--+ || || || || | +---++--------++--------++------++----+ | | | +---+ | +----+ | HIPPI-サウスカロライナ+----+ アルプ| +---+ G1+--------+ +----+ | | | +--------+ スイッチ| +---+ | +----+ | | | +---++--------++--------++------++----+ | +--+ || || || || +---+ H6| || ++++ | +--+ +-++-+ |pp| | | | +-++ | | G2| | | | | +--+--+ | +--+-+ | H7| | | +-----+ | -----+------------+-------+-----------+-------------+------ | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H8| | H9| | H10| | H11| +-----+ +-----+ +-----+ +-----+
Legend: ---+---+---+-- = 802 network, Ethernet or FDDI
|| = Paired HIPPI link
H = Host computer
PP = Outboard Protocol Processor
G = Gateway
ARP = ARP Agent
伝説: ---+---+---+--=802ネットワーク、イーサネットまたはFDDI|| = ゲートウェイ船外のプロトコルホストコンピュータ対にされたHIPPIリンクH=PP=Processor G=ARPはARPエージェントと等しいです。
A possible HIPPI configuration
可能なHIPPI構成
A single HIPPI-SC switch has a "non-blocking" characteristic, which means there is always a path available from any Source to any Destination. If the network consists of more than one switch, the path from a Source to a Destination may include a HIPPI link between switches. If this link is used by more than one Source/Destination pair, a "blocking" network is created: one Source may be blocked from access to a Destination because another Source is using the link it shares. Strategies for establishing connections may be more
単一のHIPPI-サウスカロライナスイッチには、「非ブロッキング」の特性があります。(それは、どんなSourceからどんなDestinationまでも利用可能な経路がいつもあることを意味します)。 ネットワークが1個以上のスイッチから成るなら、SourceからDestinationまでの経路はスイッチの間のHIPPIリンクを含むかもしれません。 このリンクが1Source/目的地組以上によって使用されるなら、「ブロッキング」ネットワークは創設されます: 別のSourceがそれが共有するリンクを使用しているので、1SourceがDestinationへのアクセスから妨げられるかもしれません。 関係を樹立するための戦略は、より多いかもしれません。
Renwick & Nicholson [Page 5] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[5ページ]RFC1374IPとARP
complicated on blocking networks than on non-blocking ones.
ネットワークを妨げるとき複雑にされる、非ブロッキングものより。
This memo ignores blocking issues, assuming that the HIPPI LAN consists of one HIPPI-SC switch or, if the network is more complex than that, it presents no additional problems that a node must be aware of.
このメモはブロッキング問題を無視します、HIPPI LANが1個のHIPPI-サウスカロライナスイッチから成るか、またはネットワークがそれより複雑であるならノードが意識しているに違いないどんな追加問題も提示しないと仮定して。
Protocol
プロトコル
Packet Format
パケット・フォーマット
The HIPPI packet format for Internet datagrams shall conform to the HIPPI-FP and HIPPI-LE draft standards. The HIPPI-FP D1_Area shall contain the HIPPI-LE header. The HIPPI-FP D2_Area, when present, shall contain one IEEE 802.2 Type 1 LLC Unnumbered Information (UI) PDU. Support of IEEE 802.2 XID, TEST and Type 2 PDUs is not required on HIPPI, and Destinations that receive these PDUs may either ignore them or respond correctly according to IEEE 802.2 requirements.
インターネットデータグラムのためのHIPPIパケット・フォーマットはHIPPI-FPとHIPPI-LE草稿規格に従うものとします。 HIPPI-FP D1_AreaはHIPPI-LEヘッダーを含むものとします。 存在しているとき、HIPPI-FP D2_Areaは1IEEE802.2のType1LLC Unnumbered情報(UI)PDUを含むものとします。 IEEE802.2XIDのサポート、TESTとType2PDUsはHIPPIで必要でなく、これらのPDUsを受けるDestinationsは彼らを無視するか、またはIEEEによると、802.2の要件を正しく反応させるかもしれません。
The length of a HIPPI packet, including trailing fill, shall be a multiple of eight octets as required by HIPPI-LE.
中詰めを引きずるのを含むHIPPIパケットの長さは必要に応じてHIPPI-LEで8つの八重奏の倍数になるでしょう。
+----------+-----------+---------------------+----------- ------+ | | | | IP . . . 0 - 7 | | HIPPI-FP | HIPPI-LE | IEEE 802.2 LLC/SNAP | octets| |(8 octets)|(24 octets)| (8 octets) | ARP . . . fill | +----------+-----------+---------------------+----------- ------+
+----------+-----------+---------------------+----------- ------+ | | | | IP.0--7| | HIPPI-fp| HIPPI-LE| IEEE802.2LLC/スナップ| 八重奏| |(8つの八重奏)|(24の八重奏)| (8つの八重奏) | ARPはいっぱいになります…。| +----------+-----------+---------------------+----------- ------+
HIPPI Packet Structure
HIPPIパケット構造
HIPPI-FP Header
HIPPI-fpヘッダー
ULP-id (8 bits) shall contain 4.
ULP-イド(8ビット)は4を含むものとします。
D1_Data_Set_Present (1 bit) shall be set.
D1_データ_Set_Presentは用意ができているものとします(1ビット)。
Start_D2_on_Burst_Boundary (1 bit) shall be zero.
_Burst_Boundary(1ビット)の上の始め_D2_はゼロになるでしょう。
Reserved (11 bits) shall contain zero.
予約されて、(11ビット)はゼロを含むものとします。
D1_Area_Size (8 bits) should be sent as 3. Destinations shall
accept any value that HIPPI-FP defines as legal: from 3 to 127
(32 bit HIPPI) or 3 to 255 (64 bit HIPPI).
3としてD1_領域_Sizeを送るべきです(8ビット)。 目的地は、HIPPI-FPが定義するどんな値も法的であると受け入れるものとします: 3〜127(32ビットのHIPPI)か3〜255(64ビットのHIPPI)まで。
D2_Offset (3 bits) may be any value from 0 to 7.
0〜7まで_が相殺したD2(3ビット)はどんな値であるかもしれません。
D2_Size (32 bits) Shall contain the number of octets in the
D2_サイズ(32ビット)は中に八重奏の数を含むものとします。
Renwick & Nicholson [Page 6] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[6ページ]RFC1374IPとARP
IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present. It
shall not exceed 65,288 (decimal). This value includes the
IEEE 802.2 LLC/SNAP header and the IP datagram. It does not
include trailing fill octets. (See "MTU," below.)
IEEE802.2LLC Type1PDU、ゼロはPDUでないなら存在しています。 それは6万5288(10進)を超えていないものとします。 この値はIEEE802.2LLC/SNAPヘッダーとIPデータグラムを含んでいます。 それは、中詰め八重奏を引きずるのを含んでいません。 (以下の"MTU"を見てください。)
The first octet of the IEEE 802.2 LLC PDU (SSAP) shall be
located at offset "n" of the packet, where
IEEE802.2LLC PDU(SSAP)の最初の八重奏はパケットのオフセット「n」、どこに位置するものとするか。
n = 8 + (D1_Area_Size*8) + D2_Offset
+ n=8+(D1_Area_Size*8)D2_Offset
as specified in HIPPI-FP.
HIPPI-FPで指定されるように。
HIPPI-LE Header
HIPPI-LEヘッダー
FC (3 bits) shall contain zero unless otherwise defined by
local administration.
別の方法で地方行政によって定義されない場合、FC(3ビット)はゼロを含むものとします。
Double_Wide (1 bit) shall contain one if the Destination
associated with the sending Source supports 64 bit HIPPI
operation. Otherwise it shall contain zero.
送付Sourceサポート64に関連しているDestinationがHIPPI操作に噛み付いたなら、二重_Wide(1ビット)は1つを含むものとします。 さもなければ、それはゼロを含むものとします。
Message_Type (4 bits) contains a code identifying the type of
HIPPI-LE PDU. Defined values (binary) are:
メッセージ_Type(4ビット)はHIPPI-LE PDUのタイプを特定するコードを含んでいます。 定義された値(バイナリー)は以下の通りです。
0 Data PDU
1 Address Resolution Request PDU (AR_Request)
2 Address Resolution Response PDU (AR_Response)
3 Self Address Resolution Request PDU (AR_S_Request)
4 Self Address Resolution Response PDU (AR_S_Response)
5-11 Reserved by the ANSI X3T9.3 committee
12-15 Locally Assigned
ANSI X3T9.3委員会12-15Locally Assignedによる0データPDU1Address Resolution Request PDU(AR_Request)2Address Resolution Response PDU(AR_Response)3Self Address Resolution Request PDU(_AR_S Request)4Self Address Resolution Response PDU(_AR_S Response)5-11Reserved
Destination_Switch_Address is a 24-bit field containing the
Switch Address of the Destination if known, otherwise zero. If
the address comprises less than 24 bits, it shall be right
justified (occupying the least significant bits) in the field.
そうでなければ、目的地_Switch_Addressは知られているならDestinationのSwitch Addressを含む24ビットの分野、ゼロです。 アドレスが24ビット未満を包括すると、その分野でまさしく正当になるでしょう(最下位ビットを占領します)。
Destination_Address_Type (4 bits) and Source_Address_Type (4
bits) contain codes identifying the type of addresses in the
Destination_Switch_Address and Source_Switch_Address fields
respectively. Defined values (binary) are:
目的地_Address_Type(4ビット)とSource_Address_Type(4ビット)はそれぞれDestination_Switch_Addressのアドレスのタイプを特定するコードとSource_Switch_Address分野を含んでいます。 定義された値(バイナリー)は以下の通りです。
0 Unspecified
1 HIPPI-SC Source Route (24 bits)
2 HIPPI-SC Address (12 bits)
3-11 Reserved by the ANSI X3T9.3 committee
12-15 Locally Assigned
0 ANSI X3T9.3委員会12-15Locally Assignedによる2 1不特定のHIPPI-サウスカロライナSource Route(24ビット)HIPPI-サウスカロライナAddress(12ビット)3-11Reserved
Renwick & Nicholson [Page 7] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[7ページ]RFC1374IPとARP
Source_Switch_Address is a 24-bit field containing the Switch
Address of the Source. If the address comprises less than 24
bits, it shall be right justified (occupying the least
significant bits) in the field.
ソース_Switch_AddressはSourceのSwitch Addressを含む24ビットの分野です。 アドレスが24ビット未満を包括すると、その分野でまさしく正当になるでしょう(最下位ビットを占領します)。
Reserved (16 bits) shall contain zero.
予約されて、(16ビット)はゼロを含むものとします。
Destination_IEEE_Address (48 bits) shall contain the 48 bit
Universal LAN MAC Address of the Destination if known,
otherwise zero.
別の方法で知られているなら、目的地_IEEE_Address(48ビット)はDestinationの48ビットのUniversal LANマックーアドレスを含むものとします。ゼロ。
LE_Locally_Administered (16 bits) shall contain zero unless
otherwise defined by local administration.
別の方法で地方行政によって定義されない場合、LE_Locally_Administered(16ビット)はゼロを含むものとします。
Source_IEEE_Address (48 bits) shall contain the 48 bit
Universal LAN MAC Address of the Source if known, otherwise
zero.
別の方法で知られているなら、ソース_IEEE_Address(48ビット)はSourceの48ビットのUniversal LANマックーアドレスを含むものとします。ゼロ。
IEEE 802.2 LLC
IEEE802.2LLC
The IEEE 802.2 LLC Header shall begin in the first octet of the
HIPPI-FP D2_Area.
IEEE802.2LLC HeaderはHIPPI-FP D2_Areaの最初の八重奏で始まるものとします。
SSAP (8 bits) shall contain 170 (decimal).
SSAP(8ビット)は170(10進)を含むものとします。
DSAP (8 bits) shall contain 170 (decimal).
DSAP(8ビット)は170(10進)を含むものとします。
CTL (8 bits) shall contain 3 (Unnumbered Information).
CTL(8ビット)は3(無数の情報)を含むものとします。
SNAP
スナップ
Organization Code (24 bits) shall be zero.
組織Code(24ビット)はゼロになるでしょう。
EtherType (16 bits) shall be set as defined in Assigned Numbers
[8] (IP = 2048, ARP = 2054, RARP = 32,821).
EtherType(16ビット)はAssigned民数記[8](IP=2048、アルプ=2054、RARP=3万2821)で定義されるように用意ができているものとします。
Renwick & Nicholson [Page 8] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[8ページ]RFC1374IPとARP
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| Reserved | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | (n+8) |
+-----+-+-------+-----------------------------------------------+
2 |[LA] |W|M_Type | Destination_Switch_Address |
+-----+-+-------+-----------------------------------------------+
3 | D_A_T | S_A_T | Source_Switch_Address |
+-------+-------+---------------+-------------------------------+
4 | Reserved | [Destination_IEEE_Address] |
+-------------------------------+ |
5 | |
+-------------------------------+-------------------------------+
6 | [LA] | [Source_IEEE_Address] |
+-------------------------------+ |
7 | |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | [EtherType] |
+---------------+---------------+---------------+---------------+
10 |Message octet 0|Message octet 1|Message octet 2| . . . |
+---------------+---------------+---------------+--- |
| . . .
|
| -------+---------------+---------------+---------------+
| . . . | octet (n-2) | octet (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 |1|0| 予約されます。| 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | (n+8) | +-----+-+-------+-----------------------------------------------+ 2 |[LA]|W|M_はタイプします。| 目的地_スイッチ_アドレス| +-----+-+-------+-----------------------------------------------+ 3 | D_A_T| S_A_T| ソース_スイッチ_アドレス| +-------+-------+---------------+-------------------------------+ 4 | 予約されます。| [送付先_IEEE_アドレス]| +-------------------------------+ | 5 | | +-------------------------------+-------------------------------+ 6 | [LA]| [ソース_IEEE_アドレス]| +-------------------------------+ | 7 | | +===============+===============+===============+===============+ 8 | AA| AA| 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | [EtherType]| +---------------+---------------+---------------+---------------+ 10 |メッセージ八重奏0|メッセージ八重奏1|メッセージ八重奏2| . . . | +---------------+---------------+---------------+--- | | . . . | | -------+---------------+---------------+---------------+ | . . . | 八重奏(n-2)| 八重奏(n-1)| 中詰め| +---------------+---------------+---------------+---------------+ N-1| 中詰め| 中詰め| 中詰め| 中詰め| +---------------+---------------+---------------+---------------+
HIPPI Packet Format
HIPPIパケット・フォーマット
Words 0-1: HIPPI-FP Header
Words 2-7: D1 Area (HIPPI-LE Header)
Words 8-9: D2 Area (IEEE 802.2 LLC/SNAP)
Words 10-(N-1): D2 Area (IP or ARP message)
(n) is the number of octets in the IP or ARP message.
+====+ denotes the boundary between D1 and D2 areas.
[LA] fields are zero unless used otherwise locally.
Abbreviations: "W" = Double_Wide field;
"M_Type" = Message_Type field;
"D_A_T" = Destination_Address_Type;
"S_A_T" = Source_Address_Type;
[FILL] octets complete the HIPPI packet to an even
number of 32 bit words. The number of fill octets
is not counted in the data length.
ワーズ0-1: HIPPI-fpヘッダーワーズ2-7: D1領域(HIPPI-LEヘッダー)ワーズ8-9: D2領域(IEEE802.2LLC/スナップ)ワーズ10(N-1): D2領域(IPかARPメッセージ)(n)はIPかARPメッセージの八重奏の数です。 +====+はD1とD2領域の間の境界を指示します。 そうでなければ、局所的に使用されない場合、[LA]分野はゼロです。 略語: 「W」はWideがさばく二重_と等しいです。 「M_はタイプすること」はメッセージ_Type分野と等しいです。 「D_A_T」=目的地_アドレス_タイプ。 ソース「S_A_T」=_は_タイプに演説します。 [FILL]八重奏は32ビットの単語の偶数にHIPPIパケットを完成します。 中詰め八重奏の数はデータの長さで数えられません。
Renwick & Nicholson [Page 9] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[9ページ]RFC1374IPとARP
IEEE 802.2 Data
IEEE802.2データ
The IEEE 802.2 Data shall follow the EtherType field immediately.
Fill octets shall be used following the Data as necessary to make
the number of octets in the packet a multiple of 8. In accordance
with HIPPI-FP, the amount of this fill is not included in the
D2_Size value in the HIPPI-FP Header.
IEEE802.2Dataはすぐに、EtherType野原に続くものとします。 パケットの八重奏の数を8の倍数にするように必要に応じてDataに続いて、中詰め八重奏は使用するでしょう。 HIPPI-FPによると、この中詰めの量はHIPPI-FP HeaderのD2_Size値に含まれていません。
The order of the octets in the data stream is from higher numbered
to lower numbered data signal (left to right) within the HIPPI
word, as specified in HIPPI-FP Clause 7, "Word and byte formats."
With the 1600 megabit/second data rate option (64 bit) bits 32
through 63 are on Cable B, so that the four octets on Cable B come
logically before those on Cable A. Within each octet, the most
significant bit is the highest numbered signal.
HIPPI単語の中に番号付のデータ信号(まっすぐになるのが残される)を下ろすために、より高いのからデータ・ストリームにおける、八重奏の注文に付番します、HIPPI-FP Clause7と、「Wordとバイト形式」で指定されるように。 2番目のデータ信号速度オプション(64ビット)ビットの32〜メガビット/63がCable Bにあるので、1600と共に、Cable Bにおける4つの八重奏が各八重奏で、最も重要なCable A.Withinで噛み付かれたものに論理的に優先するのは、最も高い番号付の信号です。
48 bit Universal LAN MAC Addresses
48ビットのUniversal LAN MAC Addresses
IEEE Standard 802.1A specifies the Universal LAN MAC Address. The globally unique part of the 48 bit space is administered by the IEEE. Each node on a HIPPI-SC LAN should be assigned a ULA. Multiple ULAs may be used if a node contains more than one IEEE 802.2 LLC protocol entity.
IEEE Standard 802.1AはUniversal LANマックーアドレスを指定します。 48ビットのスペースのグローバルにユニークな地域はIEEEによって管理されます。 ULAはHIPPI-サウスカロライナLANの各ノードに割り当てられるべきです。 ノードが1IEEE802.2のLLCプロトコル実体を含むなら、複数のULAsが使用されるかもしれません。
The format of the address within its 48 bit HIPPI-LE fields follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order:
48ビットのHIPPI-LE分野の中のアドレスの形式は注文とHIPPI-FPが噛み付いたIEEE 802.1A正準なビットとバイトオーダーに続きます:
31 23 15 7 0 +-------------------------------+---------------+---------------+ | (not used for ULA) |ULA octet 0|L|G| ULA octet 1 | +---------------+---------------+---------------+---------------+ | ULA octet 2 | ULA octet 3 | ULA octet 4 | ULA octet 5 | +---------------+---------------+---------------+---------------+
31 23 15 7 0 +-------------------------------+---------------+---------------+ | (ULAには中古でない)です。 |ULA八重奏0|L|G| ULA八重奏1| +---------------+---------------+---------------+---------------+ | ULA八重奏2| ULA八重奏3| ULA八重奏4| ULA八重奏5| +---------------+---------------+---------------+---------------+
Universal LAN MAC Address Format
普遍的なLANマックーアドレス形式
L (U/L bit) = 1 for Locally administered addresses, 0 for
Universal.
G (I/G bit) = 1 for Group addresses, 0 for Individual.
LocallyのためのL(U/Lに噛み付いた)=1はUniversalのためにアドレス、0を管理しました。 Groupアドレスのための1、IndividualのためのG(I/Gに噛み付いた)=0。
The use of ULAs is optional, but encouraged. Although ULAs are not used by HIPPI-SC switches, they are helpful for HIPPI Switch Address resolution, and for distinguishing between multiple logical entities that may exist within one node. They may also be used by gateway devices that replace HIPPI hardware headers with the MAC headers of other LANs. Carrying the ULAs in the HIPPI header may simplify these devices, and it may also help if HIPPI is used as an interface to some future HIPPI based LAN that uses ULAs for addressing.
ULAsの使用は、任意ですが、奨励されています。 ULAsはHIPPI-サウスカロライナスイッチによって使用されませんが、HIPPI Switch Address解決と、1つのノードの中に存在するかもしれない複数の論理的な実体を見分けるのにおいて、それらは役立っています。 また、それらはHIPPIハードウェアヘッダーを他のLANのMACヘッダーに取り替えるゲートウェイ装置によって使用されるかもしれません。 HIPPIヘッダーでULAsを運ぶと、これらの装置は簡略化するかもしれません、そして、また、HIPPIがインタフェースとしてアドレシングにULAsを使用する何らかの将来のHIPPIベースのLANに使用されるなら、それは助かるかもしれません。
Renwick & Nicholson [Page 10] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[10ページ]RFC1374IPとARP
Recommended HIPPI-FP Options
お勧めのHIPPI-fpオプション
HIPPI-FP allows some flexibility in the construction of a HIPPI packet, including placement of short bursts, optional fill and offset octets between the D1 and D2 areas and fill following the D2 data. For efficiency, Sources should limit the use of these options:
HIPPI-FPはHIPPIパケットの構造における何らかの柔軟性を許容します、D2データに従って、D1と、D2領域と中詰めの間の短い炸裂、任意の中詰め、およびオフセット八重奏のプレースメントを含んでいて。 効率のために、Sourcesはこれらのオプションの使用を制限するはずです:
1. Send the short burst as the last burst of the packet rather than
the first.
1. 1番目よりむしろパケットの最後の炸裂として短い炸裂を送ってください。
2. Do not place fill octets between the HIPPI-LE header and the
start of the D2_Area.
2. D2_AreaのHIPPI-LEヘッダーと始まりの間に中詰め八重奏を置かないでください。
3. Use no more than seven octets after the D2 Data, as needed to
make the total packet length a multiple of 8 octets.
3. D2 Dataの後の7つ未満の八重奏を使用してください、総パケット長を8つの八重奏の倍数にするのが必要であるので。
One HIPPI-FP option is forbidden: setting the Start_D2_on_Burst_Boundary flag to one. This places no limitation on the formation of packets into a series of bursts; a Source may segment the packet in any legal manner according to HIPPI-FP, including forcing the D2_Area to start on a burst boundary. The purpose of the Start_D2_on_Burst_Boundary flag is to help preserve the segmentation of the packet for some device-control protocols that use the first burst boundary to separate command and data areas within the packet. Requiring this flag to be clear means that when a packet arrives at the Destination its burst boundaries might not be exactly as the Source sent them. This may occur if a HIPPI packet passes over some other medium in the route between HIPPI LANs.
1つのHIPPI-FPオプションが禁じられます: _Start_D2_を_Burstにけしかけて、Boundaryは1つまで弛みます。 これは一連の炸裂へのパケットの構成に制限を全く置きません。 HIPPI-FPに応じて、Sourceはどんな法的な方法でもパケットを区分するかもしれません、D2_Areaに炸裂境界を始めさせるのを含んでいて。 Burst_Boundaryが旗を揚げさせる_の上のStart_D2_の目的はパケットの中でコマンドとデータ領域を切り離す最初の炸裂境界を使用するいくつかの装置制御プロトコルのためにパケットの分割を保存するのを助けることです。 Sourceがそれらを送ったので、この旗が明確であることが必要であるのがパケットがDestinationに到着する場合炸裂境界がまさにそうでないことを意味します。 HIPPIパケットがHIPPI LANの間のルートをある他の媒体を通り過ぎるなら、これは起こるかもしれません。
Notwithstanding these recommendations, each Destination shall accept any well-formed HIPPI packet within the definitions in HIPPI-FP.
これらの推薦にもかかわらず、各DestinationはHIPPI-FPとの定義の中でどんなよく形成されたHIPPIパケットも受け入れるものとします。
Note that neither HIPPI-FP nor HIPPI-LE limits the number of fill bytes placed between the end of the IP packet and the end of the HIPPI-PH packet. Some source implementations may add fill sufficient to overflow a destination input buffer. To avoid interpreting valid packets as errors, destinations should ignore overflow conditions and verify that at least the number of bytes indicated by the IP header actually arrived.
HIPPI-FPもHIPPI-LEもIPパケットの端とHIPPI-ペーハーパケットの端の間に置かれた中詰めバイトの数を制限しないことに注意してください。 いくつかのソース実現が目的地入力バッファからはみ出すことができるくらいの中詰めを加えるかもしれません。 目的地は、誤りとして有効なパケットを解釈するのを避けるために、オーバーフロー条件を無視して、少なくともIPヘッダーによって示されたバイト数が実際に到着したことを確かめるべきです。
I-Field format
I-フィールド形式
The I-field bits, as defined in HIPPI-SC, shall be set as follows:
HIPPI-サウスカロライナで定義されるI-分野ビットは以下の通り設定されるものとします:
Locally Administered (bit 31) shall be zero.
局所的に、Administered(ビット31)はゼロになるでしょう。
Reserved (bits 30, 29) should be zero. Destinations shall accept
any value for these bits.
予約されているのは(ビット30、29)、ゼロであるべきです。 目的地はどんな値もこれらのビット受け入れるものとします。
Renwick & Nicholson [Page 11] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[11ページ]RFC1374IPとARP
Double wide (bit 28) shall be set when Source Cable B is connected
and the Source wants a 64 bit connection. It shall be zero
otherwise.
Source Cable Bが接続されていて、Sourceが64ビットの接続が欲しいときに、二重に、広いのは(ビット28)、セットでしょう。 そうでなければ、それはゼロになるでしょう。
Direction (bit 27) should be sent as zero, however Destinations
shall accept either zero or one and interpret the Routing Control
field accordingly, per HIPPI-SC.
ゼロとして指示(ビット27)を送るべきであり、しかしながら、Destinationsはゼロか1つのどちらかを受け入れて、それに従って、ルート設定Control分野を解釈するものとします、HIPPI-サウスカロライナ単位で。
Path Selection (bits 26, 25) shall be 00, 01, or 11 (binary) at
the Source's option. 00 (source route mode) indicates that the
I-field bits 23-00 contain a 24 bit source route; 01 or 11
(logical address mode) indicate that bits 23-00 contain 12 bit
Source and Destination Addresses. The value 11 is meaningful when
more than one route exists from a Source to a Destination; it
allows the switch to choose the route. Use of 01 forces the
switch always to use the same route for the same
Source/Destination pair.
00、01、または11がSourceの選択で(2進)であったなら、経路Selection(ビット26、25)はそうするでしょう。 00 (送信元経路モード)は、I-分野ビット23-00が24ビットの送信元経路を含むのを示します。 01か11(論理アドレスモード)が、ビット23-00が12ビットのSourceとDestination Addressesを含むのを示します。 1つ以上のルートがSourceからDestinationまで存在するとき、値11は重要です。 それで、スイッチはルートを選ぶことができます。 01の使用は、同じSource/目的地組に同じルートを使用するためにいつもスイッチを押し込みます。
Camp-on (bit 24) may be 1 or 0; however, a Source shall not make
consecutive requests without Camp-on to the same Destination while
the requests are being rejected. The purpose of this restriction
is to prevent a node from circumventing the fair share arbitration
mechanism of the switch by repeating requests at a very high rate.
キャンプ(ビット24)は、1か0であるかもしれません。 しかしながら、Sourceが連続した要求をしないものとする、Camp、同じDestinationは要求である間、拒絶されています。 この制限の目的はノードが非常に高いレートで要求を繰り返すことによってスイッチの正当な分け前の仲裁メカニズムを回避するのを防ぐことです。
If logical address mode is used:
論理アドレスモードが使用されているなら:
Source Address (bits 23-12) is not used.
ソースAddress(ビット23-12)は使用されていません。
Destination Address (bits 11-0) shall contain the Switch
Address of the Destination.
目的地Address(ビット11-0)はDestinationのSwitch Addressを含むものとします。
If source route mode is used:
送信元経路モードが使用されているなら:
Routing control (bits 23-00) shall contain the route to the
Destination.
ルート設定コントロール(ビット23-00)はDestinationにルートを含むものとします。
Note: the outcome of Switch Address Resolution (see "Address
Resolution" below) determines whether to use logical address mode
or source route mode. If source route mode is used with multiple
interconnected switches, different sources may use different
addresses to reach the same destination, and multicast-based
address resolution may not be possible because a target node may
not know the route to itself from a given remote source.
Regardless of this difficulty, it may be possible to use source
route mode if the network consists of a single switch, or if
address resolution is supported by an ARP agent that is able to
deliver correct routes to each node. The nodes themselves need
not be concerned with these problems if they use the addressing
以下に注意してください。 Switch Address Resolution(以下の「アドレス解決」を見る)の結果は、論理アドレスモードか送信元経路モードを使用するかどうか決定します。 送信元経路モードが複数のインタコネクトされたスイッチと共に使用されるなら、さまざまな原因は同じ目的地に達するのに異なったアドレスを使用するかもしれません、そして、目標ノードが与えられたリモートソースからルートをそれ自体で知らないかもしれないので、マルチキャストベースのアドレス解決は可能でないかもしれません。 この困難にかかわらず、ネットワークが単一のスイッチから成るか、またはアドレス解決が正しいルートを各ノードに届けることができるARPエージェントによって支持されるなら、送信元経路モードを使用するのは可能であるかもしれません。 アドレシングを使用するなら、ノード自体はこれらの問題に関係がある必要はありません。
Renwick & Nicholson [Page 12] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[12ページ]RFC1374IPとARP
mode suggested by the value of the Source_Address_Type field in a
HIPPI-LE Address Resolution Response packet.
モードはHIPPI-LE Address Resolution ResponseパケットのSource_Address_Type分野の値によって示されました。
Rules For Connections
コネクションズのための規則
The following rules for connection management by Source and Destination are intended to insure frequent, fair share access to Destinations for which multiple Sources are contending. If possible, nodes should transfer data at full HIPPI speeds and hold connections no longer than necessary.
SourceとDestinationによる接続管理のために以下の規則が複数のSourcesが戦っているDestinationsへの頻繁で、公正なシェアアクセスを保障することを意図します。 できれば、ノードは、必要とするより完全なHIPPI速度でデータを移して、もう接続を保持するはずがありません。
A source may hold a connection for as long as it takes to send 68 HIPPI bursts at what ever speed the two connected nodes can achieve together. The number of packets sent in one connection is not limited, except that the number of bursts over all the packets should not exceed 68. This is not a recommendation to send as many packets as possible per connection; one packet per connection is acceptable. The purpose of this limit is to give each Source an fair share of a common Destination's bandwidth. Without a limit, if there is a Destination that is constantly in demand by multiple Sources, the Source that sends the most data per connection wins the greatest share of bandwidth.
接続ノードが一緒に実現できる2を促進するいったい何で68回のHIPPI炸裂を送るかにはかかる限り、ソースは接続を保持するかもしれません。 パケットの数は、1つの接続が限られていないのを送りました、すべてのパケットの上の炸裂の数が68を超えるべきでないのを除いて。 これはできるだけ1接続あたり多くのパケットを送るという推薦ではありません。 1接続あたりあるパケットが許容できます。 この限界の目的は一般的なDestinationの帯域幅の正当な分け前を各Sourceに与えることです。 限界がなければ、絶えず複数のSourcesで需要があるDestinationがあれば、最も多くの1接続あたりのデータを送るSourceは帯域幅の最もすばらしいシェアを得ます。
The limit of 68 bursts is not absolute. An implementation may check the burst count after transmission of a packet and end the connection if it is greater than or equal to some threshold. If this is done, the threshold should be less than 68 depending on the typical packet size, to ensure that the 68 burst limit is not normally exceeded. For instance, a Source sending 64K packets would send two per connection (130 bursts) if it checked for 68 at the end of each packet. In this situation the Source is required to check for a value small enough that it will not send a second packet in the same connection.
68回の炸裂の限界は絶対ではありません。 それが終わり以上であるなら、実現は、パケットのトランスミッションの後に炸裂カウントをチェックして、接続を終わらせるかもしれません。何らかの敷居。 これが完了しているなら、敷居は、典型的なパケットサイズへの通常、68炸裂限界が超えられていないのを保証するためには68未満依存であるべきです。 例えば、それぞれのパケットの端の68のためにチェックするなら、64Kのパケットを送るSourceは接続(130回の炸裂)あたり2を送るでしょうに。 この状況で、Sourceは同じ接続で2番目のパケットを送らないほど小さい値がないかどうかチェックしなければなりません。
Destinations shall accept all packets that arrive during a connection, and may discard those that exceed its buffering capacity. A Destination shall not abort a connection (deassert CONNECT) simply because too many bursts were received; however a Destination may abort a connection whose duration has exceeded a time period of the Destination's choosing, as long as the Source is allowed ample time to transmit its quota of bursts.
目的地は、接続の間に到着するすべてのパケットを受け入れて、容量をバッファリングするのを超えているものを捨てるかもしれません。 Destinationは単にあまりに多くの炸裂を受け取ったので、接続(deassert CONNECT)を中止しないものとします。 しかしながら、Destinationは持続時間がDestinationの選ぶことの期間を超えていた接続を中止するかもしれません、炸裂の割当てを伝える十分な時間がSourceに許容されている限り。
The rules admonish the node to do certain things as fast as it can, however there is no absolute measure of compliance. Nodes that cannot transfer data at full HIPPI speeds can still interoperate but the faster the implementation, the better the performance of the network will be.
規則は、できるだけ速くあることをするようにノードに訓戒します、どんな絶対測定もどんなにそこにコンプライアンスがなくても。 完全なHIPPI速度でデータを移すことができないノードがまだ共同利用できますが、実現が速ければ速いほど、ネットワークの性能は、より良くなるでしょう。
Renwick & Nicholson [Page 13] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[13ページ]RFC1374IPとARP
Assuming that bursts flow at the maximum rate, the most important factor in network throughput is the connection switching time, measured from the deassertion of REQUEST by the Source at the end of one connection to its first assertion of BURST after the establishment of the new connection. Implementations should keep this time as short as possible. For a guideline, assuming parallel HIPPI and a single HIPPI-SC switch, ten microseconds permits nearly full HIPPI throughput with full-sized packets, and at 60 microseconds the available throughput is reduced by about 10%. (See "Performance," below.)
炸裂が最高率で流れると仮定して、ネットワークスループットの最も重要な要素は新しい接続の設立の後に1つの接続の終わりのSourceによるREQUESTの反主張から最初のBURSTの主張まで測定された接続切換え時間です。 実現はできるだけ短く今回を保つべきです。 ガイドラインに関しては、平行なHIPPIと単一のHIPPI-サウスカロライナスイッチを仮定して、10マイクロセカンドは完全サイズのパケットでほとんど完全なHIPPIスループットを可能にして、60マイクロセカンドのときに、有効なスループットはおよそ10%減らされます。 (以下の「パフォーマンス」を見ます)
All HIPPI electrical signaling shall comply with HIPPI-PH. In every case, the following rules go beyond what HIPPI-PH requires.
すべてのHIPPIの電気シグナリングがHIPPI-ペーハーに従うものとします。 あらゆる場合に、以下の規則はHIPPI-ペーハーが必要とすることを越えます。
Rules for the Source
ソースへの規則
1. Do not assert REQUEST until a packet is ready to send.
1. パケットが発信する準備ができるまで、REQUESTについて断言しないでください。
2. Transmit bursts as quickly as READYs permit. Except for the
required HIPPI Source Wait states, there should be no delay in
the assertion of BURST whenever the Source's READY counter is
nonzero.
2. READYsが可能にするのと同じくらいはやく炸裂を伝えてください。 必要なHIPPI Source Wait州以外に、BURSTの主張の遅れが全くSourceのREADYカウンタが非零であるときはいつも、あるべきではありません。
3. Make a best effort to ensure that connection durations do not
exceed 68 bursts.
3. aを接続持続時間が68回の炸裂を超えていないのを保証するためにベストエフォート型にしてください。
4. Deassert REQUEST immediately when no packet is available for
immediate transmission or the last packet of the connection
has been sent.
4. すぐどんなパケットも接続の即座のトランスミッションか最後のパケットに利用可能でないときに、Deassert REQUESTを送りました。
Rules for the Destination
目的地への規則
1. Reject all connections if unable to receive packets. This
frees the requesting Source to connect to other Destinations
with a minimum of delay. Inability to receive packets is not
a transient condition, but is the state of the Destination
when its network interface is not initialized.
1. パケットを受けることができないなら、すべての接続を拒絶してください。 これは、最小遅れで他のDestinationsに接続するために要求しているSourceを解放します。 パケットを受けることができないことは、一時的な状態ではありませんが、ネットワーク・インターフェースが初期化されないとき、Destinationの州です。
2. A HIPPI node should be prepared to efficiently accept
connections and process incoming data packets. While this may
be best achieved by not asserting connect unless 68 bursts
worth of buffers is available, it may be possible to meet this
requirement with fewer buffers. This may be due to a priori
agreement between nodes on packet sizes, the speed of the
interface to move buffers, or other implementation dependent
considerations.
2. HIPPIノードは効率的に接続と過程受信データパケットを受け入れるように準備されるべきです。 68がはち切れない場合接続するように断言しないことによってこれを達成するかもしれませんが、最も良いバッファの価値が利用可能である、より少ないバッファでこの必要条件を満たすのは可能であるかもしれません。 これはパケットサイズ(バッファ、または他の実現に依存する問題を動かすインタフェースの速度)のノードの間の先験的な協定のためであるかもしれません。
Renwick & Nicholson [Page 14] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[14ページ]RFC1374IPとARP
3. Accept a connection immediately when buffers are available.
The Destination should never delay the acceptance of a
connection unnecessarily.
3. バッファがすぐ利用可能であるときには接続を受け入れてください。 Destinationは接続の承認を決して不必要に遅らせるはずがありません。
4. Once initialized, a Destination may reject connection requests
only for one of the following reasons:
4. いったん初期化されると、Destinationは単に以下の理由の1つで接続要求を拒絶するかもしれません:
1. The I-field was received with incorrect parity.
1. 不正確な同等でI-野原を受け取りました。
2. The I-field contents are invalid, e.g. the "W" bit set
when the Destination does not support the 1600 megabit
data rate option, the "Locally Administered" bit is set,
the Source is not permitted to send to this Destination,
etc.
2. I-分野内容が無効である、目的地が1600年のメガビットデータ信号速度オプションをサポートしないとき、例えば、「W」ビットはセットして、「局所的に管理された」ビットは設定されて、ソースがこの目的地などに発信することが許可されていません。
Transient conditions within the Destination, such as temporary
buffer shortages, must never cause rejected connections.
Destinationの中の一時的なバッファ枯渇などの一時的な状態は拒絶された接続を決して引き起こしてはいけません。
5. Ignore aborted connection sequences. Sources may time out and
abandon attempts to connect; therefore aborted connection
sequences are normal events.
5. 中止になっている接続系列を無視してください。 ソースはそうするかもしれません。タイムアウトと放棄は、接続するのを試みます。 したがって、中止になっている接続系列は正常な出来事です。
MTU
MTU
Maximum Transmission Unit (MTU) is defined as the length of the IP
packet, including IP header, but not including any overhead below
IP. Conventional LANs have MTU sizes determined by physical layer
specification. MTUs may be required simply because the chosen
medium won't work with larger packets, or they may serve to limit
the amount of time a node must wait for an opportunity to send a
packet.
最大のTransmission Unit(MTU)はIPパケットの長さと定義されます、IPヘッダーを含んでいますが、IPの下の少しのオーバーヘッドも含んでいなくて。 従来のLANには、物理的な層の仕様によって決定しているMTUサイズがあります。 単に、選ばれた媒体が、より大きいパケットで働かないか、またはノードがパケットを送る機会を待たなければならない時間を制限するのに役立つかもしれないので、MTUsが必要であるかもしれません。
HIPPI has no inherent limit on packet size. The HIPPI-FP header
contains a 32 bit D2_Size field that, while it may limit packets
to about 4 gigabytes, imposes no practical limit for networking
purposes. Even so, a HIPPI-SC switch used as a LAN needs an MTU
so that Destination buffer sizes can be determined.
HIPPIはパケットサイズにどんな固有の限界も持っていません。 HIPPI-FPヘッダーはパケットをおよそ4つのギガバイトに制限するかもしれませんが、ネットワーク目的のためのどんな実用的な限界も課さないSizeがさばく32ビットのD2_を含んでいます。 たとえそうだとしても、そのDestinationがサイズをバッファリングして、LANがMTUを必要とするので使用されるHIPPI-サウスカロライナスイッチは決定できます。
The MTU for HIPPI-SC LANs is 65280 (decimal) octets.
HIPPI-サウスカロライナLANのためのMTUは65280の(10進)の八重奏です。
This value was selected because it allows the IP packet to fit in
one 64K octet buffer with up to 256 octets of overhead. The
overhead is 40 octets at the present time; there are 216 octets of
room for expansion.
IPパケットがそれでオーバーヘッドの最大256の八重奏がある1つ64のK八重奏バッファをうまくはめ込むことができるので、この値は選択されました。 オーバーヘッドは現在の40の八重奏です。 拡大の余地の216の八重奏があります。
Renwick & Nicholson [Page 15] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[15ページ]RFC1374IPとARP
HIPPI-FP Header 8 octets
HIPPI-LE Header 24 octets
IEEE 802.2 LLC/SNAP Headers 8 octets
Maximum IP packet size (MTU) 65280 octets
------------
Total 65320 octets (64K - 216)
HIPPI-FP Header8八重奏HIPPI-LE Header24八重奏IEEE802.2LLC/SNAP Headers8八重奏Maximum IPパケットサイズ(MTU)65280八重奏------------ 総65320の八重奏(64K--216)
Camp-on
キャンプ
When several Sources contend for a single Destination, the Camp-on feature allows the HIPPI-SC switch to arbitrate and ensure that all Sources have fair access. (HIPPI-SC does not specify the method of arbitration.) Without Camp-on, the contending Sources would simply have to retry the connection repeatedly until it was accepted, and the fastest Source would usually win. To guarantee fair share arbitration, Sources are prohibited from making repeated requests to the same Destination without Camp-on in such a way as to defeat the arbitration.
数個のSourcesが独身のDestinationを競争するとき、Campオンな特徴で、すべてのSourcesには公正なアクセサリーがあるのをHIPPI-サウスカロライナスイッチを仲裁して、保証します。 (HIPPI-サウスカロライナは仲裁の方法を指定しません。) Campがなければ、戦っているSourcesはそれを受け入れるまで繰り返して単に接続を再試行しなければならなくて、通常、最も速いSourceは勝つでしょう。 正当な分け前の仲裁を保証するために、Sourcesは敗北に関するそのような方法でCampのない同じDestinationへの再三の要求を仲裁にするのが禁止されています。
There is another important reason to use Camp-on: when a connection without Camp-on is rejected, the Source cannot determine whether the rejection came from the requested Destination or from the switch. The Source also cannot tell the reason for the rejection, which could be either that the Destination was off line or not cabled, or the I- field was erroneous or had incorrect parity. Sources should not treat a rejection of a request without Camp-on as an error. Camp-on prevents rejection due to the temporary busy case; with one exception, rejection of a Camp-on request indicates an error condition, and an error event can be recorded. The exception occurs when a 64 bit connection is attempted to a Destination that does not have Cable B connected, resulting in a reject. This case is covered in "Channel Data Rate Discovery," below.
Campを使用する別の重要な理由があります: Campのない接続が拒絶されるとき、Sourceは、拒絶が要求されたDestinationかスイッチから来たかどうか決定できません。 Sourceも拒絶のために訳を話すことができないか、またはI分野には、誤ったか、不正確な同等がありました。(拒絶はDestinationが線にあったか、または電報を打たれないどちらもであることができませんでした)。 ソースは誤りとしてCampなしで要求の拒絶を扱うべきではありません。 キャンプは一時的な忙しいケースによる拒絶を防ぎます。 ただ1つを例外として、要求に応じてCampの拒絶はエラー条件を示します、そして、誤り出来事は記録できます。 64ビットの接続がCable Bを接続させないDestinationに試みられるとき、例外は起こります、廃棄物をもたらして。 本件は以下の「チャンネルデータ信号速度発見」でカバーされています。
Address Resolution
アドレス解決
The Internet Address Resolution Protocol (ARP) is defined in RFC 826 [9]. Ethernet, FDDI and 802 networks use ARP to discover another host's ULA knowing the Internet address. Reverse ARP [10] is used to discover the Internet address, knowing the ULA. ARP can be used in the conventional way on HIPPI-SC LANs equipped with a multicast capability or third party ARP agent.
インターネットAddress Resolutionプロトコル(ARP)はRFC826[9]で定義されます。 イーサネット、FDDI、および802のネットワークが、別のホストのULAがインターネット・アドレスを知ると発見するのにARPを使用します。 ULAを知っていて、逆のARP[10]は、インターネット・アドレスを発見するのに使用されます。 マルチキャスト能力か第三者ARPエージェントに持たせるHIPPI-サウスカロライナLANで従来の方法でARPを使用できます。
HIPPI-LE defines similar lower-level address resolution between ULAs and switches. HIPPI-LE adds a self-address resolution mechanism not defined for Internet ARP, which allows a node to discover its own switch address dynamically.
HIPPI-LEはULAsとスイッチの間の同様の低レベルアドレス解決を定義します。 HIPPI-LEはノードにそれ自身のスイッチアドレスをダイナミックに発見させるインターネットARPのために定義されなかった自己アドレス解決メカニズムを加えます。
Renwick & Nicholson [Page 16] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[16ページ]RFC1374IPとARP
ARP for the purpose of discovering ULAs is not necessary for the operation of a HIPPI-SC LAN, but it serves as the vehicle for discovery of HIPPI-SC Switch Addresses, without which the HIPPI-SC LAN cannot function. In other words, at the same time a node is using ARP to map another node's IP address to its ULA, it is also mapping the ULA to the 12 bit HIPPI Switch Address, from which it will construct the I-field value for sending messages to that node. This additional level of hardware addressing uses the address fields in the HIPPI-LE header.
ULAsを発見する目的のためのARPはHIPPI-サウスカロライナLANの操作に必要ではありませんが、それはHIPPI-サウスカロライナSwitch AddressesのHIPPI-サウスカロライナLANが機能できない発見のための手段として機能します。 言い換えれば、同時にノードは別のノードのIPアドレスをULAに写像するのにARPを使用します、また、それが12噛み付いているHIPPI Switch AddressにULAを写像しています。(それは送付メッセージのためにHIPPI Switch AddressからI-分野値をそのノードに構成するでしょう)。 この追加レベルのハードウェアアドレシングはHIPPI-LEヘッダーのアドレス・フィールドを使用します。
In the following discussion, the terms "requester" and "target" are used to identify the node requesting address resolution and the node whose address it wishes to discover, respectively. In third party ARP (see "ARP Implementation Methods," below) the source of a reply is an ARP agent node, not the target node.
以下の議論では、用語「リクエスタ」と「目標」は、アドレス解決を要求するノードとそれがそれぞれアドレスを発見したがっているノードを特定するのに使用されます。 第三者ARP(以下で「ARP実現方法」を見る)では、回答の源は目標ノードではなく、ARPエージェントノードです。
ARP and RARP Message Format
ARPとRARPメッセージ・フォーマット
The HIPPI ARP/RARP protocol uses the same packet format as ARP for
Ethernet. ARP packets shall be transmitted with a hardware type
code of 1 (as for Ethernet). Furthermore, ARP packets shall be
accepted if received with hardware type codes of either 1 or 6
(IEEE 802 networks).
HIPPI ARP/RARPプロトコルはイーサネットにARPと同じパケット・フォーマットを使用します。 ARPパケットは1(イーサネットのような)のハードウェアタイプコードで伝えられるものとします。 その上、1か6(IEEE802ネットワーク)のハードウェアタイプコードで受け取るなら、ARPパケットを受け入れるものとします。
ar$hrd (16 bits) shall contain 1.
ar$hrd(16ビット)は1を含むものとします。
ar$pro (16 bits) shall contain the IP protocol code 2048
(decimal).
ar$プロ(16ビット)はIPプロトコルコード2048(小数)を含むものとします。
ar$hln (8 bits) shall contain 6.
ar$hln(8ビット)は6を含むものとします。
ar$pln (8 bits) shall contain 4.
ar$pln(8ビット)は4を含むものとします。
ar$op (16 bits) shall contain 1 for requests, 2 for responses.
ar$オプアート(16ビット)は要求のための1、応答のための2を含むものとします。
ar$sha (48 bits) in requests shall contain the requester's ULA.
In replies it shall contain the target node's ULA.
要求におけるar$sha(48ビット)はリクエスタのULAを含むものとします。 回答では、それは目標ノードのULAを含むものとします。
ar$spa (32 bits) in requests shall contain the requester's IP
address if known, otherwise zero. In replies it shall contain the
target node's IP address.
要求におけるar$鉱泉(32ビット)は知られているならIPが記述するリクエスタのもの、そうでなければゼロを含むものとします。 回答では、それは目標ノードのIPアドレスを含むものとします。
ar$tha (48 bits) in requests shall contain the target's ULA if
known, otherwise zero. In replies it shall contain the
requester's ULA.
そうでなければ、tha(48ビット)が中で知られているなら目標のULAを含むよう要求するar$、ゼロ。 回答では、それはリクエスタのULAを含むものとします。
ar$tpa (32 bits) in requests shall contain the target's IP address
if known, otherwise zero. In replies it shall contain the
要求におけるar$tpa(32ビット)は知られているならIPが記述する目標のもの、そうでなければゼロを含むものとします。 それが含むものとする回答
Renwick & Nicholson [Page 17] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[17ページ]RFC1374IPとARP
requester's IP address.
リクエスタのIPアドレス。
The format of the six octets of the ULA shall be the same as
required in the HIPPI-LE header (see "48 bit Universal LAN MAC
Addresses" above), except for the alignment of the Source ULA with
respect to the 32 bit HIPPI word, which is different between ARP
and HIPPI-LE. No bit reversal is necessary as is required with
FDDI [11].
ULAの6つの八重奏の形式は必要に応じてHIPPI-LEヘッダーで同じでしょう(「48ビットのUniversal LAN MAC Addresses」が上であることを見てください)、32ビットのARPとHIPPI-LEの間で異なったHIPPI単語に関するSource ULAの整列を除いて。 どんなビット逆転もそのままでFDDI[11]によって必要な状態で必要ではありません。
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 36 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W| 1 | 000 | Target Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 |Requester's Switch Addr|
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Target ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Requester's ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | EtherType (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (1) | pro (2048) |
+---------------+---------------+-------------------------------+
11 | hln (6) | pln (4) | op (1) |
+---------------+---------------+-------------------------------+
12 | Requester's ULA octets 0 - 3 |
+-------------------------------+-------------------------------+
13 | Requester's ULA octets 4 - 5 | Requester's IP Address upper |
+-------------------------------+-------------------------------+
14 | Requester's IP Address lower | Target ULA octets 0 - 1 |
+-------------------------------+-------------------------------+
15 | Target ULA octets 2 - 5 |
+---------------------------------------------------------------+
16 | Target IP Address |
+---------------------------------------------------------------+
31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 |1|0| 000 | 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | 36 | +-----+-+-------+-----------------------+-----------------------+ 2 |[LA]|W| 1 | 000 | 目標スイッチAddr| +-----+-+-------+-----------------------+-----------------------+ 3 | 2 | 2 | 000 |リクエスタのスイッチAddr| +---------------+---------------+-------+-----------------------+ 4 | 00 00 | | +-------------------------------+ | 5 | 目標ULA| +-------------------------------+-------------------------------+ 6 | [LA]| | +-------------------------------+ | 7 | リクエスタのULA| +===============+===============+===============+===============+ 8 | AA| AA| 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | EtherType(2054)| +---------------+---------------+-------------------------------+ 10 | hrd(1)| プロ(2048)| +---------------+---------------+-------------------------------+ 11 | hln(6)| pln(4)| オプアート(1)| +---------------+---------------+-------------------------------+ 12 | リクエスタのULA八重奏0--3| +-------------------------------+-------------------------------+ 13 | リクエスタのULA八重奏4--5| リクエスタはIP Address上側です。| +-------------------------------+-------------------------------+ 14 | リクエスタのIP Addressは下ろします。| 目標ULA八重奏0--1| +-------------------------------+-------------------------------+ 15 | 目標ULA八重奏2--5| +---------------------------------------------------------------+ 16 | 目標IPアドレス| +---------------------------------------------------------------+
HIPPI ARP/RARP Request (logical address mode)
HIPPIアルプ/RARP要求(論理アドレスモード)
Renwick & Nicholson [Page 18] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[18ページ]RFC1374IPとARP
All ARP requests shall be sent with the I-field bit 28 set to zero, i.e. requesting a 32 bit connection.
28がゼロに設定するI-分野ビットですべてのARP要求を送るものとして、すなわち、要求は32ビットの接続です。
Unless another convention is locally defined for ARP requests, the I-field Path Selection bits may be set to binary 01 or 11 (logical address mode), and Destination Address field set to the HIPPI-SC address reserved for traffic conventionally directed to the IEEE 802.1[12] broadcast address (which HIPPI-SC defines as FE0, hex).
別のコンベンションがARP要求のために局所的に定義されない場合、I-分野Path Selectionビットは2進の01か11(論理アドレスモード)に設定されたかもしれません、そして、Destination Address分野は慣習上IEEE 802.1[12]放送演説(HIPPI-サウスカロライナがFE0、十六進法と定義する)に向けられた交通に予約されたHIPPI-サウスカロライナアドレスにセットしました。
Reply packets shall be sent with I-field Path Selection and Routing Control fields set according to the Source_Address_Type and Source_Switch_Address fields in the request.
要求におけるI-分野Path Selection、Source_Address_Typeによると、Control分野が設定するルート設定、およびSource_Switch_Address分野と共に回答パケットを送るものとします。
In the HIPPI-LE header of ARP/RARP requests and replies the following fields shall be set:
アルプ/RARP要求と回答のHIPPI-LEヘッダーでは、以下の分野は設定されるものとします:
Double-Wide should be 1 if the HIPPI Destination at the sending node can accept 64 bit HIPPI connections.
送付ノードのHIPPI Destinationが64ビットのHIPPI接続を受け入れることができるなら、二重広いのは、1であるべきです。
Message_Type shall contain an address resolution type code as defined in HIPPI-LE. It shall be set appropriately to the value of the ARP operation code (ar$op) in piggybacked ARP messages:
メッセージ_TypeはHIPPI-LEで定義されるようにアドレス解決タイプコードを含むものとします。 それは適切に便乗しているARPメッセージのARP命令コード(ar$オプアート)の値に設定されるものとします:
+-----------------------+-----------------------+
| ARP ar$op | HIPPI-LE Message_Type |
+=======================+=======================+
|ARP Request (1) |AR_Request (1) |
|ARP Reply (2) |AR_Response (2) |
+-----------------------+-----------------------+
|Reverse ARP Request (3)|AR_Request (1) |
|Reverse ARP Reply (4) |AR_Response (2) |
+-----------------------+-----------------------+
+-----------------------+-----------------------+ | ARP ar$オプアート| HIPPI-LEメッセージ_タイプ| +=======================+=======================+ |ARPは(1)を要求します。|AR_要求(1)| |ARP回答(2)|AR_応答(2)| +-----------------------+-----------------------+ |ARP要求(3)を逆にしてください。|AR_要求(1)| |ARP回答(4)を逆にしてください。|AR_応答(2)| +-----------------------+-----------------------+
There is no ARP message corresponding to HIPPI-LE self address discovery; these packets are sent without ULP data.
HIPPI-LE自己アドレス発見に対応するどんなARPメッセージもありません。 ULPデータなしでこれらのパケットを送ります。
Destination_Switch_Address in requests shall be the Switch Address of the target node if known, otherwise zero. In replies it shall be the requesting node's Switch Address
そうでなければ、_Addressが中で知られているなら目標ノードのSwitch Addressになるよう要求する目的地_Switch、ゼロ。 回答では、それは要求ノードのSwitch Addressになるでしょう。
Destination_Address_Type shall be 1 if the Destination_Switch_Address is a source route, 2 if it is a 12 bit address.
目的地_Address_TypeがDestination_Switch_Addressが送信元経路であるなら1歳になる、それであるなら、2は12ビット・アドレスです。
Source_Address_Type shall be 1 if the Source_Switch_Address is a source route, 2 if it is a 12 bit address.
ソース_Address_TypeがSource_Switch_Addressが送信元経路であるなら1歳になる、それであるなら、2は12ビット・アドレスです。
Source_Switch_Address in requests shall be the Switch Address of the requesting node if known, otherwise zero. In replies it shall be the
__Addressが中で知られているなら要求ノードのSwitch Addressになるよう要求するSwitch、そうでなければゼロの出典を明示してください。 それが回答であるだろう
Renwick & Nicholson [Page 19] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[19ページ]RFC1374IPとARP
target node's Switch Address.
ノードのSwitch Addressを狙ってください。
Destination_IEEE_Address shall be the same as the ar$tha field in the ARP message.
目的地_IEEE_AddressはARPメッセージのar$tha分野と同じになるでしょう。
Source_IEEE_Address shall be the same as the ar$sha field in the ARP message.
ソース_IEEE_AddressはARPメッセージのar$sha分野と同じになるでしょう。
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 36 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W| 2 | 000 |Requester's Switch Addr|
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Target Switch Address |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Requester's ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Target ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | EtherType (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (1) | pro (2048) |
+---------------+---------------+-------------------------------+
11 | hln (6) | pln (4) | op (2) |
+---------------+---------------+-------------------------------+
12 | Target ULA octets 0 - 3 |
+-------------------------------+-------------------------------+
13 | Target ULA octets 4 - 5 | Target IP Address upper |
+-------------------------------+-------------------------------+
14 | Target IP Address lower | Requester's ULA octets 0 - 1 |
+-------------------------------+-------------------------------+
15 | Requester's ULA octets 2 - 5 |
+---------------------------------------------------------------+
16 | Requester's IP Address |
+---------------------------------------------------------------+
31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 |1|0| 000 | 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | 36 | +-----+-+-------+-----------------------+-----------------------+ 2 |[LA]|W| 2 | 000 |リクエスタのスイッチAddr| +-----+-+-------+-----------------------+-----------------------+ 3 | 2 | 2 | 000 | 目標スイッチアドレス| +---------------+---------------+-------+-----------------------+ 4 | 00 00 | | +-------------------------------+ | 5 | リクエスタのULA| +-------------------------------+-------------------------------+ 6 | [LA]| | +-------------------------------+ | 7 | 目標ULA| +===============+===============+===============+===============+ 8 | AA| AA| 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | EtherType(2054)| +---------------+---------------+-------------------------------+ 10 | hrd(1)| プロ(2048)| +---------------+---------------+-------------------------------+ 11 | hln(6)| pln(4)| オプアート(2)| +---------------+---------------+-------------------------------+ 12 | 目標ULA八重奏0--3| +-------------------------------+-------------------------------+ 13 | 目標ULA八重奏4--5| 上側でIP Addressを狙ってください。| +-------------------------------+-------------------------------+ 14 | 目標IP Addressは下ろします。| リクエスタのULA八重奏0--1| +-------------------------------+-------------------------------+ 15 | リクエスタのULA八重奏2--5| +---------------------------------------------------------------+ 16 | リクエスタのIPアドレス| +---------------------------------------------------------------+
HIPPI ARP/RARP Reply (logical address mode)
HIPPIアルプ/RARP回答(論理アドレスモード)
Renwick & Nicholson [Page 20] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[20ページ]RFC1374IPとARP
ARP procedure
ARP手順
The combined HIPPI-LE/ARP packet contains six addresses, three each for the requester and the target:
結合したHIPPI-LE/ARPパケットは6つのアドレス、リクエスタのためのそれぞれ3、および目標を含んでいます:
Requester's IP Address (ARP)
Requester's ULA (ARP and HIPPI-LE)
Requester's Switch Address (HIPPI-LE)
リクエスタのIPアドレス(ARP)リクエスタのULA(ARPとHIPPI-LE)リクエスタのスイッチアドレス(HIPPI-LE)
Target's IP Address (ARP)
Target's ULA (ARP and HIPPI-LE)
Target's Switch Address (HIPPI-LE)
目標のIPアドレス(ARP)目標のULA(ARPとHIPPI-LE)目標のスイッチアドレス(HIPPI-LE)
Internet ARP concerns the IP Address and ULA; HIPPI-LE address resolution concerns the ULA and Switch Address. Thus the ULA appears in both parts of the packet.
インターネットARPはIP AddressとULAに関係があります。 HIPPI-LEは解決関心のULAとSwitch Addressを記述します。 したがって、ULAはパケットの両方の一部に現れます。
Successful ARP results in tables in each node that map remote nodes' IP addresses to ULAs and ULAs to Switch Addresses, so that when an application requests a connection to a remote node by its IP address, both the remote ULA and Switch Address can be determined, a correct HIPPI-LE header can be built, and a connection to the node can be established using the correct Switch Address in the I-field. Any recipient of an ARP request or reply may use information in the packet to augment its tables, even if it is neither the target node nor the requester.
うまくいっているARPはSwitch Addressesへの各ノードの遠隔ノードのIPがULAsに記述するその地図とULAsでテーブルをもたらします、アプリケーションがIPアドレスから遠隔ノードに接続を要求すると、リモートULAとSwitch Addressの両方が決定できて、正しいHIPPI-LEヘッダーを造ることができて、I-分野で正しいSwitch Addressを使用することでノードとの接続は確立できるように。 ARP要求か回答のどんな受取人もテーブルを増大させるのにパケットで情報を使用するかもしれません、それが目標ノードでなくてまたリクエスタでなくても。
Note that the use of ULAs with HIPPI is not required. In both the HIPPI-LE header and the Internet ARP message, the fields that contain ULAs should be set to zero when the ULA is not known. Address resolution consists of two separate protocols, HIPPI-LE address resolution and Internet ARP, neither of which can function independently without ULAs. However HIPPI Switch Address resolution can work without ULAs if the two protocols are piggybacked and treated as one operation in which Internet addresses are mapped directly to switch addresses. With the exception of the optional self-address resolution request, which has no analogous Internet protocol, HIPPI-LE address resolution and Internet ARP messages should be sent together as a single HIPPI packet.
HIPPIとのULAsの使用は必要でないことに注意してください。 ULAが知られていないとき、HIPPI-LEヘッダーとインターネットARPメッセージの両方では、ULAsを含む分野はゼロに設定されるべきです。 アドレス解決は2つの別々のプロトコル、HIPPI-LEアドレス解決、およびインターネットARPから成ります。そのどちらもULAsなしで独自に機能できません。 しかしながら、2つのプロトコルが背負われて、インターネット・アドレスがアドレスを切り換えるために直接写像される1つの操作として扱われるなら、HIPPI Switch Address解決はULAsなしで働くことができます。 任意の自己アドレス解決要求を除いて、どれに単一のHIPPIパケットとして類似のインターネットプロトコルがなく、HIPPI-LEアドレス解決、およびインターネットARPメッセージを一緒に持たせるべきですか。
If ULAs are used, the HIPPI-LE address resolution request can be sent without a piggybacked 802.2 LLC PDU, so it is possible to map ULAs to HIPPI Switch Addresses without using ARP. Nodes shall accept both piggybacked and non-piggybacked forms of HIPPI-LE address resolution messages.
ULAsが使用されているなら、便乗している802.2LLC PDUなしでHIPPI-LEアドレス解決要求を送ることができるので、ARPを使用しないでULAsをHIPPI Switch Addressesに写像するのは可能です。 ノードは便乗して非便乗の両方であっているフォームに関するHIPPI-LEアドレス解決メッセージを受け入れるものとします。
The recipient of an address resolution request, having first updated its address mapping tables with any new information it can find in
アドレス解決要求の受取人、1番目を持っていると、中のどんな新情報も見つけることができる状態で、アドレス変換テーブルはアップデートされました。
Renwick & Nicholson [Page 21] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[21ページ]RFC1374IPとARP
the request, checks to see if it is the target node. If it is, it generates a reply by filling in the unknown target address fields according to the HIPPI-LE message type and the ARP operation code, and swapping the four pairs of source/target address fields. Then it connects to the requesting node with the Source Switch Address from the request, and sends the reply packet.
要求、それが目標ノードであるかどうか考えるチェック。 そうなら、それは、HIPPI-LEメッセージタイプとARP命令コードによって未知の目標アドレス・フィールドに記入して、4組のソース/目標アドレス・フィールドを交換することによって、回答を発生させます。 次に、それは、Source Switch Addressと共に要求から要求ノードに接続して、回答パケットを送ります。
A node is the target of an address resolution request if the request contains one of the following:
要求が以下の1つを含んでいるなら、ノードはアドレス解決要求の目標です:
1. the node's ULA in the Destination_IEEE_Address field of a HIPPI-
LE AR_Request message
1. HIPPI- LE AR_RequestメッセージのDestination_IEEE_Address分野のノードのULA
2. the node's IP address in the target protocol address field
(ar$tpa) of a piggybacked Internet ARP message
2. 便乗しているインターネットARPメッセージの目標プロトコルアドレス・フィールド(ar$tpa)のノードのIPアドレス
If two target fields are known but are not mapped together in the recipient's address mapping tables, it may do one of three things:
2つの目標分野が知られていますが、受取人のアドレス変換テーブルで一緒に写像されないなら、3つのものの1つをするかもしれません:
1. treat the request as having two targets, and send correct replies
for both to the requester.
1. 2個の目標を持っているとして要求を扱ってください、そして、両方のための正しい回答をリクエスタに送ってください。
2. assume its own tables are invalid and ignore the request.
2. それ自身のテーブルが無効であり、要求を無視すると仮定してください。
3. assume one of the "known" target fields is correct and respond as
if the other had been unknown.
3. 「知られている」目標分野の1つが正しいと仮定してください、そして、まるでもう片方が未知であったかのようにこたえてください。
The best choice depends on which fields conflict and the nature of the implementation. Choice 3 is probably best for ordinary nodes, but third party ARP agents may have reason to use one of the other two. Future experience may shed light on this.
この最も良い選択はどの分野が闘争するか、そして、実現の本質次第です。 普通のノードには、選択3はたぶん最も良いのですが、第三者ARPエージェントでは、他の2の1つを使用する理由があるかもしれません。 今後の経験はこれを解明するかもしれません。
ARP Implementation Methods
ARP実現方法
The requirements for nodes to handle address resolution messages depend on the means by which address resolution is implemented on the LAN.
ノードがアドレス解決メッセージを扱うという要件はアドレス解決がLANで実行される手段によります。
In conventional networks ARP is a distributed function. ARP requests are broadcast; each host may update its address mappings with any ARP request or reply it sees, and responds to ARP requests that contain its own address in the target protocol address field. HIPPI-SC switches are not required to provide multicast service, although some do. Even if the switches do not multicast, one or more nodes can act as multicast servers, receiving packets sent to the HIPPI-SC broadcast address and repeating them to each other node in turn. Either way, if multicast exists on a HIPPI-SC LAN, ARP can be a distributed function. In this situation each node is required to
従来のネットワークでは、ARPは分散機能です。 ARP要求は放送されます。 各ホストはそれが目標プロトコルアドレス・フィールドにそれ自身のアドレスを保管しているARP要求に見て、反応させるどんなARP要求や回答でもアドレス・マッピングをアップデートするかもしれません。 何かが必要ですが、HIPPI-サウスカロライナスイッチは、マルチキャストサービスを提供するのに必要ではありません。 スイッチはどんなマルチキャストもしません、1か、より多くのノードがマルチキャストサーバとして機能できても、パケットを受けると、互いにHIPPI-サウスカロライナ放送演説の、そして、繰り返しているそれらへのノードは順番に送られました。 いずれにせよ、マルチキャストがHIPPI-サウスカロライナLANに存在しているなら、ARPは分散機能であるかもしれません。 この状況で、各ノードが必要です。
Renwick & Nicholson [Page 22] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[22ページ]RFC1374IPとARP
respond correctly to address resolution requests for which it is the target.
正しく応じて、それが目標である解決要求を記述してください。
Third party ARP is a second method that does not depend on multicast. The switches can map the HIPPI ARP multicast address to a node that acts as an ARP agent, replying to ARP requests on behalf of the real target nodes. Ordinary nodes never receive ARP requests or generate replies and never have the opportunity to update mapping tables based on ARP requests from other nodes, as usually happens on conventional networks. Each node must request any address information it needs, but never has to process ARP information it doesn't need. Under third party ARP a node should not receive address resolution requests, and each node that is not an ARP agent should ignore those that it does receive.
第三者ARPはマルチキャストによらない2番目の方法です。 スイッチはARPエージェントとして務めるノードにHIPPI ARPマルチキャストアドレスを写像できます、実質成長目標ノードを代表してARP要求に答えて。 普通のノードは、ARP要求を決して受け取らないか、回答を発生させて、または他のノードからのARP要求に基づくテーブルを写像しながら、アップデートする機会を決して持っていません、従来のネットワークで通常起こるとき。 各ノードは、それが必要とするどんなアドレス情報も要求しなければなりませんが、それが必要としないARP情報を決して処理する必要はありません。 第三者ARPの下では、ノードはアドレス解決要求を受け取るはずがありません、そして、ARPエージェントでない各ノードはそれが受けるものを無視するはずです。
As a third possibility, one can omit the implementation of ARP entirely, choosing instead to build address mapping tables in each node from information available to a network administrator. Such a technique is implementation dependent and outside the scope of this memo. It may be helpful in prototype networks without multicast where no ARP agent is yet implemented. In this case, nodes are not required to respond to address resolution requests, but must accept any they may receive.
3番目の可能性として、1つはARPの実現を完全に省略できます、ネットワーク管理者にとって、利用可能な情報からの各ノードでアドレス変換テーブルを組立てるのを代わりに選んで。 実現に依存していて、このメモの範囲の外でそのようなテクニック。 それはARPエージェントが全くまだ実行されていないところでマルチキャストなしで原型ネットワークに役立っているかもしれません。 この場合、ノードは、解決要求を記述するために応じるのが必要ではありませんが、彼らが受けるかもしれないいずれも受け入れなければなりません。
ARP Example
ARPの例
Assume a HIPPI-SC switch is installed with two nodes, X and Y, connected. Each node has a unique Switch Address. Both nodes have access to the host data base (e.g. /etc/hosts) in which the network administrator has configured the network and given the two nodes IP addresses. There is an ARP agent connected to a switch port that is mapped to the address FE0 (hex). The ARP agent contains no mappings of any IP, IEEE or Switch addresses. Both nodes know their own ULAs and Switch Addresses. They want to talk to each other; each knows the other's IP address (from the host data base) but neither knows the other's ULA or Switch Address. Node X starts:
接続されて、HIPPI-サウスカロライナスイッチが2ノード、X、およびYでインストールされると仮定してください。 各ノードには、ユニークなSwitch Addressがあります。 両方のノードはネットワーク管理者がネットワークを構成して、IPアドレスを2つのノードに与えたホストデータベース(例えば、/など/ホスト)に近づく手段を持っています。 アドレスFE0(十六進法)に写像されるスイッチポートに接続されたARPエージェントがいます。 ARPエージェントはいずれもIP、IEEEまたはSwitchアドレスに関するマッピングを全く含みません。 両方のノードはそれら自身のULAsとSwitch Addressesを知っています。 彼らは互いに話したがっています。 それぞれが、もう片方のIPアドレスを知っていますが(ホストデータベースから)、どちらももう片方のULAかSwitch Addressは知りません。 ノードXは始まります:
1. Node X connects to FE0 and sends a piggyback ARP Request
requesting addresses for Y:
1. XがFE0に接続して、aを送るノードはYのためのアドレスを要求するARP Requestを背負います:
HIPPI-LE Message_Type is 1, AR_Request
HIPPI-LE Destination_Switch_Address = 0
HIPPI-LE Source_Switch_Address = X's Switch Address
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = X's ULA
ARP ar$op = 1 (request)
ARP ar$sha = X's ULA
ARP ar$spa = X's IP Address
HIPPI-LE Message_Typeは1歳です、鉱泉=XのAR_Request HIPPI-LE Destination_Switch_Address=0HIPPI-LE Source_Switch_Address=XのSwitch Address HIPPI-LE Destination_IEEE_Address=0HIPPI-LE Source_IEEE_Address=XのULA ARP ar$オプアート=1(要求する)ARP arドルのsha=XのULA ARP ar$IP Address
Renwick & Nicholson [Page 23] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[23ページ]RFC1374IPとARP
ARP ar$tha = 0
ARP ar$tpa = Y's IP Address
ARP ar$thaは0ARP arドルのtpa=YのIP Addressと等しいです。
2. The ARP agent receives the ARP request and adds an entry for X to
its address mapping table. It does not know about Y, so it does
not generate a reply.
2. ARPエージェントは、アドレス変換テーブルにARP要求を受け取って、Xのためのエントリーを加えます。 Yに関して知らないので、それは回答を発生させません。
3. Node X waits for a reply. It may set a timer to retransmit the
request periodically, but its requests will be ignored until node
Y sends an ARP request.
3. ノードXは回答を待ちます。 それは、タイマに定期的に要求を再送するように設定するかもしれませんが、ノードYがARP要求を送るまで、要求は無視されるでしょう。
4. Node Y connects to FE0 and sends an ARP request requesting
addresses for X:
4. ノードYで、XのためにFE0に接続して、ARP要求はアドレスを要求します:
HIPPI-LE Message_Type is 1, AR_Request
HIPPI-LE Destination_Switch_Address = 0
HIPPI-LE Source_Switch_Address = Y's Switch Address
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = Y's ULA
ARP ar$op = 1 (request)
ARP ar$sha = Y's ULA
ARP ar$spa = Y's IP Address
ARP ar$tha = 0
ARP ar$tpa = X's IP Address
HIPPI-LE Message_Typeは1歳です、0ARP arドルのtpa AR_Request HIPPI-LE Destination_Switch_Address=0HIPPI-LE Source_Switch_Address=YのSwitch Address HIPPI-LE Destination_IEEE_Address=0HIPPI-LE Source_IEEE_Address=YのULA ARP ar$オプアート=1(要求する)ARP arドルのsha=YのULA ARP ar$鉱泉=YのIP Address ARP ar$tha==XのIP Address
5. The ARP agent receives Y's request and adds an entry for Y to its
address mapping table. It knows about the target node, X, so it
connects to Y (using the Source_Switch_Address given in the
request) and sends an ARP Reply:
5. ARPエージェントは、アドレス変換テーブルにYの要求を受け取って、Yのためのエントリーを加えます。 それは目標ノードに関して知っています、Xによって、Y(要求で考えて、Source_Switch_Addressを使用する)に接続して、ARP Replyを送ります:
HIPPI-LE Message_Type is 2, AR_Reply
HIPPI-LE Destination_Switch_Address = Y's Switch Address
HIPPI-LE Source_Switch_Address = X's Switch Address
HIPPI-LE Destination_IEEE_Address = Y's ULA
HIPPI-LE Source_IEEE_Address = X's ULA
ARP ar$op = 2 (reply)
ARP ar$sha = X's ULA
ARP ar$spa = X's IP Address
ARP ar$tha = Y's ULA
ARP ar$tpa = Y's IP Address
HIPPI-LE Message_Typeは2歳です、tpa=YのAR_Reply HIPPI-LE Destination_Switch_Address=YのSwitch Address HIPPI-LE Source_Switch_Address=XのSwitch Address HIPPI-LE Destination_IEEE_Address=YのULA HIPPI-LE Source_IEEE_Address=XのULA ARP ar$オプアート=2(回答)ARP arドルのsha=XのULA ARP ar$鉱泉=XのIP Address ARP ar$tha=YのULA ARP ar$IP Address
6. Node Y receives the ARP reply and builds its address mapping
table entry for Node X.
6. ノードYは、ARP回答を受け取って、Node Xのためにアドレス・マッピングテーブル項目を組み込みます。
7. Node Y connects to node X and transmits an IP packet with the
following information in the HIPPI-LE header:
7. ノードYは、HIPPI-LEヘッダーでノードXに接続して、以下の情報でIPパケットを伝えます:
HIPPI-LE Message_Type is 0, AR_Data
AR_Data、HIPPI-LE Message_Typeは0歳です。
Renwick & Nicholson [Page 24] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[24ページ]RFC1374IPとARP
HIPPI-LE Destination_Switch_Address = X's Switch Address
HIPPI-LE Source_Switch_Address = Y's Switch Address
HIPPI-LE Destination_IEEE_Address = X's ULA
HIPPI-LE Source_IEEE_Address = Y's ULA
HIPPI-LE目的地_スイッチ_アドレス=XのスイッチアドレスHIPPI-LEソース_スイッチ_アドレス=YのスイッチアドレスHIPPI-LE送付先_IEEE_アドレス=XのULA HIPPI-LEソース_IEEE_アドレスはYのULAと等しいです。
8. Node X receives the IP packet. Since the ARP agent now knows
about node Y, node X can retransmit its ARP request (repeating
step 1) and receive an ARP reply:
8. ノードXはIPパケットを受けます。 ARPエージェントが今ノードYに関して知っているので、ノードXは、ARP要求(繰り返しているステップ1)を再送して、ARP回答を受け取ることができます:
HIPPI-LE Message_Type is 2, AR_Reply
HIPPI-LE Destination_Switch_Address = X's Switch Address
HIPPI-LE Source_Switch_Address = Y's Switch Address
HIPPI-LE Destination_IEEE_Address = X's ULA
HIPPI-LE Source_IEEE_Address = Y's ULA
ARP ar$op = 2 (reply)
ARP ar$sha = Y's ULA
ARP ar$spa = Y's IP Address
ARP ar$tha = X's ULA
ARP ar$tpa = X's IP Address
HIPPI-LE Message_Typeは2歳です、tpa=XのAR_Reply HIPPI-LE Destination_Switch_Address=XのSwitch Address HIPPI-LE Source_Switch_Address=YのSwitch Address HIPPI-LE Destination_IEEE_Address=XのULA HIPPI-LE Source_IEEE_Address=YのULA ARP ar$オプアート=2(回答)ARP arドルのsha=YのULA ARP ar$鉱泉=YのIP Address ARP ar$tha=XのULA ARP ar$IP Address
Address resolution is now complete for both nodes.
両方のノードに、アドレス解決は現在、完全です。
If there had been a multicast facility instead of the ARP agent in the configuration, the target nodes themselves would have received the requests and responded to them in the same way the ARP agent did.
マルチキャスト施設が構成のARPエージェントの代わりにあったなら、目標ノード自体は、ARPエージェントがした同じように要求を受け取って、それらに応じたでしょう。
Discovery of One's Own Switch Address
自分自身のスイッチアドレスの発見
The ARP example above assumed that each node had prior knowledge of its own switch address. This may be manually configured, by means that are outside the scope of this memo, when each node is connected to the switch. If a multicast capability exists, the node may discover its own address automatically when it starts up, using a protocol defined in HIPPI-LE.
上記のARPの例は、各ノードにはそれ自身のスイッチアドレスに関する先の知識があったと仮定しました。 これは手動で構成されるかもしれません、このメモの範囲の外にある手段で、各ノードがスイッチに接続されるとき。 マルチキャスト能力が存在しているなら、始動すると、ノードは自動的にそれ自身のアドレスを発見するかもしれません、HIPPI-LEで定義されたプロトコルを使用して。
In the self-address discovery protocol, a node connects to a multicast address and sends a HIPPI-LE message containing its own ULA. It receives a multicast copy of its own message, and learns its own switch address from the destination address field of the received I-field.
自己アドレス発見プロトコルでは、ノードは、マルチキャストアドレスに接続して、それ自身のULAを含むHIPPI-LEメッセージを送ります。 それは、容認されたI-分野の目的地アドレス・フィールドからそれ自身のメッセージのマルチキャストコピーを受けて、それ自身のスイッチアドレスを学びます。
HIPPI-LE self address resolution uses the same HIPPI-LE message format described in "ARP and RARP Message Format," above, with the AR_S_Request and AR_S_Response message type codes and no piggybacked ULP data. The HIPPI-LE header contents for the request are:
同じHIPPI-LEメッセージ・フォーマットが_AR_S Requestと共に上で「ARPとRARPメッセージ・フォーマット」で説明したHIPPI-LE自己アドレス解決用途、AR_S_Responseメッセージタイプコード、およびいいえはULPデータを背負いました。 要求のためのHIPPI-LEヘッダー含有量は以下の通りです。
Message_Type is 3, AR_S_Request
Destination_Address_Type = 0 (undefined)
メッセージ_Typeは3、AR_S_Request Destination_Address_Type=0です。(未定義)です。
Renwick & Nicholson [Page 25] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[25ページ]RFC1374IPとARP
Destination_Switch_Address = 0 (unknown)
Source_Address_Type = 0 (undefined)
Source_Switch_Address = 0 (unknown)
Destination_IEEE_Address = my ULA
Source_IEEE_Address = my ULA
私のULA Source_IEEE__0の(未知)の_0の(未定義)の_目的地_Switch_Address=0(未知の)ソースAddress_Type=ソースSwitch_Address=目的地IEEE_Address=Addressは私のULAと等しいです。
There is no D2 data; the packet contains only the HIPPI-FP header and D1_Area containing the HIPPI-LE header.
D2データが全くありません。 パケットはHIPPI-LEヘッダーを含むHIPPI-FPヘッダーとD1_Areaだけを含んでいます。
The node that wants to discover its address connects to the multicast address for this purpose (hex FE0 in HIPPI-SC) and transmits the request packet. What happens next depends on the particular network:
アドレスがこのためにマルチキャストアドレスに接続する(HIPPI-サウスカロライナでFE0に魔法をかける)と発見したくて、リクエスト・パケットを伝えるノード。 何が次に起こるかを特定のネットワークに頼っています:
With multicast:
マルチキャストで:
The node receives its own request and can learn its own switch
address from the I-field it receives. This is the only time a
node should use an address from a received I-field.
ノードは、それ自身の要求を受け取って、それが受けるI-野原からそれ自身のスイッチアドレスを学ぶことができます。 これはノードが容認されたI-分野からのアドレスを使用するはずである唯一の時です。
With an ARP agent:
ARPエージェントと共に:
The node may receive an AR_S_Response message with its own ULA in
the Destination_IEEE_Address field and its own switch address in
the Destination_Switch_Address field. This address may be
different from the address contained in the I-field, and should be
used instead.
それ自身のULAがDestination_IEEE_Address分野にあって、それ自身のスイッチアドレスがDestination_Switch_Address分野にある状態で、ノードはAR_S_Responseメッセージを受け取るかもしれません。 このアドレスは、I-分野に保管されていたアドレスと異なるかもしれなくて、代わりに使用されるべきです。
The ARP agent response alternative requires that the agent have prior knowledge of the node's location and ULA through some process not specified by this memo. The node may receive both its request and the agent's response if both an ARP agent and multicast are active. In this case the address it learns from the I-field is later replaced by the address given by the ARP agent in the response. Agents may assign new addresses to nodes and inform them by sending unsolicited AR_S_Response messages. Any node whose switch address is updated in this way should invalidate the switch addresses it has saved for other nodes, and use ARP to rediscover them.
ARPエージェント応答代替手段は、エージェントにはノードの位置とULAに関する先の知識がこのメモで指定されなかった何らかの過程であるのを必要とします。 ノードは両方であるなら要求とエージェントの応答の両方を受けるかもしれません。ARPエージェントとマルチキャストは活発です。 この場合、後でそれがI-分野から学ぶアドレスを応答でARPエージェントによって与えられたアドレスに取り替えます。 エージェントは、新しいアドレスをノードに割り当てて、送付の求められていないAR_S_Responseメッセージでそれらを知らせるかもしれません。 スイッチアドレスがこのようにアップデートされるどんなノードも、それが他のノードのために保存したスイッチアドレスを無効にして、それらを再発見するのにARPを使用するはずです。
If the node reacts correctly to either the multicast request or agent-generated response, it can discover its address without having to know whether or not an ARP agent is active. The full procedure is:
ノードが正しくマルチキャスト要求かエージェントが発生している応答に反応するなら、ARPエージェントが活発であるかどうかを知る必要はなくて、それはアドレスを発見できます。 完全な手順は以下の通りです。
1. Transmit the AR_S_Request
1. S_が要求するAR_を伝えてください。
Renwick & Nicholson [Page 26] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[26ページ]RFC1374IPとARP
2. When a connection arrives, accept it and save the I-field for
later analysis.
2. 接続が到着したらそれを受け入れてください、そして、後で解析するためにI-分野を節約してください。
3. Receive the message and look at the HIPPI-LE header. If the
message is Message Type AR_S_Request, analyze the I-field to
discover the node's own switch address. HIPPI-SC I-field formats
suggest the following:
3. メッセージを受け取ってください、そして、HIPPI-LEヘッダーを見てください。 メッセージがMessage Type AR_S_Requestであるなら、I-分野を分析して、ノードの自己のスイッチアドレスを発見してください。 HIPPI-サウスカロライナI-フィールド形式は以下を示します:
if bit 25 == 1
Address type is HIPPI-SC logical address.
if bit 27 == 1
take address from bits 23-12
else
take address from bits 11-00
endif
else
Address is unusable (source route)
endif
25 == 1 噛み付かれるなら、AddressタイプはHIPPI-サウスカロライナ論理アドレスです。ビット27 == 1撮影がビット23-12からほかの撮影を記述するなら、ビット11-00endifのほかのAddressからのアドレスは使用不可能な(送信元経路)endifです。
This is a one-time operation. Once the node knows an address for
itself, it should not take any new address from a received I-
field.
これは1回の操作です。 ノードがいったんそれ自体のためのアドレスを知っていると、それは容認されたI分野から少しの新しいアドレスも取るべきではありません。
4. If a message of type AR_S_Response arrives and the
Destination_IEEE_Address field contains the node's own ULA, take
the new switch address from the Destination_Switch_Address field
and its type from the Destination_Address_Type field.
4. _タイプAR_S Responseに関するメッセージが到着して、Destination_IEEE_Address分野がノードの自身のULAを含むなら、Destination_Switch_Address分野とそのタイプからDestination_Address_Type分野から新しいスイッチアドレスを取ってください。
5. The node should invalidate its ARP tables when an AR_S_Response
changes its own switch address, to force retransmission of ARP
requests containing its new address to all the remote nodes with
which it communicates.
5. AR_S_Responseがそれが交信するすべての遠隔ノードに新しいアドレスを含むARP要求の「再-トランスミッション」を強制するためにそれ自身のスイッチアドレスを変えるとき、ノードはARPテーブルを無効にするはずです。
Path MTU Discovery
経路MTU発見
RFC 1191 [13] describes the method of determining MTU restrictions on an arbitrary network path between two hosts. HIPPI nodes may use this method without modification to discover restrictions on paths between HIPPI-SC LANs and other networks. Gateways between HIPPI-SC LANs and other types of networks should implement RFC 1191.
RFC1191[13]は2人のホストの間の任意のネットワーク経路でMTU制限を決定する方法を説明します。 HIPPIノードは、HIPPI-サウスカロライナLANと他のネットワークの間の経路で制限を発見するのに変更なしでこの方法を使用するかもしれません。 HIPPI-サウスカロライナLANと他のタイプのネットワークの間のゲートウェイはRFC1191を実行するはずです。
Channel Data Rate Discovery
チャンネルデータ信号速度発見
HIPPI exists in two data rate options (800 megabit/second and 1600 megabit/second). The higher data rate is achieved by making the HIPPI 64 bits parallel instead of 32, using an extra cable containing 32 additional data bits and four parity bits. HIPPI-SC switches can
HIPPIは2つのデータ信号速度オプション(800メガビット/秒と1600メガビット/秒)で存在しています。 より高いデータ信号速度はビットが32の代わりに沿うHIPPI64を作ることによって、達成されます、32個の追加データ・ビットと4つのパリティビットを含む余分なケーブルを使用して。 HIPPI-サウスカロライナスイッチはそうすることができます。
Renwick & Nicholson [Page 27] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[27ページ]RFC1374IPとARP
be designed to attach to both. Source and Destination HIPPI implementations can be designed to operate at either rate, selectable at the time a connection is established. The "W" bit (bit 28) of the I-field controls the width of the connection through the switch. Sources with both cables A and B attached to the switch may set the "W" bit to request a 1600 megabit/second connection. If the requested destination also has both cables attached, the switch can connect Source to Destination on both cables. If the requested Destination has only Cable A, the switch rejects the request. Sixty-four bit Sources can connect to 32 bit Destinations by requesting with the "W" bit clear and not using Cable B. Sixty-four bit Destinations must examine the "W" bit in the received I-field and use or ignore Cable B accordingly. Note that both INTERCONNECT signals stay active while a 64 bit HIPPI is used in 32 bit mode.
両方に付くには、設計されてください。 ソースとDestination HIPPI実現はどちらのレートでも作動するように設計される場合があります、接続が確立される時代に、選択可能です。 「W」はスイッチを通した接続の幅のI-フィールド制御の(ビット28)に噛み付きました。 ケーブルAとBの両方がスイッチに取り付けられているソースは1600メガビット/秒を要求するために噛み付かれた「W」接続を設定するかもしれません。 また、要求された目的地で両方のケーブルを取り付けるなら、スイッチは両方のケーブルの上のDestinationにSourceを接続できます。 要求されたDestinationにCable Aしかないなら、スイッチは要求を拒絶します。 「W」と共にはっきりと噛み付かれて、ケーブルのB.の64ビットの目的地を使用しないのがそれに従って、ケーブルBを容認されたI-分野で「W」ビットを調べて、使用しなければならないか、または無視しなければならないよう要求することによって、64ビットのSourcesは32ビットのDestinationsに接続できます。 64ビットのHIPPIが32ビットのモードで使用されている間両方のINTERCONNECT信号がアクティブな状態で残っていることに注意してください。
The following table summarizes the possible combinations, the switch's action for each, and the width of the resulting connection.
以下のテーブルは可能な組み合わせ、それぞれのためのスイッチの動作、および結果として起こる接続の幅をまとめます。
Destination
+-------------------+-------------------+
| 32 | 64 |
+----+-----+-------------------+-------------------+
| | W=0 | Accept 32 | Accept 32 |
| 32 +-----+-------------------+-------------------+
| | W=1 | N/A | N/A |
Source +----+-----+-------------------+-------------------+
| | W=0 | Accept 32 | Accept 32 |
| 64 +-----+-------------------+-------------------+
| | W=1 | Reject | Accept 64 |
+----+-----+-------------------+-------------------+
目的地+-------------------+-------------------+ | 32 | 64 | +----+-----+-------------------+-------------------+ | | W=0| 32を受け入れてください。| 32を受け入れてください。| | 32 +-----+-------------------+-------------------+ | | W=1| なし| なし| ソース+----+-----+-------------------+-------------------+ | | W=0| 32を受け入れてください。| 32を受け入れてください。| | 64 +-----+-------------------+-------------------+ | | W=1| 廃棄物| 64を受け入れてください。| +----+-----+-------------------+-------------------+
HIPPI Connection Combinations
HIPPI接続組み合わせ
If the path between a 64 bit Source and a 64 bit Destination includes more than one switch, and the route between switches uses a link that is only 32 bits wide, the switch rejects 64 bit connection requests as if the Destination did not have 64 bit capability.
64ビットのSourceと64ビットのDestinationの間の経路が1個以上のスイッチを含んで、スイッチの間のルートが幅32ビットであるだけであるリンクを使用するなら、まるでDestinationには64ビットの能力がないかのようにスイッチは64ビットの接続要求を拒絶します。
In a mixed LAN of 32 bit and 64 bit HIPPIs, a 64 bit Source needs to know the data rates available at each Destination and on the path to it. This can be known a priori by manual configuration, or it can be discovered dynamically. The only reliable method of discovery is simply to attempt a 64 bit connection with Camp-on. As long as 64 bit connections succeed, the Source knows the Destination and path are double width. If a 64 bit connection is rejected, the Source tries to connect for 32 bits. If the 32 bit connection succeeds, the Source assumes that the Destination or path is not capable of double width operation, and uses only 32 bit requests after that. If the 32
32ビットと64ビットのHIPPIsの複雑なLANでは、64ビットのSourceは、各Destinationにおいて経路の上でそれに利用可能なデータ信号速度を知る必要があります。 手動の構成が先験的にこれを知ることができますか、またはダイナミックにそれを発見できます。 発見の唯一の確かな方法は単にCampとの64ビットの接続を試みることです。 64ビットの接続が成功する限り、Sourceは、Destinationと経路がダブル幅であることを知っています。 64ビットの接続が拒絶されるなら、Sourceは32ビット接続しようとします。 32ビットの接続が成功するなら、SourceはDestinationか経路がダブル幅操作ができないと仮定して、その後に32ビットだけの要求を使用します。 32です。
Renwick & Nicholson [Page 28] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[28ページ]RFC1374IPとARP
bit request is rejected, the Source assumes that the Destination or path is down and makes no determination of its capability.
噛み付いている要求が拒絶されて、SourceはDestinationか経路が下がっていると仮定して、能力の決断を全くしません。
The Double_Wide bit in the HIPPI-LE header, if nonzero, gives the node that receives it a hint that the 64 bit connection attempt may be worthwhile when sending on the return path.
HIPPI-LEヘッダーのDouble_Wideビットは非零であるならリターンパスで発信するとき、64ビットの接続試み価値があるかもしれないというヒントをそれを受けるノードに与えます。
Note that Camp-on must be used at least in the 64 bit attempt, because it removes some ambiguity from the meaning of rejects. If the request is made with the "W" bit and no Camp-on, a reject could mean either that the Destination has no Cable B or that it is simply busy, and no conclusion can be drawn as to its status for 64 bit connections.
少なくとも64ビットの試みにCampを使用しなければならないことに注意してください、廃棄物の意味から何らかのあいまいさを取り除くので。 「W」ビットにもかかわらず、どんなキャンプと共にも要求をしないなら、廃棄物は目的地にはケーブルBが全くないか、それが単に忙しく、または64ビットの接続のために状態に関してどんな結論にも達せられることができないことを意味するかもしれません。
Performance
パフォーマンス
The HIPPI connection rules are designed to permit best utilization of the available HIPPI throughput under the constraint that each Destination must be made available frequently to receive packets from different Sources. This discipline asks both Sources and Destinations to minimize connection setup overhead to deliver high performance. Low connection setup times are easily achieved by hardware implementations, but overhead may be too high if software is required to execute between the initial request of a connection and the beginning of data transfer. Hardware implementations in which connection setup and data transfer proceed from a single software action are very desirable.
HIPPI接続規則は、頻繁に各Destinationを利用可能にしなければならないという規制での有効なHIPPIスループットの最も良い利用が異なったSourcesからパケットを受けることを許可するように設計されています。 この規律は、高性能を送るために接続設定オーバーヘッドを最小にするようにSourcesとDestinationsの両方に頼みます。 低い接続設定時間による容易にハードウェア的に達成されて、ソフトウェアが必要であるならしかし、実現、オーバーヘッドが高過ぎるかもしれないということです。接続の初期の要求とデータ転送の始まりの間で実行します。 接続設定とデータ転送がただ一つのソフトウェア動作から進んでいるハードウェア実装は非常に望ましいです。
HIPPI connections are controlled by HIPPI Sources; a Destination, being unable to initiate a disconnect without the possibility of data loss, is a slave to the Source once it has accepted a connection. Optimizations of connection strategy are therefore the province of the HIPPI Source, and several optimizations are permitted.
HIPPI接続はHIPPI Sourcesによって監督されます。 データの損失の可能性なしで分離を開始できないで、いったん接続を受け入れると、DestinationはSourceの奴隷です。 したがって、接続戦略の最適化はHIPPI Sourceの州です、そして、いくつかの最適化が受入れられます。
If the rate of available message traffic is less than the available HIPPI throughput and Destinations are seldom busy when a connection is requested, connection optimizations do not pay off and the simplest strategy of waiting indefinitely for each connection to be made and sending messages strictly in the order queued cannot be improved upon. However if some nodes are slow, or network applications can send or receive messages at a higher aggregate rate than the available HIPPI bandwidth, Sources may frequently encounter a busy Destination. In these cases, certain host output queuing strategies may enhance channel utilization. Sources may maintain separate output queues for different HIPPI Destinations, and abandon one Destination in favor of another if a connection attempt without Camp-on is rejected or a connection request with Camp-on is not accepted within a predetermined interval. Such a strategy results in
利用可能なメッセージ交通の速度が接続が要求されているとき、有効なHIPPIスループットとDestinationsがめったに忙しくないというよりも少ないなら、接続最適化はうまく行きません、そして、オーダーが列に並ばせた作られていて、厳密にメッセージを送ることを各接続を無期限に待つ最も簡単な戦略は改良できません。 しかしながら、いくつかのノードが遅いか、またはネットワーク応用が利用可能なHIPPI帯域幅より高い集合レートでメッセージを送るか、受け取ることができるなら、Sourcesは頻繁に忙しいDestinationに遭遇するかもしれません。 これらの場合では、あるホスト出力列を作り戦略はチャンネル利用を機能アップするかもしれません。 Campのない接続試みが拒絶されるか、またはCampとの接続要求が予定された間隔以内に受け入れられないなら、ソースは、異なったHIPPI Destinationsのために別々の出力キューを維持して、1Destinationを捨てて別のものを選ぶかもしれません。 戦略がもたらすそのようなもの
Renwick & Nicholson [Page 29] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[29ページ]RFC1374IPとARP
aborted connection sequences (defined in HIPPI-PH: REQUEST is deasserted before any data is sent). Destinations must treat these as normal events, perhaps counting them but otherwise ignoring them.
接続系列(HIPPI-ペーハーで定義されて、どんなデータも送る前に: REQUESTについて反断言する)を中止しました。 目的地は恐らくそれらを数える正常な出来事にもかかわらず、別の方法でそれらを無視するとしてこれらを扱わなければなりません。
Two components of connection setup time are out of the control of both Source and Destination. One is the time required for the switch to connect Source to Destination, currently less than four microseconds in the largest commercially available (32 port) switch. The second component is the round trip propagation time of the REQUEST and CONNECT signals, negligible on a standard 25 meter copper HIPPI cable, but contributing a total of about 10 microseconds per kilometer on fiber optic links. HIPPI-SC LANs spanning more than a few kilometers will have reduced throughput. Limited span networks with buffered gateways or bridges between them may perform better than long serial HIPPI links.
接続準備時間の2つのコンポーネントがSourceとDestinationの両方のコントロールから脱しています。 1つはスイッチがDestination(現在の最も大きい商業的に利用可能な(32ポート)スイッチの4マイクロセカンド未満)にSourceを接続するのに必要である時間です。 2番目のコンポーネントはREQUESTの周遊旅行伝播時間です、そして、CONNECTは合図します、25メーターの標準の銅のHIPPIケーブルで取るにたらないです、しかし、光ファイバーの上で1キロメートルあたり合計およそ10マイクロセカンド貢献するのがリンクされます。 かなり多くのキロメートルにかかるHIPPI-サウスカロライナLANがスループットを減らしてしまうでしょう。 それらの間のバッファリングされたゲートウェイか橋がある株式会社長さネットワークは長い連続のHIPPIがリンクするよりよく働くかもしれません。
A Source is required to drop its connection after the transmission of 68 HIPPI bursts. This number was chosen to allow the transmission of one maximum sized packet or a reasonable number of smaller sized packets. The following table lists some possibilities, with calculated maximum burst and throughput rates in millions (10**6) of bytes per second:
Sourceが、68HIPPIのトランスミッションがはち切れた後に接続を落とすのに必要です。 この数が1つの最大の大きさで分けられたパケットのトランスミッションを許容するために選ばれたか、または、より小さいことの相当な数はパケットを大きさで分けました。 以下のテーブルは1秒あたりのバイトの数百万(10**6)で計算された最大の炸裂と押出量でいくつかの可能性を記載します:
Maximum HIPPI Throughput Rates
最大のHIPPI押出量
Number Number Hold Burst ------Max throughput MB/sec-------
User of of Time Rate Connection Setup Overhead (usec)
Data Packets Bursts (usec) MB/sec 10 30 60 90 120 150
---- ------- ------ ------ ------ ---- ---- ---- ---- ---- ----
63K 1 64 654 98.7 97.2 94.4 90.4 86.8 83.4 80.3
32K 2 66 665 98.6 97.1 94.3 90.4 86.8 83.5 80.4
16K 4 68 667 98.3 96.8 94.1 90.2 86.6 83.3 80.2
8K 7 63 587 97.8 96.1 93.0 88.7 84.8 81.2 77.8
4K 13 65 551 96.7 95.0 91.7 87.2 83.1 79.4 76.0
2K 22 66 476 94.6 92.7 89.0 84.0 79.6 75.6 72.0
1K 34 68 384 90.8 88.5 84.2 78.5 73.5 75.8 65.3
数が保持する数ははち切れました。------マックススループットMB/秒------- ユーザ、時間では、接続設定オーバーヘッド(usec)データ・パケット炸裂が(usec)MB/秒の10 30 60 90 120 150であると評定してください。---- ------- ------ ------ ------ ---- ---- ---- ---- ---- ---- 63K1 64、654、98.7 97.2 94.4 90.4 86.8 83.4 80.3 32K2 66、665、98.6 97.1 94.3 90.4 86.8 83.5 80.4 16K4 68、667、98.3 96.8 94.1 90.2 86.6 83.3 80.2、8K7 63、587、97.8 96.1 93.0 88.7 84.8 81.2 77.8、4K13 65 551、96.7 95.0 91.7 87.2 83.1 79.4 76.0、2K22 66 476、94.6 92.7 89.0 84.0 79.6 75.6 72.0、1K34 68 384、90.8 88.5 84.2 78.5 73.5 75.8 65.3
These calculations are based 259 40 ns clock periods to transmit a full burst and 23 clock periods for a short burst. (HIPPI-PH specifies three clock periods of overhead per burst.) A packet of "n" kilobytes of user data consists of "n" full bursts and one short burst equal in length to the number of bytes in the HIPPI, LLC, IP and TCP headers. "Hold Time" is the minimum connection duration needed to send the packets. "Burst Rate" is the effective transfer rate for the duration of the connection, not counting connection switching time. Throughput rates are in megabytes/second, accounting for connection switching times of 10, 30, 60, 90, 120 and 150 microseconds. These calculations ignore any limit on the rate at
これらの計算は短い炸裂のために完全な炸裂と23回の時計の期間を伝える40ナノ秒の259回のベースの時計の期間です。 (HIPPI-ペーハーは3回の時計の期間の1炸裂あたりのオーバーヘッドを指定します。) 「n」キロバイトの利用者データのパケットはHIPPI、LLC、IP、およびTCPヘッダーで長さにおいてバイト数と等しい「n」完全な炸裂と1回の短い炸裂から成ります。 「保持Time」は持続時間がパケットを送る必要があった最小の接続です。 「炸裂Rate」は接続切換え時間を数えるのではなく、接続の持続時間のための有効な転送レートです。 10、30、60、90、120、および150マイクロセカンドの接続切り換え倍を説明して、メガバイト/秒に、押出量があります。 これらの計算はレートにおけるどんな限界も無視します。
Renwick & Nicholson [Page 30] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[30ページ]RFC1374IPとARP
which a Source or Destination can process small packets; such limits may further reduce the available throughput if small packets are used.
どのa SourceかDestinationの缶の加工処理した小型小包。 小型小包が使用されているなら、そのような限界はさらに有効なスループットを減らすかもしれません。
Sharing the Switch
スイッチを共有します。
Network interconnection is only one potential application of HIPPI and HIPPI-SC switches. While network applications need very frequent transient connections, other applications may favor longer term or even permanent connections between Source and Destination. Since the switch can serve each Source or Destination with hardware paths totally separate from every other, it is quite feasible to use the same switch to support LAN interconnects and computer/peripheral applications simultaneously.
ネットワーク相互接続はHIPPIとHIPPI-サウスカロライナスイッチの1つの潜在的アプリケーションにすぎません。 ネットワーク応用が非常に頻繁な一時的な接続を必要としている間、他のアプリケーションはSourceとDestinationの間で、より長い期間か永久接続さえ支持するかもしれません。 スイッチがあらゆるもう一方から完全に別々のハードウェア経路を各SourceかDestinationに供給できるので、同時にLAN内部連絡とコンピュータ/周囲のアプリケーションをサポートするのに同じスイッチを使用するのはかなり可能です。
Switch sharing is no problem when unlike applications do not share a HIPPI cable on any path. However if a host must use a single input or output cable for network as well as other kinds of traffic, or if a link between switches must be shared, care must be taken to ensure that all applications are compatible with the connection discipline described in this memo. Applications that hold connections too long on links shared with network traffic may cause loss of network packets or serious degradation of network service.
スイッチ共有はアプリケーションと異なって問題がないのがどんな経路でもHIPPIケーブルを共有しないということです。 しかしながら、ホストが他の種類のトラフィックと同様にネットワークにただ一つの入力か出力ケーブルを使用しなければならないか、またはスイッチの間のリンクを共有しなければならないなら、すべてのアプリケーションがこのメモで説明される接続規律と互換性があるのを保証するために注意しなければなりません。 ネットワークトラフィックと共有されたリンクの上に長く接続を支え過ぎるアプリケーションはネットワークパケットの損失かネットワーク・サービスの重大な退行を引き起こすかもしれません。
Appendix A -- HIPPI Basics
付録A--HIPPI基礎
This section is included as an aid to readers who are not completely familiar with the HIPPI standards.
このセクションは完全にHIPPI規格に詳しいというわけではない読者への援助として含まれています。
HIPPI-PH describes a parallel copper data channel between a Source and a Destination. HIPPI transmits data in one direction only, so that two sets are required for bidirectional flow. The following figure shows a simple point-to-point link between two computer systems:
HIPPI-ペーハーはSourceとDestinationの間の平行な銅のデータ・チャンネルを説明します。 HIPPIがデータを一方向だけに送るので、2セットが双方向の流れに必要です。 以下の図は2個のコンピュータ・システムの間の簡単なポイントツーポイント接続を示しています:
Renwick & Nicholson [Page 31] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[31ページ]RFC1374IPとARP
+----------+ +----------+ | | | | | +--------+ +--------+ | | | HIPPI | Cable | HIPPI | | | | +--------------------->| | | | | Source | | Dest. | | | System +--------+ +--------+ System | | X +--------+ +--------+ Y | | | HIPPI | Cable | HIPPI | | | | |<---------------------+ | | | | Dest. | | Source | | | +--------+ +--------+ | | | | | +----------+ +----------+
+----------+ +----------+ | | | | | +--------+ +--------+ | | | HIPPI| ケーブル| HIPPI| | | | +--------------------->|、|、|、|、| ソース| | Dest。 | | | システム+--------+ +--------+ システム| | X+--------+ +--------+ Y| | | HIPPI| ケーブル| HIPPI| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | | | | Dest。 | | ソース| | | +--------+ +--------+ | | | | | +----------+ +----------+
A Simple HIPPI Duplex Link
簡単なHIPPI複式のリンク
Parallel copper cables may be up to 25 meters in length.
平行な銅のケーブルは長さが最大25メーターであるかもしれません。
In this document, all HIPPI connections are assumed to be paired HIPPI channels.
本書では、すべてのHIPPI接続が対にされたHIPPIチャンネルであると思われます。
HIPPI-PH has a single optional feature: it can use a single cable in each direction for a 32 bit parallel channel with a maximum data rate of 800 megabit/second, or two cables for 64 bits and 1600 megabit/second. Cable A carries bits 0-31 and is used in both modes; Cable B carries bits 32-63 and is use only with the 1600 megabit/second data rate option.
HIPPI-ペーハーには、ただ一つのオプション機能があります: それは32ビットの平行なチャンネルに800メガビット/秒の最大のデータ信号速度、または64ビットと1600メガビット/2番目のための2本のケーブルで各方向に単一のケーブルを使用できます。 ケーブルAは、ビット0-31を運んで、両方のモードで使用されます。 ケーブルBは、ビット32-63を運んで、単に2番目の1600年のメガビット/データ信号速度オプションで使用です。
HIPPI Signal Hierarchy
HIPPI信号階層構造
HIPPI has the following hardware signals:
HIPPIには、以下のハードウェア信号があります:
Source to Destination
目的地へのソース
INTERCONNECT A
INTERCONNECT B (64 bit only)
CLOCK (25 MHz)
REQUEST
PACKET
BURST
DATA (32 or 64 signals)
PARITY (4 or 8 signals)
INTERCONNECT A INTERCONNECT B(64ビット専用)CLOCK(25MHz)REQUEST PACKET BURST DATA(32か64の信号)PARITY(4か8つの信号)
Destination to Source
ソースへの目的地
INTERCONNECT A
INTERCONNECT B (64 bit only)
内部連絡Bとインタコネクトしてください。(64ビット専用)
Renwick & Nicholson [Page 32] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[32ページ]RFC1374IPとARP
CONNECT
READY
準備ができていた状態で、接続してください。
The INTERCONNECT lines carry DC voltages that indicate that the
cable is connected and that the remote interface has power.
INTERCONNECT is not used for signaling.
INTERCONNECT系列はケーブルが接続されていて、リモートインタフェースにはパワーがあるのを示すDC電圧を運びます。 INTERCONNECTはシグナリングに使用されません。
The CLOCK signal is a continuous 25 MHz (40 ns period) square
wave. All Source-to-Destination signals are synchronized to the
clock.
CLOCK信号は連続した25MHz(40ナノ秒の期間)の矩形波です。 Sourceから目的地へのすべての信号が時計と同期します。
The REQUEST and CONNECT lines are used to establish logical
connections. A connection is always initiated by a Source as it
asserts REQUEST. At the same time it puts 32 bits of data on DATA
lines 0-31, called the I-field. The Destination samples the DATA
lines and can complete a connection by asserting CONNECT. Packets
can be transmitted only while both REQUEST and CONNECT are
asserted.
REQUESTとCONNECT系列は、論理的な接続を証明するのに使用されます。 REQUESTについて断言するとき、接続はいつもSourceによって開始されます。同時に、それはI-分野と呼ばれるDATA系列0-31に32ビットのデータを置きます。 Destinationは、DATA系列を抽出して、CONNECTについて断言することによって、接続を終了できます。 REQUESTとCONNECTの両方が断言されているだけである間、パケットを伝えることができます。
A Destination can also reject a connection by asserting CONNECT
for only a short interval between 4 and 16 HIPPI clock periods
(160-640 nanoseconds). The Source knows a connection has been
accepted when CONNECT is asserted for more than 16 clocks or it
receives a READY pulse.
また、Destinationは、4〜16HIPPIが(160-640ナノ秒)の期間に時間を計る短い間隔だけの間CONNECTについて断言することによって、接続を拒絶できます。 Sourceは、CONNECTが16個以上の時計のために断言されるか、またはREADYパルスを受けるとき、接続が受け入れられたのを知っています。
Either Source or Destination can terminate a connection by
deasserting REQUEST or CONNECT, respectively. Normally
connections are terminated by the Source after its last Packet has
been sent. A Destination cannot terminate a connection without
potential loss of data.
SourceかDestinationのどちらかがそれぞれdeasserting REQUESTかCONNECTによる接続を終えることができます。 通常、最後のPacketを送った後にSourceは接続を終えます。 Destinationは潜在的データの喪失なしで接続を終えることができません。
Renwick & Nicholson [Page 33] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[33ページ]RFC1374IPとARP
+------+-------------------------+------+
| Idle | Connected | Idle | . . .
+------+-------------------------+------+
/ \
/ \
/ \
/ \
/ \
+-------+ +-------+ +-------+ +-------+
|I-field| |Packet | |Packet | |Packet |
+-------+ +-------+ +-------+ +-------+
/ \
/ \
/ \
/ \
/ \
/ \
/ \
+-----+ +-----+ +-----+
|Burst| |Burst|...|Burst|
+-----+ +-----+ +-----+
+------+-------------------------+------+ | 怠けてください。| 接続されます。| 怠けてください。| . . . +------+-------------------------+------+ / \ / \ / \ / \ / \ +-------+ +-------+ +-------+ +-------+ |I-分野| |パケット| |パケット| |パケット| +-------+ +-------+ +-------+ +-------+ / \ / \ / \ / \ / \ / \ / \ +-----+ +-----+ +-----+ |押し破かれます。| |押し破かれます。|...|押し破かれます。| +-----+ +-----+ +-----+
HIPPI Logical Framing Hierarchy
HIPPIの論理的な縁どり階層構造
The Source asserts PACKET for the duration of a Packet
transmission, deasserting it to indicate the end of a Packet. A
sequence of Bursts comprise a Packet. To send a burst, a Source
asserts the BURST signal for 256 clock periods, during which it
places 256 words of data on the DATA lines. The first or last
Burst of a Packet may be less than 256 clock periods, allowing the
transmission of any integral number of 32 or 64 bit words in a
Packet.
Packetの端を示すためにそれについて反断言して、SourceはPacketトランスミッションの持続時間のためにPACKETについて断言します。 Burstsの系列はPacketを包括します。 炸裂を送るために、SourceはそれがDATA系列に関してデータの256の単語を課す256回の時計の期間、BURST信号について断言します。 Packetの1番目か最後のBurstは256回未満の時計の期間であるかもしれません、Packetでのどんな整数の32ビットか64ビットの単語の伝達も許して。
The READY signal is a pulse four or more clock periods long. Each
pulse signals the Source that the Destination can receive one
Burst. The Destination need not wait for a burst before sending
another READY if it has burst buffers available; up to 63
unanswered READYs may be sent, allowing HIPPI to operate at full
speed over distances of many kilometers. If a Source must wait
for flow control, it inserts idle periods between Bursts.
長い間、READY信号は、パルスfourか、より多くの時計の期間です。 各パルスは、Destinationが1Burstを受けることができるのをSourceに示します。 それが利用可能なバッファを押し破いたなら別のREADYを送る前に、Destinationは炸裂を待つ必要はありません。 HIPPIが全速力で多くのキロメートルの距離にわたって作動するのを許容して、最大63答えのないREADYsを送るかもしれません。 Sourceがフロー制御を待たなければならないなら、それは活動していない期間をBurstsの間に挿入します。
Renwick & Nicholson [Page 34] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[34ページ]RFC1374IPとARP
+------------------------------------------------+
REQUEST---+ +----
+--------------------------------------------+
CONNECT---------+ +--
+---------------------------------------+
PACKET-------------+ +----
+------------------------------------------------+ 要求---+ +---- +--------------------------------------------+は接続します。---------+ +-- +---------------------------------------+ パケット-------------+ +----
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
READY------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--
++++++++++++++++準備ができています。------------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +--
+-------+ +-------+ +-------+ +-----+
BURST--------------+ +-+ +-+ +-+ +--------
+-------+ +-------+ +-------+ +-----+ 炸裂--------------+ +-+ +-+ +-+ +--------
DATA------I-field----DATA------DATA------DATA-----DATA----------
データ------I-分野----データ------データ------データ-----データ----------
HIPPI Signal Timing Diagram
HIPPI信号タイミングダイヤグラム
Serial HIPPI
連続のHIPPI
There is no ANSI standard for HIPPI other than the parallel copper
cable version. However an implementors' agreement exists,
specifying a serial protocol to extend HIPPI signals on optical
fiber or coaxial copper cable. Serial links may be used
interchangeably with parallel links to overcome HIPPI distance
limitations; they are transparent to the Source and Destination,
except for the possibility of longer propagation delays.
平行な銅のケーブルバージョン以外のHIPPIのANSI規格が全くありません。 しかしながら、光ファイバの上のHIPPI信号か同軸銅のケーブルを広げるために連続のプロトコルを指定して、実装者間協定は存在しています。 連続のリンクはHIPPI距離限界を克服するのに平行なリンクと共に互換性を持って使用されるかもしれません。 それらはSourceと、より長い伝播遅延の可能性以外のDestinationに透明です。
I-Field and Switch Control
I-分野とスイッチ制御装置
The REQUEST, CONNECT and I-field features of HIPPI-PH were
designed for the control of switches as described in HIPPI-SC. A
switch is a hub with a number of input and output HIPPI ports.
HIPPI Sources are cabled to switch input ports, and switch output
ports are cabled to HIPPI Destinations. When a HIPPI Source
requests a connection, the switch interprets the I-field to select
an output port and electrically connects the HIPPI Source to the
HIPPI Destination on that port. Once connected, the switch does
not interact with the HIPPIs in any way until REQUEST or CONNECT
is deasserted, at which time it breaks the physical connection and
deasserts its output signals to both sides. Some existing switch
implementations can switch connections in less than one
microsecond. There is the potential for as many simultaneous
connections, each transferring data at HIPPI speeds, as there are
input or output ports on the switch. A switch offers much greater
total throughput capacity than broadcast or ring media.
HIPPI-ペーハーのREQUEST、CONNECT、およびI-分野機能はスイッチのコントロールのためにHIPPI-サウスカロライナで説明されるように設計されました。 スイッチは多くの入出力HIPPIポートがあるハブです。 HIPPI Sourcesは入力ポートを切り換えるために電報を打たれます、そして、スイッチ出力ポートはHIPPI Destinationsに電報を打たれます。 HIPPI Sourceが接続を要求するとき、スイッチは、出力ポートを選択するためにI-分野を解釈して、電気的にそのポートの上のHIPPI DestinationにHIPPI Sourceを接続します。 いったん接続されると、REQUESTかCONNECTが反断言されて、その時に物理接続と出力が両側に示すdeassertsを壊すまで、スイッチは何らかの方法でHIPPIsと対話しません。 いくつかの既存のスイッチ実装が1マイクロセカンド未満で接続を切り換えることができます。 HIPPI速度には同じくらい多くの同時接続における潜在的の、そして、それぞれ移しているデータがあります、スイッチの上のポートが入力されるか、または出力されるとき。 スイッチは放送されるよりはるかに大きい総処理能力かリングメディアを提供します。
Renwick & Nicholson [Page 35] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[35ページ]RFC1374IPとARP
31 28 26 23 11 0
+-+---+-+-+---+-+-----------------------+-----------------------+
|L| |W|D|PS |C| Source Address | Destination Address |
+-+---+-+-+---+-+-----------------------+-----------------------+
31 28 26 23 11 0 +-+---+-+-+---+-+-----------------------+-----------------------+ |L| |W|D|PS|C| ソースアドレス| 送付先アドレス| +-+---+-+-+---+-+-----------------------+-----------------------+
HIPPI-SC I-field Format (Logical Address Mode)
HIPPI-サウスカロライナI-フィールド形式(論理アドレスモード)
L = Locally defined (1 => entire I-field is locally defined)
W = Width (1 => 64 bit connection)
D = Direction (1 => swap Source and Destination Address)
PS = Path Selection (01 => Logical Address Mode)
C = Camp-on (1 => wait until Destination is free)
L=局所的に定義された(1つの=>全体のI-分野が局所的に定義されます)W=幅(=の>の64ビットの1つの接続)D=方向(1=>スワッピングSourceとDestination Address)PS=経路Selection(01=>Logical Address Mode)C=陣営(1つのDestinationが無料であるまでの=>待ち)
HIPPI-SC defines I-field formats for two different addressing
modes. The first, called Source Routing, encodes a string of port
numbers in the lower 24 bits. This string specifies a route over
a number of switches. A Destination's address may differ from one
Source to another if multiple switches are used.
HIPPI-サウスカロライナは2つの異なったアドレッシング・モードのためにI-フィールド形式を定義します。 Sourceルート設定と呼ばれる1番目は低級24ビットの一連のポートナンバーをコード化します。 このストリングは多くのスイッチの上にルートを指定します。 複数のスイッチが使用されているなら、Destinationのアドレスは1Sourceから別のSourceまで異なるかもしれません。
The second format, called Logical Address Mode, defines two 12 bit
fields, Source Address and Destination Address. A Destination's
12 bit Switch Address is the same for all Sources. Switches
commonly have address lookup tables to map 12 bit logical
addresses to physical ports. This mode is used for networking.
Logical Address Modeと呼ばれる2番目の形式は2 12ビットの分野、Source Address、およびDestination Addressを定義します。 すべてのSourcesに、Destinationの12ビットのSwitch Addressは同じです。 スイッチは一般的に物理的なポートへの地図の12ビットの論理アドレスにアドレスルックアップ表を持っています。 このモードはネットワークに使用されます。
Control fields in the I-field are:
I-分野の制御フィールドは以下の通りです。
L The "Locally Defined" bit, when set, indicates that the I-field
is not in the standard format. The meaning of bits 30-0 are
locally defined.
設定されると、噛み付かれた状態で「局所的に定義Lにされていること」は、標準書式にはI-分野がないのを示します。 ビット30-0の意味は局所的に定義されます。
W The Width bit, when set, requests a 64 bit connection through
the switch. It is meaningless if Cable B is not installed at
the Source. If W is set and either the Source or the requested
Destination has no Cable B to the switch, the switch rejects
the connection. Otherwise the switch connects both Cable A and
Cable B if W is set, or Cable A only if W is clear. This
feature is useful if both Source and Destination
implementations can selectively disable or enable Cable B on
each new connection.
スイッチを通した64ビットの接続は、設定されるとW Widthが噛み付いたよう要求します。 Cable BがSourceにインストールされないなら、無意味です。 Wが設定されて、Sourceか要求されたDestinationのどちらかがCable Bを全くスイッチに持っていないなら、スイッチは接続を拒絶します。 さもなければ、Wが設定されるなら、スイッチがCable AとCable Bの両方を接続するか、またはCable AはWである場合にだけ明確です。 SourceとDestination実装の両方がそれぞれの新しい接続のときに選択的にCable Bを無効にするか、または有効にすることができるなら、この特徴は役に立ちます。
D The Direction bit, when set, reverses the sense of the Source
Address and Destination Address fields. In other words, D=1
means that the Source Address is in bits 0-11 and the
Destination Address is in bits 12-23. This bit was defined to
give devices a simple way to route return messages. It is not
useful for LAN operations.
設定されると噛み付かれたD DirectionはSource AddressとDestination Address分野の感覚を覆します。 言い換えれば、D=1は、Source Addressがビット0-11にあることを意味します、そして、Destination Addressがビット12-23にあります。 このビットは、リターンメッセージを発送する簡単な方法をデバイスに与えるために定義されました。 それはLAN操作の役に立ちません。
Renwick & Nicholson [Page 36] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[36ページ]RFC1374IPとARP
PS The Path Selection field determines whether the I-field
contains Source Route or Address information, and in Logical
Address mode, whether the switch may select from multiple
possible routes to the destination. The value "01" selects
Logical Address mode and fixed routes.
Path SelectionがさばくPSはI-分野がSource RouteかAddress情報を含むかどうか決定して、Logical Addressモードでそうします、スイッチが複数の可能なルートから目的地に選び抜くかもしれないか否かに関係なく。 値「論理アドレスモードを選択して、ルートが修理された1インチ。」
C The Camp-on bit requests the switch not to reject the
connection if the selected Destination is busy (connected to
another Source) but wait and make the connection when the
Destination is free.
CampオンなCビットが、選択されたDestinationが忙しいなら(別のSourceに接続されます)接続を拒絶しないようスイッチに要求しますが、接続を待って、Destinationが無料であるときには作ってください。
Appendix B -- How to Build a Practical HIPPI LAN
付録B--実用的なHIPPI LANを築き上げる方法
"IP and ARP on HIPPI" describes the network host's view of a HIPPI local area network without providing much information on the architecture of the network itself. Here we describe a network constructed from available HIPPI components, having the following characteristics:
ネットワーク自体のアーキテクチャの多くの情報を提供しないで、「HIPPIの上のIPとARP」はネットワークホストのHIPPIローカル・エリア・ネットワークの視点について説明します。 ここで、私たちは以下の特性を持っていて、利用可能なHIPPIの部品から構成されたネットワークについて説明します:
1. A tree structure with a central HIPPI-SC compliant hub and
optional satellite switches
1. 中央のHIPPI-サウスカロライナ対応することのハブと任意の衛星スイッチがある木構造
2. Each satellite is connected to the hub by just one bidirectional
HIPPI link.
2. 各衛星はちょうど1個の双方向のHIPPIリンクによってハブに接続されます。
3. Serial HIPPI or transparent fiber optic HIPPI extender devices
may be used in any link.
3. 連続のHIPPIか透明な光ファイバーHIPPI増量剤デバイスがどんなリンクでも使用されるかもしれません。
4. Some satellites may be a particular switch product which is not
HIPPI-SC compliant.
4. いくつかの衛星がHIPPI-サウスカロライナ対応でない特定のスイッチ製品であるかもしれません。
5. Host systems are attached either directly to the hub or to
satellites, by single bidirectional links in which both HIPPI
cables go to the same numbered switch port.
5. ホストシステムは直接ハブ、または、衛星に取り付けられます、両方のHIPPIケーブルが同じ番号付のスイッチポートに行く単一の双方向のリンクのそばで。
6. A server system is attached to the hub. It provides multicast
and ARP services.
6. サーバシステムはハブに取り付けられます。 それはマルチキャストとARPサービスを提供します。
7. All options of the Internet Draft are supported. Hosts may use
any form of address resolution: manual configuration, ARP with
multicast, or ARP with a server.
7. インターネットDraftのすべてのオプションがサポートされます。 ホストはどんな敬称解決も使用するかもしれません: 手動の構成、マルチキャストがあるARP、またはサーバがあるARP。
Switch Address Management
スイッチアドレス管理
Switch addresses use a flat address space. The 12-bit address is
subdivided into 6 bits of switch number and 6 bits of port number.
スイッチアドレスはフラットアドレス空間を使用します。 12ビットのアドレスはスイッチ番号の6ビットとポートナンバーの6ビットに細分されます。
Renwick & Nicholson [Page 37] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[37ページ]RFC1374IPとARP
11 5 0
+-----------------------+-----------------------+
| Switch Number | Port Number |
+-----------------------+-----------------------+
11 5 0 +-----------------------+-----------------------+ | スイッチ番号| ポートナンバー| +-----------------------+-----------------------+
Logical Address Construction
論理アドレス工事
Switches may be numbered arbitrarily. A given host's address
consists of the number of the switch it is directly attached to
and the physical port number on that switch to which its input
channel is attached.
スイッチは任意に付番されるかもしれません。 与えられたホストのアドレスはそれが直接付けられているスイッチの数とそのスイッチの入力チャンネルが付けている物理的なポートナンバーから成ります。
In the singly-connected tree structure, there is exactly one path
between any pair of hosts. Since each satellite must be connected
directly to the hub, the maximum length of this path is three
hops, and the minimum length is one. Each HIPPI-SC compliant
switch is programmed to map each of the host switch addresses to
the appropriate output port: either the port to which the host is
directly attached or a port that is linked to another switch in
the path to it.
単独で接続された木構造には、どんな組のホストの間にはも、1つの経路がまさにあります。 各衛星を直接ハブに接続しなければならないので、この経路の最大の長さは3つのホップです、そして、最小の長さは1です。 それぞれのHIPPI-サウスカロライナ対応することのスイッチがそれぞれのホストスイッチアドレスを適切な出力ポートに写像するようにプログラムされます: ホストが直接付けられているポートかそれへの経路で別のスイッチにリンクされるポートのどちらか。
Special Treatment of Nonstandard Switches
標準的でないスイッチの特別な処理
There is one commercially available switch that was designed
before the drafting of HIPPI-SC and is not fully compliant. It is
in common use, so it is worth making some special provisions to
allow its use in a HIPPI LAN. This switch supports only the
Source Route mode of addressing with a four bit right shift that
can be disabled by a hardware switch on each input port.
Addresses cannot be mapped. The switch does not support the "W,"
"D," or "PS" fields of the I-field; it ignores their contents.
Use of this switch as a satellite will require a slight deviation
from normal I-field usage by the hosts that are directly attached
to it. Hosts attached to standard switches are not affected.
1個のHIPPI-サウスカロライナの草稿の前に設計された、完全に言いなりになるというわけではない商業的に利用可能なスイッチがあります。 それが共用であるので、HIPPI LANにおける使用を許すためにいくつかの特別条項を作る価値があります。 このスイッチは各入力ポートの上のハードウェアスイッチで無効にすることができる正しいシフトを4ビットがあるアドレシングのSource Routeモードだけにサポートします。 アドレスを写像できません。 スイッチは「W」、「D」、または「PS」にI-分野の分野をサポートしません。 それはそれらのコンテンツを無視します。 衛星としてのこのスイッチの使用は直接それに付けられているホストで正常なI-分野用法からのわずかな逸脱を必要とするでしょう。 標準のスイッチに取り付けられたホストは影響を受けません。
For a destination connected to a non compliant satellite, the
satellite uses only the least significant four bits of the I-field
as the address. Since the address contains the destination's
physical port number in the least significant bits, its port will
be selected. Nonstandard switches should be set to disable I-
field shifting at the input from the hub, so that the destination
host will see its correct switch address in the I-field when
performing self-address discovery. I-field shifting must be
enabled on the satellite for each input port to which a host is
attached.
非対応することの衛星につなげられた目的地のために、衛星はアドレスとしてI-分野の最も重要でない4ビットだけを使用します。 アドレスが最下位ビットにおける目的地の物理的なポートナンバーを含んでいるので、ポートは選択されるでしょう。 標準的でないスイッチが、Iが入力のときにハブから移行する分野であると無効にするように設定されるべきです、自己アドレス発見を実行するとき、あて先ホストがI-分野で正しいスイッチアドレスを見るように。 衛星の上でI-分野移行をホストが付けている各入力ポートに可能にしなければなりません。
Hosts attached to nonstandard satellites must deviate from the
normal I-field usage when connecting to hosts on another switch.
別のスイッチでホストに接するとき、標準的でない衛星に取り付けられたホストは正常なI-分野用法から逸れなければなりません。
Renwick & Nicholson [Page 38] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[38ページ]RFC1374IPとARP
It is suggested that all host implementations have this capability
as long as the nonstandard switches remain in use. The host must
know, by some manual configuration method, that it is connected to
a nonstandard switch, and it must have its "link port" number;
that is, the number of the port on the satellite that is connected
to the hub.
標準的でないスイッチが使用中であり残っている限り、すべてのホスト導入にはこの能力があることが提案されます。 ホストはそれが標準的でないスイッチに接続されて、「リンクポート」番号がなければならないのを何らかの手動の構成メソッドで知らなければなりません。 すなわち、ハブに接続される衛星の上のポートの数。
The normal I-field format for a 32-bit connection, per the
Internet Draft, is this:
インターネットDraftあたり32ビットの接続に、正常なI-フィールド形式はこれです:
31 26 23 11 0
+---------+---+-+-----------------------+-----------------------+
|0 0 0 0 0|x 1|C| Unused | Destination Address |
+---------+---+-+-----------------------+-----------------------+
31 26 23 11 0 +---------+---+-+-----------------------+-----------------------+ |0 0 0 0 0|x1|C| 未使用| 送付先アドレス| +---------+---+-+-----------------------+-----------------------+
The special I-field format is:
特別なI-フィールド形式は以下の通りです。
31 26 24 15 4 3 0
+---------+---+-+---------------+-----------------------+-------+
|0 0 0 0 0|x 1|C| Unused | Destination Address | Link |
+---------+---+-+---------------+-----------------------+-------+
31 26 24 15 4 3 0 +---------+---+-+---------------+-----------------------+-------+ |0 0 0 0 0|x1|C| 未使用| 送付先アドレス| リンク| +---------+---+-+---------------+-----------------------+-------+
This I-field is altered by shifting the lower 24 bits left by four
and adding the link port number. Camp-on is optional, and the PS
field is set to 01 or 11 (the host's option) as if the switch
supported logical address mode. All other I-field bits are set to
zero. When the host requests a connection with this I-field, the
switch selects a connection through the link port to the hub, and
shifts the lower 24 bits of the I-field right by four bits. The
link port number is discarded and the I-field passed through to
the hub is a proper HIPPI-SC I-field selecting logical address
mode.
このI-分野は、4時までに残っている低級24ビットを移動させて、リンクポートナンバーを加えることによって、変更されます。 キャンプするのは任意です、そして、まるでスイッチが論理アドレスモードをサポートするかのようにPS分野は01か11(ホストのオプション)に設定されます。 他のすべてのI-分野ビットがゼロに設定されます。 ホストがこのI-分野との関係を要求するとき、スイッチは、リンクポートを通した接続をハブに選んで、4ビットに応じて、I-分野権利の低級24ビットを移動させます。 リンクポートナンバーは捨てられます、そして、ハブに通り抜けるI-野原は論理アドレスモードを選択する適切なHIPPI-サウスカロライナI-分野です。
A host on a nonstandard satellite may use the special I-field
format for all connection requests. If connecting to another host
on the same satellite, this will cause the connection to take an
unnecessarily long path through the hub and back. If an
optimization is desired, the host can be given additional
information to allow it to use the standard I-field format when
connecting to another host on the same switch. This information
could consist of a list of the other hosts on the same switch, or
the details of address formation, along with the switch number of
the local satellite, which would allow the host to analyze the
switch address to determine whether or not the destination is on
the local switch. This optimization is fairly complicated and may
not always be worthwhile.
標準的でない衛星の上のホストはすべての接続要求に特別なI-フィールド形式を使用するかもしれません。 同じ衛星の上で別のホストに接すると、これは接続がハブを通して不必要に長い経路を取って、戻すことを引き起こすでしょう。 最適化が望まれているなら、ホストは同じスイッチで別のホストに接するとき標準のI-フィールド形式を使用するのを許容する与えられた追加情報であるかもしれません。 この情報は同じスイッチの上の他のホストのリスト、またはアドレス構成の詳細から成ることができました、地方の衛星のスイッチ番号と共に。(ホストは、地方のスイッチの上に目的地があるかどうか決定するために衛星でスイッチアドレスを分析できるでしょう)。 この最適化、公正に複雑にされて、いつも価値があるかもしれないというわけではありません。
Renwick & Nicholson [Page 39] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[39ページ]RFC1374IPとARP
Server Algorithm
サーバアルゴリズム
Different host implementations may take any of three approaches to
address resolution:
異なったホスト導入は解決を扱うために3つのアプローチのどれかで取るかもしれません:
1. Manual configuration, no ARP
1. 手動の構成、ARPがありません。
2. Send ARP requests but expect a server to reply on its behalf
2. 要求をARPに送りなさい、ただし、サーバがそのに代わって返答すると予想してください。
3. Send ARP requests and expect to receive them via multicast.
3. 要求をARPに送ってください、そして、マルチキャストでそれらを受けると予想してください。
If the network includes a server that is capable of both multicast
and ARP service, and that knows the services expected by each
host, all can coexist on the same net.
ネットワークがマルチキャストとARPサービスの両方であることができ、各ホストによって予想されたサービスを知っているサーバを含んでいるなら、すべてが同じネットに共存できます。
The HIPPI-SC compliant switches are programmed to route the
HIPPI-SC "broadcast" address FE0 (hex) to the server's port. It
is initially given the following information by a human network
administrator:
HIPPI-サウスカロライナ対応することのスイッチがHIPPI-サウスカロライナ「放送」アドレスFE0(十六進法)をサーバのポートに発送するようにプログラムされます。 初めは、人脈の管理者による以下の情報をそれに与えます:
1. The list of all addresses eligible to be used by network hosts
1. ネットワークホストによって使用されるのが適任のすべてのアドレスのリスト
2. The list of addresses that should not receive multicast
messages (a subset of list 1). This is also the list of all
hosts that either do manual configuration or expect a server
to answer ARP requests.
2. マルチキャストメッセージ(リスト1の部分集合)を受け取るはずがない住所録。 また、これは手動の構成をするか、またはサーバがARPに要求に答えると予想するすべてのホストのリストです。
3. The list of addresses of hosts that do manual configuration
and do not send ARP requests (a subset of list 2) with the IP
address corresponding to each one.
3. 手動の構成をして、ARPを送らないホストの住所録はそれぞれにおいて、対応するIPアドレスで(リスト2の部分集合)を要求します。
The server maintains an address resolution cache that it
initializes from list 3 (the manually configured hosts). It will
add to its cache as other hosts send ARP requests.
サーバはそれがリスト3(手動で構成されたホスト)から初期化するアドレス解決キャッシュを維持します。 それは、ホストが要求をARPに送ると他としてのキャッシュに言い足すでしょう。
When the server receives a message sent to the broadcast address
FE0, it
サーバが受信されるとき、メッセージが放送演説FE0に発信した、それ
1. Repeats the message to all addresses in list 1 but not in list
2
1. リスト1のすべてのアドレスにメッセージを繰り返しますが、リスト2で繰り返すというわけではありません。
2. If the message is a HIPPI-LE AR_Request with a piggybacked ARP
Request, update the cache with information about the sender.
2. メッセージが便乗しているARP RequestとHIPPI-LE AR_Requestであるなら、送付者の情報でキャッシュをアップデートしてください。
3. If the message is a HIPPI-LE AR_Request with a piggybacked ARP
Request, the target system has an entry in the cache and the
target is in list 2, respond to the ARP request.
3. メッセージが便乗しているARP RequestとHIPPI-LE AR_Requestであり、目標システムにはキャッシュにおけるエントリーがあって、目標がリスト2にあるなら、ARP要求に応じてください。
Renwick & Nicholson [Page 40] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[40ページ]RFC1374IPとARP
Server Optimizations
サーバ最適化
1. The server could be given a topological map of the hub and
satellites from which it could construct list 1.
1. それがリスト1を構成できたハブと衛星の位相幾何学で表した地図をサーバに与えることができました。
2. If all the hosts in list 2 ignore ARP messages as required
in the Internet Draft, list 2 may be eliminated and the
server can respond to all ARP requests (redundant replies
may be sent).
2. リスト2のすべてのホストが必要に応じてインターネットDraftでARPメッセージを無視するなら、リスト2は排除されるかもしれません、そして、サーバはすべてのARP要求に応じることができます(余分な回答を送るかもしれません)。
Sharing Switch Hardware With Other Devices
スイッチハードウェアを対向機器と共有します。
Some host channels and peripheral devices that are connected to
the switches may use protocols other than IP, and not participate
in the LAN. Since connections in a switch are independent, these
applications can share switch hardware with no effect on LAN
operation. To ensure success:
スイッチに接続されるいくつかのホストチャンネルと周辺機は、IP以外のプロトコルを使用して、LANに参加しないかもしれません。 スイッチでの接続が独立しているので、これらのアプリケーションはLAN操作への効果なしでスイッチハードウェアを共有できます。 成功を確実にするために:
The server's lists of addresses should not include addresses
for ports that are not used by LAN links or hosts.
サーバのアドレスのリストはLANリンクかホストによって使用されないポートへのアドレスを含んでいるはずがありません。
If non-LAN applications use paths between switches, separate
links should be installed for them so that they do not use the
same inter-switch links the LAN does.
非LANアプリケーションがスイッチの間の経路を使用するなら、別々のリンクがそれらのためにインストールされるべきであるので、それらはLANがする同じ相互スイッチリンクを使用しません。
References
参照
[1] ANSI X3.183-1991, High-Performance Parallel Interface - Mechanical,
Electrical and Signalling Protocol Specification (HIPPI-PH).
[1] ANSI X3.183-1991、機械的で、電気の高性能並列インターフェース、および合図は仕様(HIPPI-PH)を議定書の中で述べます。
[2] ANSI X3.210-199X, High-Performance Parallel Interface - Framing
Protocol (HIPPI-FP).
[2]ANSI X3.210-199X、高性能並列インターフェース--プロトコル(HIPPI-fp)を縁どっています。
[3] ANSI X3.218-199X, High-Performance Parallel Interface -
Encapsulation of IEEE 802.2 (IEEE Std 802.2) Logical Link Control
Protocol Data Units (802.2 Link Encapsulation) (HIPPI-LE).
[3]ANSI X3.218-199X、高性能並列インターフェース--IEEE802.2(IEEE Std802.2)論理リンク制御プロトコルデータ単位(802.2はカプセル化をリンクします)(HIPPI-LE)のカプセル化。
[4] ANSI X3.222-199X, High-Performance Parallel Interface - Physical
Switch Control (HIPPI-SC).
[4]ANSI X3.222-199X、高性能並列インターフェース--物理的なスイッチ制御装置(HIPPI-サウスカロライナ)。
[5] Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences
Institute, September 1981.
[5] ポステル、J.、「インターネットプロトコル」、RFC791、科学が1981年9月に設けるUSC/情報。
Renwick & Nicholson [Page 41] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[41ページ]RFC1374IPとARP
[6] Postel, J., and Reynolds, J., "A Standard for the Transmission of
IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
Sciences Institute, February 1988.
[6] ポステル、J.とレイノルズ、J.、「IEEE802ネットワークの上のIPデータグラムの送信の規格」RFC1042(科学が1988年2月に設けるUSC/情報)。
[7] IEEE, "IEEE Standards for Local Area Networks: Logical Link
Control", IEEE, New York, New York, 1985.
[7] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「論理的なリンク制御」、IEEE、ニューヨーク(ニューヨーク)1985。
[8] Reynolds, J.K., and Postel, J., "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, July 1992.
[8] USC/情報科学が1992年7月に設けるレイノルズ、J.K.、およびポステル、J.、「規定番号」、RFC1340。
[9] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet Address
for Transmission on Ethernet Hardware", RFC 826, MIT, November
1982.
[9] プラマー、D.、「イーサネットは解決プロトコルを扱います--、イーサネットハードウェアの上でトランスミッションのための48.bitイーサネットアドレスにネットワーク・プロトコルアドレスを変換する、」、RFC826、MIT(1982年11月)
[10] Finlayson, R., Mann, T., Mogul, J., and Theimer, M., "A Reverse
Address Resolution Protocol", RFC 903, Stanford University, June
1984.
[10] フィンリースンとR.とマンとT.とムガール人、J.とTheimer、M.、「逆アドレス解決プロトコル」RFC903、スタンフォード大学(1984年6月)。
[11] Katz, D., "A Proposed Standard for the Transmission of IP Datagrams
over FDDI Networks", RFC 1188, Merit/NSFNET, October, 1990.
[11] キャッツ、D.、「FDDIネットワークの上のIPデータグラムの送信の提案された標準」、RFC1188、長所/NSFNET、1990年10月。
[12] IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
[12] IEEE、「標準のP802.1Aを作成してください--概要とアーキテクチャ」、1989
[13] Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191,
Stanford University, November, 1990.
[13] ムガール人、J.C.とデアリング、東南、「経路MTU探索」、RFC1191、スタンフォード大学、1990年11月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
John K. Renwick Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55121
ジョン・K.レンウィック・クレイ・リサーチ655FひとりのオークDriveイーガン、Mn55121
Phone: (612) 683-5573
以下に電話をしてください。 (612) 683-5573
Mailing List: (none) EMail: jkr@CRAY.COM
メーリングリスト: (なにも) メール: jkr@CRAY.COM
Renwick & Nicholson [Page 42] RFC 1374 IP and ARP on HIPPI October 1992
HIPPI1992年10月のレンウィックとニコルソン[42ページ]RFC1374IPとARP
Andy Nicholson Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55121
アンディ・ニコルソン・クレイ・リサーチ655FひとりのオークDriveイーガン、Mn55121
Phone: (612) 683-5473
以下に電話をしてください。 (612) 683-5473
Mailing List: (none) EMail: droid@CRAY.COM
メーリングリスト: (なにも) メール: droid@CRAY.COM
Renwick & Nicholson [Page 43]
レンウィックとニコルソン[43ページ]
一覧
スポンサーリンク
