RFC2834 日本語訳
2834 ARP and IP Broadcast over HIPPI-800. J.-M. Pittet. May 2000. (Format: TXT=76243 bytes) (Obsoletes RFC1374) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J.-M. Pittet Request for Comments: 2834 Silicon Graphics Inc. Obsoletes: 1374 May 2000 Category: Standards Track
ワーキンググループJ.-Mをネットワークでつないでください。 Pittetはコメントのために以下を要求します。 2834 シリコングラフィックス株式会社は以下を時代遅れにします。 1374 2000年5月のカテゴリ: 標準化過程
ARP and IP Broadcast over HIPPI-800
HIPPI-800の上で放送されたARPとIP
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document specifies a method for resolving IP addresses to ANSI High-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte System Network, GSN). This document (when combined with RFC-2067 "IP over HIPPI") obsoletes RFC-1374.
このドキュメントはANSI High-パフォーマンスParallel Interface(HIPPI)ハードウェア・アドレスにIPアドレスを決議して、HARPの直接的拡張として論理的なIPサブネット(LIS)で放送されたIPを見習うための方法を指定します。 このメモはHIPPI-800とHIPPI-6400(また、Gigabyte System Network、GSNとして、知られている)の間に共同利用するHARPを定義します。 このドキュメント(いつが「HIPPIの上のIP」をRFC-2067に結合した)はRFC-1374を時代遅れにします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Global Concepts . . . . . . . . . . . . . . . . . . . 3
3.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 3
4. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
4.1 Background . . . . . . . . . . . . . . . . . . . . . 5
4.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 7
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 8
5.1.1 Selecting the authoritative HARP service . . . 8
5.1.2 HARP registration phase . . . . . . . . . . . . 9
5.1.3 HARP operational phase . . . . . . . . . . . . 10
5.2 HARP Client Operational Requirements . . . . . . . . . . 11
5.3 Receiving Unknown HARP Messages . . . . . . . . . . . 12
5.4 HARP Server Operational Requirements . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . 3 3。 定義. . . . . . . . . . . . . . . . . . . . . . . 3 3.1グローバルな概念. . . . . . . . . . . . . . . . . . . 3 3.2用語集. . . . . . . . . . . . . . . . . . . . . . 3 4。 IPサブネットワーク構成. . . . . . . . . . . . . . . 5 4.1バックグラウンド. . . . . . . . . . . . . . . . . . . . . 5 4.2HIPPI LIS要件. . . . . . . . . . . . . . . 6 5。 HIPPI Address Resolutionプロトコル--HARP. . . . . . . . 7 5.1HARP Algorithm. . . . . . . . . . . . . . . . . . . 8 5.1.1Selecting操作上の正式のHARPの.85.1.2HARP登録サービスフェーズ. . . . . . . . . . . . 9 5.1.3HARPのフェーズの.105.2HARP Client Operational Requirements. . . . . . . . . . 11 5.3のReceiving Unknown HARP Messages. . . . . . . . . . . 12 5.4HARP Server Operational Requirements. . . . . . . . 12
Pittet Standards Track [Page 1] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[1ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 14
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 14
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 15
6.1 HIPPI-LE Header of HARP Messages . . . . . . . . . . 15
6.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 16
6.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 16
6.1.3 Diagram . . . . . . . . . . . . . . . . . . . . 17
6.2 HIPPI Hardware Address Formats and Requirements . . . 18
6.2.1 48-bit Universal LAN MAC Addresses . . . . . . 18
6.3 HARP and InHARP Message Formats . . . . . . . . . . . 19
6.3.1 Example Message encodings . . . . . . . . . . . 22
6.3.2 HARP_NAK message format . . . . . . . . . . . . 22
6.3.3 Combined HIPPI-LE and HARP message addresses . 22
7. Broadcast and Multicast . . . . . . . . . . . . . . . . . 23
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 23
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 24
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 24
7.4 A Note on Broadcast Emulation Performance . . . . . . 24
8. HARP for Scheduled Transfer Protocol . . . . . . . . . . 25
9. Discovery of One's Own Switch Address . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . 26
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 26
12. HARP Examples . . . . . . . . . . . . . . . . . . . . . . 26
12.1 Registration Phase of Client Y on Non-broadcast HW . 27
12.2 Registration Phase of Client Y on Broadcast Hardware 28
12.3 Operational Phase (phase II) . . . . . . . . . . . . 28
12.3.1 Standard successful HARP_Resolve example . . 29
12.3.2 Standard non-successful HARP_Resolve example 30
13. References . . . . . . . . . . . . . . . . . . . . . . . 31
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32
15. Changes from RFC-1374 . . . . . . . . . . . . . . . . . . 32
16. Author's Address . . . . . . . . . . . . . . . . . . . . 33
17. Full Copyright Statement . . . . . . . . . . . . . . . . 34
5.5 ハープと永久的なARPテーブル項目. . . . . . . . 14 5.6はテーブルの年をと. . . . . . . . . . . . . . . . . . 14 6ることのハープを弾きます。 ハープメッセージ. . . . . . . . . . 15 6.1.1IEEE802.2LLC.166.1.2スナップ. . . . . . . . . . . . . . . . . . . . . 16 6.1.3ダイヤグラム. . . . . . . . . . . . . . . . . . . . 17 6.2のHIPPIハードウェアアドレス形式の.156.1HIPPI-LEヘッダーをコード化するメッセージと要件のハープを弾いてください; . . 18 6.2.1 48ビットUniversal LAN MAC Addresses. . . . . . 18 6.3HARPとInHARP Message Formats. . . . . . . . . . . 19 6.3.1Example Message encodings. . . . . . . . . . . 22 6.3.2のHARP_NAKメッセージ・フォーマット. . . . . . . . . . . . 22 6.3.3Combined HIPPI-LEとHARPメッセージアドレス. 22 7。 PIBES23 7.2に、IPはアドレス. . . . . . . . . . . . . . . . 24 7.3IPマルチキャストアドレス. . . . . . . . . . . . . . . . 24 7.4を放送しました。IP放送エミュレーションサーバのための放送とマルチキャスト. . . . . . . . . . . . . . . . . 23 7.1プロトコル--放送エミュレーションパフォーマンス. . . . . . 24 8に関する注。 予定されている転送プロトコル. . . . . . . . . . 25 9のために、ハープを弾いてください。 自分自身のスイッチアドレス. . . . . . . . . . 25 10の発見。 セキュリティ問題. . . . . . . . . . . . . . . . . 26 11。 問題. . . . . . . . . . . . . . . . . . . . . . . 26 12を開いてください。 うまくいっているBroadcast Hardware28 12.3Operational Phase(フェーズII)の.2Standard非うまくいっているHARP_Resolve.28 12.3.1Standard HARP_Resolve例の.29 12.3例30 13のClient YのNon-放送HW.27 12.2Registration Phaseの上のClient YのHARP Examples.26 12.1Registration Phase。 参照. . . . . . . . . . . . . . . . . . . . . . . 31 14。 承認. . . . . . . . . . . . . . . . . . . . . 32 15。 RFC-1374. . . . . . . . . . . . . . . . . . 32 16からの変化。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 33 17。 完全な著作権宣言文. . . . . . . . . . . . . . . . 34
1. Introduction
1. 序論
The ANSI High-Performance Parallel Interface (HIPPI) is a dual simplex data channel. HIPPI can send and receive data simultaneously at 800 or 1600 megabits per second. Between 1987 and 1997, the ANSI X3T11.1 HIPPI working group (now known as NCITS T11.1) Standardized five 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]), the behavior of a physical layer switch (HIPPI-SC [4]) and the physical- level and optical specification (HIPPI-Serial [5]). HIPPI-LE also implies the encapsulation of Internet Protocol[5]. The reader should be familiar with the ANSI HIPPI documents. Approved ANSI NCITS
ANSI High-パフォーマンスParallel Interface(HIPPI)は二元的なシンプレクスデータ・チャンネルです。 HIPPIは同時に、1秒あたり800か1600のメガビットでデータを送って、受け取ることができます。 1987年と1997年の間に、ANSI X3T11.1 HIPPIワーキンググループ(今、NCITS T11.1として知られている)はネットワーク・インターフェースとしてHIPPIの使用を圧迫する5通のドキュメントを標準化しました。 彼らが物理的で電気の仕様をカバーする、(HIPPI-ペーハー[1])、バイトの流れの縁どり、(HIPPI-FP[2])、IEEE802.2LLCのカプセル化、(HIPPI-LE[3])、物理的な層のスイッチの働き、(HIPPI-サウスカロライナ[4])、物理的なレベル、および光学仕様、(HIPPI-シリーズ[5])。 また、HIPPI-LEはインターネットプロトコル[5]のカプセル化を含意します。 読者はANSI HIPPIドキュメントに詳しいはずです。 承認されたANSI NCITS
Pittet Standards Track [Page 2] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[2ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
standards are available from ANSI (http://www.ansi.org). The working documents of the T11.1 working group may be obtained from the T11 web page (http://www.t11.org/).
規格はANSI( http://www.ansi.org )から利用可能です。 T11ウェブページ( http://www.t11.org/ )からT11.1ワーキンググループの働くドキュメントを入手するかもしれません。
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. RFC-2067 [15] describes the encapsulation of IP over HIPPI-800. This memo takes up where the working group and RFC-2067 [15] left off and defines address resolution and LIS IP broadcast emulation for HIPPI-800 networks.
多くの目的のためにさまざまなコンピュータと周辺装置を接続するのにHIPPIスイッチを使用できましたが、ワーキンググループは、彼らの使用をローカル・エリア・ネットワークとして記述するまでには至りませんでした。 RFC-2067[15]はHIPPI-800の上でIPのカプセル化について説明します。 このメモは、ワーキンググループとRFC-2067[15]がやめたところに取って、HIPPI-800ネットワークのためにアドレス解決とLIS IP放送エミュレーションを定義します。
While investigating possible solutions for HARP it became evident that IP broadcast could easily be emulated for both HIPPI-800 and HIPPI-6400 hardware types. This is useful since HIPPI switches are not required to implement broadcast but many standard networking protocols rely on broadcast. This memo therefore further addresses the emulation of LIS IP broadcast as an extension of HARP.
HARPの可能な解決策を調査している間、HIPPI-800とHIPPI-6400ハードウェアタイプの両方のために容易にIP放送を見習うことができたのは明白になりました。 HIPPIスイッチは放送を実行するのに必要でないので、これは役に立ちますが、多くの標準のネットワーク・プロトコルが放送に依存します。 したがって、このメモはさらにHARPの拡大として放送されたLIS IPのエミュレーションを記述します。
2 Terminology
2 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [18].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[18]で説明されるように本書では解釈されることであるべきですか?
3. Definitions
3. 定義
3.1 Global concepts used
3.1 使用されるグローバルな概念
In the following discussion, the terms "requester" and "target" are used to identify the port initiating the address resolution request and the port whose address it wishes to discover, respectively. If not all switches in the LIS support broadcast then there will be a HARP server providing the address resolution service and it will be the source of the reply. If on the other hand all switches support broadcast then the source address of a reply will be the target's target address.
以下の議論、アドレス解決要求を開始する「リクエスタ」と「目標」がポートを特定するのに使用される用語、およびそれがそれぞれアドレスを発見したがっているポートで。 まして、回答の源になるなら、そしてそこでのLISサポート放送におけるすべてのスイッチがHARPサーバになるでしょう。 他方では、スイッチが支持するすべてが放送されると、回答のソースアドレスは目標のあて先アドレスになるでしょう。
Values are decimal unless otherwise noted. Formatting follows IEEE 802.1A canonical bit order and and HIPPI-FP bit and byte order.
別の方法で注意されない場合、値は10進です。 そして、そして、形式がIEEE 802.1Aの正準なビットオーダーに従う、HIPPI-FPビットとバイトオーダー。
3.2 Glossary
3.2 用語集
Broadcast
放送
A distribution mode which transmits a message to all ports. Particularly also the port sending the message.
すべてのポートに送信する分配モード。 特にまた、メッセージを送るポート。
Pittet Standards Track [Page 3] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[3ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
Classical/Conventional
古典的であるか、または従来です。
Both terms are used to refer to networks such as Ethernet, FDDI, and other 802 LAN types, as distinct from HIPPI-SC LANs.
両方の用語はイーサネットや、FDDIや、他の802のLANタイプなどのネットワークを示すのに使用されます、HIPPI-サウスカロライナLANと異なるとして。
Destination
目的地
The HIPPI port that receives data from a HIPPI Source.
HIPPI Sourceからデータを受け取るHIPPIポート。
HARP
ハープ
HARP describes the whole set of HIPPI address resolution encodings and algorithms defined in this memo. HARP is a combination and adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 [13] and Inverse ARP (InARP) [7] (see section 5). HARP also describes the HIPPI specific version of ARP [10] (i.e. the protocol and the HIPPI specific encoding).
HARPはHIPPIアドレス解決encodingsとこのメモで定義されたアルゴリズムの全体集合について説明します。 HARPはインターネットAddress Resolutionプロトコル(ARP)RFC-826[13]とInverse ARP(InARP)[7]の組み合わせと適合(セクション5を見る)です。 また、HARPはARP[10](すなわち、プロトコルとHIPPIの特定のコード化)のHIPPIの特定のバージョンについて説明します。
HARP table
HARPテーブル
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
各ホストはIPメンバーのハードウェアアドレス・マッピングにIPを含むHARPテーブルを持っています。
HIPPI-Serial
HIPPI-シリーズ
An implementation of HIPPI in serial fashion on coaxial cable or optical fiber. (see [5])
同軸ケーブルか光ファイバにおける連続のファッションにおける、HIPPIの実現。 ([5])を見てください。
HRAL
HRAL
The HARP Request Address List. A list of ULAs to which HARP messages are sent when resolving names to addresses (see section 4.2).
ハープ要求住所録。 アドレス(セクション4.2を見る)に名前を決議するときHARPメッセージが送られるULAsのリスト。
Hardware (HW) address
ハードウェア(HW)アドレス
The hardware address of a port consisting of an I-Field and an optional ULA (see section 6.2). Note: the term port as used in this document refers to a HIPPI port and is roughly equivalent to the term "interface" as commonly used in other IP documents.
I-分野と任意のULA(セクション6.2を見る)から成るポートのハードウェア・アドレス。 以下に注意してください。 本書では使用される用語ポートは、他のIPドキュメントで一般的に使用されるようにHIPPIポートを呼んで、およそ「インタフェース」という用語に同等です。
Host
ホスト
An entity, usually a computer system, that may have one or more HIPPI ports and which may serve as a client or a HARP server.
実体、通常コンピュータ・システム。(そのコンピュータ・システムは、1つ以上のHIPPIポートを持って、クライアントかHARPサーバとして機能するかもしれません)。
Pittet Standards Track [Page 4] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[4ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
Port
ポート
An entity consisting of one HIPPI Source/Destination dual simplex pair that is connected by parallel or serial HIPPI to a HIPPI-SC switch and that transmits and receives IP datagrams.
平行であるか連続のHIPPIによってHIPPI-サウスカロライナスイッチとそれに接続される二元的な1HIPPI Source/目的地シンプレクス組から成る実体は、IPデータグラムを送信して、受けます。
PIBES
PIBES
The Protocol for Internet Broadcast Emulation Server (see section 7).
インターネットBroadcast Emulation Server(セクション7を見る)のためのプロトコル。
Switch Address
スイッチアドレス
A value used as the address of a port on a HIPPI-SC network. It is transmitted in the I-field. HIPPI-SC switches map Switch Addresses to physical switch port numbers. The switch address is extended with a mode byte to form an I-Field (see [4] and 6.2.2)
HIPPI-サウスカロライナネットワークのポートのアドレスとして使用される値。 それはI-分野で伝えられます。 HIPPI-サウスカロライナは物理的なスイッチポートナンバーに地図Switch Addressesを切り換えます。 スイッチアドレスはモードバイトで広げられて、I-分野を形成します。([4]と6.2を見てください、.2)
Source
ソース
The HIPPI port that generates data to send to a HIPPI Destination.
HIPPI Destinationに発信するためにデータを発生させるHIPPIポート。
Universal LAN MAC Address (ULA)
普遍的なLANマックーアドレス(ULA)
A 48-bit globally unique address, administered by the IEEE, assigned to each port on an Ethernet, FDDI, 802 network, or HIPPI-SC LAN.
IEEEによって管理されたグローバルにユニークなアドレスが802のイーサネット、FDDI、ネットワーク、またはHIPPI-サウスカロライナLANの各ポートに割り当てた48ビット。
4. IP Subnetwork Configuration
4. IPサブネットワーク構成
4.1 Background
4.1 バックグラウンド
ARP (address resolution protocol) as defined in [12] was meant to work on the 'local' cable. This definition gives the ARP protocol a local logical IP subnet (LIS) scope. In the LIS scenario, each separate administrative entity configures its hosts and routers within the LIS. Each LIS operates and communicates independently of other LIS's on the same HIPPI network.
[12]で定義されるARP(アドレス解決プロトコル)は'地方'のケーブルに働くことになっていました。 この定義は地方の論理的なIPサブネット(LIS)範囲をARPプロトコルに与えます。 LISシナリオでは、それぞれの別々の管理実体はLISの中でそのホストとルータを構成します。 各LISは同じHIPPIネットワークの他のLISの如何にかかわらず作動して、交信します。
HARP has LIS scope only and serves all ports in the LIS. Communication to ports located outside of the local LIS is usually provided via an IP router. This router is a HIPPI port attached to the HIPPI network that is configured as a member of one or more LIS's. This configuration MAY result in a number of disjoint LIS's operating over the same HIPPI network. Using this model, ports of different IP subnets SHOULD communicate via an intermediate IP router even though it may be possible to open a direct HIPPI connection between the two IP members over the HIPPI network. This is a consequence of using IP and choosing to have multiple LIS's on the same HIPPI fabric.
HARPはLIS範囲しか持たないで、LISのすべてのポートに役立ちます。 通常、IPルータで地方のLISの外に位置したポートへのコミュニケーションを提供します。 このルータは1LISのメンバーとして構成されるHIPPIネットワークに取り付けられたHIPPIポートです。 5月が数に結果になるこの構成は同じHIPPIネットワークの上のLISの作動をばらばらにならせます。 このモデルを使用して、HIPPIネットワークの上で2人のIPメンバーの間のダイレクトHIPPI接続を開くのが可能であるかもしれませんが、異なったIPサブネットSHOULDのポートは中間的IPルータで交信します。 これはIPを使用して、同じHIPPI織物の上にLISの複数のものを持っているのを選ぶ結果です。
Pittet Standards Track [Page 5] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[5ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
By default, the HARP method detailed in section 5 and the classical LIS routing model MUST be available to any IP member client in the LIS.
デフォルトで、LISのどんなIPメンバークライアントにとっても、セクション5で詳細なHARP方法と古典的なLISルーティングモデルは手があいていなければなりません。
4.2 HIPPI LIS Requirements
4.2 HIPPI LIS要件
The requirement for IP members (hosts, routers) operating in a HIPPI LIS configuration is:
HIPPI LIS構成で働いているIPメンバー(ホスト、ルータ)のための要件は以下の通りです。
o All members of the LIS SHALL have the same IP network/subnet
address and address mask [6].
o LIS SHALLのすべてのメンバーが同じIPネットワーク/サブネットアドレスとアドレスマスク[6]を持っています。
The following list identifies the set of HIPPI-specific parameters that MUST be implemented in each IP station connected to the HIPPI network:
以下のリストはHIPPIネットワークにつなげられたそれぞれのIPステーションで実行しなければならないHIPPI特有のパラメタのセットを特定します:
o HIPPI Hardware Address:
o HIPPIハードウェア・アドレス:
The HIPPI hardware address of an individual IP port MUST contain
the port's Switch Address (see section 9). The address SHOULD also
contain a non-zero ULA address. If there is no ULA then that field
MUST be zero.
個々のIPポートのHIPPIハードウェア・アドレスはポートのSwitch Addressを含まなければなりません(セクション9を見てください)。 また、アドレスSHOULDは非ゼロULAアドレスを含んでいます。 ULAが全くなければ、その分野はゼロであるに違いありません。
o HARP Request Address List (HRAL):
o 要求住所録(HRAL)のハープを弾いてください:
The HRAL is an ordered list of two or more addresses identifying
the address resolution service(s). All HARP clients MUST be
configured identically, i.e. all ports MUST have the same
addresses(es) in the HRAL.
HRALはアドレス解決サービスを特定する2つ以上のアドレスの規則正しいリストです。 同様にすべてのHARPクライアントを構成しなければなりません、すなわち、すべてのポートがHRALに同じアドレス(es)を持たなければなりません。
The HRAL MUST contain at least two HIPPI HW addresses identifying
the individual HARP service(s) that have authoritative
responsibility for resolving HARP requests of all IP members
located within the LIS.
HRAL MUSTはLISの中に位置したすべてのIPメンバーのHARP要求を決議することへの正式の責任を持っている個々のHARPサービスを特定する少なくとも2つのHIPPI HWアドレスを含んでいます。
By default the first address MUST be the reserved address for
broadcast, i.e. the address for "IP traffic conventionally
directed to the IEEE 802.1 broadcast address: 0xFE1" [4]. The ULA
for this HARP service entry SHALL be FF:FF:FF:FF:FF:FF.
デフォルトで、「慣習上IEEE802.1に向けられたIP交通はアドレスを放送した」ので、最初のアドレスはすなわち、放送、アドレスのための予約されたアドレスでなければなりません。 0xFE1"[4]。 このHARPのためのULAは: FF:FF:FF:FF:FFがFFであったならエントリーSHALLを調整します。
It is REQUIRED that the second address be the address for
"Messages pertaining to (the) ... address resolution requests:
0xFE0" [4]. The ULA for this HARP server entry is
00:00:00:00:00:00.
2番目のアドレスが「(the)…アドレス解決要求に以下を関係させるメッセージ」のためのアドレスであることはREQUIREDです。 0xFE0"[4]。 このHARPサーバエントリーへのULAは00 00:00:歳です: 00:00:00。
Pittet Standards Track [Page 6] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[6ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
Therefore, the HRAL entries are sorted in the following order:
1st ** : broadcast address (0x07000FE1 FF:FF:FF:FF:FF:FF),
2nd ** : official HARP server address (0x07000FE0 00:00:00:00:00:00),
3rd & on: any additional HARP server addresses will be sorted in
decreasing order of the 12bit destination switch
address portion of their I-Field (see section 6.2).
** REQUIRED
したがって、HRALエントリーは以下のオーダーで分類されます: 最初の**: アドレス(0x07000FE1 FF:FF:FF:FF:FF: FF)、2番目の**を放送してください: 公式のHARPサーバアドレス、(0x07000FE0、00:00:00、:、00:00:00、)、3番目と: どんな追加HARPサーバアドレスも多いほうから少ないほうへ順に並べるとそれらのI-分野の12ビットの目的地のスイッチアドレスの部分について分類されるでしょう(セクション6.2を見てください)。 ** 必要です。
Within the restrictions mentioned above and in Section 6.2.2, local administration choose address(es) for the additional HARP services which they will put into the HRAL.
中に、制限は、地方行政の上と、そして、セクション6.2.2、地方行政で彼らがHRALに置く追加HARPサービスのためのアドレス(es)を選ぶように言及しました。
An example of such a list:
1st entry: 0x07000FE1 FF:FF:FF:FF:FF:FF
2nd entry: 0x07000FE0 00:00:00:00:00:00
3rd entry: 0x07000001 <Alternate-HARP-server-ula>
...
そのようなリストに関する例: 最初のエントリー: 0x07000FE1 FF:FF:FF:FF:FF: FF2番目のエントリー: 0x07000FE0 00:00:00:00:00:00 3番目のエントリー: 0×07000001 <の交互のハープのサーバ-ulaの>…
Manual configuration of the addresses and address lists presented in this section is implementation dependent and beyond the scope of this memo.
実現に依存していて、このメモの範囲を超えてこのセクションに提示されたアドレスと住所録の手動の構成。
5. HIPPI Address Resolution Protocol - HARP
5. HIPPIアドレス解決プロトコル--ハープを弾いてください。
Address resolution within the HIPPI LIS SHALL make use of the HIPPI Address Resolution Protocol (HARP) and the Inverse HIPPI Address Resolution Protocol (InHARP). HARP provides the same functionality as the Internet Address Resolution Protocol (ARP). HARP is based on ARP which is defined in RFC-826 [13]. Knowing the Internet address, conventional networks use ARP to discover another port's hardware address. HARP presented in this section further specifies the combination of the original protocol definitions to form a coherent address resolution service that is independent of the hardware's broadcast capability.
HIPPI LIS SHALLの中のアドレス決議はHIPPI Address Resolutionプロトコル(HARP)とInverse HIPPI Address Resolutionプロトコル(InHARP)を利用します。 HARPはインターネットAddress Resolutionプロトコル(ARP)と同じ機能性を提供します。 HARPはRFC-826[13]で定義されるARPに基づいています。 インターネット・アドレスを知っていて、従来のネットワークは、別のポートのハードウェア・アドレスを発見するのにARPを使用します。 このセクションにさらに示されたHARPは、ハードウェアの放送能力から独立している一貫性を持っているアドレス解決サービスを形成するためにオリジナルのプロトコル定義の組み合わせを指定します。
InHARP is based on the original Inverse ARP (InARP) protocol presented in [7]. Knowing its hardware address, InARP is used to discover the other party's Internet address.
InHARPは[7]に提示されたオリジナルのInverse ARP(InARP)プロトコルに基づいています。 ハードウェア・アドレスを知っていて、InARPは、相手のインターネット・アドレスを発見するのに使用されます。
This memo further REQUIRES the PIBES (see section 7 below) extension to the HARP protocol, guaranteeing broadcast service to upper layer protocols like IP.
HARPへのPIBES(下のセクション7を見る)拡張子が議定書の中で述べる一層のこのメモREQUIRES、保証はIPのような上側の層のプロトコルに対するサービスを放送しました。
Internet addresses are assigned independent of ULAs and switch addresses. Before using HARP, each port MUST know its IP and its hardware addresses. The ULA is optional but is RECOMMENDED if bridging to conventional networks is desired.
インターネット・アドレスはULAsとスイッチアドレスの如何にかかわらず割り当てられます。 HARPを使用する各ポートは知らなければならない前に、IPとそのハードウェア・アドレスを知ってください。 ULAは任意ですが、従来のネットワークへの橋を架けることが望まれているなら、RECOMMENDEDです。
Pittet Standards Track [Page 7] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[7ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
5.1 HARP Algorithm
5.1ハープアルゴリズム
This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI-SC networks. HARP creates a table in each port which maps the IP address of each port to a hardware address, so that when an application requests a connection to a remote port by its IP address, the hardware address can be determined, a correct HIPPI-LE header can be built, and a connection to the port can be established using the correct Switch Address in the I-field.
このセクションは両方の放送と非放送のできるHIPPI-サウスカロライナネットワークでHARP実現のための振舞いと要件を定義します。 HARPはそれぞれのポートのIPアドレスをハードウェア・アドレスに写像する各ポートでテーブルを作成します、アプリケーションがIPアドレスから遠く離れたポートに接続を要求すると、ハードウェア・アドレスが決定できて、正しいHIPPI-LEヘッダーを造ることができて、I-分野で正しいSwitch Addressを使用することでポートとの接続は確立できるように。
HARP is a two phase protocol. The first phase is the registration phase and the second phase is the operational phase. In the registration phase the port detects if it is connected to broadcast hardware or not. The InHARP protocol is used in the registration phase. In case of non-broadcast capable hardware, the InHARP Protocol will register and establish a table entry with the server. The operational phase works much like conventional ARP with the exception of the message format.
HARPは二相プロトコルです。 第1段階は登録フェーズです、そして、2番目のフェーズは操作上のフェーズです。 ポートが検出するフェーズは登録がそれであるならハードウェアを放送するのにおいて関連しています。 InHARPプロトコルは登録フェーズに使用されます。 非放送のできるハードウェアの場合には、InHARPプロトコルは、サーバによるテーブル項目を登録して、設置するでしょう。操作上のフェーズはメッセージ・フォーマット以外の従来のARPのように働いています。
5.1.1 Selecting the authoritative HARP service
5.1.1 正式のHARPサービスを選択すること。
Within the HIPPI LIS, there SHALL be an authoritative HARP service. At each point in time there is only one authoritative HARP service.
そこのHIPPI LIS、SHALL、正式のHARPサービスになってください。 各ポイントには、1つの正式のHARPサービスしか時間内にありません。
To select the authoritative HARP service, each port needs to determine if it is connected to a broadcast network.
正式のHARPサービスを選択するために、各ポートは、それが放送網に関連づけられるかどうか決定する必要があります。
The port SHALL send an InHARP_REQUEST to the first address in its HRAL (0x07000FE1 FF:FF:FF:FF:FF:FF). If the port sees its own InHARP_REQUEST, then it is connected to a broadcast capable network. In this case, the rest of the HRAL is ignored and the authoritative HARP service is the broadcast entry.
ポートSHALLはHRAL(0x07000FE1 FF:FF:FF:FF:FF: FF)における最初のアドレスにInHARP_REQUESTを送ります。 ポートがそれ自身のInHARP_REQUESTを見るなら、それは放送のできるネットワークに関連づけられます。 この場合、HRALの残りは無視されます、そして、正式のHARPサービスは放送エントリーです。
If the port is connected to a non-broadcast capable network, then the port SHALL send the InHARP_REQUEST to all of the remaining entries in the HRAL. Every address which sends an InHARP_REPLY is considered to be a responsive HARP server. The authoritative HARP service SHALL be the HARP server which appears first in the HRAL.
ポートが非放送のできるネットワークにつなげられるなら、ポートSHALLはHRALの残っているエントリーのすべてにInHARP_REQUESTを送ります。 InHARP_REPLYを送るあらゆるアドレスが敏感なHARPサーバであると考えられます。正式のHARPは現れるHARPサーバがHRALの1番目であったならSHALLを調整します。
The sequence of the HRAL is only important for deciding which address will be the authoritative one. On a non-broadcast network, the port is REQUIRED to keep "registered" with all HARP server addresses in the HRAL (NOTE: not the broadcast address since it is not a HARP server address). If for instance the authoritative HARP service is non-responsive, then the port will consider the next address in the HRAL as a candidate for the authoritative address and send an InHARP_REQUEST.
どのアドレスが正式のものになるかを単に決めるのに、HRALの系列は重要です。 非放送網では、ポートはHRALのすべてのHARPサーバアドレスに「登録されていた」状態で保つREQUIRED(注意: それ以来のいずれの放送演説もHARPサーバアドレスでない)です。 例えば、正式のHARPサービスが非敏感であるなら、ポートは、HRALの次のアドレスを正式のアドレスの候補と考えて、InHARP_REQUESTを送るでしょう。
Pittet Standards Track [Page 8] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[8ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
The authoritative HARP server SHOULD be considered non-responsive when it has failed to reply to: (1) one or more registration requests by the client (see section 5.1.2 and 5.2), (2) any two HARP_REQUESTs in the last 120 seconds or (3) if an external agent has detected failure of the authoritative HARP server. The details of such an external agent and its interaction with the HARP client are beyond the scope of this document. Should an authoritative HARP server become non-responsive, then the registration process SHOULD be restarted. Alternative methods for choosing an authoritative HARP service are not prohibited.
正式のHARPサーバSHOULD、以下のことのために返答していないとき、非敏感であると考えられてください。 (1) (2) クライアント(セクション5.1 .2と5.2を見る)による1つ以上の登録要求、最後の120秒か(3)のどんな2HARP_REQUESTsも外部のエージェントであるなら正式のHARPサーバの失敗を検出しました。そのような外部のエージェントの細部とHARPクライアントとのその相互作用はこのドキュメントの範囲を超えています。 正式のHARPサーバは非敏感になるべきです、次に、登録がSHOULDを処理します。再開されます。 正式のHARPサービスを選ぶための別法は禁止されていません。
5.1.2 HARP registration phase
5.1.2 HARP登録フェーズ
HARP clients SHALL initiate the registration phase by sending an InHARP_REQUEST message using the addresses in the HRAL in order. The client SHALL terminate the registration phase and transition into the operational phase, either when it receives its own InHARP_REQUEST or when it receives an InHARP_REPLY from at least one of the HARP servers and when it has determined the authoritative HARP service as described in section 5.1.1.
HARPクライアントSHALLは、整然とした状態でHRALのアドレスを使用することでInHARP_REQUESTメッセージを送ることによって、登録フェーズを開始します。 クライアントSHALLは操作上のフェーズへの登録フェーズと変遷を終えます、それ自身のInHARP_REQUESTを受けるか、または少なくともHARPサーバの1つからInHARP_REPLYを受けて、セクション5.1.1で説明されるように正式のHARPサービスを決定したとき。
When ports are initiated they send an InHARP_REQUEST to the authoritative address as described in section 5.1.2. The first address to be tried will be the broadcast address "0x07000FE1 FF:FF:FF:FF:FF:FF". There are two outcomes:
ポートが開始されるとき、それらはセクション5.1.2で説明されるようにInHARP_REQUESTを正式のアドレスに送ります。 放送演説が「0x07000FE1ff: ff:ff:ff:ff:ff」であるつもりであったなら試みられるべき最初のアドレス。 2つの結果があります:
1. The port sees its own InHARP_REQUEST: then the port is connected
to a broadcast capable network. The first address becomes and
remains the authoritative address for the HARP service.
1. ポートはそれ自身のInHARP_REQUESTを見ます: そして、ポートは放送のできるネットワークにつなげられます。 最初のアドレスは、なって、HARPサービスのための正式のアドレスのままで残っています。
2. The port does not receive its InHARP_REQUEST: then the port is
connected to a non-broadcast capable network.
2. ポートはInHARP_REQUESTを受けません: そして、ポートは非放送のできるネットワークにつなげられます。
In the second case, the port SHALL choose the next address in the HRAL as a candidate for a authoritative address and send an InHARP_REQUEST to that address: (0x07000FE0 00:00:00:00:00:00).
2番目の場合では、ポートSHALLは正式のアドレスの候補としてHRALの次のアドレスを選んで、InHARP_REQUESTをそのアドレスに送ります: (0x07000FE0 00:00:00:00:00:00。)
o If the port receives its own message, then the port itself is the
HARP server and the port is REQUIRED to provide broadcast services
using the PIBES (see section 7).
o ポートがそれ自身のメッセージを受け取るなら、ポート自体はHARPサーバです、そして、ポートはPIBESを使用することで放送サービスを提供するREQUIRED(セクション7を見る)です。
o If the port receives an InHARP_REPLY, then it is a HARP client and
not a HARP server.
o ポートがInHARP_REPLYを受けるなら、それはHARPサーバではなく、HARPクライアントです。
In both cases, the current candidate address becomes the authoritative HARP service address.
どちらの場合も、現在の候補アドレスは正式のHARPサービスアドレスになります。
Pittet Standards Track [Page 9] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[9ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
If the client determines it is connected to a non-broadcast capable network then the client SHALL continue to retry each non-broadcast HARP server address in the HRAL at least once every 5 seconds until one of these two termination criteria are met for each address.
クライアントが、それが非放送のできるネットワークに関連づけられると決心しているなら、クライアントSHALLは、これらの2つの終了評価基準の1つの5秒前毎が各アドレスのためにいったん達成されると少なくともHRALのそれぞれの非放送HARPサーバアドレスを再試行し続けています。
InHARP is an application of the InARP protocol for a purpose not originally intended. The purpose is to accomplish registration of port IP address mappings with a HARP server if one exists or detect hardware broadcast capability.
InHARPは元々意図しなかった目的のためのInARPプロトコルの応用です。 目的は、1つが存在しているならHARPサーバによるポートIPアドレス・マッピングの登録を実行するか、またはハードウェア放送能力を検出することです。
If the HIPPI-SC LAN supports broadcast, then the client will see its own InHARP_REQUEST message and SHALL complete the registration phase. The client SHOULD further note that it is connected to a broadcast capable network and use this information for aging the HARP server entry and for IP broadcast emulation as specified in sections 5.4 and 5.6 respectively.
HIPPI-サウスカロライナのLANサポートが放送されると、クライアントは、それ自身のInHARP_REQUESTメッセージとSHALLが登録フェーズを完成するのを見るでしょう。 クライアントSHOULDはそれが放送のできるネットワークに関連づけられることにさらに注意して、HARPサーバエントリーの年をとって、セクション5.4と5.6の指定されるとしてのIP放送エミュレーションにそれぞれこの情報を使用します。
If the client doesn't see its own InHARP_REQUEST, then it SHALL await an InHARP_REPLY before completing the registration phase. This will also provide the client with the protocol address by which the HARP server is addressable. This will be the case when the client happens to be connected to a non-broadcast capable HIPPI-SC network.
クライアントはそれ自身のInHARP_REQUESTを見ないで、次に、それはSHALLです。登録フェーズを完成する前に、InHARP_REPLYを待ってください。 また、これはHARPサーバがアドレス可能であるプロトコルアドレスをクライアントに提供するでしょう。 クライアントがたまたま非放送のできるHIPPI-サウスカロライナネットワークに関するとき、これはそうになるでしょう。
5.1.3 HARP operational phase
5.1.3 HARPの操作上のフェーズ
Once a HARP client has completed its registration phase it enters the operational phase. In this phase of the protocol, the HARP client SHALL gain and refresh its own HARP table which contains the IP to HW address mapping of IP members by sending HARP_REQUESTS to the authoritative address in the HRAL and receiving HARP_REPLYs. The client is fully operational during the operational phase.
HARPクライアントがいったん登録フェーズを完成すると、それは操作上のフェーズに入ります。 プロトコルのこのフェーズでは、HARPクライアントSHALLはHARP_REQUESTSをHRALの正式のアドレスに送って、HARP_REPLYsを受けることによってIPメンバーのHWアドレス・マッピングにIPを含むそれ自身のHARPテーブルを、獲得して、リフレッシュします。 クライアントは操作上の段階の間、完全に操作上です。
In the operational phase, the client's behavior for requesting HARP resolution is the same for broadcast or non-broadcast networks.
操作上のフェーズでは、HARP解決を要求するためのクライアントの振舞いは、放送に同じであるか非放送網です。
The target of an address resolution request updates its address mapping tables with any new information it can find in the request. If it is the target port it SHALL formulate and send a reply message. A port is the target of an address resolution request if at least ONE of the following statements is true of the request:
アドレス解決要求の目標はそれが要求で見つけることができるどんな新情報でもアドレス変換テーブルをアップデートします。 目標がそれを移植するということであるなら、SHALLは応答メッセージを定式化して、送ります。 少なくとも以下の声明のONEが要求に関して本当であるなら、ポートはアドレス解決要求の目標です:
1. The port's IP address is in the target protocol address field
(ar$tpa) of the HARP message.
1. ポートのIPアドレスがHARPメッセージの目標プロトコルアドレス・フィールド(ar$tpa)にあります。
2. The port's ULA (if non-zero), is in the ULA part of the Target
Hardware Address field (ar$tha) of the message.
2. ポートのULA(非ゼロであるなら)はメッセージのTarget Hardware Address分野(ar$tha)のULA地域のそうです。
Pittet Standards Track [Page 10] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[10ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
3. The port's switch address is in the Target Switch Address field of
Target Hardware Address field (ar$tha) of the message (see section
6.2.2).
3. ポートのスイッチアドレスがメッセージのTarget Hardware Address分野(ar$tha)のTarget Switch Address分野にあります(セクション6.2.2を見てください)。
4. The port is a HARP server.
4. ポートはHARPサーバです。
NOTE: It is RECOMMENDED that all HARP servers run on a ports which each have a non-zero ULA.
以下に注意してください。 すべてのHARPサーバがそれぞれ非ゼロULAを持っているポートで走るのは、RECOMMENDEDです。
5.2 HARP Client Operational Requirements
5.2 ハープのクライアントの操作上の要件
The HARP client is responsible for contacting the HARP server(s) to have its own HARP information registered and to gain and refresh its own HARP entry/information about other IP members. This means, as noted above, that HARP clients MUST be configured with the hardware address of the HARP server(s) in the HRAL.
HARPクライアントは他のIPメンバーのそれ自身のHARPエントリー/情報をそれ自身のHARP情報を登録させて、獲得して、リフレッシュするためにHARPサーバに連絡するのに責任があります。 これは、HRALのHARPサーバのハードウェア・アドレスでHARPクライアントを構成しなければならないことを上で述べたように意味します。
HARP clients MUST:
HARPクライアントはそうしなければなりません:
1. When an interface is enabled (e.g. "ifconfig <interface> up" with
an IP address) or assigned the first or an additional IP address
(i.e. an IP alias), the client SHALL initiate the registration
phase.
1. インタフェースは可能にされるか(例えば、IPアドレスで「上に<インタフェース>をifconfigする」)、または1番目か追加IPアドレス(すなわち、IP別名)を割り当てられるとき、クライアントSHALLは登録フェーズを開始します。
2. In the operational phase the client MUST respond to HARP_REQUEST
and InHARP_REQUEST messages if it is the target port. If an
interface has multiple IP addresses (e.g., IP aliases) then the
client MUST cycle through all the IP addresses and generate an
InHARP_REPLY for each such address. In that case an InHARP_REQUEST
will have multiple replies. (Refer to Section 7, "Protocol
Operation" in RFC-1293 [7].)
2. 操作上のフェーズでは、クライアントはそれが目標ポートであるならHARP_REQUESTとInHARP_REQUESTメッセージに応じなければなりません。 インタフェースに複数のIPアドレス(例えば、IP別名)があるなら、クライアントは、すべてのIPアドレスを通って自転車で行って、そのような各アドレスのためにInHARP_がREPLYであると生成しなければなりません。 その場合、InHARP_REQUESTには、複数の回答があるでしょう。 (セクション7、RFC-1293[7]の「プロトコル操作」を参照してください。)
3. React to address resolution reply messages appropriately to build
or refresh its own client HARP table entries. All solicited and
unsolicited HARP_REPLYs from the authoritative HARP server SHALL
be used to update and refresh its own client HARP table entries.
3. それ自身のクライアントHARPテーブル項目に適切にアドレス解決応答メッセージに反応して、組み込むか、またはリフレッシュしてください。 すべてが請求して、求められていないHARP_REPLYsは正式のHARPサーバSHALLからアップデートに使用されて、それ自身のクライアントHARPテーブル項目をリフレッシュします。
Explanation: This allows the HARP server to update the clients
when one of server's mappings change, similar to what is
accomplished on Ethernet with gratuitous ARP.
説明: サーバのマッピング変化の1つであるときに、これで、HARPサーバはクライアントをアップデートできます、無料のARPと共にイーサネットで達成されることと同様です。
4. Generate and transmit InHARP_REQUEST messages as needed and
process InHARP_REPLY messages appropriately (see section 5.1.2 and
5.6). All InHARP_REPLY messages SHALL be used by the client to
build or refresh its HARP table entries. (Refer to Section 7,
"Protocol Operation" in [7].)
4. 必要に応じてInHARP_REQUESTメッセージを生成して、送ってください、そして、適切にInHARP_REPLYメッセージを処理してください(セクション5.1 .2と5.6を見てください)。 すべてのInHARP_REPLYメッセージSHALLが建てるクライアントによって使用されるか、またはHARPテーブル項目をリフレッシュします。 (セクション7、[7]の「プロトコル操作」を参照してください。)
Pittet Standards Track [Page 11] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[11ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
If the registration phase showed that the hardware does not support broadcast, then the client MUST refresh its own entry for the HARP server, created during the registration phase, at least once every 15 minutes. This can be accomplished either through the exchange of a HARP request/reply with the HARP server or by repeating step 1. To decrease the redundant network traffic, this timeout SHOULD be reset after each HARP_REQUEST/HARP_REPLY exchange.
登録フェーズが、ハードウェアが放送をサポートしないのを示したなら、クライアントは少なくとも15分に一度登録段階の間に作成されたHARPサーバのためのそれ自身のエントリーをリフレッシュしなければなりません。 HARPサーバによるHARP要求/回答の交換を通して、または、繰り返しているステップ1でこれを達成できます。 余分なネットワークトラフィック、このタイムアウトSHOULDを減少させるには、それぞれのHARP_REQUEST/HARP_REPLY交換の後にリセットされてください。
Explanation: The HARP_REQUEST shows the HARP server that the client is still alive. Receiving a HARP_REPLY indicates to the client that the server must have seen the HARP_REQUEST.
説明: HARP_REQUESTは、クライアントがまだ生きているのをHARPサーバに示します。 HARP_REPLYを受けるのは、サーバがHARP_REQUESTを見たに違いないのをクライアントに示します。
If the registration phase shows that the underlying network supports broadcast, then periodic InHARP_REQUEST/InHARP_REPLY operations of step 4 are NOT REQUIRED.
基本的なネットワークがサポートする登録フェーズショーが放送されるなら、ステップ4の周期的なInHARP_REQUEST/InHARP_REPLY操作はNOT REQUIREDです。
5.3 Receiving Unknown HARP Messages
5.3 未知のハープメッセージを受け取ること。
If a HARP client receives a HARP message with an operation code (ar$op) that it does not support, it MUST gracefully discard the message and continue normal operation. A HARP client is NOT REQUIRED to return any message to the sender of the undefined message.
HARPクライアントがそれがサポートしない命令コード(ar$オプアート)でHARPメッセージを受け取るなら、それは、優雅にメッセージを捨てて、通常の操作を続けなければなりません。 HARPクライアントは未定義のメッセージの送付者にどんなメッセージも返すNOT REQUIREDです。
5.4 HARP Server Operational Requirements
5.4 ハープのサーバの操作上の要件
A HARP server MUST accept HIPPI connections from other HIPPI ports. The HARP server expects an InHARP_REQUEST as the first message from the client. A server examines the IP source address, the hardware source address of the InHARP_REQUEST and adds or updates its HARP table entry <IP address(es), switch address, ULA> as well as the time stamp.
HARPサーバは他のHIPPIポートからHIPPI接続を受け入れなければなりません。 HARPサーバはクライアントからの最初のメッセージとしてInHARP_REQUESTを予想します。 サーバは、HARPテーブル項目<IPアドレス(es)をIPソースアドレス、InHARP_REQUESTのハードウェアソースアドレスを調べて、加えるか、またはアップデートします、スイッチアドレス、タイムスタンプと同様にULA>。
A HARP server SHALL reply to HARP_REQUESTs and InHARP_REQUESTs based on the information which it has in its HARP table. The HARP server SHALL reply with a HARP_REPLY or a InHARP_REPLY, if it has the requested information in its tables; otherwise it SHALL reply with a HARP_NAK. The HARP server replies SHALL contain the hardware type and corresponding format of the request (see also section 6).
HARP_REQUESTsとInHARP_REQUESTsへのHARPサーバSHALL回答はそれがHARPテーブルに持っている情報を基礎づけました。 テーブルに求められた情報を持っているなら、HARPサーバSHALLはHARP_REPLYかInHARP_REPLYと共に返答します。 そうでなければ、それ、SHALLはHARP_NAKと共に返答します。 HARPサーバ回答SHALLは要求のハードウェアタイプと対応する形式を含んでいます(また、セクション6を見てください)。
The following table shows all possible source address combinations on an incoming message and the actions to be taken. "linked" indicates that an existing "IP entry" is linked to a "hardware entry". It is possible to have an existing "IP entry" and to have an existing "hardware entry" but neither is linked to the other.
以下のテーブルは、取るためにすべての可能なソースアドレス組み合わせを入力メッセージと動作に示しています。 「リンク」は、既存の「IPエントリー」が「ハードウェアエントリー」にリンクされるのを示します。 それは、既存の「IPエントリー」を持っていて、既存の「ハードウェアエントリー」を持つのにおいて可能ですが、どちらももう片方にリンクされません。
Pittet Standards Track [Page 12] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[12ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
+---+----------+----------+------------+---------------------+
| # | IP entry | HW entry | misc | Action |
+---+----------+----------+------------+---------------------+
| 1 | exists | exists | linked | * |
| 2 | exists | exists | not linked | *, a, b, e, f |
| 3 | exists | new | not linked | *, a, b, d, e, f |
| 4 | new | exists | not linked | *, c, e, f |
| 5 | new | new | not linked | *, c, d, e, f |
+---+----------+----------+------------+---------------------+
Actions:
*: update timeout value
a: break the existing IP -> hardware (HW) - old link
b: delete HW(old) -> IP link and decrement HW(old) refcount, if
refcount = 0, delete HW(old)
c: create new IP entry
d: create new HW entry
e: add new IP -> HW link to IP entry
f: add new HW -> IP link to HW entry
+---+----------+----------+------------+---------------------+ | # | IPエントリー| HWエントリー| 雑ネタ| 動作| +---+----------+----------+------------+---------------------+ | 1 | 存在しています。| 存在しています。| リンクされます。| * | | 2 | 存在しています。| 存在しています。| リンクされません。| *, a、b、e、f| | 3 | 存在しています。| 新しい| リンクされません。| *, a、b、d、e、f| | 4 | 新しい| 存在しています。| リンクされません。| *, c、e、f| | 5 | 新しい| 新しい| リンクされません。| *, c、d、e、f| +---+----------+----------+------------+---------------------+ 動作: *: アップデートタイムアウトはaを評価します: 中断の既存のIP->ハードウェア(HW)--古いリンクb: refcount=0であるならHWの(古い)の->IPリンクと減少HW(古い)refcountを削除してください、そして、HWの(古い)のcを削除してください: 新しいIPエントリーdを作成してください: 新しいHWエントリーeを作成してください: 新しいIP->HWがIPエントリーfにリンクすると言い足してください: 新しいHW->IPリンクをHWエントリーに加えてください。
Examples of when this could happen (Numbers match lines in above table):
これが起こることができた(数は上のテーブルで系列に合っています)時に関する例:
1: supplemental message
1: 補足のメッセージ
Just update timer.
ただタイマをアップデートしてください。
2: move an IP alias to an existing interface
2: IP別名を既存のインタフェースに動かしてください。
If the IP source address of the InHARP_REQUEST duplicates a table
entry IP address (e.g. IPa <-> HWa) and the InHARP_REQUEST
hardware source address matches a hardware address entry (e.g. HWb
<-> IPb), but they are not linked together, then:
- HWa entry needs to have its reference to the current IPa
address removed.
- HWb needs to have a new reference to IPa added
- IPa needs to be linked to HWb
InHARP_REQUESTのIPソースアドレスがテーブル項目をコピーするなら、IPアドレス(例えば、IPa<->HWa)とInHARP_REQUESTハードウェアソースはハードウェア・アドレスエントリー(例えば、HWb<->IPb)をマッチに扱いますが、それらは結びつけられません、そして: - HWaエントリーは、現在のIPaアドレスの参照を取り除かせる必要があります。 - HWbは、IPaの新しい参照を加えさせる必要があります--IPaは、HWbにリンクされる必要があります。
3: move IP address to a new interface
3: IPアドレスを新しいインタフェースに動かしてください。
If the InHARP_REQUEST requester's IP source address duplicates a
table entry IP address and the InHARP_REQUEST hardware source
address does not match the table entry hardware address, then a
new HW entry SHALL be created. The requestor's IP address SHALL be
moved from the original HW entry to the new one (see above).
InHARP_REQUESTリクエスタのIPソースアドレスがテーブル項目IPアドレスとInHARP_REQUESTハードウェアソースアドレスをコピーするなら、テーブル項目ハードウェアが扱うマッチ、次に新しいHWエントリーSHALLは作成されませんか? IPがSHALLを扱う要請者は元のHWエントリーから新しい方まで動かされました(上を見てください)。
Pittet Standards Track [Page 13] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[13ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
4: add IP alias to table
4: 見送るIP別名を加えてください。
If the InHARP_REQUEST requester's hardware source address
duplicates a hardware source address entry, but there is no IP
entry matching the received IP address, then the IP address SHALL
be added to the hardware entries previous IP address(es). (E.g.
adding an IP alias).
InHARP_REQUESTリクエスタのハードウェアソースアドレスがハードウェアソースアドレスエントリーをコピーしますが、受け取られていているIPアドレスに合っているIPエントリーが全くなければ、IPはSHALLを扱います。前のハードウェアエントリーIPアドレス(es)に加えられてください。 (例えば、IP別名を加えます。)
5: fresh entry, add it
5: 新鮮なエントリー、それを加えてください。
Standard case, create both entries and link them.
一般的なケース、両方のエントリーを作成してください、そして、それらをリンクしてください。
A server MUST update the HARP table entry's timeout for each HARP_REQUEST. Explanation: if the client is sending HARP requests to the server, then the server SHOULD note that the client is still "alive" by updating the timeout on the client's HARP table entry.
サーバが各HARP_REQUESTのためにHARPテーブル項目のタイムアウトをアップデートしなければならない、説明: クライアントがサーバへの要求をHARPに送るなら、サーバSHOULDは、クライアントがクライアントのHARPテーブル項目のときにタイムアウトをアップデートすることによってまだ「生きている」と述べます。
A HARP server SHOULD use the PIBES (see section 7) to send out HARP_REPLYs to all hardware addresses in its table when the HARP server table changes mappings. This feature decreases the time of stale entries in the clients.
HARPサーバテーブルがマッピングを変えるとき、SHOULDがPIBES(セクション7を見る)を使用するHARPサーバはテーブルのすべてのハードウェア・アドレスにHARP_REPLYsを出します。 この特徴はクライアントの聞き古したエントリーの時間を減少させます。
If there are multiple addresses in the HRAL, then a server needs to act as a client to the other servers.
複数のアドレスがHRALにあれば、サーバは、クライアントとして他のサーバに機能する必要があります。
5.5 HARP and Permanent ARP Table Entries
5.5 ハープを弾いてください。そうすれば、永久的なARPはエントリーをテーブルの上に置きます。
An IP station MUST have a mechanism (e.g. manual configuration) for determining what permanent entries it has. The details of the mechanism are beyond the scope of this memo. The permanent entries allow interoperability with legacy HIPPI adapters which do not yet implement dynamic HARP and use a table-based static ARP. Permanent entries are not aged.
IPステーションには、それがどんな永久的なエントリーを持っているかを決定するためのメカニズム(例えば、手動の構成)がなければなりません。 メカニズムの細部はこのメモの範囲を超えています。 永久的なエントリーはまだダイナミックなHARPを実装していて、テーブルベースの静的なARPを使用しないレガシーHIPPIアダプターで相互運用性を許容します。 永久的なエントリー老いない。
The HARP server SHOULD use the static entries to resolve incoming HARP_REQUESTs from the clients. This feature eliminates the need for maintaining a static HARP table on the client ports.
HARPサーバSHOULDは、クライアントから入って来るHARP_REQUESTsを決議するのに静的なエントリーを使用します。 この特徴はクライアントポートの上の静的なHARPテーブルを維持する必要性を排除します。
5.6 HARP Table Aging
5.6 ハープテーブルの年をとること
HARP table aging MUST be supported since IP addresses, especially IP aliases and also interfaces (with their ULA), are likely to move. When so doing the mapping in the clients own HARP table/cache becomes invalid and stale.
IPアドレス(特にIP別名とインタフェース(それらのULAと)も)が移行しそうであるので、HARPテーブルの年をとることをサポートしなければなりません。 したがって、クライアントでマッピングをするとき、自己のHARPテーブル/キャッシュは無効で聞き古したであるなります。
o When a client's HARP table entry ages beyond 15 minutes, a HARP
client MUST invalidate the table entry.
o クライアントのHARPテーブル項目が15分間年をとると、HARPクライアントはテーブル項目を無効にしなければなりません。
Pittet Standards Track [Page 14] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[14ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
o When a server's HARP table entry ages beyond 20 minutes, the HARP
server MUST delete the table entry.
o サーバのHARPテーブル項目が20分間年をとると、HARPサーバはテーブル項目を削除しなければなりません。
NOTE: the client SHOULD revalidate a HARP table entry before it ages, thus restarting the aging time when the table entry is successfully revalidated. The client MAY continue sending traffic to the port referred to by this entry while revalidation is in progress, as long as the table entry has not aged. The client MUST revalidate an aged entry prior to transmitting any non-address-resolution traffic to the port referred to by this entry.
以下に注意してください。 それの前のHARPテーブル項目が年をとらせるクライアントSHOULD revalidate、その結果、テーブル項目が首尾よくそうである古い時間を再開するのは再有効にされました。 クライアントは、再合法化が進行している間にこのエントリーで言及されたポートにトラフィックを送り続けるかもしれません、テーブル項目が年をとっていない限り。 クライアントはこのエントリーでどんな非アドレスの解決トラフィックもポートに送る前の老いているエントリーが言及したrevalidateがそうしなければなりません。
The client revalidates the entry by querying the HARP server with a HARP_REQUEST. If a valid reply is received (e.g. HARP_REPLY), the entry is updated. If the address resolution service cannot resolve the entry (e.g. HARP_NAK, "host not found"), the associated table entry is removed. If the address resolution service is not available (i.e. "server failure") the client MUST attempt to revalidate the entry by transmitting an InHARP_REQUEST to the hardware address of the entry in question and updating the entry on receipt of an InHARP_REPLY. If the InHARP_REQUEST attempt fails to return an InHARP_REPLY, the associated table entry is removed.
クライアントは、HARP_REQUESTと共にHARPサーバについて質問することによって、エントリーを再有効にします。有効な回答が受け取られているなら(例えば、HARP_REPLY)、エントリーをアップデートします。 アドレス解決サービスがエントリー(例えば、HARP_NAK、「見つけられなかったホスト」)を決議できないなら、関連テーブル項目を取り除きます。 アドレス解決サービスが利用可能でないなら(すなわち、「サーバ失敗」)、クライアントは、InHARP_REQUESTを問題のエントリーのハードウェア・アドレスに伝えて、InHARP_REPLYを受け取り次第エントリーをアップデートすることによって、revalidateにエントリーを試みなければなりません。 InHARP_REQUEST試みがInHARP_REPLYを返さないなら、関連テーブル項目を取り除きます。
6. HARP Message Encoding
6. ハープメッセージコード化
The HARP Message is encapsulated over HIPPI-FP and HIPPI-LE headers. The HARP FP header values are to be set as defined in RFC-2067 "IP over HIPPI" [15]. The following sections detail the HIPPI-LE field contents and HARP message structure and contents. In a broadcast capable network the client MAY also support Type 1 and 6, Ethernet and IEEE 802 ARP packet formats.
HARP MessageはHIPPI-FPとHIPPI-LEヘッダーの上にカプセル化されます。 HARP FPヘッダー値はRFC-2067「HIPPIの上のIP」[15]で定義されるように設定されることです。 以下のセクションはHIPPI-LE分野コンテンツ、HARPメッセージ構造、およびコンテンツについて詳述します。 できる放送では、クライアントのために5月をネットワークでつないでください、そして、また、Type1と6(イーサネットとIEEE802ARPパケット・フォーマット)をサポートしてください。
6.1 HIPPI-LE Header of HARP Messages
6.1 ハープメッセージのHIPPI-LEヘッダー
The HIPPI message format for Internet datagrams shall conform to the HIPPI-FP [2] and HIPPI-LE [3] standards. The length of a HIPPI message, including trailing fill, shall be a multiple of eight bytes as required by HIPPI-LE. The HIPPI-LE header fields of HARP and InHARP requests and replies SHALL be:
インターネットデータグラムのためのHIPPIメッセージ・フォーマットはHIPPI-FP[2]とHIPPI-LE[3]規格に従うものとします。 中詰めを引きずるのを含むHIPPIメッセージの長さは必要に応じてHIPPI-LEで8バイトの倍数になるでしょう。 HARP、InHARP要求、および回答SHALLのHIPPI-LEヘッダーフィールド、あります:
FC (3 bits) SHALL contain zero.
FC(3ビット)SHALLはゼロを含んでいます。
Double-wide SHOULD be set according to HIPPI-LE [3]. This memo does NOT address the implications on HARP when this bit is set to 1 indicating the possibility of a port being able to accept 64-bit HIPPI connections.
HIPPI-LEに従ったセットが[3]であったなら-広くSHOULDを倍にしてください。 このビットがポートの可能性を示す1に設定されるとき、64ビットのHIPPI接続を受け入れることができて、このメモはHARPで含意を扱いません。
Pittet Standards Track [Page 15] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[15ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
Message_Type SHALL contain 0 to indicate a data message. HARP messages are identified using the Ethertype and the message type in the ar$op field of the HARP message.
メッセージ_Type SHALLはデータメッセージを示す0を含んでいます。 HARPメッセージは、HARPメッセージのar$オプアート分野でEthertypeとメッセージタイプを使用することで特定されます。
Destination_Switch_Address, SHALL be the Switch Address of the destination port.
目的地_Switch_Address、SHALL、仕向港のSwitch Addressになってください。
Destination_IEEE_Address SHALL be the ULA of the destination port, if known, otherwise zero.
目的地_IEEE_Address SHALL、そうでなければ、仕向港であって、知られることのULA、ゼロになってください。
Destination_Address_Type SHALL be 2, a 12-bit logical address. The behavior with type = 1, source routing, is NOT defined in this specification.
目的地_Address_Type SHALL、2、12ビットの論理アドレスになってください。 タイプ=1がある振舞い(ソースルーティング)はこの仕様に基づき定義されません。
Source_Switch_Address in requests SHALL be the sender's Switch Address.
ソース_Switch_Addressは送付者のものがSwitch Addressであったなら中でSHALLを要求します。
Source_IEEE_Address SHALL be the sender's ULA if known, otherwise zero.
送付者のものがULAであったなら別の方法で知られているなら_IEEE_Address SHALLの出典を明示してください。ゼロ。
Source_Address_Type SHALL be 2, a 12-bit logical address. The behavior with type = 1, source routing, is NOT defined in this specification.
_Address_Type SHALLの出典を明示してください。2、12ビットの論理アドレスになってください。 タイプ=1がある振舞い(ソースルーティング)はこの仕様に基づき定義されません。
6.1.1 IEEE 802.2 LLC
6.1.1 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の最初のバイトで始まります。
The LLC value for SSAP-DSAP-CTL SHALL be 0xAA-AA-03 (3 bytes) indicating the presence of a SNAP header.
LLCは0xAA-AA-03がSNAPヘッダーの存在を示す(3バイト)であったならSSAP-DSAP-CTL SHALLのために評価します。
6.1.2 SNAP
6.1.2 スナップ
The OUI value for Organization Code SHALL be 0x00-00-00 (3 bytes) indicating that the following two-bytes is an Ethertype.
0×00 00-00(3バイト) 以下の2バイトがEthertypeであることを示すことであるOrganization Code SHALLのためのOUI値。
The Ethertype value SHALL be set as defined in Assigned Numbers [16]: InHARP = InARP = HARP = ARP = 2054 = 0x0806.
EthertypeはAssignedで定義されるセットが民数記[16]であったならSHALLを評価します: InHARP=InARP=は=ARP=2054=0×0806のハープを弾きます。
The total size of the LLC/SNAP header is fixed at 8-bytes.
LLC/SNAPヘッダーの総サイズは8バイトで固定されています。
Pittet Standards Track [Page 16] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[16ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
6.1.3 HIPPI-LE header Diagram
6.1.3 HIPPI-LEヘッダーDiagram
HIPPI-LE header for HARP/InHARP PDUs:
HARP/InHARP PDUsのためのHIPPI-LEヘッダー:
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 = IP ULP |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | n + 8 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|M_Type | 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | D_A_T | S_A_T | 000 | Source Switch Addr |
+-------+-------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 |Message byte 0 |Message byte 1 |Message byte 2 | . . . |
+---------------+---------------+---------------+--- |
| . . . |
+ ------------+---------------+---------------+---------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+---------------+---------------+---------------+---------------+
N-1| FILL | FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HIPPI Message Format
31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 =IP ULP|1|0| 000 | 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | n+8| +-----+-+-------+-----------------------+-----------------------+ 2 |[LA]|W|M_はタイプします。| 000 | Dest。 スイッチAddr| +-----+-+-------+-----------------------+-----------------------+ 3 | D_A_T| S_A_T| 000 | ソーススイッチAddr| +-------+-------+---------------+-------+-----------------------+ 4 | 00 00 | | +-------------------------------+ | 5 | 目的地ULA| +-------------------------------+-------------------------------+ 6 | [LA]| | +-------------------------------+ | 7 | ソースULA| +===============+===============+===============+===============+ 8 | AA| AA| 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | Ethertype(2054)| +---------------+---------------+-------------------------------+ 10 |メッセージバイト0|メッセージバイト1|メッセージバイト2| . . . | +---------------+---------------+---------------+--- | | . . . | + ------------+---------------+---------------+---------------+ | . . . | バイト(n-2)| バイト(n-1)| 中詰め| +---------------+---------------+---------------+---------------+ N-1| 中詰め| 中詰め| 中詰め| 中詰め| +---------------+---------------+---------------+---------------+ 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 (HARP message)
(n+8) is the nb of bytes in the HARP message, incl. LLC/SNAP.
+====+ denotes the boundary between D1_Area and D2_Area.
[LA] fields are zero unless used otherwise locally.
Abbreviations:
"W" = Double_Wide field SHALL be 0
"M_Type" = Message_Type field SHALL be set according to
HIPPI-LE
"D_A_T" = Destination_Address_Type SHALL be 2
ワーズ0-1: HIPPI-fpヘッダーワーズ2-7: D1_領域(HIPPI-LEヘッダー)ワーズ8-9: D2_領域(IEEE802.2LLC/スナップ)ワーズ10(N-1): D2_領域(HARPメッセージ)(n+8)はHARPメッセージ、inclのバイトのNbです。 LLC/スナップ。 +====+はD1_AreaとD2_Areaの間の境界を指示します。 そうでなければ、局所的に使用されない場合、[LA]分野はゼロです。 略語: 「W」=二重_Wideは0がメッセージ_Type分野「M_はタイプする」=SHALLであったならHIPPI-LEに従ったセットが2になる目的地_アドレス_が、タイプする「D_A_T」=であったならSHALLをさばきます。
Pittet Standards Track [Page 17] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[17ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
"S_A_T" = Source_Address_Type SHALL be 2
[FILL] bytes complete the HIPPI message to an even
number of 32 bit words. The number of fill bytes
is not counted in the data length.
「S_A_T」は[FILL]バイトが完成する2が32ビットの単語の偶数へのHIPPIメッセージであったならソース_Address_Type SHALLと等しいです。 中詰めバイトの数はデータの長さで数えられません。
6.2 HIPPI Hardware Address Formats and Requirements
6.2 HIPPIハードウェアアドレス形式と要件
For HIPPI-800, the Hardware Address is a 10-byte unit that SHALL contain the Switch Address AND the ULA. The format of a hardware address is:
Hardware Addressによる10バイトのユニット、そのSHALLがSwitch AddressとULAを含んでいるというHIPPI-800に関しては、ことです。 ハードウェア・アドレスの形式は以下の通りです。
31 23 15 7 0 +---------------+---------------+-------+-------+---------------+ | Mode Byte | 00 | 0 | X | XX | +---------------+---------------+-------+-------+---------------+ | ULA byte 0 | ULA byte 1 | ULA byte 2 | ULA byte 3 | +---------------+---------------+---------------+---------------+ | ULA byte 4 | ULA byte 5 | +---------------+---------------+
31 23 15 7 0 +---------------+---------------+-------+-------+---------------+ | モードバイト| 00 | 0 | X| XX| +---------------+---------------+-------+-------+---------------+ | ULAバイト0| ULAバイト1| ULAバイト2| ULAバイト3| +---------------+---------------+---------------+---------------+ | ULAバイト4| ULAバイト5| +---------------+---------------+
Where "XXX" is the 12 bit HIPPI logical address defined in HIPPI-SC [4]. Details on ULA see next section.
"XXX"がHIPPI-サウスカロライナ[4]で定義された12ビットのHIPPI論理アドレスであるところ。 ULAに関する詳細は次のセクションを見ます。
Two switch addresses are considered to be the same when they have the same 12 bit destination HIPPI logical address.
それらに同じ12ビットの目的地HIPPI論理アドレスがあるとき、2つのスイッチアドレスが同じであると考えられます。
NOTE: In the case of HIPPI-6400, the hardware address is ONLY the 6- byte ULA. Therefore the length of the hardware address clearly defines which version of HIPPI is being used.
以下に注意してください。 HIPPI-6400の場合では、ハードウェア・アドレスは6バイトULAにすぎません。 したがって、ハードウェア・アドレスの長さは、HIPPIのどのバージョンが使用されているかを明確に定義します。
6.2.1 48-bit Universal LAN MAC Addresses
6.2.1 48ビットの普遍的なLAN MACアドレス
IEEE Standard 802.1A [11] specifies the Universal LAN MAC Address format. The globally unique part of the 48-bit space is administered by the IEEE. Each port on a HIPPI-SC LAN SHOULD be assigned a ULA. Multiple ULAs may be used if a port contains more than one IEEE 802.2 LLC protocol entity.
IEEE Standard 802.1A[11]はUniversal LANマックーアドレス形式を指定します。 48ビットのスペースのグローバルにユニークな地域はIEEEによって管理されます。 それぞれがaでHIPPI-SC LAN SHOULDを移植します。ULAは割り当てられます。 ポートが1IEEE802.2のLLCプロトコル実体を含んでいるなら、複数のULAsが使用されるかもしれません。
The format of the HIPPI hardware address within its HARP message follows IEEE 802.1A canonical bit order and HIPPI-FP bit and byte order. For example the requester's ULA part of the HIPPI hardware address would decompose to:
HARPメッセージの中のHIPPIハードウェア・アドレスの形式は注文とHIPPI-FPが噛み付いたIEEE 802.1A正準なビットとバイトオーダーに続きます。 例えばリクエスタのHIPPIハードウェア・アドレスのULA部分は以下のことのために分解するでしょう。
Pittet Standards Track [Page 18] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[18ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
31 23 15 7 0 +---------------+---------------+---------------+---------------+ |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バイト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 RECOMMENDED. The use of ULAs is REQUIRED if a port wishes to interoperate with a conventional network.
しかし、ULAsの使用はOPTIONAL、RECOMMENDEDです。 従来のネットワークと共に共同利用するというポート願望であるなら、ULAsの使用はREQUIREDです。
ULAs may also be used by bridging devices that replace HIPPI hardware headers with the MAC headers of other LANs.
また、ULAsは、HIPPIハードウェアヘッダーを他のLANのMACヘッダーに取り替えるデバイスをブリッジすることによって、使用されるかもしれません。
6.3 HARP and InHARP Message Formats
6.3 ハープとInHARPメッセージ・フォーマット
The HARP protocols use the HIPARP hardware type (ar$hrd) [16], protocol type (ar$pro), and operation code (ar$op) data formats as the ARP, and InARP protocols [15,7]. In addition, HARP makes use of an additional operation code for ARP_NAK introduced with [12]. The remainder of the HARP/InHARP message format is different than the ARP/InARP message format defined in [15,7,10] and it is also different from the format defined in the first "IP and ARP on HIPPI" RFC-1374 [14].
HARPプロトコルはHIPARPハードウェアタイプ(ar$hrd)[16]を使用します、プロトコルタイプ(ar$プロ)、そして、命令コード(ar$オプアート)データがARP、およびInARPとしてプロトコル[15、7]をフォーマットします。 さらに、HARPは[12]で導入されたARP_NAKに兼業コードを利用します。 HARP/InHARPメッセージ・フォーマットの残りは[15、7、10]で定義されたARP/InARPメッセージ・フォーマットと異なっています、そして、また、それも最初の「HIPPIの上のIPとARP」RFC-1374[14]で定義された書式と異なっています。
HARP messages SHALL be transmitted with the HIPARP hardware type code of 28 (decimal). Furthermore, HARP messages SHALL be accepted if received with hardware type codes of either 28, 1 or 6 (decimal).
HARPはSHALLを通信させます。28(10進)のHIPARPハードウェアタイプコードで、伝えられてください。 その上、HARPはSHALLを通信させます。28、1または6(10進)のハードウェアタイプコードで受け取るなら、受け入れてください。
The HARP message has several fields that have the following format and values:
HARPメッセージには、以下の形式と値を持っているいくつかの分野があります:
Data sizes and field meaning:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below
ar$op 16 bits Operation code (request, reply, or NAK)
ar$pln 8 bits byte length of each protocol address
ar$rhl 8 bits requester's HIPPI hardware address length (q)
ar$thl 8 bits target's HIPPI hardware address length (x)
ar$rpa 32 bits requester's protocol address
ar$tpa 32 bits target's protocol address
データサイズと分野意味: それぞれのプロトコルの8ビットの16ビットのar$オプアートOperationコード(要求、回答、またはNAK)ar$plnバイトの長さの下のプロトコル分野の16ビットのhrd16ドルのarビットHardwareタイプar$プロプロトコルタイプは、ar$rhlの8ビットのリクエスタのHIPPIハードウェア・アドレス長さ(q)ar$thlの8ビットの目標のHIPPIハードウェア・アドレス長さ(x)ar$rpaの32ビットのリクエスタのプロトコルアドレスar$tpaが32ビットの目標のプロトコルアドレスであると扱います。
Pittet Standards Track [Page 19] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[19ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
ar$rha qbytes requester's HIPPI Hardware address
ar$tha xbytes target's HIPPI Hardware address
tha xbytes目標のrha qbytesリクエスタのHIPPI Hardwareアドレスar$HIPPI Hardwareが扱うar$
Where :
ar$hrd - SHALL contain 28. (HIPARP)
どこ: ar$hrd--SHALLは28を含んでいます。 (HIPARP)
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$プロ--SHALLはIPプロトコルコード2048(小数)を含んでいます。
ar$op - SHALL contain the operational value (decimal):
1 for HARP_REQUESTs
2 for HARP_REPLYs
8 for InHARP_REQUESTs
9 for InHARP_REPLYs
10 for HARP_NAK
ar$オプアート--SHALLは操作上の値(小数)を含んでいます: 1 ハープ_NAKのためのInHARP_リプライ10を求めるInHARP_要求9のためのハープ_リプライ8を求めるハープ_要求2のために
ar$pln - SHALL contain 4.
ar$pln--SHALLは4を含んでいます。
ar$rln - SHALL contain 10 IF this is a HIPPI-800 HW address
ELSE, for HIPPI-6400, it SHALL contain 6.
ar$はrlnされます--SHALLはこれがHIPPI-6400のためのHIPPI-800 HWアドレスELSEであるなら10を含んでいて、それはSHALLです。6を含んでください。
ar$thl - SHALL contain 10 IF this is a HIPPI-800 HW address
ELSE, for HIPPI-6400, it SHALL contain 6.
ar$はthlされます--SHALLはこれがHIPPI-6400のためのHIPPI-800 HWアドレスELSEであるなら10を含んでいて、それはSHALLです。6を含んでください。
ar$rha - in requests and NAKs it SHALL contain the requester's
HW address. In replies it SHALL contain the target
port's HW address.
要求におけるar$rhaとNAKs、それ、SHALLはリクエスタのHWアドレスを含んでいます。 回答、それ、SHALLは目標ポートのHWアドレスを含んでいます。
ar$rpa - in requests and NAKs it SHALL contain the requester's IP
address if known, otherwise zero.
In other replies it SHALL contain the target
port's IP address.
要求におけるar$rpaとNAKs、それ、SHALLは知られているならIPが扱うリクエスタのもの、そうでなければゼロを含んでいます。 他では、それは返答しています。SHALLは目標ポートのIPアドレスを含んでいます。
ar$tha - in requests and NAKs it SHALL contain the target's
HW address if known, otherwise zero.
In other replies it SHALL contain the requester's
HW addressA.
要求におけるar$thaとNAKs、それ、SHALLは知られているならHWが扱う目標のもの、そうでなければゼロを含んでいます。 他では、それは返答しています。SHALLはリクエスタのHW addressAを含んでいます。
ar$tpa - in requests and NAKs it SHALL contain the
target's IP address if known, otherwise zero.
In other replies it SHALL contain the requester's
IP address.
要求におけるar$tpaとNAKs、それ、SHALLは知られているならIPが扱う目標のもの、そうでなければゼロを含んでいます。 他では、それは返答しています。SHALLはリクエスタのIPアドレスを含んでいます。
The format of the six bytes of the ULA SHALL be the same as required in the HIPPI-LE header (see section 6.2), except for the alignment of the ULAs with respect to the 32-bit HIPPI word, which is different between ARP and HIPPI-LE. No bit reversal is necessary as is required with FDDI.
形式、ULA SHALLの6バイトでは、必要に応じてHIPPI-LEヘッダーで同じであってください(セクション6.2を見てください)、ARPとHIPPI-LEの間で異なった32ビットのHIPPI単語に関するULAsの整列を除いて。 どんなビット逆転もそのままでFDDIによって必要な状態で必要ではありません。
Pittet Standards Track [Page 20] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[20ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP Message
31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 |1|0| 000 | 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | 45 | +-----+-+-------+-----------------------+-----------------------+ 2 |[LA]|W|MsgT=0| 000 | Dest。 スイッチAddr| +-----+-+-------+-----------------------+-----------------------+ 3 | 2 | 2 | 000 | ソーススイッチAddr| +---------------+---------------+-------+-----------------------+ 4 | 00 00 | | +-------------------------------+ | 5 | 目的地ULA| +-------------------------------+-------------------------------+ 6 | [LA]| | +-------------------------------+ | 7 | ソースULA| +===============+===============+===============+===============+ 8 | AA| AA| 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | Ethertype(2054)| +---------------+---------------+-------------------------------+ 10 | hrd(28)| プロ(2048)| +---------------+---------------+---------------+---------------+ 11 | オプアート(ar$オプアート)| pln(6)| rhl(q)| +---------------+---------------+---------------+---------------+ 12 | thlは(x)と等しいです。| リクエスタIP Address覚醒剤(24ビット)| +---------------------------------------------------------------+ 13 | Req。 IPは下ろされます。| 上側で(24ビット)IP Addressを狙ってください。| +---------------+-----------------------------------------------+ 14 | Tgt。 IPは下ろされます。| リクエスタHIPPI Hardware Addressバイト0--2| +---------------+-----------------------------------------------+ 15 | リクエスタHIPPI Hardware Addressバイト3--6| +-----------------------------------------------+---------------+ 16 | リクエスタHW Addressバイト7--q| Tgt HWバイト0| +---------------+---------------+---------------+---------------+ 17 | 目標HIPPI Hardware Addressバイト1--4| +---------------------------------------------------------------+ 18 | 目標HIPPI Hardware Addressバイト5--8| +---------------+---------------+---------------+---------------+ 19 |Tgt HWバイト9-x| 中詰め| 中詰め| 中詰め| +---------------+---------------+---------------+---------------+ ハープ--InHARPメッセージ
Pittet Standards Track [Page 21] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 21] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
6.3.1 Example Message encodings:
6.3.1 Example Message encodings:
HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = IPa
HARP ar$rha = SWy ULAy HARP ar$tha = 0 **
** is what we would like to find out
HARP_REQUEST message HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = IPa HARP ar$rha = SWy ULAy HARP ar$tha = 0 ** ** is what we would like to find out
HARP_REPLY message format
HARP ar$op = 2 (HARP_REPLY)
HARP ar$rpa = IPa HARP ar$tpa = IPy
HARP ar$rha = SWa ULAa * HARP ar$tha = SWy ULAy
* answer we were looking for
HARP_REPLY message format HARP ar$op = 2 (HARP_REPLY) HARP ar$rpa = IPa HARP ar$tpa = IPy HARP ar$rha = SWa ULAa * HARP ar$tha = SWy ULAy * answer we were looking for
InHARP_REQUEST message format
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAa
** is what we would like to find out
InHARP_REQUEST message format HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAa ** is what we would like to find out
InHARP_REPLY message format
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs * HARP ar$tpa = IPy
HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy
* answer we were looking for
InHARP_REPLY message format HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy * answer we were looking for
6.3.2 HARP_NAK message format
6.3.2 HARP_NAK message format
The HARP_NAK message format is the same as the received HARP_REQUEST message format with the operation code set to HARP_NAK; i.e. the HARP_REQUEST message data is copied byte for byte for transmission with the HARP_REQUEST operation code changed to the HARP_NAK value. HARP makes use of an additional operation code for HARP_NAK. Hence, HARP_NAK MUST be implemented.
The HARP_NAK message format is the same as the received HARP_REQUEST message format with the operation code set to HARP_NAK; i.e. the HARP_REQUEST message data is copied byte for byte for transmission with the HARP_REQUEST operation code changed to the HARP_NAK value. HARP makes use of an additional operation code for HARP_NAK. Hence, HARP_NAK MUST be implemented.
6.3.3 Combined HIPPI-LE and HARP message addresses
6.3.3 Combined HIPPI-LE and HARP message addresses
The combined HIPPI-LE/HARP message contains ten addresses, two for the destination and two for the source of the message, three for the requester and three for the target:
The combined HIPPI-LE/HARP message contains ten addresses, two for the destination and two for the source of the message, three for the requester and three for the target:
Destination Switch Address (HIPPI-LE)
Destination ULA (HIPPI_LE)
Destination Switch Address (HIPPI-LE) Destination ULA (HIPPI_LE)
Source Switch Address (HIPPI-LE)
Source ULA (HIPPI-LE)
Source Switch Address (HIPPI-LE) Source ULA (HIPPI-LE)
Pittet Standards Track [Page 22] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 22] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Requester IP Address (HARP)
Requester ULA (HARP)
Requester Switch Address (HARP)
Requester IP Address (HARP) Requester ULA (HARP) Requester Switch Address (HARP)
Target IP Address (HARP)
Target ULA (HARP)
Target Switch Address (HARP)
Target IP Address (HARP) Target ULA (HARP) Target Switch Address (HARP)
Examples:
Examples:
The following relations are true for a HARP_REQUEST and InHARP_REQUESTs.
The following relations are true for a HARP_REQUEST and InHARP_REQUESTs.
LIS without broadcast - Dest SW Addr = HARP server SW Addr
(with HARP server) Dest ULA = HARP server ULA
Source SW Addr = Requester's SW Addr
Source ULA = Requester's ULA
LIS without broadcast - Dest SW Addr = HARP server SW Addr (with HARP server) Dest ULA = HARP server ULA Source SW Addr = Requester's SW Addr Source ULA = Requester's ULA
7 Broadcast and Multicast
7 Broadcast and Multicast
HIPPI-SC does not require switches to support broadcast. Broadcast support has therefore been absent from many HIPPI networks.
HIPPI-SC does not require switches to support broadcast. Broadcast support has therefore been absent from many HIPPI networks.
During its registration phase, every port, including HARP server(s), discover if the underlying medium is capable of broadcast (see section 5.1.2). Should this not be the case, then the HARP server(s) MUST emulate broadcast through an IP broadcast emulation server.
During its registration phase, every port, including HARP server(s), discover if the underlying medium is capable of broadcast (see section 5.1.2). Should this not be the case, then the HARP server(s) MUST emulate broadcast through an IP broadcast emulation server.
A HIPPI IP broadcast server (PIBES) is an extension to the HARP server and only makes sense when the LIS does not inherently support broadcast. The PIBES allows common upper layer networking protocols (RIP, TCP, UDP, etc.) to access IP LIS broadcast.
A HIPPI IP broadcast server (PIBES) is an extension to the HARP server and only makes sense when the LIS does not inherently support broadcast. The PIBES allows common upper layer networking protocols (RIP, TCP, UDP, etc.) to access IP LIS broadcast.
7.1 Protocol for an IP Broadcast Emulation Server - PIBES
7.1 Protocol for an IP Broadcast Emulation Server - PIBES
To emulate broadcast within an LIS, a PIBES SHALL use the currently valid HARP table of the HARP server as a list of addresses called the target list. The broadcast server SHALL validate that all incoming messages have a source address which corresponds to an address in the target list. Only messages addressed to the IP LIS broadcast addresses, multicast address or 255.255.255.255 are considered valid messages for broadcasting. Invalid messages MUST be dropped. All valid incoming messages shall be forwarded to all addresses in the target list.
To emulate broadcast within an LIS, a PIBES SHALL use the currently valid HARP table of the HARP server as a list of addresses called the target list. The broadcast server SHALL validate that all incoming messages have a source address which corresponds to an address in the target list. Only messages addressed to the IP LIS broadcast addresses, multicast address or 255.255.255.255 are considered valid messages for broadcasting. Invalid messages MUST be dropped. All valid incoming messages shall be forwarded to all addresses in the target list.
Pittet Standards Track [Page 23] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 23] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
It is RECOMMENDED that the broadcast server run on the same port as the HARP server since this memo does not define the protocol for exchanging the valid HARP table. The default address to use for the broadcast address is the operational HARP server address.
It is RECOMMENDED that the broadcast server run on the same port as the HARP server since this memo does not define the protocol for exchanging the valid HARP table. The default address to use for the broadcast address is the operational HARP server address.
7.2 IP Broadcast Address
7.2 IP Broadcast Address
This memo only defines IP broadcast. It is independent of the underlying hardware addressing and broadcast capabilities. Any port can differentiate between IP traffic directed to itself and a broadcast message sent to it by looking at the IP address. All IP broadcast messages SHALL use the IP LIS broadcast address or.
This memo only defines IP broadcast. It is independent of the underlying hardware addressing and broadcast capabilities. Any port can differentiate between IP traffic directed to itself and a broadcast message sent to it by looking at the IP address. All IP broadcast messages SHALL use the IP LIS broadcast address or.
It is RECOMMENDED that the PIBES run on the same port as the HARP server. In that case, the PIBES SHALL use the same address as the HARP server.
It is RECOMMENDED that the PIBES run on the same port as the HARP server. In that case, the PIBES SHALL use the same address as the HARP server.
7.3 IP Multicast Address
7.3 IP Multicast Address
HIPPI does not directly support multicast address, therefore there are no mappings available from IP multicast addresses to HIPPI multicast services. Current IP multicast implementations (i.e. MBONE and IP tunneling, see [9]) will continue to operate over HIPPI-based logical IP subnets if all IP multicast packets are sent using the same algorithm as if the packet were being sent to 255.255.255.255.
HIPPI does not directly support multicast address, therefore there are no mappings available from IP multicast addresses to HIPPI multicast services. Current IP multicast implementations (i.e. MBONE and IP tunneling, see [9]) will continue to operate over HIPPI-based logical IP subnets if all IP multicast packets are sent using the same algorithm as if the packet were being sent to 255.255.255.255.
7.4 A Note on Broadcast Emulation Performance
7.4 A Note on Broadcast Emulation Performance
It is obvious that a broadcast emulation service (as defined in
section 7.1) has an inherent performance limit. In an LIS with n
ports, the upper bound on the bandwidth that such a service can
broadcast is:
(total bandwidth)/(n+1)
It is obvious that a broadcast emulation service (as defined in section 7.1) has an inherent performance limit. In an LIS with n ports, the upper bound on the bandwidth that such a service can broadcast is: (total bandwidth)/(n+1)
since each message must first enter the broadcast server, accounting for the additional 1, and then be sent to all n ports. The broadcast server could forward the message destined to the port on which it runs internally, thus reducing (n+1) to (n) in a first optimization.
since each message must first enter the broadcast server, accounting for the additional 1, and then be sent to all n ports. The broadcast server could forward the message destined to the port on which it runs internally, thus reducing (n+1) to (n) in a first optimization.
This service is adequate for the standard networking protocols such as RIP, OSPF, NIS, etc. since they usually use a small fraction of the network bandwidth for broadcast. For these purposes, the broadcast emulation server as defined in this memo allows the HIPPI network to look similar to an Ethernet network to the higher layers.
This service is adequate for the standard networking protocols such as RIP, OSPF, NIS, etc. since they usually use a small fraction of the network bandwidth for broadcast. For these purposes, the broadcast emulation server as defined in this memo allows the HIPPI network to look similar to an Ethernet network to the higher layers.
It is further obvious that such an emulation cannot be used to broadcast high bandwidth traffic. For such a solution, hardware support for true broadcast is required.
It is further obvious that such an emulation cannot be used to broadcast high bandwidth traffic. For such a solution, hardware support for true broadcast is required.
Pittet Standards Track [Page 24] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 24] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
8 HARP for Scheduled Transfer Protocol[17]
8 HARP for Scheduled Transfer Protocol[17]
This RFC also applies for resolving addresses used with Scheduled Transfer (STP) over HIPPI-800 instead of IP. This RFC's message types and algorithms can be used for STP (since STP uses Internet Addresses) as long as there is also an IP over HIPPI implementation on all of the ports.
This RFC also applies for resolving addresses used with Scheduled Transfer (STP) over HIPPI-800 instead of IP. This RFC's message types and algorithms can be used for STP (since STP uses Internet Addresses) as long as there is also an IP over HIPPI implementation on all of the ports.
9 Discovery of One's Own Switch Address
9 Discovery of One's Own Switch Address
This HARP specification assumes that each port has prior knowledge of its own hardware address. This address may be manually configured, by means outside the scope of this memo or a port may discover its own logical address through the algorithm described below.
This HARP specification assumes that each port has prior knowledge of its own hardware address. This address may be manually configured, by means outside the scope of this memo or a port may discover its own logical address through the algorithm described below.
Ports are NOT REQUIRED to implement this switch address discovery protocol but are encouraged to do so since it reduces the administrative overhead. The algorithm presented in this section is based on John Renwick's work as detailed in RFC-1374 [14]. The concept of the discovery process is to scan all possible switch addresses. The messages that are received will be the ones containing one of our switch addresses.
Ports are NOT REQUIRED to implement this switch address discovery protocol but are encouraged to do so since it reduces the administrative overhead. The algorithm presented in this section is based on John Renwick's work as detailed in RFC-1374 [14]. The concept of the discovery process is to scan all possible switch addresses. The messages that are received will be the ones containing one of our switch addresses.
If a port implements this algorithm it SHALL form a HIPPI-LE message as defined in HIPPI-LE: containing an Self_Address_Resolution_Request (see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address (set to the correct ULA for the sender), and the Source_Switch_Address and Destination_Switch_Address.
If a port implements this algorithm it SHALL form a HIPPI-LE message as defined in HIPPI-LE: containing an Self_Address_Resolution_Request (see [3]) PDU Type, a Source_IEEE_Address and Destination_IEEE_Address (set to the correct ULA for the sender), and the Source_Switch_Address and Destination_Switch_Address.
This self address resolution message uses the same HIPPI-LE message format as described in HIPPI-SC and HIPPI-LE: the Self Address Resolution Request PDU and Self Address Resolution Response PDU type codes and no piggybacked ULP data. The HIPPI-LE header contents for the request are:
This self address resolution message uses the same HIPPI-LE message format as described in HIPPI-SC and HIPPI-LE: the Self Address Resolution Request PDU and Self Address Resolution Response PDU type codes and no piggybacked ULP data. The HIPPI-LE header contents for the request are:
HIPPI-LE Message_Type is = 3, Self Addr. Resolution Request
HIPPI-LE Destination_Address_Type = 0 (undefined)
HIPPI-LE Destination_Switch_Address = X (X element scan range)
HIPPI-LE Source_Address_Type = 0 (undefined)
HIPPI-LE Source_Switch_Address = 0 (unknown)
HIPPI-LE Destination_IEEE_Address = 0
HIPPI-LE Source_IEEE_Address = my ULA
HIPPI-LE Message_Type is = 3, Self Addr. Resolution Request HIPPI-LE Destination_Address_Type = 0 (undefined) HIPPI-LE Destination_Switch_Address = X (X element scan range) HIPPI-LE Source_Address_Type = 0 (undefined) HIPPI-LE Source_Switch_Address = 0 (unknown) HIPPI-LE Destination_IEEE_Address = 0 HIPPI-LE Source_IEEE_Address = my ULA
There is no D2 data; the message contains only the HIPPI-FP header and D1_Area with the HIPPI-LE header.
There is no D2 data; the message contains only the HIPPI-FP header and D1_Area with the HIPPI-LE header.
Pittet Standards Track [Page 25] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 25] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Ports SHALL start the scan with a configurable logical address (default 0x000) and increment the value for by one for each subsequent try. The port SHALL continue until it sees its own self address resolution request or it has reached the end, which may be another configurable value (default 0xFFF). It is RECOMMENDED that the range of addresses to scan be configurable since some networks have equipment that does not gracefully handle HIPPI-LE messages.
Ports SHALL start the scan with a configurable logical address (default 0x000) and increment the value for by one for each subsequent try. The port SHALL continue until it sees its own self address resolution request or it has reached the end, which may be another configurable value (default 0xFFF). It is RECOMMENDED that the range of addresses to scan be configurable since some networks have equipment that does not gracefully handle HIPPI-LE messages.
After a port sends the[se] request[s], two positive outcomes are possible:
After a port sends the[se] request[s], two positive outcomes are possible:
o the port receives its own request(s), and obtains one of its own
Switch Address, or
o the port receives its own request(s), and obtains one of its own Switch Address, or
o the port receives an AR_S_Response with the
Destination_Switch_Address filled in.
o the port receives an AR_S_Response with the Destination_Switch_Address filled in.
10 Security Considerations
10 Security Considerations
HARP messages are not authenticated which is a potentially flaw that could allow corrupt information to be introduced into the server system.
HARP messages are not authenticated which is a potentially flaw that could allow corrupt information to be introduced into the server system.
There are other known security issues relating to port impersonation via the address resolution protocols used in the Internet [8]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using HARP.
There are other known security issues relating to port impersonation via the address resolution protocols used in the Internet [8]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using HARP.
Not all of the security issues relating to ARP over HIPPI are clearly understood at this time. However, given the security hole ARP allows, other concerns are probably minor.
Not all of the security issues relating to ARP over HIPPI are clearly understood at this time. However, given the security hole ARP allows, other concerns are probably minor.
11 Open Issues
11 Open Issues
Synchronization and coordination of multiple HARP servers and multiple broadcast servers are left for further study.
Synchronization and coordination of multiple HARP servers and multiple broadcast servers are left for further study.
12 HARP Examples
12 HARP Examples
Assume a HIPPI-SC switch is installed with three connected ports: x, y, and a. Each port has a unique hardware address that consists of Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and ULAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa (SWa, ULAa), this address is the authoritative HIPPI hardware address in the HRAL (HARP Request Address List).
Assume a HIPPI-SC switch is installed with three connected ports: x, y, and a. Each port has a unique hardware address that consists of Switch Address (e.g. SWx, SWy, SWa) and unique ULA (ULAx, ULAy and ULAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa (SWa, ULAa), this address is the authoritative HIPPI hardware address in the HRAL (HARP Request Address List).
Pittet Standards Track [Page 26] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 26] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
The HARP server's table is empty. Ports X and Y each know their own hardware address. Eventually they want to talk to each other; each knows the other's IP address (from the port database) but neither knows the other's ULA or Switch Address. Both ports X and Y have their interfaces configured DOWN.
The HARP server's table is empty. Ports X and Y each know their own hardware address. Eventually they want to talk to each other; each knows the other's IP address (from the port database) but neither knows the other's ULA or Switch Address. Both ports X and Y have their interfaces configured DOWN.
NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. Likewise, ar$rhl = ar$thl = 9 are omitted since these are all HIPPI-800 examples.
NOTE: The LLC, SNAP, Ethertype, HIPPI-LE Message Type, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. Likewise, ar$rhl = ar$thl = 9 are omitted since these are all HIPPI-800 examples.
12.1 Registration Phase of Client Y on Non-broadcast Hardware
12.1 Registration Phase of Client Y on Non-broadcast Hardware
Port Y starts: its HARP table entry state for the server: PENDING
Port Y starts: its HARP table entry state for the server: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa
after starting a table entry for HWa.
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa after starting a table entry for HWa.
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy
HARP ar$tha = SWa ULAa
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Source_Switch_Address = SWy HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWa ULAa ** is what we would like to find out
2. HARP server receives Y's InHARP_REQUEST, it examines the source
addresses and scans its tables for a match. Since this is the
first time Y connects to this server there is no entry and one
will be created and time stamped with the information from the
InHARP_REQUEST. The HARP server will then send a InHARP_REPLY
including its IP address.
2. HARP server receives Y's InHARP_REQUEST, it examines the source addresses and scans its tables for a match. Since this is the first time Y connects to this server there is no entry and one will be created and time stamped with the information from the InHARP_REQUEST. The HARP server will then send a InHARP_REPLY including its IP address.
HIPPI-LE Destination_Switch_Address = SWy
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAy
HIPPI-LE Source_IEEE_Address = ULAa
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs *
HARP ar$tpa = IPy
HARP ar$rha = SWa ULAa
HARP ar$tha = SWy ULAy
* answer we were looking for
HIPPI-LE Destination_Switch_Address = SWy HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = SWa ULAa HARP ar$tha = SWy ULAy * answer we were looking for
Pittet Standards Track [Page 27] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 27] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
3. Port Y examines the incoming InHARP_REPLY, completes its table
entry for the HARP server. The client's HARP table entry for the
server now passes into the VALID state and is usable for regular
HARP traffic. Receiving this reply ensures that the HARP server
has properly registered the client.
3. Port Y examines the incoming InHARP_REPLY, completes its table entry for the HARP server. The client's HARP table entry for the server now passes into the VALID state and is usable for regular HARP traffic. Receiving this reply ensures that the HARP server has properly registered the client.
12.2 Registration Phase of Client Y on Broadcast Capable Hardware
12.2 Registration Phase of Client Y on Broadcast Capable Hardware
If there is a broadcast capable network then the authoritative address in the HRAL would be mapped to the broadcast address, HWb = SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
If there is a broadcast capable network then the authoritative address in the HRAL would be mapped to the broadcast address, HWb = SWb, ULAb (likely 0xFE1 and FF:FF:FF:FF:FF:FF).
Port Y starts: its HARP table entry state for HWa: PENDING
Port Y starts: its HARP table entry state for HWa: PENDING
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa,
in this example the broadcast address, after starting a table
entry.
1. Port Y initiates its interface and sends an InHARP_REQUEST to HWa, in this example the broadcast address, after starting a table entry.
HIPPI-LE Destination_Switch_Address = SWb
HIPPI-LE Source_Switch_Address = SWy
HIPPI-LE Destination_IEEE_Address = ULAb
HIPPI-LE Source_IEEE_Address = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = SWy ULAy
HARP ar$tha = SWb ULAb
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWb HIPPI-LE Source_Switch_Address = SWy HIPPI-LE Destination_IEEE_Address = ULAb HIPPI-LE Source_IEEE_Address = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = SWy ULAy HARP ar$tha = SWb ULAb ** is what we would like to find out
2. Since the network is a broadcast network, client Y will receive a
copy of its InHARP_REQUEST. Client Y examines the source
addresses. Since they are the same as what Y filled in the
InHARP_REQUEST, Y can deduce that it is connected to a broadcast
medium. Port Y completes its table entry for HWa. This entry will
not timeout since it is considered unlikely for a particular
underlying hardware type to change between broadcast and non-
broadcast; therefore this mapping will never change.
2. Since the network is a broadcast network, client Y will receive a copy of its InHARP_REQUEST. Client Y examines the source addresses. Since they are the same as what Y filled in the InHARP_REQUEST, Y can deduce that it is connected to a broadcast medium. Port Y completes its table entry for HWa. This entry will not timeout since it is considered unlikely for a particular underlying hardware type to change between broadcast and non- broadcast; therefore this mapping will never change.
12.3 Operational Phase (phase II)
12.3 Operational Phase (phase II)
The Operational Phase of the HARP protocol as specified in this memo is the same for both broadcast and non-broadcast capable HIPPI hardware. The authoritative address in the HRAL for this example will be HWa: <SWa, ULAa> and IPs for simplicity reasons.
The Operational Phase of the HARP protocol as specified in this memo is the same for both broadcast and non-broadcast capable HIPPI hardware. The authoritative address in the HRAL for this example will be HWa: <SWa, ULAa> and IPs for simplicity reasons.
Pittet Standards Track [Page 28] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 28] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
12.3.1 Standard successful HARP_Resolve example
12.3.1 Standard successful HARP_Resolve example
Assume the same process (steps 1-3 of section 10.1) happened for port X. Then the state of X and Y's tables is: the HARP server table entry is in the VALID state. So lets look at the message traffic when X tries to send a message to Y. Since X doesn't have an entry for Y,
Assume the same process (steps 1-3 of section 10.1) happened for port X. Then the state of X and Y's tables is: the HARP server table entry is in the VALID state. So lets look at the message traffic when X tries to send a message to Y. Since X doesn't have an entry for Y,
1. Port X connects to the authoritative address of the HRAL and sends
a HARP_REQUEST for Y's hardware address:
1. Port X connects to the authoritative address of the HRAL and sends a HARP_REQUEST for Y's hardware address:
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPy HARP ar$rha = SWx ULAx HARP ar$tha = 0 ** ** is what we would like to find out
2. The HARP server receives the HARP request and updates its entry
for X if necessary. It then generates a HARP_REPLY with Y's
hardware address information.
2. The HARP server receives the HARP request and updates its entry for X if necessary. It then generates a HARP_REPLY with Y's hardware address information.
HIPPI-LE Destination_Switch_Address = SWx
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAx
HIPPI-LE Source_IEEE_Address = ULAa
HARP ar$op = 2 (HARP_Reply)
HARP ar$rpa = IPy
HARP ar$tpa = IPx
HARP ar$rha = SWy ULAy *
HARP ar$tha = SWx ULAx
* answer we were looking for
HIPPI-LE Destination_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 2 (HARP_Reply) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = SWy ULAy * HARP ar$tha = SWx ULAx * answer we were looking for
3. Port X connects to port Y and transmits an IP message with the
following information in the HIPPI-LE header:
3. Port X connects to port Y and transmits an IP message with the following information in the HIPPI-LE header:
HIPPI-LE Destination_Switch_Address = SWy
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAy
HIPPI-LE Source_IEEE_Address = ULAx
HIPPI-LE Destination_Switch_Address = SWy HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAy HIPPI-LE Source_IEEE_Address = ULAx
If there had been a broadcast capable HIPPI network, the target ports would themselves have received the HARP_REQUEST of step 2 above and responded to them in the same way the HARP server did.
If there had been a broadcast capable HIPPI network, the target ports would themselves have received the HARP_REQUEST of step 2 above and responded to them in the same way the HARP server did.
Pittet Standards Track [Page 29] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 29] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
12.3.2 Standard non-successful HARP_Resolve example
12.3.2 Standard non-successful HARP_Resolve example
Like in 12.3.1, assume that X and Y are fully registered with the HARP server. Then the state of X and Y's HARP server table entry is: VALID. So lets look at the message traffic when X tries to send a message to Q. Further assume that interface Q is NOT configured UP, i.e. it is DOWN. Since X doesn't have an entry for Q,
Like in 12.3.1, assume that X and Y are fully registered with the HARP server. Then the state of X and Y's HARP server table entry is: VALID. So lets look at the message traffic when X tries to send a message to Q. Further assume that interface Q is NOT configured UP, i.e. it is DOWN. Since X doesn't have an entry for Q,
1. Port X connects to the HARP server switch address and sends a
HARP_REQUEST for Q's hardware address:
1. Port X connects to the HARP server switch address and sends a HARP_REQUEST for Q's hardware address:
HIPPI-LE Destination_Switch_Address = SWa
HIPPI-LE Source_Switch_Address = SWx
HIPPI-LE Destination_IEEE_Address = ULAa
HIPPI-LE Source_IEEE_Address = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 **
** is what we would like to find out
HIPPI-LE Destination_Switch_Address = SWa HIPPI-LE Source_Switch_Address = SWx HIPPI-LE Destination_IEEE_Address = ULAa HIPPI-LE Source_IEEE_Address = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = SWx ULAx HARP ar$tha = 0 ** ** is what we would like to find out
2. The HARP server receives the HARP request and updates its entry
for X if necessary. It then looks up IPq in its tables and doesn't
find it. The HARP server then generates a HARP_NAK reply message.
2. The HARP server receives the HARP request and updates its entry for X if necessary. It then looks up IPq in its tables and doesn't find it. The HARP server then generates a HARP_NAK reply message.
HIPPI-LE Destination_Switch_Address = SWx
HIPPI-LE Source_Switch_Address = SWa
HIPPI-LE Destination_IEEE_Address = ULAx
HIPPI-LE Source_IEEE_Address = ULAa
HARP ar$op = 10 (HARP_NAK)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = SWx ULAx
HARP ar$tha = 0 ***
*** No Answer, and notice that the fields do not get swapped,
i.e. the HARP message is the same as the HARP_REQUEST
except for the operation code.
HIPPI-LE Destination_Switch_Address = SWx HIPPI-LE Source_Switch_Address = SWa HIPPI-LE Destination_IEEE_Address = ULAx HIPPI-LE Source_IEEE_Address = ULAa HARP ar$op = 10 (HARP_NAK) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = SWx ULAx HARP ar$tha = 0 *** *** No Answer, and notice that the fields do not get swapped, i.e. the HARP message is the same as the HARP_REQUEST except for the operation code.
If there had been a broadcast capable HIPPI network, then there would not have been a reply.
If there had been a broadcast capable HIPPI network, then there would not have been a reply.
Pittet Standards Track [Page 30] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 30] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
13 References
13 References
[1] ANSI X3.183-1991(R1996), Information Technology - High-
Performance Parallel Interface - Mechanical, Electrical and
Signaling Protocol Specification; (HIPPI-PH).
[1] ANSI X3.183-1991(R1996), Information Technology - High- Performance Parallel Interface - Mechanical, Electrical and Signaling Protocol Specification; (HIPPI-PH).
[2] ANSI X3.210-1998, Information Technology - High-Performance
Parallel Interface - Framing Protocol; (HIPPI-FP).
[2] ANSI X3.210-1998, Information Technology - High-Performance Parallel Interface - Framing Protocol; (HIPPI-FP).
[3] ANSI X3.218-1993, Information Technology - High-Performance
Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std
802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
[3] ANSI X3.218-1993, Information Technology - High-Performance Parallel Interface - Encapsulation of ISO 8802-2 (IEEE Std 802.2) Logical Link Control Protocol Data Units; (HIPPI-LE).
[4] ANSI X3.222-1997, Information Technology - High-Performance
Parallel Interface - Physical Switch Control; (HIPPI-SC).
[4] ANSI X3.222-1997, Information Technology - High-Performance Parallel Interface - Physical Switch Control; (HIPPI-SC).
[5] ANSI X3.300-1997, Information Technology - High-Performance
Parallel Interface - Serial Specification; (HIPPI-Serial).
[5] ANSI X3.300-1997, Information Technology - High-Performance Parallel Interface - Serial Specification; (HIPPI-Serial).
[6] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[6] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[7] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
RFC 2390, September 1998.
[7] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
pp. 32-48, 1989.
[8] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[9] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[9] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[10] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "A Reverse
Address Resolution Protocol", RFC 903, June 1984.
[10] Finlayson, R., Mann, T., Mogul, J. and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, June 1984.
[11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems -
Local Area Networks - Logical Link Control, "IEEE Standards for
Local Area Networks: Logical Link Control", IEEE, New York, New
York, 1985.
[11] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.
[12] Laubach, Mark., "Classical IP and ARP over ATM", RFC 2225, April
1998.
[12] Laubach, Mark., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[13] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC 826, November 1982.
[13] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, November 1982.
Pittet Standards Track [Page 31] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 31] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
[14] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374,
October 1992.
[14] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[15] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[15] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[16] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol
ANSI NCITS, Scheduled Transfer Protocol draft standard.
[17] ANSI NCITS xxx.199x, Project 1245-D, Scheduled Transfer Protocol ANSI NCITS, Scheduled Transfer Protocol draft standard.
[18] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[18] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
14 Acknowledgments
14 Acknowledgments
This memo could not have come into being without the critical review from Greg Chesson, Carlin Otto, the high performance interconnect group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand and Jeff Young) and the expertise of the ANSI T11.1 Task Group responsible for the HIPPI standards work.
This memo could not have come into being without the critical review from Greg Chesson, Carlin Otto, the high performance interconnect group of Silicon Graphics (specifically Jim Pinkerton, Brad Strand and Jeff Young) and the expertise of the ANSI T11.1 Task Group responsible for the HIPPI standards work.
This memo is based on the second part of [14], written by John Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written by T. Bradley and C. Brown provide the fundamental algorithms of HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [12], written by Mark Laubach who laid the structural groundwork for the HARP server.
This memo is based on the second part of [14], written by John Renwick. ARP [13] written by Dave Plummer and Inverse ARP [7] written by T. Bradley and C. Brown provide the fundamental algorithms of HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [12], written by Mark Laubach who laid the structural groundwork for the HARP server.
15 Changes from RFC-1374 [14]
15 Changes from RFC-1374 [14]
RFC-2067 obsoletes RFC-1374 but left ARP outside of its scope because there was not enough implementation experience. This memo is an effort to clarify and expand the definition of ARP over HIPPI as found in RFC-1374 such that implementations will be more readily possible, especially considering forward interoperability with HIPPI-6400.
RFC-2067 obsoletes RFC-1374 but left ARP outside of its scope because there was not enough implementation experience. This memo is an effort to clarify and expand the definition of ARP over HIPPI as found in RFC-1374 such that implementations will be more readily possible, especially considering forward interoperability with HIPPI-6400.
The changes from RFC-1374 [14] are:
The changes from RFC-1374 [14] are:
o A new message format to acknowledge the HIPPI hardware address
format and to eliminate the requirement of HIPPI-LE ARP for HARP
to function.
o A new message format to acknowledge the HIPPI hardware address format and to eliminate the requirement of HIPPI-LE ARP for HARP to function.
o Explicit registration phase.
o Explicit registration phase.
Pittet Standards Track [Page 32] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet Standards Track [Page 32] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
o Additional message formats: InHARP requests and replies as well as
HARP_NAKs.
o Additional message formats: InHARP requests and replies as well as HARP_NAKs.
o Details about the IP subnetwork configuration.
o Details about the IP subnetwork configuration.
o Details about table aging.
o Details about table aging.
o IP broadcast emulation.
o IP broadcast emulation.
16 Author's Address
16 Author's Address
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94043
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94043
Phone: 650-933-6149 Fax: 650-933-3542 EMail: jmp@sgi.com, jmp@acm.org
以下に電話をしてください。 650-933-6149 Fax: 650-933-3542 メールしてください: jmp@sgi.com 、jmp@acm.org
Pittet Standards Track [Page 33] RFC 2834 ARP and IP Broadcast over HIPPI-800 May 2000
Pittet標準化過程[33ページ]RFC2834ARPと2000年5月にHIPPI-800の上で放送されたIP
17 Full Copyright Statement
17 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Pittet Standards Track [Page 34]
Pittet標準化過程[34ページ]
一覧
スポンサーリンク
