RFC2835 日本語訳
2835 IP and ARP over HIPPI-6400 (GSN). J.-M. Pittet. May 2000. (Format: TXT=74178 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J.-M. Pittet Request for Comments: 2835 Silicon Graphics Inc. Category: Standards Track May 2000
ワーキンググループJ.-Mをネットワークでつないでください。 Pittetはコメントのために以下を要求します。 2835年のシリコングラフィックス株式会社カテゴリ: 標準化過程2000年5月
IP and ARP over HIPPI-6400 (GSN)
HIPPI-6400の上のIPとARP(GSN)
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
要約
The ANSI T11.1 task force has standardized HIPPI-6400 also known as Gigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified in HIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3].
Gigabyte System Network(GSN)(物理的なレベルの、そして、二地点間の全二重)が利用者データの信頼できて、流れで制御された伝達のために6400メガビット/sでインタフェースをリンクするとき、ANSI T11.1特別委員会はまた、知られているHIPPI-6400を標準化しました、指示単位で。 最大40mの距離への平行な銅のケーブルインタフェースは6400年のHIPPIペーハー[1]で指定されます。 より長い距離の光学インタフェースへのコネクションズはHIPPI-6400-OPT[3]で標準化されます。
HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs [10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2]. T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI- 6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks.
6400年のHIPPIペーハー[1]はGSNでIEEE802.2LLC PDUs[10]のカプセル化、および含意によるIPを定義します。 別のT11.1規格はHIPPI-6400の物理的なスイッチHIPPI6400サウスカロライナ[2]の操作について説明します。 T11.1は、HIPPI-6400がそれらの規格の範囲の主に外で問題をネットワークでつないでいるままにするのを選びました。 このドキュメントはIPローカル・エリア・ネットワークとしてHIPPI6400スイッチの使用を指定します。 このドキュメントはさらにHIPPI-6400ハードウェア・アドレス(HARP)にIPアドレスを決議して、HARPの直接的拡張として論理的なIPサブネット(LIS)で放送されたIPを見習うための方法を指定します。 その上、それは両方の放送と非放送のできるネットワークをHIPPI-800とHIPPI-6400設備のための相互運用性に許容するIPとHARPを定義するこのメモの目標です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Global concepts used . . . . . . . . . . . . . . . . 3
2.2 Glossary . . . . . . . . . . . . . . . . . . . . . . 4
1. 序論. . . . . . . . . . . . . . . . . . . . . . 3 2。 定義. . . . . . . . . . . . . . . . . . . . . . . 3 2.1Global概念中古の. . . . . . . . . . . . . . . . 3 2.2Glossary. . . . . . . . . . . . . . . . . . . . . . 4
Pittet Standards Track [Page 1] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[1ページ]。
3. IP Subnetwork Configuration . . . . . . . . . . . . . . . 5
3.1 Background . . . . . . . . . . . . . . . . . . . . . 5
3.2 HIPPI LIS Requirements . . . . . . . . . . . . . . . 6
4. Internet Protocol . . . . . . . . . . . . . . . . . . . . 7
4.1 Packet Format . . . . . . . . . . . . . . . . . . . 7
4.1.1 IEEE 802.2 LLC . . . . . . . . . . . . . . . . 7
4.1.2 SNAP . . . . . . . . . . . . . . . . . . . . . 7
4.1.3 Packet diagrams . . . . . . . . . . . . . . . 8
4.2 HIPPI-6400 Hardware address: Universal LAN MAC addr. 9
4.3 Maximum Transmission Unit - MTU . . . . . . . . . . 10
5. HIPPI Address Resolution Protocol - HARP . . . . . . . . 11
5.1 HARP Algorithm . . . . . . . . . . . . . . . . . . . 12
5.1.1 Selecting the authoritative HARP service . . . 12
5.1.2 HARP registration phase . . . . . . . . . . . 13
5.1.3 HARP operational phase . . . . . . . . . . . . 14
5.2 HARP Client Operational Requirements . . . . . . . . 15
5.3 Receiving Unknown HARP Messages . . . . . . . . . . 16
5.4 HARP Server Operational Requirements . . . . . . . . 16
5.5 HARP and Permanent ARP Table Entries . . . . . . . . 18
5.6 HARP Table Aging . . . . . . . . . . . . . . . . . . 18
6. HARP Message Encoding . . . . . . . . . . . . . . . . . . 19
6.1 Generic IEEE 802 ARP Message Format . . . . . . . . . 19
6.2 HIPARP Message Formats . . . . . . . . . . . . . . . 21
6.2.1 Example Message encodings: . . . . . . . . . . 23
6.2.2 HARP_NAK message format . . . . . . . . . . . . 24
7. Broadcast and Multicast . . . . . . . . . . . . . . . . 24
7.1 Protocol for an IP Broadcast Emulation Server - PIBES 25
7.2 IP Broadcast Address . . . . . . . . . . . . . . . . 25
7.3 IP Multicast Address . . . . . . . . . . . . . . . . 25
7.4 A Note on Broadcast Emulation Performance . . . . . . 26
8. HARP for Scheduled Transfer . . . . . . . . . . . . . . . 26
9. Security Consierations . . . . . . . . . . . . . . . . . 26
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 27
11. HARP Examples . . . . . . . . . . . . . . . . . . . . . 27
11.1 Registr. Phase of Client Y on Non-broadcast Hardware 27
11.2 Registr. Phase of Client Y on Broadcast-capable . . 28
11.3 Operational Phase (phase II) . . . . . . . . . . . 29
11.3.1 Successful HARP_Resolve example . . . . . . 29
11.3.2 Non-successful HARP_Resolve example . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . 32
14. Author's Address . . . . . . . . . . . . . . . . . . . . 32
15. Full Copyright Statement . . . . . . . . . . . . . . . . 33
3. IPサブネットワーク構成. . . . . . . . . . . . . . . 5 3.1バックグラウンド. . . . . . . . . . . . . . . . . . . . . 5 3.2HIPPI LIS要件. . . . . . . . . . . . . . . 6 4。 インターネットプロトコル. . . . . . . . . . . . . . . . . . . . 7 4.1Packet Format. . . . . . . . . . . . . . . . . . . 7 4.1.1IEEE802.2LLC. . . . . . . . . . . . . . . . 7 4.1.2SNAP. . . . . . . . . . . . . . . . . . . . . 7 4.1.3Packetは.84.2HIPPI-6400 Hardwareアドレスを図解します: 普遍的なLAN MAC addr。 9 4.3マキシマム・トランスミッション・ユニット--MTU. . . . . . . . . . 10 5。 HIPPI Address Resolutionプロトコル--HARP. . . . . . . . 11 5.1HARP Algorithm. . . . . . . . . . . . . . . . . . . 12 5.1.1Selectingの正式のHARPは.125.1.2HARP登録フェーズ. . . . . . . . . . . 13 5.1.3のHARPの操作上のフェーズ. . . . . . . . . . . . 14 5を修理します; 2 未知のハープメッセージ. . . . . . . . . . 16 5.4ハープサーバの操作上の要件. . . . . . . . 16 5.5ハープと永久的なARPテーブル項目. . . . . . . . 18 5.6を受けるハープのクライアントの操作上の要件. . . . . . . . 15 5.3がテーブルの年をと. . . . . . . . . . . . . . . . . . 18 6ることのハープを弾きます。 HARP Message Encoding. . . . . . . . . . . . . . . . . . 19 6.1Generic IEEE802ARP Message Format. . . . . . . . . 19 6.2HIPARP Message Formats. . . . . . . . . . . . . . . 21 6.2.1Example Message encodings: . . . . . . . . . . 23 6.2 .2 HARP_NAKメッセージ・フォーマット. . . . . . . . . . . . 24 7。 PIBES25 7.2に、IPはアドレス. . . . . . . . . . . . . . . . 25 7.3IPマルチキャストアドレス. . . . . . . . . . . . . . . . 25 7.4を放送しました。IP放送エミュレーションサーバのための放送とマルチキャスト. . . . . . . . . . . . . . . . 24 7.1プロトコル--放送エミュレーションパフォーマンス. . . . . . 26 8に関する注。 予定されている転送. . . . . . . . . . . . . . . 26 9のために、ハープを弾いてください。 セキュリティConsierations. . . . . . . . . . . . . . . . . 26 10。 問題. . . . . . . . . . . . . . . . . . . . . . . 27 11を開いてください。 例. . . . . . . . . . . . . . . . . . . . . 27 11.1のRegistrのハープを弾いてください。 非放送ハードウェア27 11.2Registrの上のクライアントYのフェーズ。 Broadcastできる.28 11.3Operational Phase(フェーズII)の.29 11.3の.2のNonうまくいっているHARP_Resolve.29 11.3.1Successful HARP_Resolve例の例. . . . 30 12のClient Yのフェーズ。 参照. . . . . . . . . . . . . . . . . . . . . . . 31 13。 承認. . . . . . . . . . . . . . . . . . . . 32 14。 作者のアドレス. . . . . . . . . . . . . . . . . . . . 32 15。 完全な著作権宣言文. . . . . . . . . . . . . . . . 33
Pittet Standards Track [Page 2] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[2ページ]。
1. Introduction
1. 序論
HIPPI-6400 is a duplex data channel that can transmit and receive data simultaneously at nearly 6400 megabits per second. HIPPI-6400 data transfers are segmented into micropackets, each composed of 32 data bytes and 8 control bytes. HIPPI-6400 uses four multiplexed virtual channels. These virtual channels are allocated to control traffic, low latency traffic, and bulk traffic (see [1] for more details).
HIPPI-6400は同時に1秒あたりおよそ6400のメガビットでデータを送受信できる複式のデータ・チャンネルです。 HIPPI-6400データ転送はmicropackets、32データ・バイトで構成されたそれぞれ、および8コントロールバイトに区分されます。 HIPPI-6400用途fourは事実上のチャンネルを多重送信しました。 交通、低遅延交通、および大量の交通を制御するためにこれらの事実上のチャンネルを割り当てます(その他の詳細のための[1]を見てください)。
Using small packets and four virtual channels, large file transfers cannot lock out a host or switch port for interactive traffic. HIPPI-6400 guarantees in order delivery of data. It also supports link-level and end-to-end checksumming and credit-based flow control.
小型小包と4個の事実上のチャンネルを使用して、大きいファイル転送はホストかスイッチポートを対話的な通信に締め出すことができません。 データの注文配送におけるHIPPI-6400保証。 また、それはリンク・レベルと終わりから終わりへのchecksummingとクレジットベースのフロー制御を支持します。
HIPPI-6400-PH defines a 20-bit interface for copper cables operating at 500 MBaud. This provides a user payload bandwidth of 6400 Mb/s (800,000,000 Bytes/sec) in each direction. [8]
HIPPI6400ペーハーは500MBaudで作動する銅のケーブルのために20ビットのインタフェースを定義します。 これは6400Mb/s(8億Bytes/秒)の各方向へのユーザペイロード帯域幅を供給します。 [8]
HIPPI-6400-SC [2] defines two types of switches: bridging and non- bridging. The bridging switches are required to support hardware broadcast. Non-bridging switches are not required to support broadcast. This memo allows for a coherent implementation of IP and HARP with both types of switches.
HIPPI6400サウスカロライナ[2]は2つのタイプのスイッチを定義します: 橋を架けるのと非の橋を架けること。 橋を架けるスイッチが、ハードウェア放送を支持するのに必要です。 支持するスイッチは必要でない非の橋を架けることが放送されました。 このメモは両方のタイプのスイッチでIPとHARPの一貫性を持っている実現を考慮します。
Gigabyte System Network(TM) (GSN) is a marketing name for HIPPI-6400. It is a trademark of the High Performance Networking Forum (HNF; http://www.hnf.org) for use by its member companies that supply products complying to ANSI HIPPI-6400 standards.
ギガバイトSystem Network(TM)(GSN)はHIPPI-6400のためのマーケティング名です。 それはANSI HIPPI-6400規格に応じる製品を供給するメンバー会社による使用のためにHighパフォーマンスNetworking Forum(HNF; http://www.hnf.org )の商標です。
2 Definitions
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 [19].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[19]で説明されるように本書では解釈されることであるべきですか?
2.1 Global concepts used
2.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. This document will use HIPPI-800 and HIPPI-6400 when referring to concepts that apply to one or the other technology. The term HIPPI will be used when referring to both technologies.
以下の議論、アドレス解決要求を開始する「リクエスタ」と「目標」がポートを特定するのに使用される用語、およびそれがそれぞれアドレスを発見したがっているポートで。 1つに適用される概念かもう片方の技術を示すとき、このドキュメントはHIPPI-800とHIPPI-6400を使用するでしょう。 両方の技術を示すと、HIPPIという用語は使用されるでしょう。
Values are decimal unless otherwise noted. Formatting follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and byte ordering.
別の方法で注意されない場合、値は10進です。 形式はIEEE 802.1A正準な噛み付いている注文と6400年のHIPPIペーハービットとバイト順に続きます。
Pittet Standards Track [Page 3] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[3ページ]。
2.2 Glossary
2.2 用語集
Broadcast
放送
A distribution mode which transmits a message to all ports. The sending port is part of "all" and will therefore also receive a copy of the sent message.
すべてのポートに送信する分配モード。 送付ポートは「すべて」の一部です、そして、したがって、また、送信されたメッセージのコピーを受けるでしょう。
Classical/Conventional
古典的であるか、または従来です。
Both terms are used with respect to networks, including 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 (HIPPI Address Resolution Protocol describes the whole set of HIPPI-6400 address resolution encodings and algorithms defined in this memo. HARP is a combination and adaptation of the Internet Address Resolution Protocol (ARP) RFC-826 [14] and Inverse ARP (InARP) [5] (see section 5). HARP also describes the HIPPI (800 and 6400) specific version of ARP (i.e. the protocol and the HIPPI specific encoding).
HIPPI Address ResolutionプロトコルはHIPPI-6400アドレス解決encodingsとこのメモで定義されたアルゴリズムの全体集合について説明します。HARPはインターネットAddress Resolutionプロトコル(ARP)RFC-826[14]とInverse ARP(InARP)[5]の組み合わせと適合(セクション5を見る)です。HARP、(また、HARPはARP(すなわち、プロトコルとHIPPIの特定のコード化)のHIPPI(800と6400)の特定のバージョンについて説明します。
HARP table
HARPテーブル
Each host has a HARP table which contains the IP to hardware address mapping of IP members.
各ホストはIPメンバーのハードウェアアドレス・マッピングにIPを含むHARPテーブルを持っています。
HRAL
HRAL
The HARP Request Address List. A list of ULAs to which HARP messages are sent when resolving names to addresses (see section 3.2).
ハープ要求住所録。 アドレス(セクション3.2を見る)に名前を決議するときHARPメッセージが送られるULAsのリスト。
Hardware (HW) address
ハードウェア(HW)アドレス
The hardware address of a port; it consists of an ULA (see section 4.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.
ポートのハードウェア・アドレス。 それはULAから成ります(セクション4.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 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[4ページ]。
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. A port may be an Internet host, bridge, router, or gateway.
平行であるか連続のHIPPIによってHIPPI-サウスカロライナスイッチとそれに接続される二元的な1HIPPI Source/目的地シンプレクス組から成る実体は、IPデータグラムを送信して、受けます。ポートは、インターネット・ホスト、橋、ルータ、またはゲートウェイであるかもしれません。
PIBES
PIBES
The Protocol for Internet Broadcast Emulation Server (see section 7).
インターネットBroadcast Emulation Server(セクション7を見る)のためのプロトコル。
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ビット。
3. IP Subnetwork Configuration
3. IPサブネットワーク構成
3.1 Background
3.1 バックグラウンド
ARP (address resolution protocol) as defined in [14] 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-6400 network.
[14]で定義されるARP(アドレス解決プロトコル)は'地方'のケーブルに働くことになっていました。 この定義は地方の論理的なIPサブネット(LIS)範囲をARPプロトコルに与えます。 LISシナリオでは、それぞれの別々の管理実体はLISの中でそのホストとルータを構成します。 各LISは同じHIPPI-6400ネットワークの他の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-6400 port attached to the HIPPI-6400 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-6400 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-6400 connection between the two IP members over the HIPPI-6400 network. This is an consequence of using IP and choosing to have multiple LIS's on the same HIPPI-6400 fabric.
HARPはLIS範囲しか持たないで、LISのすべてのポートに役立ちます。 通常、IPルータで地方のLISの外に位置したポートへのコミュニケーションを提供します。 このルータは1LISのメンバーとして構成されるHIPPI-6400ネットワークに取り付けられたHIPPI-6400ポートです。 5月が数に結果になるこの構成は同じHIPPI-6400ネットワークの上のLISの作動をばらばらにならせます。 このモデルを使用して、HIPPI-6400ネットワークの上で2人のIPメンバーの間のダイレクトHIPPI-6400接続を開くのが可能であるかもしれませんが、異なったIPサブネットSHOULDのポートは中間的IPルータで交信します。 これはIPを使用して、同じHIPPI-6400織物の上にLISの複数のものを持っているのを選ぶ結果です。
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ルーティングモデルは手があいていなければなりません。
Pittet Standards Track [Page 5] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[5ページ]。
3.2 HIPPI LIS Requirements
3.2 HIPPI LIS要件
The requirement for IP members (hosts, routers) operating in a HIPPI-6400 LIS configuration is:
HIPPI-6400 LIS構成で働いているIPメンバー(ホスト、ルータ)のための要件は以下の通りです。
o All members of the LIS SHALL have the same IP network/subnet
address and address mask [4].
o LIS SHALLのすべてのメンバーが同じIPネットワーク/サブネットアドレスとアドレスマスク[4]を持っています。
The following list identifies the set of HIPPI-6400-specific parameters that MUST be implemented in each IP station connected to the HIPPI-6400 network:
以下のリストはHIPPI-6400ネットワークにつなげられたそれぞれのIPステーションで実行しなければならない6400年のHIPPI詳細パラメタのセットを特定します:
o HIPPI-6400 Hardware Address:
o HIPPI-6400ハードウェア・アドレス:
The HIPPI-6400 hardware address (a ULA) of an individual IP
endpoint (i.e. a network adapter within a host) MUST be unique in
the LIS.
個々のIP終点(すなわち、ホストの中のネットワークアダプター)のHIPPI-6400ハードウェア・アドレス(ULA)はLISでユニークであるに違いありません。
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. By default the first address MUST be the reserved address for broadcast, i.e. FF:FF:FF:FF:FF:FF.
HRAL MUSTはLISの中に位置したすべてのIPメンバーのHARP要求を決議することへの正式の責任を持っている個々のHARPサービスを特定する少なくとも2つのHIPPI HWアドレスを含んでいます。 デフォルトで、最初のアドレスは放送のための予約されたアドレス、すなわち、FF:FF:FFであるに違いありません: FF:FF:FF。
The second address MUST be the standard HW address for the HARP server 00:10:3B:FF:FF:E0.
2番目のアドレスはHARPサーバ00:10:3Bのための標準のHWアドレスでなければなりません: FF:FF:E0。
Therefore, the HRAL entries are sorted in the following order:
1st : broadcast address (FF:FF:FF:FF:FF:FF) REQUIRED
2nd : official HARP server address (00:10:3B:FF:FF:E0) REQUIRED
3rd & on: any additional HARP server addresses will be OPTIONAL
sorted in decreasing order.
したがって、HRALエントリーは以下のオーダーで分類されます: 1番目: アドレス(FF:FF:FF:FF:FF: FF)REQUIRED2番目を放送してください: 3番目と以下の上の公式のHARPサーバアドレス(0 00:10:3B:FF:FF:E)REQUIRED どんな追加HARPサーバアドレスも多いほうから少ないほうへ順に並べると分類されたOPTIONALになるでしょう。
Manual configuration of the addresses and address lists presented in this section is implementation dependent and beyond the scope of this memo. However, prior to use by any service or operation detailed in this memo, clients MUST have HRAL address(es) configured as appropriate for their LIS.
実現に依存していて、このメモの範囲を超えてこのセクションに提示されたアドレスと住所録の手動の構成。 しかしながら、このメモで詳細などんなサービスや操作による使用の前にも、クライアントは彼らのLISのために、HRALアドレス(es)を適宜、構成させなければなりません。
Pittet Standards Track [Page 6] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[6ページ]。
4. Internet Protocol
4. インターネットプロトコル
4.1 Packet format
4.1 パケット・フォーマット
The HIPPI-6400 packet format for Internet datagrams [15] shall conform to the HIPPI-6400-PH standard [1]. The length of a HIPPI- 6400-PH packet, including headers and trailing fill, shall be a multiple of 32 bytes as required by HIPPI-6400-PH.
インターネットデータグラム[15]のためのHIPPI-6400パケット・フォーマットは6400年のHIPPIペーハー規格[1]に従うものとします。 ヘッダーと引きずっている中詰めを含むHIPPIの6400ペーハーのパケットの長さは必要に応じて6400年のHIPPIペーハーで32バイトの倍数になるでしょう。
All IP Datagrams shall be carried on HIPPI-6400-PH Virtual Channel 1 (VC1). Since HIPPI-6400-PH has a 32-byte granularity, IP Datagrams MUST be padded to a 32-byte granularity prior to sending. Added padding is transparent to IP and is not reflected in the length field of the IP header.
すべてのIPデータグラムが6400年のHIPPIペーハーVirtual Channel1(VC1)で運ばれるものとします。 HIPPI6400ペーハーには32バイトの粒状があるので、発信の前に32バイトの粒状にIPデータグラムを水増ししなければなりません。 加えられた詰め物は、IPに透明であり、IPヘッダーの長さの分野に反映されません。
D_ULA Destination ULA SHALL be the ULA of the destination port.
D_ULA Destination ULA SHALL、仕向港のULAになってください。
S_ULA Source ULA SHALL be the ULA of the requesting port.
S_ULA Source ULA SHALL、要求ポートのULAになってください。
M_len Set to the IEEE 802 packet (e.g. IP or HARP message)
length + 8 Bytes to account for the LLC/SNAP header length.
The HIPPI-6400-PH [1] length parameter shall not include
the pad.
LLC/SNAPヘッダ長を説明するパケット(例えば、IPかHARPメッセージ)長さ+8IEEE802BytesへのM_len Set。 6400年のHIPPIペーハー[1]長さのパラメタはパッドを含んでいないものとします。
4.1.1 IEEE 802.2 LLC
4.1.1 IEEE802.2LLC
The IEEE 802.2 LLC Header SHALL begin in the first byte after M_len.
IEEE802.2LLC Header SHALLはM_lenの後に最初のバイトで始まります。
The LLC values (in hexadecimal and decimal) SHALL be
LLCはSHALLを評価します(16進と小数で)。
SSAP 0xAA 170 (8 bits) DSAP 0xAA 170 (8 bits) CTL 0x03 3 (8 bits)
SSAP 0xAA170(8ビット)DSAP 0xAA170(8ビット)CTL0x03 3(8ビット)
for a total length of 3 bytes. The 0x03 CTL value indicates the presence of a SNAP header.
3バイトの全長のために。 0×03CTL価値はSNAPヘッダーの存在を示します。
4.1.2 SNAP
4.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 [18]:
EthertypeはAssignedで定義されるセットが民数記[18]であったならSHALLを評価します:
IP 0x0800 2048 (16 bits) HARP = ARP = 0x0806 2054 (16 bits)
IP0x0800 2048(16ビット)HARP=ARP=0x0806 2054(16ビット)
The total size of the LLC/SNAP header is fixed at 8 bytes.
LLC/SNAPヘッダーの総サイズは8バイトで固定されています。
Pittet Standards Track [Page 7] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[7ページ]。
4.1.3 HIPPI-6400 802 Packet diagrams
4.1.3 HIPPI-6400 802Packetダイヤグラム
The following diagram shows a HIPPI-6400 message carrying IEEE 802 data.
以下のダイヤグラムは、HIPPI-6400メッセージがIEEE802データを運ぶのを示します。
|31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------
0 | |
| D_ULA +-------------------------+ HIPPI-6400
1 | | |
+-------------------------+ S_ULA | MAC
2 | |
+---------------------------------------------------+ header
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | DSAP | SSAP | Ctl | Org | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP
5 | Org | Org | Ethertype | header
+============+============+============+============+ =============
6 | Msg byte 0 | Msg byte 1 | Msg byte 2 | . . . | IEEE 802
+---------------------------------------------------+ Data
Generic 802.1 data packet diagram
|31 |23 |15 |7 0| +------------+------------+------------+------------+ ------------- 0 | | | D_ULA+-------------------------+ HIPPI-6400 1| | | +-------------------------+ S_ULA| Mac2| | +---------------------------------------------------+ ヘッダー3| M_len| +------------+------------+------------+------------+ ------------- 4 | DSAP| SSAP| Ctl| Org| IEEE802+------------+------------+------------+------------+ LLC/スナップ5| Org| Org| Ethertype| ヘッダー+============+============+============+============+ ============= 6 | エムエスジーバイト0| エムエスジーバイト1| エムエスジーバイト2| . . . | IEEE802+---------------------------------------------------+ Generic802.1データパケットが図解するデータ
The following diagram shows an IP datagram of length n with the FILL bytes ( value: 0x0 ). "<><>" indicates the micropacket separation. A HIPPI-6400-PH [1] micropacket is 32 bytes long.
以下のダイヤグラムはFILLバイト(値: 0×0)がある長さnのIPデータグラムを示しています。 「<><>」はmicropacket分離を示します。 6400年のHIPPIペーハー[1]micropacketは32バイト長です。
All IP (v4) [15] packets will always span two or more micropackets. The first micropacket has a TYPE = header. The second and any further micropackets have a TYPE = Data (see [1]).
すべてのIP(v4)[15]パケットがいつも2以上micropacketsにかかるでしょう。 最初のmicropacketには、TYPE=ヘッダーがあります。 2番目とどんな一層のmicropacketsもTYPEにデータと等しくさせます。([1])を見てください。
Pittet Standards Track [Page 8] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[8ページ]。
|31 |23 |15 |7 0|
+------------+------------+------------+------------+ -------------
0 | |
| D_ULA +-------------------------+ HIPPI-6400
1 | | |
+-------------------------+ S_ULA | MAC
2 | |
+---------------------------------------------------+ header
3 | M_len |
+------------+------------+------------+------------+ -------------
4 | AA | AA | 03 | 00 | IEEE 802
+------------+------------+------------+------------+ LLC/SNAP
5 | 00 | 00 | Ethertype = 0x0800=2048 | header
+============+============+============+============+ =============
6 | VER | HLEN | TOS | Total Length |
+-----+------+------------+-----+-------------------+
7 | ID | FLG | Frag Offset |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+ IPv4 Header
8 | TTL | PROTO | Header Checksum |
+------------+------------+-------------------------+
9 | Source IP Address |
+---------------------------------------------------+
10 | Destination IP Address |
+---------------------------------------------------+
11 | . . . |
+---------------------------------------------------+
| . . . | byte (n-2) | byte (n-1) | FILL |
+------------+------------+------------+------------+
| FILL | FILL | FILL | FILL |
+------------+------------+------------+------------+
M-1| FILL | FILL | FILL | FILL |
+<><><><><><>+<><><><><><>+<><><><><><>+<><><><><><>+
IP v4 data packet diagram
|31 |23 |15 |7 0| +------------+------------+------------+------------+ ------------- 0 | | | D_ULA+-------------------------+ HIPPI-6400 1| | | +-------------------------+ S_ULA| Mac2| | +---------------------------------------------------+ ヘッダー3| M_len| +------------+------------+------------+------------+ ------------- 4 | AA| AA| 03 | 00 | IEEE802+------------+------------+------------+------------+ LLC/スナップ5| 00 | 00 | Ethertype=0x0800=2048| ヘッダー+============+============+============+============+ ============= 6 | VER| HLEN| TOS| 全長| +-----+------+------------+-----+-------------------+ 7 | ID| FLG| オフセットを破片手榴弾で殺傷してください。| + <><><><><><>+<><><><><><>+<><><>< @? h? 吹{? 腹' i? 蔓+ C? D? O+IPv4ヘッダー? TTL| プロト| ヘッダーチェックサム| +------------+------------+-------------------------+ 9 | ソースIPアドレス| +---------------------------------------------------+ 10 | 送付先IPアドレス| +---------------------------------------------------+ 11 | . . . | +---------------------------------------------------+ | . . . | バイト(n-2)| バイト(n-1)| 中詰め| +------------+------------+------------+------------+ | 中詰め| 中詰め| 中詰め| 中詰め| +------------+------------+------------+------------+ M-1| 中詰め| 中詰め| 中詰め| 中詰め| + データパケットが図解する<><><><><><>+<><><><><><>+<><><>< @? h? 吹{? 腹' i? 蔓+ C? D? O+IP v?br />上図で示されるように、IPデータグラムの最初の8バイトは[1] HIPPI6400ペーハーヘッダーmicropacketのベストエイトバイトを占領します。
As shown in above figure the first eight bytes of the IP Datagram occupy the last eight bytes of the HIPPI-6400-PH [1] Header micropacket.
4.2 HIPPI-6400 Hardwareアドレス: 普遍的なLAN MACアドレス(ULA)
4.2 HIPPI-6400 Hardware address: Universal LAN MAC address (ULA)
HIPPI-6400はHIPPI6400サウスカロライナ[2]で定義されるようにIEEE Standard 802.1A[10]か部分集合で指定されたUniversal LAN MAC Addressesを使用します。 48ビットのスペースのグローバルにユニークな地域はIEEEによって管理されます。 HIPPI6400サウスカロライナLANの各ポートにULAを割り当てなければなりません。 ノードが1IEEE802.2のLLCプロトコル実体を含むなら、複数のULAsが使用されるかもしれません。
HIPPI-6400 uses Universal LAN MAC Addresses specified in IEEE Standard 802.1A [10] or a subset as defined in HIPPI-6400-SC [2]. The globally unique part of the 48 bit space is administered by the IEEE. Each port on a HIPPI-6400-SC LAN MUST be assigned a ULA. Multiple ULAs may be used if a node contains more than one IEEE 802.2 LLC protocol entity.
Pittet Standards Track [Page 9] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
This memo assumes the use of "Logical Addressing" as described in Annex A.2 of HIPPI-6400-SC[2].
48ビットの6400年のHIPPIペーハー分野の中のアドレスの形式はIEEE 802.1A正準な噛み付いている注文と6400年のHIPPIペーハービットとバイトオーダーに続きます:
The format of the address within its 48 bit HIPPI-6400-PH fields follows IEEE 802.1A canonical bit order and HIPPI-6400-PH bit and byte order:
31 23 15 7 0 +---------------+---------------+---------------+---------------+ |ULAバイト0|L|G| ULAバイト1| ULAバイト2| ULAバイト3| +---------------+---------------+---------------+---------------+ | ULAバイト4| ULAバイト5| (ULAには中古でない)です。 | +---------------+---------------+---------------+---------------+
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 | (not used for ULA) |
+---------------+---------------+---------------+---------------+
普遍的なLANマックーアドレス形式
Universal LAN MAC Address Format
LocallyのためのL(U/Lに噛み付いた)=1はUniversalのためにアドレス、0を管理しました。 Groupアドレスのための1、IndividualのためのG(I/Gに噛み付いた)=0。
L (U/L bit) = 1 for Locally administered addresses, 0 for Universal. G (I/G bit) = 1 for Group addresses, 0 for Individual.
4.3マキシマム・トランスミッション・ユニット--MTU
4.3 Maximum Transmission Unit - MTU
最大のTransmission Unit(MTU)はIPパケットの最大の長さと定義されます、IPヘッダーを含んでいますが、IP(すなわち、HIPPI-6400 MACヘッダーとIEEE802LLC/SNAPヘッダー)の下の少しのオーバーヘッドも含んでいなくて 従来のLANには、物理的な層の仕様によって決定しているMTUサイズがあります。 単に、選ばれた媒体が、より大きいパケットで働かないか、またはノードがパケットを送る機会を待たなければならない時間を制限するのに役立つかもしれないので、MTUsが必要であるかもしれません。
Maximum Transmission Unit (MTU) is defined as the maximum length of the IP packet, including IP header, but not including any overhead below IP, i.e., HIPPI-6400 MAC header and IEEE 802 LLC/SNAP header. Conventional LANs have MTU sizes determined by physical layer specification. MTUs may be required simply because the chosen medium won't work with larger packets, or they may serve to limit the amount of time a node must wait for an opportunity to send a packet.
6400年のHIPPIペーハー[1]はパケットをネットワーク目的のためのどんな実用的な限界も課さないおよそ4つのギガバイト(VC3の)に制限します。 HIPPI6400PH VC1(IPとARP交通に選ばれた)はメッセージをおよそ128キロバイトに制限します(HIPPI-800 MTU[17]よりなお大きいです)。
HIPPI-6400-PH [1] limits packets to about 4 gigabytes (on VC 3) which imposes no practical limit for networking purposes. HIPPI-6400-PH VC 1, which was chosen for IP and ARP traffic, limits messages to about 128 Kbytes which is still larger than the HIPPI-800 MTU [17].
MTU、HIPPI-6400LAN SHALLのために、(10進)の65280バイトはそうです。
The MTU for HIPPI-6400 LANs SHALL be 65280 (decimal) bytes.
この値は後方にHIPPI-800と互換性があった状態であります。 それで、IPパケットは最大256バイトのオーバーヘッドがある1つ64のKバイトバッファをうまくはめ込むことができます。 IP v4オーバーヘッドは、HIPPI-6400のための24バイトとHIPPI-800のための40バイトです。
This value is backwards compatible with HIPPI-800. It allows the IP packet to fit in one 64K byte buffer with up to 256 bytes of overhead. The IP v4 overhead is 24 bytes for HIPPI-6400 and 40 bytes for HIPPI-800.
Pittet Standards Track [Page 10] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
For HIPPI-6400 the byte accounting is:
65280バイトの232バイトの6400年のHIPPIペーハーのHeaderの16バイトのIEEE802.2LLC/SNAP Headers8バイトMaximum IPパケットサイズ(MTU)Unused拡大部屋------------ 総65536バイト(64K)
HIPPI-6400-PH Header 16 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes
Unused expansion room 232 bytes
------------
Total 65536 bytes (64K)
対照的に、HIPPI-800会計は以下の通りです。
In contrast, the HIPPI-800 accounting is:
216バイトの8バイトのHIPPI-800-FP HeaderのHIPPI-800-LE Headerの24バイトのIEEE802.2LLC/SNAP Headers8バイトUnused拡大余地のMaximum IPパケットサイズ(MTU)65280バイト------------ 総65536バイト(64K)
HIPPI-800-FP Header 8 bytes
HIPPI-800-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Unused expansion room 216 bytes
Maximum IP packet size (MTU) 65280 bytes
------------
Total 65536 bytes (64K)
5. HIPPIアドレス解決プロトコル--ハープを弾いてください。
5. HIPPI Address Resolution Protocol - HARP
HIPPI-6400 LIS SHALLの中のアドレス決議はHIPPI Address Resolutionプロトコル(HARP)とInverse HIPPI Address Resolutionプロトコル(InHARP)を利用します。 HARPはインターネットAddress Resolutionプロトコル(ARP)と同じ機能性を提供します。
Address resolution within the HIPPI-6400 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はHIPPI-6400の特定のパケット・フォーマットを除いて、RFC-826[14]で定義されるARPに基づいています。 インターネット・アドレスを知っていて、従来のネットワークは、別のノードのハードウェア・アドレスを発見するのにARPを使用します。 このセクションにさらに示されたHARPは、ハードウェアの放送能力から独立している一貫性を持っているアドレス解決サービスを形成するためにオリジナルのプロトコル定義の組み合わせを指定します。 InHARPはHIPPI-6400の特定のパケット・フォーマットを除いて、[5]に提示されたオリジナルのInverse ARP(InARP)プロトコルと同じプロトコルです。 ハードウェア・アドレスを知っていて、InARPは、相手のインターネット・アドレスを発見するのに使用されます。
HARP is based on ARP which is defined in RFC-826 [14] except the HIPPI-6400 specific packet format. Knowing the Internet address, conventional networks use ARP to discover another node'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. InHARP is the same protocol as the original Inverse ARP (InARP) protocol presented in [5] except the HIPPI-6400 specific packet format. Knowing its hardware address, InARP is used to discover the other party's Internet address.
HARPへのPIBES(セクション7を見る)拡張子が議定書の中で述べる一層のこのメモREQUIRES、保証はIPのような上側の層のプロトコルに対するサービスを放送しました。
This memo further REQUIRES the PIBES (see section 7) extension to the HARP protocol, guaranteeing broadcast service to upper layer protocols like IP.
インターネット・アドレスはULAsの如何にかかわらず割り当てられます。 HARPを使用する前に、各ノードはIPとそのHWアドレスを知らなければなりません。 ULAは任意ですが、従来のネットワークがある相互運用性が望まれているなら、RECOMMENDEDです。
Internet addresses are assigned independent of ULAs. Before using HARP, each node MUST know its IP and its HW addresses. The ULA is optional but is RECOMMENDED if interoperability with conventional networks is desired.
Pittet Standards Track [Page 11] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[11ページ]。
If all switches in the LIS support broadcast, then the source address in the reply will be the target's source address. If all switches in the LIS do not support broadcast, then a HARP server MUST be used to provide the address resolution service, and the source address in the reply will be the HARP server's source address.
LISサポートにおけるすべてのスイッチが放送されると、回答におけるソースアドレスは目標のソースアドレスになるでしょう。 LISのすべてのスイッチが放送をサポートしないなら、アドレス解決サービスを提供するのにHARPサーバを使用しなければなりません、そして、回答におけるソースアドレスはHARPサーバのソースアドレスになるでしょう。
5.1 HARP Algorithm
5.1ハープアルゴリズム
This section defines the behavior and requirements for HARP implementations on both broadcast and non-broadcast capable HIPPI- 6400-SC networks. HARP creates a table in each port which maps remote ports' IP addresses to ULAs, so that when an application requests a connection to a remote port by its IP address, the remote ULA can be determined, a correct HIPPI-6400-PH header can be built, and a connection to the port can be established using the ULA.
このセクションは両方のできる放送と非放送のHIPPIの6400サウスカロライナのネットワークでHARP実装のための振舞いと要件を定義します。 HARPは遠く離れたポートのIPアドレスをULAsに写像する各ポートでテーブルを作成します、アプリケーションがIPアドレスから遠く離れたポートに接続を要求すると、リモートULAが決定できて、正しい6400年のHIPPIペーハーヘッダーを造ることができて、ULAを使用することでポートとの接続は確立できるように。
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. To select the authoritative HARP service, each port needs to determine if it is connected to a broadcast network. At each point in time there is only one authoritative HARP service.
そこのHIPPI LIS、SHALL、正式のHARPサービスになってください。 正式のHARPサービスを選択するために、各ポートは、それが放送網に関連づけられるかどうか決定する必要があります。 各ポイントには、1つの正式のHARPサービスしか時間内にありません。
The port SHALL send an InHARP_REQUEST to the first address in the HRAL (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(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 order of addresses in 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
どのアドレスが正式のものになるかを単に決めるのに、HRALでのアドレスの注文は重要です。 ポートがHRALのすべてのHARPサーバアドレスに「登録されていた」状態で保つ非放送網では、REQUIREDである、(注意: いずれの放送も以来、扱いません。
Pittet Standards Track [Page 12] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[12ページ]。
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.
それがHARPサーバアドレスでない、) 例えば、正式のHARPサービスが非敏感であるなら、ポートは、HRALの次のアドレスを正式のアドレスの候補と考えて、InHARP_REQUESTを送るでしょう。
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 HRAL addresses in order. The client SHALL terminate the registration phase and transition into the operational phase, when either: (1) it receives its own InHARP_REQUEST, or (2) when it receives an InHARP_REPLY from at least one of the HARP servers and it has determined the authoritative HARP service as described in 5.1.1.
HARPクライアントSHALLは、整然とした状態でHRALアドレスを使用することでInHARP_REQUESTメッセージを送ることによって、登録フェーズを開始します。 どちらかであるときに、クライアントSHALLは操作上のフェーズへの登録フェーズと変遷を終えます: (1) 少なくともHARPサーバとそれの1つからInHARP_REPLYを受けるとき、それがそれ自身のInHARP_REQUESTを受けるか、または(2)が中で説明されるように正式のHARPサービスを決定した、5.1、.1
When ports are initiated they send an InHARP_REQUEST to the authoritative HRAL address. The first address to be tried will be the broadcast address "FF:FF:FF:FF:FF:FF". There are two outcomes:
ポートが開始されるとき、それらはInHARP_REQUESTを正式のHRALアドレスに送ります。 放送演説が「ff: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を受けません: そして、ポートは非放送のできるネットワークにつなげられます。
The port SHALL choose the next address in the HRAL as a candidate
for a HARP server and send an InHARP_REQUEST to that address:
(00:10:3B:FF:FF:E0).
ポートSHALLはHARPサーバの候補としてHRALの次のアドレスを選んで、InHARP_REQUESTをそのアドレスに送ります: (0 00:10:3B:ff:ff:E。)
The port SHALL continue to retry each non-broadcast HARP server
address in the HRAL at least once every 5 seconds until one of the
following termination criteria are met for each address.
ポートSHALLは、以下の終了評価基準の1つの5秒前毎が各アドレスのためにいったん達成されると少なくともHRALのそれぞれの非放送HARPサーバアドレスを再試行し続けています。
a. 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).
a。 ポートがそれ自身のメッセージを受け取るなら、ポート自体はHARPサーバです、そして、ポートはPIBESを使用することで放送サービスを提供するREQUIRED(セクション7を見る)です。
Pittet Standards Track [Page 13] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[13ページ]。
b. If the port receives an InHARP_REPLY, then it is a HARP client
and not a HARP server. In both cases, the current candidate
address becomes the authoritative HARP service address.
b。 ポートがInHARP_REPLYを受けるなら、それはHARPサーバではなく、HARPクライアントです。どちらの場合も、現在の候補アドレスは正式の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-6400-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.
HIPPI6400サウスカロライナのLANサポートが放送されると、クライアントは、それ自身のInHARP_REQUESTメッセージとSHALLが登録フェーズを完成するのを見るでしょう。 クライアントSHOULDはそれが放送のできるネットワークに関連づけられることにさらに注意して、HARPサーバエントリーの年をとって、セクション5.4と5.6の指定されるとしてのIP放送エミュレーションにそれぞれこの情報を使用します。
If the client doesn't see its own InHARP_REQUEST 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-6400-SC network.
クライアントがそれ自身のInHARP_REQUESTを見ない、それ、登録フェーズを完成する前に、SHALLはInHARP_REPLYを待ちます。 また、これはHARPサーバがアドレス可能であるプロトコルアドレスをクライアントに提供するでしょう。 クライアントがたまたま非放送のできるHIPPI6400サウスカロライナネットワークに関するとき、これはそうになるでしょう。
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 information about other IP members by sending of HARP_REQUESTs to the authoritative address in the HRAL and by receiving of HARP_REPLYs. The client is fully operational during the operational phase.
HARPクライアントがいったん登録フェーズを完成すると、それは操作上のフェーズに入ります。 プロトコルのこのフェーズでは、HARPクライアントSHALLは、HARP_REQUESTsをHRALの正式のアドレスに発信させて、HARP_REPLYsを受信することによって、他のIPメンバーのそれ自身のHARPテーブル情報を獲得して、リフレッシュします。 クライアントは操作上の段階の間、完全に操作上です。
In the operational phase, the client's behavior for requesting HARP resolution is the same for broadcast or non-broadcast HIPPI-6400-SC switched networks.
操作上のフェーズでは、放送か非放送HIPPI6400サウスカロライナ交換網に、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, is in the ULA part of the Target Hardware Address
field (ar$tha) of the message.
2. ポートのULAはメッセージのTarget Hardware Address分野(ar$tha)のULA地域のそうです。
3. The port is a HARP server.
3. ポートはHARPサーバです。
Pittet Standards Track [Page 14] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[14ページ]。
NOTE: It is REQUIRED to have a HARP server run on a port that has a non-zero ULA.
以下に注意してください。 非ゼロULAを持つのは、HARPサーバにポートで走らせるREQUIREDです。
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 [5].)
2. 操作上のフェーズでは、クライアントはそれが目標ポートであるならHARP_REQUESTとInHARP_REQUESTメッセージに応じなければなりません。 インタフェースに複数のIPアドレス(例えば、IP別名)があるなら、クライアントは、すべてのIPアドレスを通って自転車で行って、そのような各アドレスのためにInHARP_がREPLYであると生成しなければなりません。 その場合、InHARP_REQUESTには、複数の回答があるでしょう。 (セクション7、RFC-1293[5]の「プロトコル操作」を参照してください。)
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.3 and
5.6). All InHARP_REPLY messages SHALL be used to build/refresh its
client HARP table entries. (Refer to Section 7, "Protocol
Operation" in [5].)
4. 必要に応じてInHARP_REQUESTメッセージを生成して、送ってください、そして、適切にInHARP_REPLYメッセージを処理してください(セクション5.1 .3と5.6を見てください)。 すべてのInHARP_REPLYがSHALLを通信させます。クライアントHARPテーブル項目を組み込むか、またはリフレッシュするのが使用されてください。 (セクション7、[5]の「プロトコル操作」を参照してください。)
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交換の後にリセットされてください。
Pittet Standards Track [Page 15] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[15ページ]。
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 showed that the underlying network supports broadcast, then the refresh sequence is NOT REQUIRED.
リフレッシュしてください。登録フェーズが、次に、基本的なネットワークサポートが放送されるのを示した、系列は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-6400 connections from other HIPPI- 6400 ports. The HARP server expects an InHARP_REQUEST as the first message from the client. A server examines the IP address, the hardware address of the InHARP_REQUEST and adds or updates its HARP table entry <IP address(es), ULA> as well as the time stamp.
HARPサーバは他のHIPPI6400ポートからHIPPI-6400接続を受け入れなければなりません。 HARPサーバはクライアントからの最初のメッセージとしてInHARP_REQUESTを予想します。 サーバは、HARPテーブル項目<IPアドレス(es)(タイムスタンプと同様にULA>)をIPアドレス、InHARP_REQUESTのハードウェア・アドレスを調べて、加えるか、またはアップデートします。
A HARP server replies to HARP_REQUESTs and InHARP_REQUESTs based on the information which it has in its table. The HARP server replies SHALL contain the hardware type and corresponding format of the request (see also sec. 6).
HARPサーバはそれがテーブルに持っている情報に基づくHARP_REQUESTsとInHARP_REQUESTsに答えます。 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エントリー」を持っていて、既存の「ハードウェアエントリー」を持つのにおいて可能ですが、どちらももう片方にリンクされません。
+---+----------+----------+------------+---------------------+
| # | 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
+---+----------+----------+------------+---------------------+ | # | 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エントリーを作成してください。
Pittet Standards Track [Page 16] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[16ページ]。
d: create new HW entry
e: add new IP -> HW link to IP entry
f: add new HW -> IP link to HW entry
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:
InHARP_REQUESTのIPソースアドレスがテーブル項目をコピーするなら、IPアドレス(例えば、IPa<->HWa)とInHARP_REQUESTハードウェアソースはハードウェア・アドレスエントリー(e.g.HWb<->IPb)をマッチに扱いますが、それらは結びつけられません、そして:
- 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
- HWaエントリーは、現在のIPaアドレスの参照を取り除かせる必要があります。 - HWbは、IPaの新しい参照を加えさせる必要があります--IPaは、HWbにリンクされる必要があります。
The result will be a table with: IPb <-> HWa <-> IPb If IPb was
the only IP address referred to by the HWb entry, then delete the
HWb entry.
結果は以下をもってテーブルの上に置くことのようになるでしょう。 IPb<->HWa<->IPb If IPbはHWbエントリーで参照された唯一のIPアドレスであり、次に、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エントリーから新しい方まで動かされました(上を見てください)。
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.
一般的なケース、両方のエントリーを作成してください、そして、それらをリンクしてください。
Pittet Standards Track [Page 17] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[17ページ]。
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に送るなら、サーバは、クライアントがクライアントのHARPテーブル項目のときにタイムアウトをアップデートすることによってまだ「生きている」と述べるべきです。
A HARP server SHOULD use the PIBES (see sect. 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クライアントはテーブル項目を無効にしなければなりません。
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 the invalidated entry prior to transmitting any non-address resolution traffic to the port referred to by this entry.
以下に注意してください。 それの前のHARPテーブル項目が年をとらせるクライアントSHOULD revalidate、その結果、テーブル項目が首尾よくそうである古い時間を再開するのは再有効にされました。 クライアントは、再合法化が進行している間にこのエントリーで言及されたポートにトラフィックを送り続けるかもしれません、テーブル項目が年をとっていない限り。 クライアントはこのエントリーでどんな非アドレス解決トラフィックもポートに送る前の無効にされたエントリーが言及したrevalidateがそうしなければなりません。
Pittet Standards Track [Page 18] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[18ページ]。
The client revalidates the entry by querying the HARP server. 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サーバについて質問することによって、エントリーを再有効にします。有効な回答が受け取られているなら(例えば、HARP_REPLY)、エントリーをアップデートします。 アドレス解決サービスがエントリー(例えば、HARP_NAK、「見つけられなかったホスト」)を決議できないなら、関連テーブル項目を取り除きます。 アドレス解決サービスが利用可能でないなら(すなわち、「サーバ失敗」)、クライアントは、InHARP_REQUESTを問題のエントリーのハードウェア・アドレスに伝えて、InHARP_REPLYを受け取り次第エントリーをアップデートすることによって、revalidateにエントリーを試みなければなりません。 InHARP_REQUEST試みがInHARP_REPLYを返さないなら、関連テーブル項目を取り除きます。
6. HARP Message Encoding
6. ハープメッセージコード化
The HARP message is another type of IEEE 802 payload as described in section 4.1.3 above. The HIPPI-6400 HARP SHALL support two packet formats, both the generic Ethernet ARP packet and the HIPPI-800 HARP packet format defined in [13]. HARP messages SHALL be transmitted with a hardware type code of 28 on non-broadcast capable hardware or 1 in either case.
HARPメッセージは上のセクション4.1.3で説明されるように別のタイプのIEEE802ペイロードです。 HIPPI-6400 HARP SHALLは2つのパケット・フォーマット、ジェネリックイーサネットARPパケットと[13]で定義されたHIPPI-800 HARPパケット・フォーマットの両方をサポートします。 HARPはSHALLを通信させます。28のハードウェアタイプコードで、非放送のできるハードウェアか1でどちらの場合でも伝えられてください。
The ar$hrd field SHALL be used to differentiate between the two packet formats. The reply SHALL be in the format of the request.
ar$hrdはSHALLをさばきます。使用されて、2つのパケット・フォーマットを区別してください。 回答SHALLは要求の形式においてそうです。
6.1 Generic IEEE 802 ARP Message Format
6.1 ジェネリックIEEE802ARPメッセージ・フォーマット
This is the ARP packet format used by conventional IEEE 802 networks (i.e. Ethernet, etc). The packet format is described in RFC-826 [14] and is given here only for completeness purpose.
これは従来のIEEE802ネットワーク(すなわち、イーサネットなど)によって使用されたARPパケット・フォーマットです。 パケット・フォーマットをRFC-826[14]で説明して、完全性目的のためだけにここに与えます。
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below
ar$hln 8 bits byte length of each hardware address
ar$pln 8 bits byte length of each protocol address
ar$op 16 bits opcode (ares_op$REQUEST | ares_op$REPLY)
ar$sha 48 bits Hardware address of sender of this packet
ar$spa 32 bits Protocol address of sender of this packet
ar$tha 48 bits Hardware address of target of this
ar$tpa 32 bits Protocol address of target.
プロトコルの16ビットのhrd16ドルのarビットHardwareタイプar$プロプロトコルタイプはそれぞれのプロトコルアドレスarそれぞれの8ビットのハードウェア・アドレスar$plnバイトの長さの8ビットのar$hlnバイトの長さより下でHardwareが扱うthaの48ビットのHardwareが扱う目標のこのtpa32ドルのarビットプロトコルアドレスの目標のこのパケットar送付者のこの32ビットのパケットar$鉱泉プロトコルアドレスの送付者のオプアートの16ビットのopcode(アール_オプアート$REQUEST| アール_オプアート$REPLY)のarのsha48ドルのビットをさばきます。
Where:
ar$hrd - SHALL contain 1. (Ethernet)
どこ: ar$hrd--SHALLは1を含んでいます。 (イーサネット)
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$プロ--SHALLはIPプロトコルコード2048(小数)を含んでいます。
ar$hln - SHALL contain 6.
ar$hln--SHALLは6を含んでいます。
ar$pln - SHALL contain 4.
ar$pln--SHALLは4を含んでいます。
Pittet Standards Track [Page 19] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[19ページ]。
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$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$sha - in requests and NAKs it SHALL contain the requester's ULA
In replies it SHALL contain the target port's ULA.
要求におけるar$shaとNAKs、それ、SHALLがリクエスタのULA In回答を含んでいる、それ、SHALLは目標ポートのULAを含んでいます。
ar$spa - 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$の要求における鉱泉とNAKs、それ、SHALLは知られているならIPが扱うリクエスタのもの、そうでなければゼロを含んでいます。 他では、それは返答しています。SHALLは目標ポートのIPアドレスを含んでいます。
ar$tha - in requests and NAKs it SHALL contain the target's ULA
if known, otherwise zero.
In other replies it SHALL contain the requester's ULA.
別の方法で知られているなら、SHALLは目標のULAを含んでいます。要求におけるar$thaとNAKs、それ、ゼロ。 他では、それは返答しています。SHALLはリクエスタのULAを含んでいます。
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アドレスを含んでいます。
Pittet Standards Track [Page 20] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[20ページ]。
|31 |23 |15 |7 0| +---------------+---------------+---------------+---------------+----- 0 | | | D_ULA +-------------------------------+HIPPI 1 | | |6400 +-------------------------------+ S_ULA |MAC 2 | |hdr +---------------------------------------------------------------+ 3 | M_len | +---------------+---------------+---------------+---------------+----- 4 | AA | AA | 03 | 00 |IEEE +---------------+---------------+---------------+---------------+802 5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/ +------------+------------------+-------------------------------+SNAP 6 | hrd (1) | pro (2048) | +---------------+---------------+---------------+---------------+ 7 | hln (6) | phl (4) | op (ar$op) | +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ 8 | Source Hardware Address 0 - 3 | +-------------------------------+-------------------------------+ 9 | Source ULA bytes 4 - 5 | Source IP Address bytes 0 - 1 | +-------------------------------+-------------------------------+ 10 | Source IP Address bytes 2 - 3 | Target ULA bytes 0 - 1 | +-------------------------------+-------------------------------+ 11 | Target Hardware Address (ULA) bytes 2 - 5 | +---------------------------------------------------------------+ 12 | Target IP Address | +---------------+---------------+---------------+---------------+ 13 | FILL | FILL | FILL | FILL | +---------------+---------------+---------------+---------------+ 14 | FILL | FILL | FILL | FILL | +><><><><><><><>+<><><><><><><><+><><><><><><><>+<><><><><><><><+
|31 |23 |15 |7 0| +---------------+---------------+---------------+---------------+----- 0 | | | D_ULA+-------------------------------+ HIPPI1| | |6400 +-------------------------------+ S_ULA|Mac2| |hdr+---------------------------------------------------------------+ 3 | M_len| +---------------+---------------+---------------+---------------+----- 4 | AA| AA| 03 | 00 |IEEE+---------------+---------------+---------------+---------------+802 5 | 00 | 00 | Ethertype=0x0800=2048|LLC/+------------+------------------+-------------------------------+ スナップ6| hrd(1)| プロ(2048)| +---------------+---------------+---------------+---------------+ 7 | hln(6)| phl(4)| オプアート(ar$オプアート)| + <><><><><><><><+><><><><><><><>+< @? h? 摺% 腹' i? 蔓+ C?+ D? O? Q? S? U? W? F? メ{? ソースハードウェア・アドレス0--3| +-------------------------------+-------------------------------+ 9 | ソースULAバイト4--5| ソースIP Addressバイト0--1| +-------------------------------+-------------------------------+ 10 | ソースIP Addressバイト2--3| 目標ULAバイト0--1| +-------------------------------+-------------------------------+ 11 | Hardware Address(ULA)バイト2--5を狙ってください。| +---------------------------------------------------------------+ 12 | 目標IPアドレス| +---------------+---------------+---------------+---------------+ 13 | 中詰め| 中詰め| 中詰め| 中詰め| +---------------+---------------+---------------+---------------+ 14 | 中詰め| 中詰め| 中詰め| 中詰め| + ><><><><><><><>+<><><><><><><><+> @? h? 摺% 腹' i? 蔓+ C?+ D? O? Q? S? U? W? F? メ
6.2 HIPARP Message Formats
6.2 HIPARPメッセージ・フォーマット
The HARP protocols further SHALL support the HIPARP hardware type (ar$hrd) = 28 (dec) [18], protocol type (ar$pro), and operation code (ar$op) data formats as the ARP, and InARP protocols [14,7]. In addition, HARP makes use of an additional operation code for ARP_NAK introduced with [11]. The remainder of the HIPARP message format (defined in [13]) is different than the ARP/InARP message format defined in [14,7,10] and it is also different from the format defined in the first "IP and ARP on HIPPI" RFC-1374 [16].
一層のSHALLがHIPARPハードウェアを支えるHARPプロトコルは=28(DEC社)[18]、プロトコルタイプ(ar$プロ)、および命令コード(ar$オプアート)データがARPとしてフォーマットする(ar$hrd)、およびInARPプロトコル[14、7]をタイプします。 さらに、HARPは[11]で導入されたARP_NAKに兼業コードを利用します。 HIPARPの残りは書式を通信させます。([13])で定義されているのは、また、メッセージ・フォーマットが[14、7、10]で定義したARP/InARPとそれも最初の「HIPPIの上のIPとARP」RFC-1374で定義された書式と異なっているより異なった[16]です。
The HARP message has several fields that have the following format and values:
HARPメッセージには、以下の形式と値を持っているいくつかの分野があります:
Pittet Standards Track [Page 21] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet規格は2000年5月にHIPPI-6400(GSN)の上でRFC2835IPとARPを追跡します[21ページ]。
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
ar$rha qbytes requester's HIPPI Hardware address
ar$tha xbytes target's HIPPI Hardware address
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 ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address
Where :
ar$hrd - SHALL contain 28. (HIPARP)
Where : ar$hrd - SHALL contain 28. (HIPARP)
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
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$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$pln - SHALL contain 4.
ar$pln - SHALL contain 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 contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 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 contain 10 IF this is a HIPPI-800 HW address ELSE, for HIPPI-6400, it SHALL contain 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 - in requests and NAKs it SHALL contain the requester's HW address. In replies it SHALL contain the target port's HW address.
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 - 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$tha - in requests and NAKs it SHALL contain the target's
HW address if known, otherwise zero.
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 address.
In other replies it SHALL contain the requester's HW address.
Pittet Standards Track [Page 22] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 22] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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 - 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.
Payload Format for HARP/InHARP PDUs:
Payload Format for HARP/InHARP PDUs:
|31 |23 |15 |7 0|
+---------------+---------------+---------------+---------------+-----
0 | |
| D_ULA +-------------------------------+HIPPI
1 | | |6400
+-------------------------------+ S_ULA |MAC
2 | |hdr
+---------------------------------------------------------------+
3 | M_len |
+---------------+---------------+---------------+---------------+-----
4 | AA | AA | 03 | 00 |IEEE
+---------------+---------------+---------------+---------------+802
5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/
+------------+------------------+-------------------------------+SNAP
6 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
7 | op (ar$op) | pln (6) | shl (q) |
+<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+
8 | thl (x) | Source IP Address upper (24 bits) |
+---------------------------------------------------------------+
9 | Src. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
10 | Tgt. IP lower | Source HW Address bytes 0 - 2 |
+---------------+-------------------------------+---------------+
11 | Source HW Address bytes 3 - q | Tgt HW byte 0 |
+-----------------------------------------------+---------------+
12 | Target Hardware Address bytes 1 - 4 |
+---------------+-----------------------------------------------+
13 |Tgt HW byte 5-x|
+---------------+
HARP - InHARP Message
|31 |23 |15 |7 0| +---------------+---------------+---------------+---------------+----- 0 | | | D_ULA +-------------------------------+HIPPI 1 | | |6400 +-------------------------------+ S_ULA |MAC 2 | |hdr +---------------------------------------------------------------+ 3 | M_len | +---------------+---------------+---------------+---------------+----- 4 | AA | AA | 03 | 00 |IEEE +---------------+---------------+---------------+---------------+802 5 | 00 | 00 | Ethertype = 0x0800 = 2048 |LLC/ +------------+------------------+-------------------------------+SNAP 6 | hrd (28) | pro (2048) | +---------------+---------------+---------------+---------------+ 7 | op (ar$op) | pln (6) | shl (q) | +<><><><><><><><+><><><><><><><>+<><><><><><><><+><><><><><><><>+ 8 | thl (x) | Source IP Address upper (24 bits) | +---------------------------------------------------------------+ 9 | Src. IP lower | Target IP Address upper (24 bits) | +---------------+-----------------------------------------------+ 10 | Tgt. IP lower | Source HW Address bytes 0 - 2 | +---------------+-------------------------------+---------------+ 11 | Source HW Address bytes 3 - q | Tgt HW byte 0 | +-----------------------------------------------+---------------+ 12 | Target Hardware Address bytes 1 - 4 | +---------------+-----------------------------------------------+ 13 |Tgt HW byte 5-x| +---------------+ HARP - InHARP Message
6.2.1 Example Message encodings:
6.2.1 Example Message encodings:
Assume for the following example that the HARP server is in the HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side of the non-broadcast capable network.
Assume for the following example that the HARP server is in the HIPPI-6400 side and the clients, X and Y are on the HIPPI-800 side of the non-broadcast capable network.
Pittet Standards Track [Page 23] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 23] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
HARP_REQUEST message
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPy HARP ar$tpa = IPx
HARP ar$rha = SWy ULAy HARP ar$tha = **
** is what we would like to find out
HARP_REQUEST message HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = SWy ULAy HARP ar$tha = ** ** is what we would like to find out
HARP_REPLY message format
HARP ar$op = 2 (HARP_REPLY)
HARP ar$rpa = IPx HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx * HARP ar$tha = SWy ULAy
* answer we were looking for
HARP_REPLY message format HARP ar$op = 2 (HARP_REPLY) HARP ar$rpa = IPx HARP ar$tpa = IPy HARP ar$rha = SWx ULAx * 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 = SWx ULAx
** 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 = SWx ULAx ** is what we would like to find out
InHARP_REPLY message format
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPx * HARP ar$tpa = IPy
HARP ar$rha = SWx ULAx HARP ar$tha = SWy ULAy
* answer we were looking for
InHARP_REPLY message format HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPx * HARP ar$tpa = IPy HARP ar$rha = SWx ULAx HARP ar$tha = SWy ULAy * answer we were looking for
6.2.2 HARP_NAK message format
6.2.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 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 and 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 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 and MUST be implemented.
7 Broadcast and Multicast
7 Broadcast and Multicast
HIPPI-6400-SC requires compliant systems to support broadcast. Initial HIPPI-6400-SC systems MAY defer broadcast capability to a broadcast server rather than support it directly in the switching mechanism. A centralized HARP server architecture meets two of the three major duties of a broadcast server.
HIPPI-6400-SC requires compliant systems to support broadcast. Initial HIPPI-6400-SC systems MAY defer broadcast capability to a broadcast server rather than support it directly in the switching mechanism. A centralized HARP server architecture meets two of the three major duties of a broadcast server.
A central entity serving the whole LIS solves the coordination problem of a distributed approach. The registration requirement solves the second problem of determining which addresses make up the set loosely called "everyone". The last duty of a broadcast server is to replicate an incoming packet and send it to "everyone".
A central entity serving the whole LIS solves the coordination problem of a distributed approach. The registration requirement solves the second problem of determining which addresses make up the set loosely called "everyone". The last duty of a broadcast server is to replicate an incoming packet and send it to "everyone".
Pittet Standards Track [Page 24] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 24] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
During its registration phase, every port , including HARP server(s), discover if the underlying medium is capable of broadcast (see section 5.1.1). 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.1). 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.
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.
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.
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-6400 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 [7]) 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-6400 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 [7]) 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.
Pittet Standards Track [Page 25] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 25] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
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:
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)
(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- 6400 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- 6400 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.
8 HARP for Scheduled Transfer
8 HARP for Scheduled Transfer
This RFC also applies for resolving addresses used with Scheduled Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message types and algorithms can be used for ST (since ST uses Internet Addresses) as long as there is also an IP over HIPPI-6400 implementation on all the ports.
This RFC also applies for resolving addresses used with Scheduled Transfer (ST) over HIPPI-6400 instead of IP. This RFC's message types and algorithms can be used for ST (since ST uses Internet Addresses) as long as there is also an IP over HIPPI-6400 implementation on all the ports.
9 Security Consierations
9 Security Consierations
There are known security issues relating to port impersonation via the address resolution protocols used in the Internet [6]. No special security mechanisms have been added to the address resolution mechanism defined here for use with networks using HARP.
There are known security issues relating to port impersonation via the address resolution protocols used in the Internet [6]. 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-6400 are clearly understood at this time, due to the fluid state of HIPPI-6400 specifications, newness of the technology, and other factors. However, given the security hole ARP allows, other concerns are probably minor.
Not all of the security issues relating to ARP over HIPPI-6400 are clearly understood at this time, due to the fluid state of HIPPI-6400 specifications, newness of the technology, and other factors. However, given the security hole ARP allows, other concerns are probably minor.
Pittet Standards Track [Page 26] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 26] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
10 Open Issues
10 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.
11 HARP Examples
11 HARP Examples
Assume a HIPPI-6400-SC switch is installed with three connected ports: x, y, and a. Each port has a unique hardware address that consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa, this address is the authoritative HIPPI hardware address in the HRAL (HARP Request Address List).
Assume a HIPPI-6400-SC switch is installed with three connected ports: x, y, and a. Each port has a unique hardware address that consists unique ULA (ULAx, ULAy and UlAa, respectively). There is a HARP server connected to a switch port that is mapped to the address HWa, this address is the authoritative HIPPI hardware address in the HRAL (HARP Request Address List).
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. 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. Both ports X and Y have their interfaces configured DOWN.
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. As well as ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.
NOTE: The LLC, SNAP, Ethertype, ar$hrd, ar$pro, ar$pln fields are left out from the examples below since they are constant. As well as ar$rhl = ar$thl = 6 since these are all HIPPI-6400 examples.
11.1 Registration Phase of Client Y on Non-broadcast Hardware
11.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 the
HWa after starting a table entry for the HWa.
1. Port Y initiates its interface and sends an InHARP_REQUEST to the HWa after starting a table entry for the HWa.
HIPPI-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = ULAa
** is what we would like to find out
HIPPI-6400-PH D_ULA = ULAa HIPPI-6400-PH S_ULA = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = ULAy HARP ar$tha = 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.
Pittet Standards Track [Page 27] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 27] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
HIPPI-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 9 (InHARP_REPLY)
HARP ar$rpa = IPs *
HARP ar$tpa = IPy
HARP ar$rha = ULAa
HARP ar$tha = ULAy
* answer we were looking for
HIPPI-6400-PH D_ULA = ULAy HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 9 (InHARP_REPLY) HARP ar$rpa = IPs * HARP ar$tpa = IPy HARP ar$rha = ULAa HARP ar$tha = ULAy * answer we were looking for
3. Port Y examines the incoming InHARP_REPLY and 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 and 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.
11.2 Registration Phase of Client Y on Broadcast Capable Hardware
11.2 Registration Phase of Client Y on Broadcast Capable Hardware
If port Y is connected to a broadcast-capable network then the authoritative address is the broadcast address, HWb = SWb, ULAb (FF:FF:FF:FF:FF:FF).
If port Y is connected to a broadcast-capable network then the authoritative address is the broadcast address, HWb = SWb, ULAb (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-6400-PH D_ULA = ULAb
HIPPI-6400-PH S_ULA = ULAy
HARP ar$op = 8 (InHARP_REQUEST)
HARP ar$rpa = IPy
HARP ar$tpa = 0 **
HARP ar$rha = ULAy
HARP ar$tha = ULAb
** is what we would like to find out
HIPPI-6400-PH D_ULA = ULAb HIPPI-6400-PH S_ULA = ULAy HARP ar$op = 8 (InHARP_REQUEST) HARP ar$rpa = IPy HARP ar$tpa = 0 ** HARP ar$rha = ULAy HARP ar$tha = 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.
Pittet Standards Track [Page 28] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 28] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
11.3 Operational Phase (phase II)
11.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-6400 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-6400 hardware. The authoritative address in the HRAL for this example will be HWa: <SWa, ULAa> and IPs for simplicity reasons.
11.3.1 Successful HARP_Resolve example
11.3.1 Successful HARP_Resolve example
Assume the same process (steps 1-3 of section 11.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 11.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-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPy
HARP ar$rha = ULAx
HARP ar$tha = 0 **
** is what we would like to find out
HIPPI-6400-PH D_ULA = ULAa HIPPI-6400-PH S_ULA = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPy HARP ar$rha = 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-6400-PH D_ULA = ULAx
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 2 (HARP_Reply)
HARP ar$rpa = IPy
HARP ar$tpa = IPx
HARP ar$rha = ULAy *
HARP ar$tha = ULAx
* answer we were looking for
HIPPI-6400-PH D_ULA = ULAx HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 2 (HARP_Reply) HARP ar$rpa = IPy HARP ar$tpa = IPx HARP ar$rha = ULAy * HARP ar$tha = 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-6400-PH D_ULA = ULAy
HIPPI-6400-PH S_ULA = ULAx
<data>
HIPPI-6400-PH D_ULA = ULAy HIPPI-6400-PH S_ULA = ULAx <data>
Pittet Standards Track [Page 29] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 29] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
If the network had been broadcast-capable, 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 the network had been broadcast-capable, 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.
11.3.2 Non-successful HARP_Resolve example
11.3.2 Non-successful HARP_Resolve example
As in 11.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,
As in 11.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-6400-PH D_ULA = ULAa
HIPPI-6400-PH S_ULA = ULAx
HARP ar$op = 1 (HARP_REQUEST)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = ULAx
HARP ar$tha = 0 **
** is what we would like to find out
HIPPI-6400-PH D_ULA = ULAa HIPPI-6400-PH S_ULA = ULAx HARP ar$op = 1 (HARP_REQUEST) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = 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-6400-PH D_ULA = ULAx
HIPPI-6400-PH S_ULA = ULAa
HARP ar$op = 10 (HARP_NAK)
HARP ar$rpa = IPx
HARP ar$tpa = IPq
HARP ar$rha = 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-6400-PH D_ULA = ULAx HIPPI-6400-PH S_ULA = ULAa HARP ar$op = 10 (HARP_NAK) HARP ar$rpa = IPx HARP ar$tpa = IPq HARP ar$rha = 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 the network had been broadcast-capable, then there would not have been a reply.
If the network had been broadcast-capable, then there would not have been a reply.
Pittet Standards Track [Page 30] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 30] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
12 References
12 References
[1] ANSI NCITS 323-1998, Information Technology - High-Performance
Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[1] ANSI NCITS 323-1998, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Layer (HIPPI-6400-PH).
[2] ANSI NCITS 324-199x, Information Technology - High-Performance
Parallel Interface - 6400 Mbit/s Physical Switch Control
(HIPPI-6400-SC).
[2] ANSI NCITS 324-199x, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Physical Switch Control (HIPPI-6400-SC).
[3] ANSI NCITS Project Number 1249-D, Information Technology -
High-Performance Parallel Interface - 6400 Mbit/s Optical
Specification (HIPPI-6400-OPT).
[3] ANSI NCITS Project Number 1249-D, Information Technology - High-Performance Parallel Interface - 6400 Mbit/s Optical Specification (HIPPI-6400-OPT).
[4] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[4] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[5] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol",
RFC 2390, September 1998.
[5] Bradely, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, Issue 2,
pp. 32-48, 1989.
[6] Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[7] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[7] Deering, S, "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects
1996, Stanford University.
[8] Chesson, Greg, "HIPPI-6400 Overview", IEEE Hot Interconnects 1996, Stanford University.
[10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems -
Local Area Networks - Logical Link Control IEEE, IEEE, New York,
New York, 1989.
[10] ANSI/IEEE Std. 802.2-1989, Information Processing Systems - Local Area Networks - Logical Link Control IEEE, IEEE, New York, New York, 1989.
[11] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April
1998.
[11] Laubach, M., "Classical IP and ARP over ATM", RFC 2225, April 1998.
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November, 1990.
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November, 1990.
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834,
May 2000.
[13] Pittet, J.-M., "ARP and IP Broadcast over HIPPI-800", RFC 2834, May 2000.
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Addresses to 48-bit Ethernet Address for
Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
[14] Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", RFC-826, MIT, November 1982.
Pittet Standards Track [Page 31] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 31] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[15] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374,
October 1992.
[16] Renwick, J. and A. Nicholson, "IP and ARP on HIPPI", RFC 1374, October 1992.
[17] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[17] Renwick, J., "IP over HIPPI", RFC 2067, January 1997.
[18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[18] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
13 Acknowledgments
13 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 [17], written by John Renwick. ARP [14] written by Dave Plummer and Inverse ARP [7] written by Terry Bradley and Caralyn Brown provide the fundamental algorithms of HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [13], written by Mark Laubach who laid the structural groundwork for the HARP server.
This memo is based on the second part of [17], written by John Renwick. ARP [14] written by Dave Plummer and Inverse ARP [7] written by Terry Bradley and Caralyn Brown provide the fundamental algorithms of HARP as presented in this memo. Further, the HARP server is based on concepts and models presented in [13], written by Mark Laubach who laid the structural groundwork for the HARP server.
14 Author's Address
14 Author's Address
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94040
Jean-Michel Pittet Silicon Graphics Inc 1600 Amphitheatre Parkway Mountain View, CA 94040
Phone: 650-933-6149 Fax: 650-933-3542 EMail: jmp@sgi.com, jmp@acm.org
Phone: 650-933-6149 Fax: 650-933-3542 EMail: jmp@sgi.com, jmp@acm.org
Pittet Standards Track [Page 32] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
Pittet Standards Track [Page 32] RFC 2835 IP and ARP over HIPPI-6400 (GSN) May 2000
15 Full Copyright Statement
15 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (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 33]
Pittet標準化過程[33ページ]
一覧
スポンサーリンク
