RFC2067 日本語訳

2067 IP over HIPPI. J. Renwick. January 1997. (Format: TXT=66702 bytes) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                         J. Renwick
Request for Comments: 2067                                 NetStar, Inc.
Category: Standards Track                                   January 1997
Obsoletes: 1374

コメントを求めるワーキンググループJ.レンウィックの要求をネットワークでつないでください: 2067年のNetStar Inc.カテゴリ: 標準化過程1997年1月は以下を時代遅れにします。 1374

                             IP over HIPPI

HIPPIの上のIP

Status of This Memo

このメモの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Abstract

要約

   ANSI Standard X3.218-1993 (HIPPI-LE[3]) defines the encapsulation of
   IEEE 802.2 LLC PDUs and, by implication, IP on HIPPI.  ANSI X3.222-
   1993 (HIPPI-SC[4]) describes the operation of HIPPI physical
   switches.  The ANSI committee responsible for these standards chose
   to leave HIPPI networking issues largely outside the scope of their
   standards; this document describes the use of HIPPI switches as IP
   local area networks.

ANSI Standard X3.218-1993、(HIPPI-LE[3])はHIPPIでIEEE802.2のLLC PDUsと含意によるIPのカプセル化を定義します。 ANSI X3.222 1993(HIPPIサウスカロライナ[4])はHIPPIの物理的なスイッチの操作について説明します。 これらの規格に責任があるANSI委員会は、HIPPIがそれらの規格の範囲の主に外で問題をネットワークでつないでいるままにするのを選びました。 このドキュメントはHIPPIスイッチの使用をIPローカル・エリア・ネットワークとして記述します。

   This memo is a revision of RFC 1374, "IP and ARP on HIPPI", and is
   intended to replace it in the Standards Track.  RFC 1374 has been a
   Proposed Standard since November, 1992, with at least 10
   implementations of IP encapsulation and HIPPI switch discipline.  No
   major changes to it are required.  However, the ARP part of RFC 1374
   has not had sufficient implementation experience to be advanced to
   Draft Standard.  The present document contains all of RFC 1374 except
   for the description ARP, which has been moved into a separate
   document.

このメモは、RFC1374と、「HIPPIの上のIPとARP」の改正であり、Standards Trackでそれを取り替えることを意図します。 IPカプセル化とHIPPIスイッチ規律の少なくとも10の実装がある1992年11月以来RFC1374はProposed Standardです。 それへの大きな変化は全く必要ではありません。 しかしながら、RFC1374のARP部分には、Draft Standardに進めることができるくらいの実装経験がありません。 現在のドキュメントは記述ARP以外のRFC1374のすべてを含んでいます。(それは、別々のドキュメントに動かされました)。

TABLE OF CONTENTS

目次

   1  Introduction.............................................  2
   2  Scope....................................................  3
      2.1   Changes from RFC 1374..............................  3
      2.2   Terminology........................................  4
   3  Definitions..............................................  4
   4  Equipment................................................  5
   5  Protocol ................................................  7
      5.1   Packet Format......................................  7
      5.2   48 bit Universal LAN MAC addresses................. 11
      5.3   I-Field Format..................................... 12

1つの序論… 2 2範囲… 3 2.1 RFC1374から、変化します… 3 2.2用語… 4 3の定義… 4 4設備… 5 5は議定書を作ります… 7 5.1 パケット形式… 7 5.2 48はUniversal LAN MACアドレスに噛み付きました… 11 5.3 形式をIでさばいてください… 12

Renwick                     Standards Track                     [Page 1]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[1ページ]。

      5.4   Rules For Connections.............................. 13
      5.5   MTU................................................ 15
   6  Camp-on ................................................. 16
   7  Path MTU Discovery....................................... 17
   8  Channel Data Rate Discovery.............................. 17
   9  Performance.............................................. 18
   10 Sharing the Switch....................................... 20
   11 References............................................... 21
   12 Security Considerations.................................. 21
   13 Author's Address......................................... 21
   14 Appendix A -- HIPPI Basics............................... 22
   15 Appendix B -- How to Build a Practical HIPPI LAN......... 27

5.4 コネクションズのために、統治します… 13 5.5MTU… 15 6 陣営オン… 16 7 経路MTU発見… 17 8はデータ信号速度発見を向けます… 17 9パフォーマンス… スイッチを共有する18 10… 20 11の参照箇所… 21 12のセキュリティ問題… 21 13作者のアドレス… 21 14付録A--HIPPI基礎… どうa実用的なHIPPI LANを築き上げるかという22 15付録B… 27

1  Introduction

1つの序論

   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 bytes (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 "ftp.network.com"
   in the directory "hippi", and may be obtained via anonymous FTP.

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"というディレクトリのサイト"ftp.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で有効であるべきです。

Renwick                     Standards Track                     [Page 2]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[2ページ]。

2  Scope

2 範囲

   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
   may be interoperable on more complex networks as well, 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.

このメモはホストと交差点スイッチとのHIPPI-サウスカロライナ草稿規格に従うHIPPIインタフェースについて説明します。 このメモの範囲の外に影響力を全くホスト導入に持っていない問題があります。 このメモに従うホスト導入が単一のHIPPI-サウスカロライナスイッチで構成されたネットワークで共同利用できさせると信じられています。 また、それらも簡単なポイントからポイント、それらの間のスイッチのない両用HIPPI接続のときに共同利用できます。 それらはまた、より複雑なネットワークで共同利用できるかもしれません、スイッチとそれらがどうインタコネクトされるかに関するインターナルによって。 しかしながら実装に依存していて、このメモの範囲の外でこれらの詳細。

   Within the scope of this memo are:

このメモの範囲の中に、以下があります。

      1.  Packet format and header contents, including HIPPI-FP, HIPPI-
      LE, IEEE 802.2 LLC[7] and SNAP.

1. HIPPI-FP、HIPPI- LE、IEEE802.2LLC[7]、およびSNAPを含むパケット・フォーマットとヘッダーコンテンツ。

      2.  I-Field contents

2. I-分野コンテンツ

      3.  Rules for the use of connections.

3. 接続の使用のための規則。

   Outside of the scope are

範囲の外に、あります。

      1.  Address Resolution (ARP)

1. アドレス解決(アルプ)

      2.  Network configuration and management

2. ネットワーク・コンフィギュレーションと管理

      3.  Host internal optimizations

3. 内部の最適化を主催してください。

      4.  The interface between a host and an outboard protocol
      processor.

4. ホストと船外のプロトコルプロセッサとのインタフェース。

2.1  Changes from RFC 1374

2.1 RFC1374からの変化

   RFC 1374 described the use of ARP on HIPPI, but because of
   insufficient implementation experience, the description of ARP has
   been separated from IP encapsulation and moved to an Informational
   memo.  It may be returned to the standards track in the future if
   interest and implementations warrant it.

RFC1374がHIPPIにおけるARPの使用について説明しましたが、不十分な実装経験のために、ARPの記述は、IPカプセル化と切り離されて、Informationalメモに動かされました。 関心と実装がそれを保証するなら、将来、それを標準化過程に返すかもしれません。

Renwick                     Standards Track                     [Page 3]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[3ページ]。

   RFC 1374's specification of IP over HIPPI has been changed in this
   document.  Certain packet format options, permitted in RFC 1374, are
   no longer allowed:

本書ではRFC1374のHIPPIの上のIPの仕様を変えました。 RFC1374で受入れられたあるパケット・フォーマットオプションはもう許容されていません:

           1.  Optional short burst first;

1. 任意のショートは1番目を押し破きました。

           2.  D1 fill bytes;

2. D1はバイトをいっぱいにしています。

           3.  Nonzero D2 offset.

3. 非零D2は相殺します。

   That is, the header format is no longer variable and is required to
   be that which is recommended by RFC 1374.

すなわち、ヘッダー形式が、もう可変でなく、RFC1374によって推薦されるそれになるのに必要です。

   With these changes, it is possible to send packets which conform to
   the ANSI standards but not to this memo.  Because there are no RFC
   1374 implementations in use that used these options, we believe that
   all existing RFC 1374 implementations are compliant with the
   requirements of this memo, and there should be no interoperability
   problems associated with these changes.

これらの変化では、ANSI規格に従うパケットを送りますが、このメモに少しも送るのは可能ではありません。 これらのオプションを使用した使用中のどんなRFC1374実装もないので、私たちは、すべての既存のRFC1374実装がこのメモの要件で対応であると信じています、そして、これらの変化に関連しているどんな相互運用性問題もあるべきではありません。

2.2  Terminology

2.2 用語

   In this document the use of the word SHALL in capital letters
   indicates mandatory points of compliance.

本書ではSHALLという単語の使用は大文字で義務的なポイントのコンプライアンスを示します。

3  Definitions

3つの定義

   Conventional

従来

      Used with respect to networks, this refers to Ethernet, FDDI and
      802 LAN types, as distinct from HIPPI-SC LANs.

ネットワークに関して使用されていて、これはイーサネット、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 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/目的地組から成る実体は、IPデータグラムを送信して、受けます。ノードは、インターネット・ホスト、ブリッジ、ルータまたはゲートウェイであるかもしれません。 このメモは、ホストが直接で接続されるのではなく、ホストのためのプロトコル処理のいくつかをする外部のアダプターを通してHIPPI LANに接続されるかもしれないのを示すのに普通の「ホスト」に代わってノードという用語を使用します。

Renwick                     Standards Track                     [Page 4]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[4ページ]。

   Serial HIPPI

連続の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の実装。

   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-サウスカロライナネットワークのノードのアドレスとして使用される値。 それはI-分野で伝えられます。 HIPPI-サウスカロライナスイッチは物理的なポートナンバーにSwitch Addressesを写像するかもしれません。

   Source

ソース

      The HIPPI implementation that generates data to send to a HIPPI
      Destination.

HIPPI Destinationに発信するためにデータを生成するHIPPI実装。

   Universal LAN Address (ULA)

普遍的なLANアドレス(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によって管理されたグローバルにユニークなアドレスがイーサネット、FDDI、802ネットワークまたはHIPPIサウスカロライナLANの各ノードに割り当てた48ビット。

4  Equipment

4 設備

   A HIPPI network can be composed of nodes with HIPPI interfaces, HIPPI
   cables or serial links, HIPPI-SC switches, gateways to other
   networks.

HIPPIインタフェース、HIPPIケーブルまたは連続のリンクでノードからHIPPIネットワークを構成できます、HIPPI-サウスカロライナスイッチ、他のネットワークへのゲートウェイ。

   Each HIPPI interconnection between a node and a switch SHALL consist
   of a pair of HIPPI links, one in each direction.

ノードとスイッチSHALLの間のそれぞれの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/秒データ信号速度オプションができるなら(すなわち、Cable Bは幅64ビットの操作のためにインストールしました)、どちらかの方向、ノードのHIPPI-ペーハー実装SHALLでも、できてください。32のビット演算(抑圧されたケーブルBデータ)とSHALLでは、それぞれの新しい接続の設立のときに1600Mb/sのデータ信号速度オプションを選択するか、または反選択できてください。

Renwick                     Standards Track                     [Page 5]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[5ページ]。

   The following figure shows a sample HIPPI switch configuration.

以下の図はサンプルHIPPIスイッチ構成を示しています。

                                                      +-----+
                                                      | H 4 |
      |                                               +--+--+
      |                   +----+    +----+    +----+     |
      |                   | H1 |    | H2 |    | H3 |   +-++
      |   +--+            +-++-+    +-++-+    +-++-+   |PP|
      +---+H5|              ||        ||        ||     ++++
      |   +--+              ||        ||        ||      ||
      |                 +---++--------++--------++------++----+
      |                 |                                     |
      |   +----+        |              HIPPI-SC               |
      +---+ 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

伝説: ---+---+---+--=802ネットワーク、イーサネットまたはFDDI|| = 船外のプロトコルホストコンピュータ対にされたHIPPIリンクH=PP=Processor Gはゲートウェイと等しいです。

                       A possible HIPPI configuration

可能なHIPPI構成

Renwick                     Standards Track                     [Page 6]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[6ページ]。

   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
   complicated on blocking networks than on non-blocking ones.

単一のHIPPI-サウスカロライナスイッチには、「非ブロッキング」の特性があります。(それは、どんなSourceからどんなDestinationまでも利用可能な経路がいつもあることを意味します)。 ネットワークが1個以上のスイッチから成るなら、SourceからDestinationまでの経路はスイッチの間のHIPPIリンクを含むかもしれません。 このリンクが1Source/目的地組以上によって使用されるなら、「ブロッキング」ネットワークは創設されます: 別のSourceがそれが共有するリンクを使用しているので、1SourceがDestinationへのアクセスから妨げられるかもしれません。 ネットワークを妨げるとき、関係を樹立するための戦略は非ブロッキングものより複雑であるかもしれません。

   This memo does not take blocking issues into account, 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-サウスカロライナスイッチから成るか、またはネットワークがそれより複雑であるならノードが意識しているに違いないどんな追加問題も提示しないと仮定して。

5  Protocol

5 プロトコル

5.1  Packet Format

5.1 パケット・フォーマット

   The HIPPI packet format for Internet datagrams SHALL conform to the
   HIPPI-FP and HIPPI-LE draft standards, with further restrictions as
   imposed by this memo.  Because this memo is more restrictive than the
   ANSI standards, it is possible to send encapsulated IP datagrams that
   conform to the ANSI standards, but are illegal according to this
   memo.  Destinations may either accept or ignore such datagrams.

SHALLがこのメモで課されるようにさらなる制限でHIPPI-FPとHIPPI-LE草稿規格に従わせるインターネットデータグラムのためのHIPPIパケット・フォーマット。 このメモがANSI規格より制限しているので、発信するのが、IPがANSI規格に従っていますが、このメモによると、不法なデータグラムであるとカプセル化したのは、可能です。 目的地は、そのようなデータグラムを受け入れるか、または無視するかもしれません。

   To summarize the additional restrictions on ANSI standards found
   here:

追加制限をANSI規格へまとめるために、ここに以下を設立してください。

           Any short burst must be the last burst of the packet.
           Leading short bursts are not permitted.

どんな短い炸裂もパケットの最後の炸裂であるに違いありません。 主な短い炸裂は受入れられません。

           Nonzero values for the HIPPI-FP D2_Offset field are not
           permitted.

HIPPI-FP D2_Offset分野への非ゼロ値は受入れられません。

           The D1_AreaSize SHALL be 3 (64-bit words).  No D1 Fill is
           permitted.

D1_AreaSize SHALL、3(64ビットの単語)になってください。 D1 Fillは全く受入れられません。

   Note: Although this document is for IP over HIPPI, the encapsulation
   described below accommodates ARP as well.

以下に注意してください。 HIPPIの上にこのドキュメントはIPのためにありますが、以下で説明されたカプセル化はまた、ARPを収容します。

   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-FP D1_Area SHALLはHIPPI-LEヘッダーを含んでいます。 存在しているとき、HIPPI-FP D2_Areaであり、SHALLは1IEEE802.2のType1LLC Unnumbered情報(UI)PDUを含んでいます。 IEEE802.2XIDのサポート、TESTとType2PDUsはHIPPIで必要でなく、これらのPDUsを受けるDestinationsは彼らを無視するか、またはIEEEによると、802.2の要件を正しく反応させるかもしれません。

Renwick                     Standards Track                     [Page 7]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[7ページ]。

   The length of a HIPPI packet, including trailing fill, SHALL be a
   multiple of eight bytes as required by HIPPI-LE.

8の倍数がバイトであったなら必要に応じてHIPPI-LEで中詰め、SHALLを引きずるのを含むHIPPIパケットの長さ。

   +----------+-----------+---------------------+-----------   ------+
   |          |           |                     |              0 - 7 |
   | HIPPI-FP | HIPPI-LE  | IEEE 802.2 LLC/SNAP | IP . . .     bytes |
   |(8 bytes) |(24 bytes) |      (8 bytes)      |               fill |
   +----------+-----------+---------------------+-----------   ------+

+----------+-----------+---------------------+----------- ------+ | | | | 0 - 7 | | HIPPI-fp| HIPPI-LE| IEEE802.2LLC/スナップ| IP…バイト| |(8バイト) |(24バイト) | (8バイト) | 中詰め| +----------+-----------+---------------------+----------- ------+

                          HIPPI Packet Structure

HIPPIパケット構造

        ULP-id (8 bits) SHALL contain 4.

ULP-イド(8ビット)SHALLは4を含んでいます。

        D1_Data_Set_Present (1 bit) SHALL be set.

_D1_データSet_Present(1ビット)SHALL、設定されてください。

        Start_D2_on_Burst_Boundary (1 bit) SHALL be zero.

_D2を始動してください。__Burst_Boundary(1ビット)SHALLでは、ゼロになってください。

        Reserved (11 bits) SHALL contain zero.

(11ビット)の予約されたSHALLはゼロを含んでいます。

        D1_Area_Size (8 bits) SHALL be sent as 3.

_D1_領域Size(8ビット)SHALL、3として、送ってください。

        D2_Offset (3 bits) SHALL be zero.

D2_は(3ビット)SHALLを相殺しました。ゼロになってください。

        D2_Size (32 bits) Shall contain the number of bytes in the
        IEEE 802.2 LLC Type 1 PDU, or zero if no PDU is present.  It
        SHALL NOT exceed 65,288.  This value includes the IEEE 802.2
        LLC/SNAP header and the IP datagram.  It does not include
        trailing fill bytes.  (See "MTU", below.)

D2_サイズ(32ビット)がIEEE802.2LLC Typeにバイト数を含むものとする、1PDU、ゼロはPDUでないなら存在しています。 それ、SHALL NOTは6万5288を超えています。 この値はIEEE802.2LLC/SNAPヘッダーとIPデータグラムを含んでいます。 それは引きずっている中詰めバイトを含んでいません。 (以下の"MTU"を見てください。)

HIPPI-LE Header

HIPPI-LEヘッダー

   FC (3 bits) SHALL contain zero unless otherwise defined by local
   administration.

別の方法で地方行政によって定義されない場合、FC(3ビット)SHALLはゼロを含んでいます。

   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ビット)SHALLは1つを含んでいます。 そうでなければ、それ、SHALLはゼロを含んでいます。

   Message_Type (4 bits) contains a code identifying the type of HIPPI-
   LE PDU.  Defined values 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)

0 データPDU1アドレス解決要求PDU(AR_要求)2アドレス解決応答PDU(AR_応答)3自己アドレス解決要求PDU(S_が要求するAR_)4自己アドレス解決応答PDU(AR_S_応答)

Renwick                     Standards Track                     [Page 8]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[8ページ]。

   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ビット未満を包括して、それはSHALLです。その分野で正当化された(最下位ビットを占領します)権利になってください。

   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)

0 2 1不特定のHIPPI-サウスカロライナSource Route(24ビット)HIPPI-サウスカロライナAddress(12ビット)

   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ビット未満を包括して、それはSHALLです。その分野で正当化された(最下位ビットを占領します)権利になってください。

   Reserved (16 bits) SHALL contain zero.

(16ビット)の予約されたSHALLはゼロを含んでいます。

   Destination_IEEE_Address (48 bits) SHALL contain the 48 bit
   Universal LAN MAC Address of the Destination if known,
   otherwise zero.

別の方法で知られているなら、目的地_IEEE_Address(48ビット)SHALLはDestinationの48ビットのUniversal LANマックーアドレスを含んでいます。ゼロ。

   LE_Locally_Administered (16 bits) SHALL contain zero UNLESS
   otherwise defined by local administration.

LE_Locally_Administered(16ビット)SHALLはそうでなければUNLESSが地方行政で定義したゼロを含んでいます。

   Source_IEEE_Address (48 bits) SHALL contain the 48 bit
   Universal LAN MAC Address of the Source if known, otherwise
   zero.

別の方法で知られているなら、ソース_IEEE_Address(48ビット)SHALLはSourceの48ビットのUniversal LANマックーアドレスを含んでいます。ゼロ。

IEEE 802.2 LLC

IEEE802.2LLC

   The IEEE 802.2 LLC Header SHALL begin in the first byte of the
   HIPPI-FP D2_Area.

IEEE802.2LLC Header SHALLはHIPPI-FP D2_Areaの最初のバイトで始まります。

   SSAP (8 bits) SHALL contain 170 ('AA'h).

SSAP(8ビット)SHALLが170('AA'h)を含んでいる、'

   DSAP (8 bits) SHALL contain 170 ('AA'h).

DSAP(8ビット)SHALLが170('AA'h)を含んでいる、'

   CTL (8 bits) SHALL contain 3 (Unnumbered Information).

CTL(8ビット)SHALLは3(無数の情報)を含んでいます。

SNAP

スナップ

   Organization Code (24 bits) SHALL be zero.

組織Code(24ビット)SHALL、ゼロになってください。

Renwick                     Standards Track                     [Page 9]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[9ページ]。

   EtherType (16 bits) SHALL be set as defined in Assigned Numbers [8]:
   IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h).

EtherType(16ビット)SHALL、Assigned民数記[8]で定義されるように、設定されてください: IP=2048('0800'h)、ARP=2054('0806'h)、RARP=3万2821('8035'h)。

      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 byte 0 |Message byte 1 |Message byte 2 | . . .         |
      +---------------+---------------+---------------+---            |
      |                            .  .  .
                                                                      |
      |        -------+---------------+---------------+---------------+
      |         . . . |  byte (n-2)   |  byte (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| 中詰め| 中詰め| 中詰め| 中詰め| +---------------+---------------+---------------+---------------+

Renwick                     Standards Track                    [Page 10]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[10ページ]。

                            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 message)
              (n) is the number of bytes in the IP message.
              [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] bytes complete the HIPPI packet to an even
              number of 32 bit words.  The number of fill bytes
              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メッセージ)(n)はIPメッセージのバイト数です。 そうでなければ、局所的に使用されない場合、[LA]分野はゼロです。 略語: 「W」はWideがさばく二重_と等しいです。 「M_はタイプすること」はメッセージ_Type分野と等しいです。 「D_A_T」=目的地_アドレス_タイプ。 ソース「S_A_T」=_は、_がタイプであると扱います。 [FILL]バイトは32ビットの単語の偶数にHIPPIパケットを完成します。 中詰めバイトの数はデータの長さで数えられません。

IEEE 802.2 Data

IEEE802.2データ

   The IEEE 802.2 Data SHALL begin in the byte following the EtherType
   field.  Fill bytes SHALL be used following the Data as necessary to
   make the number of bytes 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 SHALLはEtherType野原に続くバイトで始まります。 必要に応じてDataがパケットでバイト数をする中古の次の事柄が8の倍数であったならバイトSHALLをいっぱいにしてください。 HIPPI-FPによると、この中詰めの量はHIPPI- FP HeaderのD2_Size値に含まれていません。

   The order of the bytes 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 bytes on Cable B come logically before
   those on Cable A.  Within each byte, the most significant bit is the
   highest numbered signal.

HIPPI単語の中に番号付のデータ信号(右にいなくなる)を下ろすために、より高いのからデータ・ストリームにおける、バイトの注文に付番します、HIPPI-FP Clause7と、「Wordとバイト形式」で指定されるように。 1600と共に、2番目のデータ信号速度オプション(64ビット)ビットの32〜メガビット/63がCable Bにあります、Cable Bの4バイトが各バイト単位でCable A.Withinでそれらに論理的に優先するように最も重要なビットは最も高い番号付の信号です。

5.2  48 bit Universal LAN MAC Addresses

5.2 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が使用されるかもしれません。

Renwick                     Standards Track                    [Page 11]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[11ページ]。

   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 byte 0 |L|G|  ULA byte  1  |
     +---------------+---------------+---------------+---------------+
     |  ULA byte  2  |  ULA byte  3  |  ULA byte  4  |  ULA byte  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 may be 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に使用されるなら、それは助かるかもしれません。

5.3  I-Field format

5.3 I-フィールド形式

   fi The I-field bits, as defined in HIPPI-SC, SHALL be set as follows:

HIPPI-サウスカロライナ、SHALLで定義されるようにI-分野ビットをfiする、以下の通り設定されてください:

         Locally Administered (bit 31) SHALL be zero.

局所的にAdministered(ビット31)SHALL、ゼロになってください。

         Reserved (bits 30, 29) should be zero.  Destinations SHALL
         accept any value for these bits.

予約されているのは(ビット30、29)、ゼロであるべきです。 目的地SHALLはどんな値もこれらのビット受け入れます。

         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)SHALLを倍にしてください。 それ、SHALL、そうでなければ、ゼロになってください。

         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 SHALLはゼロか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

経路Selection(ビット26、25)SHALL、00、01、またはSourceの選択における11(バイナリー)がそうです。 00 (送信元経路モード)は、I-分野ビット23-00が24ビットの送信元経路を含むのを示します。 01か11(論理アドレスモード)が、ビット23-00が12ビットのSourceとDestination Addressesを含むのを示します。 値11はそうです。

Renwick                     Standards Track                    [Page 12]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[12ページ]。

         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.

重要1つ以上のルートがSourceからDestinationまで存在していると。 それで、スイッチはルートを選ぶことができます。 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であるかもしれません。 しかしながら、a Source SHALLが連続した要求をしない、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)SHALLはDestinationのSwitch Addressを含んでいます。

        If source route mode is used:

送信元経路モードが使用されているなら:

            Routing control (bits 23-00) SHALL contain the route to
            the Destination.

ルート設定コントロール(ビット23-00)SHALLはDestinationにルートを含んでいます。

5.4  Rules For Connections

コネクションズのための5.4の規則

   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

68回の炸裂の限界は絶対ではありません。 それが終わり以上であるなら、実装は、パケットのトランスミッションの後に炸裂カウントをチェックして、接続を終わらせるかもしれません。何らかの敷居。 これが完了しているなら、敷居は典型的なパケットによる68未満であるべきです。

Renwick                     Standards Track                    [Page 13]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[13ページ]。

   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のためにチェックするなら、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.

目的地SHALLは接続の間に到着するすべてのパケットを受け入れます、そして、容量をバッファリングするのを超えているものを捨てるかもしれません。 Destination SHALLは単にあまりに多くの炸裂を受け取ったので、接続(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速度でデータを移すことができないノードがまだ共同利用できますが、実装が速ければ速いほど、ネットワークの性能は、より良くなるでしょう。

   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.

炸裂が最高率で流れると仮定して、ネットワークスループットの最も重要な要素は新しい接続の設立の後に1つの接続の終わりのSourceによるREQUESTの反主張から最初のBURSTの主張まで測定された接続切換え時間です。

   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.)

実装はできるだけ短く今回を保つべきです。 ガイドラインに関しては、平行な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の電気シグナリングSHALLが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回の炸裂を超えていないのを保証するためにベストエフォート型にしてください。

Renwick                     Standards Track                    [Page 14]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[14ページ]。

   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がはち切れない場合接続するように断言しないことによってこれを達成するかもしれませんが、最も良いバッファの価値が利用可能である、より少ないバッファでこの必要条件を満たすのは可能であるかもしれません。 これはパケットサイズ(バッファ、または他の実装に依存する問題を動かすインタフェースの速度)のノードの間の先験的な協定のためであるかもしれません。

   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. 中止になっている接続系列を無視してください。 ソースはそうするかもしれません。タイムアウトと放棄は、接続するのを試みます。 したがって、中止になっている接続系列は正常なイベントです。

5.5  MTU

5.5 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

最大のTransmission Unit(MTU)はIPパケットの長さと定義されます、IPヘッダーを含んでいますが、IPの下の少しのオーバーヘッドも含んでいなくて。 従来のLANには、物理的な層の仕様によって決定しているMTUサイズがあります。 MTUsが単に必要であるかもしれない、選ばれた媒体

Renwick                     Standards Track                    [Page 15]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[15ページ]。

   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.

より大きいパケットで働かないか、またはそれらは、ノードがパケットを送る機会を待たなければならない時間を制限するのに役立つかもしれません。

   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 bytes.

HIPPI-サウスカロライナLANのためのMTUは65280バイトです。

   This value was selected because it allows the IP packet to fit in one
   64K byte buffer with up to 256 bytes of overhead.  The overhead is 40
   bytes at the present time; there are 216 bytes of room for expansion.

IPパケットがそれで最大256バイトのオーバーヘッドがある1つ64のKバイトバッファをうまくはめ込むことができるので、この値は選択されました。 オーバーヘッドは現在で40バイトです。 216バイトの余地が拡張のためにあります。

         HIPPI-FP Header                  8 bytes
         HIPPI-LE Header                 24 bytes
         IEEE 802.2 LLC/SNAP Headers      8 bytes
         Maximum IP packet size (MTU) 65280 bytes
                                      ------------
                           Total      65320 bytes (64K - 216)

8バイトのHIPPI-FP HeaderのHIPPI-LE Headerの24バイトのIEEE802.2LLC/SNAP Headers8バイトMaximum IPパケットサイズ(MTU)65280バイト------------ 総65320バイト(64K--216)

6  Camp-on

6 キャンプします。

   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に試みられるとき、例外は起こります、廃棄物をもたらして。 本件は以下の「チャンネルデータ信号速度発見」でカバーされています。

Renwick                     Standards Track                    [Page 16]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[16ページ]。

7  Path MTU Discovery

7 経路MTU発見

   RFC 1191 [9] 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[9]は2人のホストの間の任意のネットワーク経路でMTU制限を決定するメソッドを説明します。 HIPPIノードは、HIPPI-サウスカロライナLANと他のネットワークの間の経路で制限を発見するのに変更なしでこのメソッドを使用するかもしれません。 HIPPI-サウスカロライナLANと他のタイプのネットワークの間のゲートウェイは、RFCが1191であると実装するはずです。

8  Channel Data Rate Discovery

8 チャンネルデータ信号速度発見

   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
   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.

HIPPIは2つのデータ信号速度オプション(800メガビット/秒と1600メガビット/秒)で存在しています。 より高いデータ信号速度はビットが32の代わりに沿うHIPPI64を作ることによって、達成されます、32個の追加データ・ビットと4つのパリティビットを含む付加的なケーブルを使用して。 HIPPI-サウスカロライナスイッチは、両方に付くように設計される場合があります。 ソースと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を受け入れてください。| +----+-----+-------------------+-------------------+

Renwick                     Standards Track                    [Page 17]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[17ページ]。

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
   bit request is rejected, the Source assumes that the Destination or
   path is down and makes no determination of its capability.

32ビットと64ビットのHIPPIsの複雑なLANでは、64ビットのSourceは、各Destinationにおいて経路の上でそれに利用可能なデータ信号速度を知る必要があります。 手動の構成が先験的にこれを知ることができますか、またはダイナミックにそれを発見できます。 発見の唯一の確かな方法は単にCampとの64ビットの接続を試みることです。 64ビットの接続が成功する限り、Sourceは、Destinationと経路がダブル幅であることを知っています。 64ビットの接続が拒絶されるなら、Sourceは32ビット接続しようとします。 32ビットの接続が成功するなら、SourceはDestinationか経路がダブル幅操作ができないと仮定して、その後に32ビットだけの要求を使用します。 32ビットの要求が拒絶されるなら、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ビットの接続のために状態に関してどんな結論にも達せられることができないことを意味するかもしれません。

9  Performance

9パフォーマンス

   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.

HIPPI接続はHIPPI Sourcesによって監督されます。 データの損失の可能性なしで分離を開始できないで、いったん接続を受け入れると、DestinationはSourceの奴隷です。

Renwick                     Standards Track                    [Page 18]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[18ページ]。

   Optimizations of connection strategy are therefore the province of
   the HIPPI Source, and several optimizations are permitted.

したがって、接続戦略の最適化は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
   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スループットとDestinationsがめったに忙しくないというよりも少ないなら、接続最適化はうまく行きません、そして、オーダーが列に並ばせた作られていて、厳密にメッセージを送ることを各接続を無期限に待つ最も簡単な戦略は改良できません。 しかしながら、いくつかのノードが遅いか、またはネットワーク応用が利用可能なHIPPI帯域幅より高い集合レートでメッセージを送るか、受け取ることができるなら、Sourcesは頻繁に忙しいDestinationに遭遇するかもしれません。 これらの場合では、あるホスト出力列を作り戦略はチャンネル利用を機能アップするかもしれません。 Campのない接続試みが拒絶されるか、またはCampとの接続要求が予定された間隔以内に受け入れられないなら、ソースは、異なったHIPPI Destinationsのために別々の出力キューを維持して、1Destinationを捨てて別のものを選ぶかもしれません。 戦略がもたらすそのようなものは接続系列を中止しました(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)で計算された最大の炸裂と押出量でいくつかの可能性を記載します:

Renwick                     Standards Track                    [Page 19]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[19ページ]。

                     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
   which a Source or Destination can process small packets; such limits
   may further reduce the available throughput if small packets are
   used.

これらの計算は短い炸裂のために完全な炸裂と23回の時計の期間を伝える40ナノ秒の259回のベースの時計の期間です。 (HIPPI-ペーハーは3回の時計の期間の1炸裂あたりのオーバーヘッドを指定します。) 「n」キロバイトの利用者データのパケットはHIPPI、LLC、IP、およびTCPヘッダーで長さにおいてバイト数と等しい「n」完全な炸裂と1回の短い炸裂から成ります。 「保持Time」は持続時間がパケットを送る必要があった最小の接続です。 「炸裂Rate」は接続切換え時間を数えるのではなく、接続の持続時間のための有効な転送レートです。 10、30、60、90、120、および150マイクロセカンドの接続切り換え倍を説明して、メガバイト/秒に、押出量があります。 これらの計算はSourceかDestinationが小型小包を処理できるレートにおけるどんな限界も無視します。 小型小包が使用されているなら、そのような限界はさらに有効なスループットを減らすかもしれません。

10 Sharing the Switch

10 スイッチを共有すること。

   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ケーブルを共有しないということです。 しかしながら、ホストが他の種類のトラフィックと同様にネットワークにただ一つの入力か出力ケーブルを使用しなければならないか、またはスイッチの間のリンクを共有しなければならないなら、すべてのアプリケーションがこのメモで説明される接続規律と互換性があるのを保証するために注意しなければなりません。 ネットワークトラフィックと共有されたリンクの上に長く接続を支え過ぎるアプリケーションはネットワークパケットの損失かネットワーク・サービスの重大な退行を引き起こすかもしれません。

Renwick                     Standards Track                    [Page 20]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[20ページ]。

11 References

11の参照箇所

   [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-1992, High-Performance Parallel Interface - Framing
        Protocol (HIPPI-FP).

[2]ANSI X3.210-1992、高性能並列インターフェース--プロトコル(HIPPI-fp)を縁どっています。

   [3]  ANSI X3.218-1993, 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-1993、高性能並列インターフェース--IEEE802.2(IEEE Std802.2)論理リンク制御プロトコルデータ単位(802.2はカプセル化をリンクします)(HIPPI- LE)のカプセル化。

   [4]  ANSI X3.222-1993, High-Performance Parallel Interface - Physical
        Switch Control (HIPPI-SC).

[4]ANSI X3.222-1993、高性能並列インターフェース--物理的なスイッチ制御装置(HIPPI-サウスカロライナ)。

   [5]  Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information
        Sciences Institute, September 1981.

[5] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、科学が1981年9月に設けるUSC/情報。

   [6]  IEEE, "IEEE Standards for Local Area Networks: Logical Link
        Control", IEEE, New York, New York, 1985.

[6] IEEE、「ローカル・エリア・ネットワークのIEEE規格:」 「論理的なリンク制御」、IEEE、ニューヨーク(ニューヨーク)1985。

   [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", STD 2, RFC
        1340, USC/Information Sciences Institute, July 1992.

[8] USC/情報科学が1992年7月に設けるレイノルズ、J.K.、およびポステル、J.、「規定番号」、STD2、RFC1340。

   [9]  Mogul, J.C., and Deering, S.E., "Path MTU discovery", RFC 1191,
        Stanford University, November, 1990.

[9] ムガール人、J.C.とデアリング、東南、「経路MTU探索」、RFC1191、スタンフォード大学、1990年11月。

12 Security Considerations

12 セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

13 Author's Address

13作者のアドレス

   John K. Renwick
   NetStar, Inc.
   10250 Valley View Road
   Minneapolis, MN USA 55344

ミネソタ米国 ジョンK.レンウィックNetStar Inc.10250バレー視点Roadミネアポリス、55344

   Phone: (612) 996-6847
   EMail: jkr@NetStar.com

以下に電話をしてください。 (612) 996-6847 メールしてください: jkr@NetStar.com

   Mailing List: hippi-ext@think.com

メーリングリスト: hippi-ext@think.com

Renwick                     Standards Track                    [Page 21]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[21ページ]。

14 Appendix A -- HIPPI Basics

14付録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個のコンピュータ・システムの間の簡単なポイントツーポイント接続を示しています:

   +----------+                                        +----------+
   |          |                                        |          |
   |          +--------+                      +--------+          |
   |          | 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年のメガビット/データ信号速度オプションで使用です。

Renwick                     Standards Track                    [Page 22]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[22ページ]。

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)
         CONNECT
         READY

INTERCONNECT A INTERCONNECT B(64ビット専用)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                     Standards Track                    [Page 23]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[23ページ]。

                  +------+-------------------------+------+
                  | 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ビットの単語の伝達も許して。

Renwick                     Standards Track                    [Page 24]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[24ページ]。

   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の間に挿入します。

                +------------------------------------------------+
      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に透明です。

Renwick                     Standards Track                    [Page 25]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[25ページ]。

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速度には同じくらい多くの同時接続における潜在的の、そして、それぞれ移しているデータがあります、スイッチの上のポートが入力されるか、または出力されるとき。 スイッチは放送されるよりはるかに大きい総処理能力かリングメディアを提供します。

      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)

局所的に定義された(1つの=>全体のI-分野が局所的に定義されます)W=幅(=の>の64ビットの1つの接続)D=指示(1=>スワッピングSourceとDestination Address)PS=経路Selection(01=>Logical Address Mode)L=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ビットの論理アドレスにアドレスルックアップ表を持っています。 このモードはネットワークに使用されます。

Renwick                     Standards Track                    [Page 26]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[26ページ]。

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操作の役に立ちません。

   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が無料であるときには作ってください。

15 Appendix B -- How to Build a Practical HIPPI LAN

15付録B--実用的なHIPPI LANを築き上げる方法

   "IP 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」はネットワークホストの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リンクによってハブに接続されます。

Renwick                     Standards Track                    [Page 27]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[27ページ]。

   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ケーブルが同じ番号付のスイッチポートに行く単一の双方向のリンクのそばで。

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ビットに細分されます。

   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

1個のHIPPI-サウスカロライナの草稿の前に設計された、完全に言いなりになるというわけではない商業的に利用可能なスイッチがあります。 それが共用であるので、HIPPI LANにおける使用を許すためにいくつかの特別条項を作る価値があります。 このスイッチは4ビットで各入力ポートの上のハードウェアスイッチが無効にすることができる正しいシフトを記述するSource Routeモードだけを支持します。 アドレスを写像できません。 スイッチはI-分野の「W」、「D」、または「PS」分野を支持しません。 それはそれらのコンテンツを無視します。 衛星としてのこのスイッチの使用は直接付けられているホストで正常なI-分野用法からのわずかな逸脱を必要とするでしょう。

Renwick                     Standards Track                    [Page 28]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[28ページ]。

   to it.  Hosts attached to standard switches are not affected.

それに。 標準のスイッチに取り付けられたホストは影響を受けません。

   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.
   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.

別のスイッチでホストに接するとき、標準的でない衛星に取り付けられたホストは正常なI-分野用法から逸れなければなりません。 標準的でないスイッチが使用中であり残っている限り、すべてのホスト導入にはこの能力があることが提案されます。 ホストはそれが標準的でないスイッチに接続されて、「リンクポート」番号がなければならないのを何らかの手動の構成方法で知らなければなりません。 すなわち、ハブに接続される衛星の上のポートの数。

   The normal I-field format for a 32-bit connection, per the
   document, is this:

1ドキュメントあたり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-分野です。

Renwick                     Standards Track                    [Page 29]

RFC 2067                     IP over HIPPI                  January 1997

レンウィックStandardsは1997年1月にHIPPIの上でRFC2067IPを追跡します[29ページ]。

   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                     Standards Track                    [Page 30]

レンウィック標準化過程[30ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

eclipseで『.』(ドット)から始まるファイル[.htaccess]を表示する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る