RFC1221 日本語訳
1221 Host Access Protocol (HAP) specification: Version 2. W. Edmond. April 1 1991. (Format: TXT=152740 bytes) (Updates RFC0907) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group W. Edmond Request for Comments: 1221 BBN Updates: RFC 907 April 1991
コメントを求めるワーキンググループW.エドモンド要求をネットワークでつないでください: 1221のBBNアップデート: RFC907 1991年4月
Host Access Protocol (HAP) Specification - Version 2
ホストアクセス・プロトコル(機会)仕様--バージョン2
Status of this Memo
このMemoの状態
This memo describes the Host Access Protocol implemented in the Terrestrial Wideband Network (TWBNET). It obsoletes most but not all of RFC 907. This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはTerrestrial Wideband Network(TWBNET)で実装されたHost Accessプロトコルについて説明します。 それはRFC907の大部分にもかかわらず、すべてを時代遅れにするというわけではありません。 このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Preface
序文
This memo specifies the Host Access Protocol (HAP). HAP is a Network layer (OSI Layer 3 lower) access protocol that was first implemented about a decade ago for the DARPA/DCA sponsored Wideband Packet Satellite Network (WBNET), the precursor of the current Terrestrial Wideband Network (TWBNET). This version of the specification obsoletes references [1] and [2] in addition to most of RFC 907.
このメモはHost Accessプロトコル(HAP)を指定します。 HAPによるおよそ10年前に最初にDARPA/DCAのために実装されたNetwork層(OSI Layer3は下ろす)のアクセス・プロトコルがWideband Packet Satellite Network(WBNET)(現在のTerrestrial Wideband Network(TWBNET)の先駆)を後援したということです。 仕様のこのバージョンはRFC907の大部分に加えて参照[1]と[2]を時代遅れにします。
HAP is a developmental protocol, and will be revised as new capabilities are added and unused features are eliminated or revised. One reason that HAP is being revised now is that, unlike the original WBNET's satellite channel, the TWBNET's T1 fiber links are not a broadcast medium. This has prompted some changes to the protocol that will permit greater efficiency in a mesh topology network. Another cause of revision is the need to make HAP able to support a variety of OSI layer 3 upper protocols, such as DECNET Phase V, ST, and CLNP, where before only Internet Protocol (IP) was used. Appendix B describes how backward compatibility with the older IP- only version of HAP is achieved. A third cause of protocol changes is the desire to simplify interaction between ST2 protocol (RFC 1190) agents and the TWBNET. This has mainly affected the way certain setup errors are handled. These changes are expected to be backward compatible. Appendix A describes two capabilities that may be added to HAP in the future.
HAPが開発上のプロトコルであり、新しい能力が加えられるとき改訂されて、未使用の特徴は、取り除かれるか、または改訂されます。 HAPが現在改訂されている1つの理由はTWBNETのT1ファイバーリンクがオリジナルのWBNETの衛星チャンネルと異なった放送媒体でないということです。 これはメッシュトポロジーネットワークで、より大きい効率を可能にするプロトコルへのいくつかの変化をうながしました。 改正の別の原因はHAPをさまざまなOSI層が3つの上側のプロトコルであるとサポートすることができるようにする必要性です、DECNET Phase Vや、STや、CLNPなどのように。そこでは、以前、インターネットプロトコル(IP)だけが使用されました。 付録Bは、HAPの、より古いIPだけバージョンとの互換性がどれくらい後方であるかを達成されていた状態で説明します。 プロトコル変化の3番目の原因はST2プロトコル(RFC1190)エージェントとTWBNETとの相互作用を簡素化する願望です。 これはセットアップ誤りが扱われるのを確信している道に主に影響しました。 これらの変化が後方にあると予想されます。互換性がある。 付録Aは将来HAPに加えられるかもしれない2つの能力について説明します。
One of the protocol enhancements, "Group Streams", described in reference [2] has been eliminated. There are no known applications that use the feature. As described in Appendix A, a new mechanism, to be called "shared streams", capable of providing equivalent capabilities will be implemented if needed. Changes in [2] that have been retained include various query/reply control messages that permit a host to determine what resources it owns (mostly useful for
「グループストリーム」という増進が参照[2]で説明するプロトコルの1つは排除されました。 特徴を使用するアプリケーションが知られていません。 Appendix A、新しいメカニズムで説明されるように、呼ばれるのは「ストリームを共有しました」、提供できます必要であるなら同等な能力が実装される。 [2]における保有された変化がホストが、それがどんなリソースを所有しているかを決心していることを許可する様々な質問/回答コントロールメッセージを含んでいる、(ほとんど役に立つ。
Edmond [Page 1] RFC 1221 HAP2 April 1991
エドモンド[1ページ]RFC1221HAP2 April 1991
cleanup following a host reboot or crash).
ホストリブートかクラッシュの後をつけるクリーンアップ)
This document assumes the reader is familiar with DoD internetworking terminology.
このドキュメントは、読者がDoDインターネットワーキング用語に詳しいと仮定します。
1. Introduction
1. 序論
The Host Access Protocol (HAP) is a network layer protocol (as is
X.25). ("Network layer" here means ISO layer 3 lower, the protocol
layer below the DoD Internet Protocol (IP) layer [3] and above any
link layer protocol.) HAP defines the different types of host-to-
network control messages and host-to-host data messages that may be
exchanged over the access link connecting a host and the network
packet switch node. The protocol establishes formats for these
messages, and describes procedures for determining when each type of
message should be transmitted and what it means when one is received.
Host Accessプロトコル(HAP)はネットワーク層プロトコル(X.25のような)です。 (ここの「ネットワーク層」は、より低くISO層3を意味します、DoDインターネットプロトコル(IP)層[3]とどんなリンクレイヤプロトコルを超えたプロトコル層。) HAPはホストからネットワーク制御への異なったタイプに関するメッセージ、ホストからホストへのデータホストに接しながらアクセスリンクの上と交換されるかもしれないメッセージ、およびネットワークパケット交換機ノードを定義します。 プロトコルは、これらのメッセージのために形式を確立して、それぞれのタイプに関するメッセージがいつ送られるべきであるか、そして、1つが受け取られているときそれが何を意味するかを決定するために手順について説明します。
HAP has been implemented in the wide-area network called the Terrestrial Wideband Network (TWBNET) [5] and in the routers and other hosts that connect to TWBNET. The packet switch nodes that compose the TWBNET are called Wideband Packet Switches (WPS).
HAPはTWBNETに接続するTerrestrial Wideband Network(TWBNET)[5]と呼ばれる広域ネットワークとルータと他のホストで実装されました。 TWBNETを構成するパケット交換機ノードはWideband Packet Switches(WPS)と呼ばれます。
Both the precursor to HAP, the Host/SATNET Protocol [6], used in the Atlantic Packet Satellite Network (SATNET) and the Mobile Access Terminal Network (MATNET [7]), and HAP, used in the original Wideband Satellite Network (WBNET) [8], were originally designed to provide efficient access to the single satellite channel each network used to connect all sites. The HAP protocol designers reflected some of the peculiarities of the single satellite channel environment in the HAP protocol itself. The current Terrestrial Wideband Network (TWBNET) utilizes T1-speed fiber connections between sites. Future networks and TWBNET may use a combination of terrestrial connections and satellite connections, and may have more than one of each. The HAP protocol has been changed to accommodate these extensions.
HAPへの両方の先駆(Host/SATNETプロトコル[6])は大西洋でPacket Satellite Network(SATNET)とモバイルAccess Terminal Networkを使用しました。(オリジナルのWideband Satellite Network(WBNET)[8]で使用されたMATNET[7])、およびHAPは、元々、すべてのサイトをつなげるのに使用される各ネットワークを単独の衛星チャンネルへの効率的なアクセスに提供するように設計されました。 HAPプロトコルデザイナーはHAPプロトコル自体のただ一つの衛星流通経路環境のユニークさのいくつかを反映しました。 現在のTerrestrial Wideband Network(TWBNET)はサイトの間のT1-速度ファイバー関係を利用します。 将来のネットワークとTWBNETは陸生の接続と衛星接続の組み合わせを使用して、それぞれの1つ以上を持っているかもしれません。 これらの拡大を収容するためにHAPプロトコルを変えました。
Section 2 presents an overview of HAP. Details of HAP formats and message exchange procedures are contained in Sections 3 through 10. Further explanation of some of the topics addressed in this HAP specification can be found in reference [1].
セクション2はHAPの概要を提示します。 HAP形式と交換処理手順の詳細はセクション3〜10に含まれています。 参照[1]でこのHAP仕様で扱われた話題のいくつかに関する詳細な説明を見つけることができます。
Any protocol employed to provide sufficiently reliable message exchange over the Host-WPS link is assumed to be transparent to the protocol defined in this document. Examples of such link-level protocols are ARPANET 1822 local and distant host [9], ARPANET VDH protocol [9], and HDLC.
十分信頼できる交換処理をHost-WPSリンクの上に供給するのに使われたどんなプロトコルも本書では定義されたプロトコルに透明であると思われます。 そのようなリンク・レベルプロトコルに関する例は、アルパネット1822の地方の、そして、冷ややかなホスト[9]と、ARPANET VDHプロトコル[9]と、HDLCです。
Edmond [Page 2] RFC 1221 HAP2 April 1991
エドモンド[2ページ]RFC1221HAP2 April 1991
2. Overview
2. 概要
HAP can be characterized as a full duplex, nonreliable protocol with an optional flow control mechanism. HAP messages flow simultaneously in both directions between the WPS and the host. Transmission is nonreliable in the sense that the protocol does not provide any guarantee of error-free sequenced delivery. If error-free delivery on the host's access link is required, it must be provided by the link layer protocol below HAP. (Use of link layer protocols for this purpose is not within the scope of this document.) HAP's flow control mechanism operates independently in each direction, but the choice to enable flow control or not applies to both directions together.
全二重、任意のフロー制御メカニズムがある「非-信頼でき」プロトコルとしてHAPを特徴付けることができます。 HAPメッセージは同時に、WPSの間の方向とホストの両方を流れます。 トランスミッションはプロトコルがエラーのない配列された配送のどんな保証も提供しないという意味で「非-信頼でき」です。 ホストのアクセスリンクにおけるエラーのない配送を必要とするなら、リンクレイヤプロトコルはHAPの下にそれを提供しなければなりません。 (このドキュメントの範囲の中にリンクレイヤプロトコルの使用がこのためにありません。) HAPのフロー制御メカニズムは独自に各方向に動作しますが、フロー制御を可能にする選択は両方の方向に一緒に適用されます。
HAP supports host-to-host communication in two modes corresponding to the two types of HAP data messages, datagram messages and stream messages. Each type of message can be up to 2048 octets in length. The basic transmission service in the network is datagram service. Datagrams are variable length, unsequenced, independent, and delivery is not guaranteed. The HAP header of each datagram determines the processing of the message.
HAPは2つのタイプに関するHAPデータメッセージ、データグラムメッセージ、およびストリームメッセージに対応する2つのモードによるホスト間通信をサポートします。 それぞれのタイプに関するメッセージは長さにおける2048の八重奏まで達することができます。 ネットワークにおける基本的なトランスミッションサービスはデータグラムサービスです。 データグラムは非配列されて、独立している可変長です、そして、配送は保証されません。 それぞれのデータグラムのHAPヘッダーはメッセージの処理を決定します。
On this datagram service base a "stream" service is built. Stream service provides network bandwidth guarantees, but requires explicit setup and teardown operations to allocate and deallocate network resources. Stream traffic is best suited for continuous media traffic, but may also be used to obtain the lowest possible network delay. Host streams are established by a setup message exchange between the host and the network prior to the commencement of data flow. Although established host streams can have their characteristics modified by subsequent setup messages while they are in use, the fixed allocation properties of streams relative to datagrams impose rather strict requirements on the source of the traffic using the stream. Stream traffic arrivals must match the stream allocation both in interarrival time and message size if reasonable efficiency is to be achieved. The characteristics and use of datagrams and streams are described in detail in Sections 3 and 4 of this document.
このデータグラムサービスベースでは、「ストリーム」サービスが組立しています。 ストリームサービスは、ネットワーク回線容量保証を提供しますが、明白なセットアップ、割り当てる分解操作、およびdeallocateネットワーク資源を必要とします。 ストリームトラフィックは、連続したメディアトラフィックに合うのが最も良いのですが、また、可能な限り低いネットワーク遅延を得るのに使用されるかもしれません。 ホストストリームはデータフローの始めの前にホストとネットワークの間のセットアップ交換処理で確立されます。 それらが使用中である間その後のセットアップメッセージでそれらの特性を変更できますが、確立したホストストリームでデータグラムに比例したストリームの固定配分の特性は、ストリームを使用することでかなり厳しい要件をトラフィックの源に課します。 ストリームトラフィック到着は妥当な効率が達成されることであるならinterarrival時間とメッセージサイズにおけるストリーム配分に合わなければなりません。 データグラムとストリームの特性と使用はこのドキュメントのセクション3と4で詳細に説明されます。
Both datagram and stream transmission in the network use logical addressing. Each host on the network is assigned a permanent 16-bit logical address which is independent of the physical port on the WPS to which it is attached. These 16-bit logical addresses are present in all Host-to-WPS and WPS-to-Host data messages.
ネットワークにおける、データグラムと流れ転送の両方が論理的なアドレシングを使用します。 ネットワークの各ホストは物理的なポートから独立している16ビットの永久的な論理アドレスをそれが付けているWPSに割り当てられます。 これらの16ビットの論理アドレスはHostからWPSとWPSからホストへのデータすべてのメッセージに存在しています。
HAP supports multicast addressing via "groups". Multicast addressing is provided primarily to support the multi-destination delivery required for conferencing applications. Group addresses are
HAPは「グループ」を通してマルチキャストアドレシングをサポートします。 主としてマルチの目的地が会議アプリケーションに必要である配送であるとサポートするためにマルチキャストアドレシングを提供します。 グループアドレスはそうです。
Edmond [Page 3] RFC 1221 HAP2 April 1991
エドモンド[3ページ]RFC1221HAP2 April 1991
dynamically created and deleted by the use of setup messages exchanged between a host and the WPS. Membership in a group may be any arbitrary subset of the network hosts. A message addressed to a group address is delivered to all hosts that are members of that group, except the sender. Once a multicast address has been created, any member host may use that address, not just the creator.
ホストとWPSの間で交換されたセットアップメッセージの使用でダイナミックに作成されて、削除されて. グループにおける会員資格はネットワークホストのどんな任意の部分集合であるかもしれません。 グループアドレスに扱われたメッセージはそのグループのメンバーであるすべてのホストに提供されます、送付者を除いて。 マルチキャストアドレスがいったん作成されると、どんなメンバーホストもクリエイターだけではなく、そのアドレスを使用するかもしれません。
Although HAP does not guarantee error-free delivery, error control is an important aspect of the protocol design. HAP error control is concerned with both local transfers between a host and its local WPS and transfers through the network to the destination(s). The WPS offers users a choice of network error protection options based on the network's ability to selectively send messages over its transmission media at different forward error correction (FEC) rates. These FEC options are referred to as reliability levels. Four reliability levels (low, medium-low, medium-high, and high) are available. The precise error rate provided by each reliability level is not specified.
HAPはエラーのない配送を保証しませんが、誤り制御はプロトコルデザインの重要な一面です。 HAP誤り制御はホストとその地方のWPSの間の両方の地方の転送と目的地へのネットワークを通した転送に関係があります。 WPSは異なった前進型誤信号訂正(FEC)率で選択的にトランスミッションメディアの上にメッセージを送るネットワークの能力に基づくネットワーク誤り保護オプションの選択をユーザに提供します。 これらのFECオプションは信頼性レベルと呼ばれます。 4つの信頼性レベル(低くて、媒体低くて、媒体高くて、高い)が利用可能です。 各信頼性レベルによって提供された正確な誤り率は指定されません。
Various checksum and CRC mechanisms are employed in the network to provide an error detection capability. A host has an opportunity when sending a message to indicate whether the message should be delivered to its destination or discarded if a data error is detected by the network. Each message received by a host from the network will have a flag indicating whether or not an error was detected in that particular message. A host can decide on a per-message basis whether or not it wants to accept or discard transmissions containing data errors.
様々なチェックサムとCRCメカニズムは、誤り検出能力を提供するのにネットワークで使われます。 データ誤りがネットワークによって検出されるなら、メッセージが送付先に提供されるべきであるか、または捨てられるべきであるかを示すメッセージを送るとき、ホストは機会があります。 ホストによってネットワークから受け取られた各メッセージで、旗は、誤りがその特定のメッセージに検出されたかどうかを示すでしょう。 データ誤りを含むトランスミッションを受け入れたいか、または捨てたがっていることにかかわらずホストは1メッセージあたり1つの基礎を決めることができます。
For connection of a host and WPS in close proximity, error rates due to external noise or hardware failures on the access circuit may reasonably be expected to be much smaller than the best network trunk circuit error rates. Thus for this case, little is gained by using error detection and retransmission on the access circuit. A 16-bit header checksum is provided, however, to ensure that WPSen do not act on incorrect control information. For relatively long distances or noisy connections, retransmissions over the access circuit may be required to optimize performance for both low and high reliability traffic. It is expected that link layer error control procedures (such as HDLC with retransmission) will be used for this purpose, but use of a reliable link layer protocol is not within the scope of this document.
近接性におけるホストとWPSの接続において、外部の雑音による誤り率かアクセス回路の上のハードウェアの故障が最も良いネットワークトランク回路誤り率よりはるかに小さいと合理的に予想されるかもしれません。 したがって、このような場合、アクセス回路の上の誤り検出と「再-トランスミッション」を使用することによって、少ししか獲得されません。 しかしながら、WPSenが不正確な制御情報に影響しないのを保証するために16ビットのヘッダーチェックサムを提供します。 比較的長い距離か騒がしい接続において、アクセス回路の上の「再-トランスミッション」は低いものと同様に高い信頼性のトラフィックのために性能を最適化しなければならないかもしれません。 リンクレイヤ誤り制御手順(「再-トランスミッション」があるHDLCなどの)がこのために用いられますが、このドキュメントの範囲の中に信頼できるリンクレイヤプロトコルの使用がないと予想されます。
Each datagram message submitted to the WPS by a host is marked as being in one of three priority classes, from priority 2 (highest) through priority 0 (lowest). The priority class is used by the WPS for arbitrating contention for scarce network resources (e.g., link bandwidth). That is, if the network cannot deliver all of the
ホストによってWPSに提出されたそれぞれのデータグラムメッセージは3つの優先権のクラスの1つにはあるとしてマークされます、優先権2(最も高い)から優先権0(最も低い)まで。 優先権のクラスは、不十分なネットワーク資源のための主張を仲裁するのにWPSによって使用されます(例えば、帯域幅をリンクしてください)。 すなわち、ネットワークはすべてを提供できません。
Edmond [Page 4] RFC 1221 HAP2 April 1991
エドモンド[4ページ]RFC1221HAP2 April 1991
offered messages, high priority messages will be delivered in preference to low priority messages. Priority level affects the order of access to intersite link bandwidth and the order of message delivery at the destination WPS.
提供されたメッセージであり、高い至急メッセージは少ない至急メッセージに優先して提供されるでしょう。 優先順位は目的地WPSでintersiteリンク帯域幅へのアクセスの注文とメッセージ配送の注文に影響します。
Each stream message also has three priority classes, from priority 2 (highest) through priority 0 (lowest). In addition, streams themselves have three precedence classes, from precedence 2 (highest) through precedence 0. A stream of higher precedence can preempt a stream of lower precedence at setup time. Stream message priority provides a mechanism for a low-bandwidth host to receive a high- bandwidth stream and selectively discard messages marked as less important by the sender. Stream message priority does not affect the order of delivery of stream messages between the source and the destination.
また、それぞれのストリームメッセージには、優先権2(最も高い)から優先権0(最も低い)まで3つの優先権のクラスがあります。 さらに、ストリーム自体には、3つの先行のクラスが先行2(最も高い)から先行0であります。 より高い先行のストリームは準備時間に下側の先行のストリームを先取りできます。 低バンド幅ホストが高い帯域幅ストリームを受けて、選択的に送付者によってそれほど重要でないとマークされたメッセージを捨てるように、ストリームメッセージ優先権はメカニズムを提供します。 ストリームメッセージ優先権はソースと目的地の間のストリームメッセージの配送の注文に影響しません。
Datagram and stream messages being presented to the WPS by a host may not be accepted for a number of reasons: priority too low, destination dead, lack of buffers in the source WPS, etc. The host faces a similar situation with respect to handling messages from the WPS. To permit the receiver of a message to inform the sender of the local disposition of its message, an acceptance/refusal (A/R) mechanism is implemented. The mechanism is the external manifestation of the WPS's (or host's) internal flow and congestion control algorithm. If A/Rs are enabled, an explicit or implicit acceptance or refusal for each message is returned to the host by the WPS (and conversely). This allows the host (or WPS) to retry refused messages at its discretion and can provide information useful for optimizing the sending of subsequent messages when the reason for refusals is also provided. The A/R mechanism can be disabled to provide a "pure discard" interface. The host's choice to use the A/R mechanism or not does not limit its ability to send and receive messages to any other hosts.
ホストによってWPSに提示されるデータグラムとストリームメッセージは様々な意味で受け入れられないかもしれません: 低過ぎる優先権目的地死者、ソースWPSのバッファの不足など ホストはWPSからの取り扱いメッセージに関して同様の状況に直面しています。メッセージの地方の気質について送付者に知らせるメッセージの受信機を可能にするために、承認/拒否(/R)メカニズムは実装されます。 メカニズムはWPS(または、ホストのもの)の内部の流れと輻輳制御アルゴリズムの外的発現です。 A/Rsが有効にされるなら、各メッセージのための明白であるか暗黙の承認か拒否がWPS(逆に)によってホストに返されます。 これは、ホスト(または、WPS)が自己判断で拒否されたメッセージを再試行するのを許容して、また、拒否の理由を提供するときその後のメッセージの発信を最適化することの役に立つ情報を前提とすることができます。 A/Rメカニズムは「純粋な破棄」を提供する身体障害者が連結するということであるかもしれません。 A/Rメカニズムを使用するホストの選択はいかなる他のホストにもメッセージを送って、受け取る性能を制限しません。
While the A/R mechanism allows control of individual message transfers, it does not facilitate regulation of priority flows. Such regulation is handled by passing advisory status information (GOPRI) across the Host-WPS interface indicating which priorities are currently being accepted. As long as this information, relative to the change in priority status, is passed frequently, the sender can avoid originating messages which are sure to be refused.
A/Rメカニズムが個々のメッセージ転送のコントロールを許している間、それは優先権流れの規則を容易にしません。 そのような規則は、現在プライオリティがどれであるかを示すHost-WPSインタフェースの向こう側の受け入れられる顧問状態情報(GOPRI)を通過することによって、扱われます。 この情報が頻繁に優先権状態の変化に比例して通過される限り、送付者は、確実に拒否されるメッセージを溯源するのを避けることができます。
HAP defines both data messages (datagram messages and stream messages) and link control messages. Data messages are used to send information between hosts on the network. Link control messages are exchanged between a host and the WPS to manage the local access link.
HAPはデータメッセージ(データグラムメッセージとストリームメッセージ)とリンク制御メッセージの両方を定義します。 データメッセージは、ネットワークでホストの間に情報を送るのに使用されます。 地方のアクセスリンクを管理するためにホストとWPSの間でリンク制御メッセージを交換します。
Allocation of network resources, such as streams and groups, is
ストリームやグループなどのネットワーク資源の配分があります。
Edmond [Page 5] RFC 1221 HAP2 April 1991
エドモンド[5ページ]RFC1221HAP2 April 1991
accomplished via an exchange of datagram messages, called Setups, between the user host and an agent inside the WPS called the "Service Agent." Setups are used to reserve, allocate, modify, free, and deallocate network resources. Each allocated resource has a unique identifier which, when placed in an appropriate field in a message header, allows that message to use the resource. E.g., after an exchange of Setups to create a group address, a message may be sent to the group by placing the group address in the destination field of that message. The Service Agent also permits a host to inquire about resources it owns.
Setupsと呼ばれるデータグラムメッセージの交換で、「サービスエージェント」と呼ばれるWPSの中でユーザー・ホストとエージェントの間で優れています。 セットアップは、ネットワーク資源を予約して、割り当てて、変更して、解放して、「反-割り当て」るのに使用されます。 それぞれの割り当てられたリソースには、メッセージヘッダーの適切な分野に置かれるとリソースを使用するそのメッセージを許容するユニークな識別子があります。 例えば、グループアドレスを作成するSetupsの交換の後に、そのメッセージのあて先フィールドにグループアドレスを置くことによって、メッセージをグループに送るかもしれません。 また、Serviceエージェントは、ホストがそれが所有しているリソースについて問い合わせをすることを許可します。
Every HAP message consists of an integral number of 16-bit words (i.e., an even number of octets). The first several words of the message always contain control information and are referred to as the message header. The first word of the message header identifies the type of message which follows. The second word of the message header is a checksum which covers all header information. Any message whose received header checksum does not match the checksum computed on the received header information must be discarded. The format of the rest of the header depends on the specific message type.
あらゆるHAPメッセージが整数の16ビットの単語(すなわち、八重奏の偶数)から成ります。 メッセージのいくつかの最初の言葉が、いつも制御情報を含んでいて、メッセージヘッダーと呼ばれます。 メッセージヘッダーの最初の単語は従うメッセージのタイプを特定します。 メッセージヘッダーの2番目の単語はすべてのヘッダー情報をカバーするチェックサムです。 容認されたヘッダーチェックサムが受信されたヘッダー情報で計算されたチェックサムに合っていないどんなメッセージも捨てなければなりません。 ヘッダーの残りの形式は特定のメッセージタイプに頼っています。
The formats and use of the individual message types are detailed in the following sections. A common format description is used for this purpose. Words in a message are numbered starting at zero (i.e., zero is the first word of a message header). Bits within a word are numbered from zero (most significant) to fifteen (least significant). The notation used to identify a particular field location is:
独特のメッセージタイプの形式と使用は以下のセクションで詳細です。 一般的な書式の記述はこのために使用されます。 ゼロから出発して、メッセージのワーズは番号付です(すなわち、ゼロはメッセージヘッダーの最初の単語です)。 単語の中のビットはゼロ(最も重要な)から15(最も重要でない)に付番されます。 特定の分野の位置を特定するのに使用される記法は以下の通りです。
<WORD#>{-<WORD#>} [ <BIT#>{-<BIT#>} ] <description>
-<が#>を言い表すという<単語#>、[<が#>に噛み付いた、-<が#>に噛み付いた、]、<記述>。
where optional elements in {} are used to specify the (inclusive)
upper limit of a range. The reader should refer to these field
identifiers for precise field size specifications. Fields which are
common to several message types are defined in the first section
which uses them. Only the name of the field will usually appear in
the descriptions in subsequent sections.
どこ、中の随意的な要素、1つの範囲の(包括的)の上限を指定するために、使用されるか。 読者は正確な分野サイズ仕様のためのこれらの分野識別子を参照するべきです。 いくつかのメッセージタイプに、一般的な分野は彼らを使用する最初のセクションで定義されます。 通常、分野の名前だけがその後のセクションに記述に現れるでしょう。
Link-level protocols used to support HAP can differ in the order in which they transmit the bits constituting HAP messages. The words of the message are transmitted from word 0 to word N.
HAPをサポートするのに使用されるリンク・レベルプロトコルは彼らがHAPメッセージを構成するビットを伝えるオーダーにおいて異なることができます。 メッセージの言葉はWord0から単語Nまで伝えられます。
3. Datagram Messages
3. データグラムメッセージ
Datagrams are one of the two message types provided by HAP, as described in the previous section. Because network resources are not reserved in advance for datagram traffic, delivery of datagram traffic is subject to greater delivery delays and delay variance than stream traffic, and is subject to flow and congestion controls.
データグラムは前項で説明されるようにHAPによって提供された2つのメッセージタイプのひとりです。 ネットワーク資源があらかじめデータグラムトラフィックのために予約されないので、データグラムトラフィックの配送は、流れるより大きい配送遅れと遅れ変化のトラフィックを受けることがあって、流れと輻輳制御を被りやすいです。
Edmond [Page 6] RFC 1221 HAP2 April 1991
エドモンド[6ページ]RFC1221HAP2 April 1991
Datagram priority determines which packets are delivered or discarded when network resources do not permit handling all of the presented traffic. It is expected that datagram messages will be used to support the majority of computer-to-computer and terminal-to-computer traffic which is bursty in nature.
データグラム優先権は、ネットワーク資源が提示されたトラフィックのすべてを取り扱いように可能にしないとき、どのパケットが提供されるか、または捨てられるかを決定します。 データグラムメッセージがコンピュータからコンピュータと端末からコンピュータへの現実にburstyであるトラフィックの大部分をサポートするのに使用されると予想されます。
The format of datagram messages and the purpose of each of the header control fields is described in Figure 1.
データグラムメッセージの形式とそれぞれのヘッダー制御フィールドの目的は図1で説明されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| 0 | F| MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 0|IL| D| E| PRI | TTL | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | PROTOCOL ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
7-N : DATA :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 0|lb|GOPRI| 0 | F| メッセージ番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | /R| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 0|IL| D| E| PRI| TTL| RLY| RLEN| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4 | あて先ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5 | 送信元ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | プロトコルID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | 7-N: データ: | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DATAGRAM MESSAGE
Figure 1
データグラムメッセージ数値1
0[0] Message Class. This bit identifies the message as a
data message or a control message.
0[0]メッセージのクラス。 このビットは、メッセージがデータメッセージかコントロールメッセージであると認識します。
0 = Data Message
1 = Control Message
0 =データメッセージ1=コントロールメッセージ
0[1] Loopback indicator. This bit allows the sender of a
message to determine if its own messages are being
looped back. The host and the WPS each use different
settings of this bit for their transmissions. If a
message arrives with the loopback bit set equal to its
0[1]ループバックインディケータ。 このビットはそれ自身のメッセージが輪にし返されているかどうか決定するメッセージの送付者を許容します。 ホストとWPSは彼らのトランスミッションにそれぞれこのビットの異なった設定を使用します。 メッセージが等しい状態で設定されたループバックビットと共に到着する、それ
Edmond [Page 7] RFC 1221 HAP2 April 1991
エドモンド[7ページ]RFC1221HAP2 April 1991
outgoing value, then the message has been looped.
外向的な値、次にメッセージは輪にされました。
0 = Sent by Host
1 = Sent by WPS
0 WPSによって送られたホスト1=によって送られた=
0[2-3] Go-Priority. In WPS-to-Host messages, this field
provides advisory information concerning the lowest
priority currently being accepted by the WPS. The host
may optionally choose to provide similar priority
information to the WPS.
0[2-3]碁優先権。 WPSからホストへのメッセージに、この分野は現在WPSによって受け入れられる中で最も低い優先度に関して顧問情報を前提とします。ホストは、同様の優先権情報をWPSに供給するのを任意に選ぶかもしれません。
0 = Low Priority
1 = Medium Priority
2 = High Priority
3 = (Reserved.)
0 = 低い優先度1は高優先度3中型の優先権2==と等しいです。(予約されます。)
0[4-6] Reserved. Must be zero.
予約された0[4-6]。 ゼロにならなければならなくなってください。
0[7] Reserved. Must be zero. Formerly used for WPS
diagnostic purposes.
予約された0[7]。 ゼロにならなければならなくなってください。 以前、WPSの診断目的に使用されています。
0[8-15] Message Number. This field contains the identification
of the message used by the acceptance/refusal (A/R)
mechanism (when enabled). If the message number is
zero, A/R is disabled for this specific message. See
Section 5 for a detailed description of the A/R
mechanism.
0[8-15]メッセージ番号。 この分野は承認/拒否(/R)メカニズムによって使用されるメッセージの識別を含んでいます(可能にされると)。 メッセージ番号がゼロであるなら、A/Rはこの特定のメッセージのために無効にされます。 A/Rメカニズムの詳述に関してセクション5を見てください。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-6 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-6(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2[0-15] Piggybacked A/R. This field may contain an
acceptance/refusal word providing A/R status on traffic
flowing in the opposite direction. Its inclusion may
eliminate the need for a separate A/R control message
(see Section 5). A value of zero for this word is used
to indicate that no piggybacked A/R information is
present.
2[0-15]は/Rを背負いました。 この分野は、逆方向に流れながら、トラフィックに承認/拒否単語提供A/R状態を含むかもしれません。 包含は別々のA/Rコントロールメッセージの必要性を排除するかもしれません(セクション5を見てください)。 この単語のためのゼロの値は、どんな便乗しているA/R情報も存在していないのを示すのに使用されます。
3[0] Data Message Type. This bit identifies whether the
message is a datagram message or a stream message.
3[0]データメッセージタイプ。 このビットは、メッセージがデータグラムメッセージかそれともストリームメッセージであるかを特定します。
0 = Datagram Message
1 = Stream Message
0 =データグラムメッセージ1=ストリームメッセージ
3[1] IL flag. Obsolete. Must be zero. (See Appendix B.)
3[1]ILは弛みます。 時代遅れ。 ゼロにならなければならなくなってください。 (付録B.を見ます)
Edmond [Page 8] RFC 1221 HAP2 April 1991
エドモンド[8ページ]RFC1221HAP2 April 1991
3[2] Discard Flag. This flag allows a source host to
instruct the network (including the destination host)
what to do with the message when data errors are
detected (assuming the header checksum is correct).
3[2]は旗を捨てます。 データ誤りが検出されるとき(ヘッダーチェックサムを仮定するのは正しいです)、この旗で、送信元ホストは、メッセージで何をするようネットワーク(あて先ホストを含んでいる)に命令できます。
0 = Discard message if data errors detected.
1 = Don't discard message if data errors detected.
0 = 検出されて、データ誤りであるならメッセージを捨ててください。 1 = 検出されて、データ誤りであるならメッセージを捨てないでください。
The value of this flag, set by the source host, is
passed on to the destination host.
送信元ホストによって設定されたこの旗の値はあて先ホストに渡されます。
3[3] Data Error Flag. This flag is used in conjunction with
the Discard Flag to indicate to the destination host
whether any data errors have been detected in the
message prior to transmission over the destination's
WPS-to-Host access link. It is used only if Discard
Flag = 1. It should be set to zero by the source host.
3[3]データ誤りは弛みます。 この旗は、何かデータ誤りがWPSからホストへのアクセス目的地のリンクの上のトランスミッションの前にメッセージに検出されたかどうかをあて先ホストに示すのにDiscard Flagに関連して使用されます。 Discard Flag=1である場合にだけ使用されています。 それは送信元ホストによるゼロに設定されるべきです。
0 = No Data Errors Detected
1 = Data Errors Detected
0 検出された1=データ誤りが検出した=いいえデータ誤り
3[4-5] Priority. The source host uses this field to specify
the priority with which the message should be handled
within the network.
3[4-5]優先権。 送信元ホストは、メッセージがネットワークの中で扱われるべきである優先権を指定するのにこの分野を使用します。
0 = Low Priority
1 = Medium Priority
2 = High Priority
3 = (Reserved.)
0 = 低い優先度1は高優先度3中型の優先権2==と等しいです。(予約されます。)
The priority of each message is passed to the
destination host by the destination WPS.
それぞれのメッセージの優先権は目的地WPSによってあて先ホストに渡されます。
3[6-7] Time-to-Live Designator. The source host uses this
field to specify the maximum time that a message should
be allowed to exist within the network before being
deleted. Elapsed time begins when the message has been
received by the WPS from the source host (or is sent by
a WPS agent) and is last checked when the message is
queued for transmission out the I/O interface to the
destination host. If a message is multicast, each copy
is treated separately.
3[6-7]生きる時間指示子。 送信元ホストは削除される前のメッセージがネットワークの中に存在できるべきである最大の時に指定するこの分野を使用します。 経過時間は、メッセージがWPSによって送信元ホスト(または、WPSエージェントが送られる)から受け取られたとき、始まって、メッセージがトランスミッションのために入出力インターフェースからあて先ホストへ列に並ばせられるとき、チェックであることの形で最後です。 メッセージがマルチキャストであるなら、各コピーは別々に扱われます。
0 = 1 seconds
1 = 2 seconds
2 = 5 seconds
3 = 10 seconds
0 = 1秒1 = 2秒2 = 5秒3 = 10秒
Edmond [Page 9] RFC 1221 HAP2 April 1991
エドモンド[9ページ]RFC1221HAP2 April 1991
3[8-9] Reliability. The source host uses this field to
specify the basic bit error rate requirement for the
data portion of this message. The source WPS uses this
field to determine the trunk circuit transmission
parameters and forward error correction level required
to provide that bit error rate.
3[8-9]の信頼性。 送信元ホストは、このメッセージのデータ部のための基本のビット誤り率要件を指定するのにこの分野を使用します。 ソースWPSは、トランク回路トランスミッションパラメタと前進型誤信号訂正レベルがそのビット誤り率を提供するのが必要であることを決定するのにこの分野を使用します。
0 = Low Reliability
1 = Medium-Low Reliability
2 = Medium-High Reliability
3 = High Reliability
0 = 媒体低低信頼性1=信頼性2は媒体高信頼性の3=高信頼性と等しいです。
3[10-15] Reliability Length. The source host uses this field to
specify a portion of the user data which should be
transmitted at the highest reliability level (lowest
bit error rate). Both the HAP message header words and
the first 2*<Reliability Length> octets of user data
will be transmitted at high reliability while the
remainder of the user data will be transmitted at
whatever reliability level is specified in field 3[8-
9]. The reliability length mechanism gives the user
the ability to transmit private header information
(e.g., IP and TCP headers) at a higher reliability
level than the remainder of the data.
3[10-15]信頼性の長さ。 送信元ホストは、最も高い信頼性レベル(最も低いビット誤り率)で伝えられるべきである利用者データの部分を指定するのにこの分野を使用します。 利用者データの残りが分野3[8- 9]で指定されるどんな信頼性レベルでも伝えられている間、両方のHAPメッセージヘッダー言葉と利用者データの最初の2*<Reliability Length>八重奏は高信頼性で伝えられるでしょう。 信頼性の長さのメカニズムはデータの残りより高い信頼性レベルで個人的なヘッダー情報(例えば、IPとTCPヘッダー)を伝える能力をユーザに与えます。
4[0-15] Destination Host Address. This field contains the
network logical address of the destination host.
4[0-15]目的地ホスト・アドレス。 この分野はあて先ホストのネットワーク論理アドレスを含んでいます。
5[0-15] Source Host Address. This field contains the network
logical address of the source host.
5[0-15]ソースホスト・アドレス。 この分野は送信元ホストのネットワーク論理アドレスを含んでいます。
6[0-15] Protocol ID. This field specifies the next higher
level protocol. Protocol identifiers are assigned
administratively, except 0 which is reserved, and are
not part of this specification. See reference [10].
6[0-15]Protocol ID。 この分野は次の、より高い平らなプロトコルを指定します。 プロトコル識別子は、予約された0以外に、行政上割り当てられて、この仕様の一部ではありません。 参照[10]を見てください。
7-N Data. This field contains up to 16,384 bits (2048
octets) of user data, and must be an even number of
octets.
7-Nデータ。 この分野は、最大1万6384ビット(2048の八重奏)の利用者データを含んでいて、八重奏の偶数であるに違いありません。
4. Stream Messages
4. ストリームメッセージ
Stream messages are the second message type provided by HAP, as described in Section 2. Streams provide guaranteed bandwidth between the source and destination(s), and provide the minimum delivery delay and delay variance available in the network. Streams are suitable for volatile traffic, such as speech, and for support of high duty cycle applications that require throughput guarantees.
ストリームメッセージはセクション2で説明されるようにHAPによって提供された2番目のメッセージタイプです。 ストリームは、ソースと目的地の間の保証された帯域幅を供給して、ネットワークで利用可能な最小の配送遅れと遅れ変化を提供します。 ストリームはスピーチなどの揮発性のトラフィック、およびスループット保証を必要とする高いデューティサイクルアプリケーションのサポートに適しています。
Edmond [Page 10] RFC 1221 HAP2 April 1991
エドモンド[10ページ]RFC1221HAP2 April 1991
Streams must be created before stream messages can flow from host to host. The protocol to accomplish stream creation is described in Section 6.1. Once established, a stream is allocated specific network resources, such as bandwidth. Within the bounds of its stream allocation, a host is permitted considerable flexibility in how it may use the stream. Although the time to live, reliability, and reliability length of each stream message is fixed at stream setup time, the destination logical address can vary from stream message to stream message.
ストリームメッセージが接待するホストから流れることができる前にストリームを作成しなければなりません。 ストリーム作成を達成するプロトコルはセクション6.1で説明されます。 いったん設立すると、帯域幅などの特定のネットワーク資源をストリームに割り当てます。 ストリーム配分の領域の中では、それがどうストリームを使用するかもしれないかでかなりの柔軟性がホストに受入れられます。 生きる時間、信頼性、およびそれぞれのストリームメッセージの信頼性の長さはストリーム準備時間に固定されていますが、目的地論理アドレスはメッセージを流すストリームメッセージと異なることができます。
A host can, therefore, multiplex a variety of logical flows onto a single stream, as long as the stream was set up to reach all the destination hosts. The format of stream messages is described in Figure 2.
したがって、ホストはさまざまな論理的な流れをただ一つのストリームに多重送信できます、ストリームがすべてのあて先ホストに届くようにセットアップされた限り。 ストリームメッセージの形式は図2で説明されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| 0 | MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 1|IL| D| E| PRI | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | PROTOCOL ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
7-N : DATA :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 0|lb|GOPRI| 0 | メッセージ番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | /R| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 1|IL| D| E| PRI| ホストSTREAM ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4 | あて先ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5 | 送信元ホストアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | プロトコルID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | 7-N: データ: | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
STREAM MESSAGE
Figure 2
ストリームメッセージ図2
0[0] Message Class = 0 (Data Message).
0[0]メッセージのクラス=0(データメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-3] Go-Priority.
0[2-3]碁優先権。
Edmond [Page 11] RFC 1221 HAP2 April 1991
エドモンド[11ページ]RFC1221HAP2 April 1991
0[4-7] Reserved.
予約された0[4-7]。
0[8-15] Message Number. This field serves the same purpose as
the message number field in the datagram message.
Moreover, a single message number sequence is used for
both datagram and stream messages (see Section 5).
0[8-15]メッセージ番号。 この分野はデータグラムメッセージのメッセージナンバーフィールドと同じ目的に役立ちます。 そのうえ、ただ一つのメッセージ数順はデータグラムとストリームメッセージの両方に使用されます(セクション5を見てください)。
1[0-15] Header Checksum. (See datagram checksum for
description.)
1[0-15]ヘッダーチェックサム。 (記述に関してデータグラムチェックサムを見てください。)
2[0-15] Piggybacked A/R.
2[0-15]は/Rを背負いました。
3[0] Data Message Type = 1 (Stream).
3[0]データメッセージは=1(ストリーム)をタイプします。
3[1] IL flag. Obsolete. Must be zero.
3[1]ILは弛みます。 時代遅れ。 ゼロにならなければならなくなってください。
3[2] Discard Flag.
3[2]は旗を捨てます。
3[3] Data Error Flag.
3[3]データ誤りは弛みます。
3[4-5] Stream message priority. Note that all stream messages
have priority over any datagram message. Priority will
not affect the order of stream message delivery.
3[4-5]ストリームメッセージ優先権。 すべてのストリームメッセージにはどんなデータグラムメッセージより優先権もあることに注意してください。 優先権はストリームメッセージ配送の注文に影響しないでしょう。
0 = Low priority
1 = Medium priority
2 = High priority
3 = Reserved
0 = 低い優先度1は高優先度3=が予約した中型の優先権2=と等しいです。
3[6-15] Stream ID. The WPS uses this field to identify the
preallocated network resources (bandwidth allocations,
queues, buffers, etc.) to use for delivery of the
message. Streams and their identifying numbers (stream
IDs) are established by an explicit Create Stream
request (see Section 6.1).
3[6-15]Stream ID。 WPSは、メッセージの配送に使用する「前-割り当て」られたネットワーク資源(帯域幅配分、待ち行列、バッファなど)を特定するのにこの分野を使用します。 ストリームと数(ストリームID)を特定するのは明白なCreate Stream要求で確立されます(セクション6.1を見てください)。
4[0-15] Destination Host Address.
4[0-15]目的地ホスト・アドレス。
5[0-15] Source Host Address.
5[0-15]ソースホスト・アドレス。
6[0-15] Protocol ID.
6[0-15]Protocol ID。
7-N Data. This field contains up to 16,384 bits (2048
octets) of user data, and must be an even number of
octets.
7-Nデータ。 この分野は、最大1万6384ビット(2048の八重奏)の利用者データを含んでいて、八重奏の偶数であるに違いありません。
Edmond [Page 12] RFC 1221 HAP2 April 1991
エドモンド[12ページ]RFC1221HAP2 April 1991
5. Flow Control Messages
5. フロー制御メッセージ
The WPS supports an acceptance/refusal (A/R) mechanism in each direction on the host access link. The A/R mechanism is enabled for the link by the host by setting a bit in the Restart Complete control message (see Section 8). Each datagram and stream message contains an 8-bit message number used to identify the message for flow control purposes. When the A/R mechanism is enabled, the message number is incremented modulo 256 in successive messages, skipping over message number zero (zero indicates that A/R's are disabled for that message). Up to 127 messages may be outstanding (awaiting acceptance or refusal) in each direction. If the receiver of a message is unable to accept the message, a refusal indication containing the message number of the refused message and the reason for the refusal is returned. The refusal indication may be piggybacked on data messages in the opposite direction over the link or may be sent in a separate control message in the absence of reverse data traffic.
WPSは承認/拒否(/R)メカニズムをホストアクセスリンクの各方向にサポートします。 A/Rメカニズムは、ホストによってRestart Completeコントロールメッセージに少しセットすることによって、リンクに可能にされます(セクション8を見てください)。 それぞれのデータグラムとストリームメッセージはフロー制御目的へのメッセージを特定するのに使用される8ビットのメッセージ番号を含んでいます。 A/Rメカニズムが可能にされるとき、メッセージ番号は連続したメッセージの増加している法256です、メッセージ番号ゼロを飛ばして(ゼロは、RのA/ものがそのメッセージのために無効にされるのを示します)。 最大127のメッセージが各方向に傑出しているかもしれません(承認か拒否を待ちます)。 メッセージの受信機がメッセージを受け入れることができないなら、拒否されたメッセージと拒否の理由のメッセージ番号を含む拒否指示を返します。 拒否指示をデータメッセージでリンクの上の逆方向に便乗するか、または逆のデータ通信量がないとき別々のコントロールメッセージで送るかもしれません。
Acceptance indications are returned in a similar manner, either piggybacked on data messages or in a separate control message. An acceptance is returned by the receiver to indicate that the identified message was received from the host access link and was not refused. Acceptance indications returned by the WPS are not an end- to-end acknowledgement and do not imply any guarantee of delivery to the destination host(s), or even any assurance that the message will not be intentionally discarded by the network. They are sent primarily to facilitate buffer management in the host.
データメッセージで背負われるか、別々のコントロールメッセージのどちらかで同じように承認指摘を返します。 受信機で承認を返して、特定されたメッセージがホストアクセスリンクから受け取られて、拒否されなかったのを示します。 WPSによって返された承認指摘は、終わりまでの終わりの承認でなく、またメッセージが故意にネットワークによって捨てられないというあて先ホスト、またはどんな保証にさえも少しの受渡保証も含意しません。 主としてホストでバッファ管理を容易にするためにそれらを送ります。
To reduce the number of A/R messages exchanged, a single A/R indication can be returned for multiple (lower numbered) previously unacknowledged messages. Explicit acceptance of message number N implies implicit acceptance of outstanding messages with numbers N-1, N-2, etc., according to the definition of acceptance outlined above. Analogous interpretation of the refusal message number allows the receiver of a group of messages to reject them as a group when they all are being refused for the same reason. As a further efficiency measure, HAP permits aggregation of any mix of A/R indications into a single A/R control message. Such a message might be used, for example, to reject a group of messages where the refusal code on each is different.
メッセージが交換したA/Rの数を減少させるために、複数の(番号付で、下ろします)以前に不承認のメッセージのためにただ一つのA/R指示を返すことができます。 メッセージ番号Nの明白な承認は数のN-1、N-2などがある傑出しているメッセージの暗黙の承認を含意します、上に概説された承認の定義に従って。 拒否メッセージ番号の類似の解釈はそれらが皆、同じくらいのために拒否されているとき、グループが推論するようにそれらを拒絶するメッセージのグループの受信機を許容します。 さらなる効率測定として、HAPはA/R指摘のどんなミックスの集合もただ一つのA/Rコントロールメッセージに可能にします。 例えば、そのようなメッセージは、それぞれの拒否コードが異なっているメッセージのグループを拒絶するのに使用されるかもしれません。
In some circumstances the overhead associated with processing A/R messages may prove unattractive. For these cases, it is possible to disable the A/R mechanism and operate the HAP interface in a purely discard mode. The ability to effect this on a link basis has already been noted (see Sections 2 and 8). In addition, messages with sequence number zero are taken as messages for which the A/R mechanism is selectively disabled. To permit critical feedback, even
いくつかの事情では、処理A/Rメッセージに関連しているオーバーヘッドはつまらないと判明するかもしれません。 これらのケースにおいて、A/Rメカニズムを無効にして、中でHAPインタフェースを操作するために、aが純粋にモードを捨てるのは、可能です。 リンクベースでこれに作用する能力は既に注意されました(セクション2と8を見てください)。 さらに、一連番号ゼロがある伝言はA/Rメカニズムが選択的に無効にされるメッセージとしてみなされます。 重要なフィードバックを可能にさえするために
Edmond [Page 13] RFC 1221 HAP2 April 1991
エドモンド[13ページ]RFC1221HAP2 April 1991
when operating in discard mode, HAP defines an "Unnumbered Response" control message. Flow control information, and other information which cannot be sent as an A/R indication, is sent in an Unnumbered Response control message. The format of this type of message is illustrated in Figure 5.
破棄で作動するとき、モード、HAPは「無数の応答」コントロールメッセージを定義します。 Unnumbered ResponseコントロールメッセージでA/R指示として送ることができないフロー制御情報、および他の情報を送ります。 このタイプに関するメッセージの形式は図5で例証されます。
The format shown in Figure 3 is used both for A/R indications that are piggybacked on data messages (word 2), and for aggregated A/R information in A/R control messages. The format of A/R control messages is shown in Figure 4.
図3に示された書式はデータメッセージ(Word2)で背負われるA/R指摘、およびA/Rコントロールメッセージの集められたA/R情報に使用されます。 A/Rコントロールメッセージの書式は図4に示されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AR| REFUSAL CODE | A/R MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |アルゴン| 拒否コード| /Rメッセージ番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ACCEPTANCE/REFUSAL WORD
Figure 3
承認/拒否単語図3
[0] Acceptance/Refusal Type. This field identifies whether
A/R information is an acceptance or a refusal.
[0] 承認/拒否タイプ。 この分野は、A/R情報が承認かそれとも拒否であるかを特定します。
0 = Acceptance
1 = Refusal
0 =承認1=拒否
[1-7] Refusal Code. When the Acceptance/Refusal Type = 1,
this field gives the Refusal Code.
[1-7] 拒否コード。 Acceptance/拒否Type=1であるときに、この分野はRefusal Codeに与えます。
0 = Priority not being accepted
1 = Source WPS congestion
2 = Destination WPS congestion
3 = Destination host dead
4 = Destination WPS dead
5 = Illegal destination host address
6 = Destination host access not allowed
7 = Illegal source host address
8 = Message lost in access link
9 = Invalid stream ID
10 = Illegal source host for stream ID
11 = Message length too long
12 = Stream message too early
13 = Illegal control message type
14 = Illegal refusal code in A/R
15 = Can't implement loop
0 = Priority not being accepted 1 = Source WPS congestion 2 = Destination WPS congestion 3 = Destination host dead 4 = Destination WPS dead 5 = Illegal destination host address 6 = Destination host access not allowed 7 = Illegal source host address 8 = Message lost in access link 9 = Invalid stream ID 10 = Illegal source host for stream ID 11 = Message length too long 12 = Stream message too early 13 = Illegal control message type 14 = Illegal refusal code in A/R 15 = Can't implement loop
Edmond [Page 14] RFC 1221 HAP2 April 1991
エドモンド[14ページ]RFC1221HAP2 April 1991
16 = Destination host congestion
17 = Delivery refused
18 = Odd byte length packet (not allowed)
19 = Invalid stream time-to-live value
20 = "Reliability length" exceeds message length
16 = 無効のストリーム生きる時間=18奇数バイトの長さのパケット(許容されていない)19=価値20=「信頼性の長さ」が拒否されたあて先ホスト混雑17=配送はメッセージ長を超えています。
[8-15] A/R Message Number. This field contains the number of
the message to which this acceptance/refusal refers.
It also applies to all outstanding messages with
earlier numbers. Note that this field can never be
zero since a message number of zero implies that the
A/R mechanism is disabled.
[8-15] /Rメッセージ番号。 この分野はこの承認/拒否が参照されるメッセージの数を含んでいます。 また、それは以前の数ですべての傑出しているメッセージに適用されます。 ゼロのメッセージ番号が、A/Rメカニズムは障害があるのを含意するのでこの分野がゼロであるはずがないことに注意してください。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | LENGTH | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
2-N : A/R's :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| 0 | 長さ| 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | 2-N: /Rのもの: | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ACCEPTANCE/REFUSAL MESSAGE
Figure 4
承認/拒否メッセージ図4
0[0] Message Class = 1 (Control Message).
0[0]メッセージのクラス=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-3] Go-Priority.
0[2-3]碁優先権。
0[4-7] Reserved.
予約された0[4-7]。
0[8-11] Message Length. This field contains the total length
of this message in words (N+1).
0[8-11]メッセージ長。 この分野は単語(N+1)によるこのメッセージの全長を含んでいます。
0[12-15] Control Message Type = 1 (Acceptance/Refusal).
0[12-15]コントロールメッセージタイプは1(承認/拒否)と等しいです。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-N (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-N(チェックサム単語自体を除いた)の2の補数合計の2補数です。
Edmond [Page 15] RFC 1221 HAP2 April 1991
エドモンド[15ページ]RFC1221HAP2 April 1991
2[0-15] Acceptance/Refusal Word.
2[0-15]承認/拒否Word。
3-N Additional Acceptance/Refusal Words (optional).
3-Nの追加承認/拒否ワーズ(任意の)。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | RES-CODE | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| 0 | RES-コード| 5 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 応答インフォメーション| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 応答インフォメーション| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
UNNUMBERED RESPONSE
Figure 5
無数の応答図5
0[0] Message Class = 1 (Control Message).
0[0]メッセージのクラス=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-3] Go-Priority.
0[2-3]碁優先権。
0[4-7] Reserved.
予約された0[4-7]。
0[8-11] Response Code.
0[8-11]応答コード。
3 = Destination unreachable
5 = Illegal destination host address
7 = Illegal source host address
9 = Nonexistent stream ID
10 = Illegal stream ID
13 = Protocol violation
15 = Can't implement loop
3 = 不法なストリーム実在しないストリーム不法なソース目的地手の届かない=不法な目的地5ホスト・アドレス7=ホスト・アドレス9=ID10=ID13は15=が輪を実装することができないプロトコル違反と等しいです。
0[12-15] Control Message Type = 5 (Unnumbered Response).
0[12-15]コントロールメッセージタイプ=5(無数の応答)。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-3 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-3(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2[0-15] Response Information. If Response Code is:
2[0-15]応答情報。 Response Codeがそうなら:
Edmond [Page 16] RFC 1221 HAP2 April 1991
エドモンド[16ページ]RFC1221HAP2 April 1991
3: Destination Host Address
5: Destination Host Address
7: Source Host Address
9: Stream ID (right justified)
10: Stream ID (right justified)
13: Word 0 of offending message
15: Word 0 of Loopback Request message
3: あて先ホストアドレス5: あて先ホストアドレス7: 送信元ホストアドレス9: ID(まさしく正当な)10を流してください: ID(まさしく正当な)13を流してください: 腹立たしいメッセージ15のWord0: Loopback RequestメッセージのWord0
3[0-15] Response Information. If Response Code is:
3[0-15]応答情報。 Response Codeがそうなら:
3,5,7, or 9: Undefined
10: Source Host Address
13: Word 3 of offending message, or 0 if no word 3
15: Word 2 of Loopback Request message
3、5、7、または9: 未定義の10: 送信元ホストアドレス13: いいえWord3 15ならメッセージ、または0を怒らせるWord3: Loopback RequestメッセージのWord2
6. The Service Agent
6. サービスエージェント
Allocation of network resources, such as streams and groups, is accomplished via an exchange of datagram messages, called Setup messages, between the user host and the Service Agent (network address zero). Setup operations include reserving, allocating, modifying, freeing, and deallocating resources. The Service Agent causes the requested action to be carried out and serves as the intermediary between the user and the rest of the network. In the process of implementing the requested action, various network data bases are updated to reflect the current state of the referenced resource. The Service Agent also permits a host to inquire about resources it owns using Information Request and Information Reply messages.
ストリームやグループなどのネットワーク資源の配分はユーザー・ホストとServiceエージェント(ネットワーク・アドレスゼロ)の間でSetupメッセージと呼ばれるデータグラムメッセージの交換で実行されます。 セットアップ操作は、リソースを予約して、割り当てて、変更して、解放して、「反-割り当て」るのを含んでいます。 Serviceエージェントは、要求された動作が行われることを引き起こして、ユーザとネットワークの残りの間の仲介者として役目を果たします。 要求された動作を実装することの途中に、参照をつけられたリソースの現状を反映するために様々なネットワークデータベースをアップデートします。 また、Serviceエージェントは、ホストがそれが所有しているリソースについて問い合わせをすることを情報Requestと情報Replyメッセージを使用することで許可します。
A setup interaction initiated by a host involves a 3-way exchange where: (1) the requesting host sends a Setup Request to the Service Agent, (2) the Service Agent returns a Setup Reply to the requesting host, and (3) the requesting host returns a Setup Acknowledgment to the Service Agent. This procedure is used to ensure reliable transmission of Setup Requests and Replies. In order to allow more than one Setup Request message from a host to be outstanding, each Request is assigned a unique Request ID. The associated Reply and subsequent Acknowledgment are identified by the Request ID that they contain. The requesting host should receive a reply to a setup request within 3 seconds. The actual delay will depend on the nature of the request and the topology of the network. For simple networks, the delay will often be less than one second. The requesting host should respond to a Reply with a Setup Acknowledgment within one second.
ホストによって起こされたセットアップ相互作用は3ウェイを伴います。どこを交換してくださいか: (1) (3) 要求ホストはServiceエージェントにSetup Requestを送ります、そして、(2) ServiceエージェントはSetup Replyを要求ホストに返します、そして、要求ホストはServiceエージェントにSetup Acknowledgmentを返します。 この手順は、Setup RequestsとRepliesの信頼できるトランスミッションを確実にするのに用いられます。 傑出しているためにホストからの1つ以上のSetup Requestメッセージを許容するために、ユニークなRequest IDは各Requestに割り当てられます。 関連Replyとその後のAcknowledgmentはそれらが含むRequest IDによって特定されます。 要求ホストは3秒以内にセットアップ要求に回答を受け取るべきです。 実際の遅れは要求の本質とネットワークのトポロジーによるでしょう。 遅れはしばしば簡単なネットワークにおける1秒未満になるでしょう。 要求ホストは1秒以内にSetup Acknowledgmentと共にReplyに応じるべきです。
Setup exchanges initiated by the Service Agent involve a two-way exchange where: (1) the Service Agent sends a Notification to
Serviceエージェントによって起こされたセットアップ交換はツーウェイにかかわります。どこを交換してくださいか: (1) エージェントが通知書を送るService
Edmond [Page 17] RFC 1221 HAP2 April 1991
エドモンド[17ページ]RFC1221HAP2 April 1991
affected hosts, and (2) the hosts return a Setup Acknowledgment to the Service Agent. Notifications are used to inform a host of changes in the status of a network resource. In order to allow more than one Notification to be outstanding, each is assigned a unique Notification ID. The Setup Acknowledgment returned by the notified host to the Service Agent must contain the Notification ID. The host should respond within one second.
影響を受けるホスト、およびホストがServiceエージェントへのSetup Acknowledgmentを返す(2)。 通知は、ネットワーク資源の状態の多くの変化を知らせるのに使用されます。 1Notificationが傑出しているのを許容するために、ユニークなNotification IDはそれぞれに割り当てられます。 通知されたホストによってServiceエージェントに返されたSetup AcknowledgmentはNotification IDを含まなければなりません。 ホストは1秒以内に応じるべきです。
An information query is initiated by a host and involves a two-way exchange where: (1) the host sends an Information Request message to the Service Agent, and (2) the Service Agent sends back an Information Reply. There is no acknowledgment mechanism, since this request does not change any resource allocation. Furthermore, if there is an error in the request, only one response will be sent by the WPS, and the WPS will make no effort to check for or retransmit lost responses. It is the responsibility of the host to wait a certain amount of time and then determine that an unanswered information request has been lost and to resend it. (The time necessary to answer such a request is usually much less than one second.) The WPS will return the message ID of the information request in the information reply message.
質問がホストによって開始されて、ツーウェイにかかわるという情報はどこを交換するか: (1) (2) ホストは情報RequestメッセージをServiceエージェントに送ります、そして、Serviceエージェントは情報Replyを返送します。 この要求が少しの資源配分も変えないので、承認メカニズムが全くありません。 その上、要求における誤りがあると、1つの応答だけがWPSが送られるでしょう、そして、WPSは無くなっている応答をチェックするか、または再送するための努力を全くしないでしょう。 ある時間を待って、次に、答えのない情報要求が失われたことを決定して、それを再送するのは、ホストの責任です。 (通常、そのような要求に答えるのに必要な時間ははるかに1秒未満です。) WPSは情報応答メッセージにおける情報要求のIDをメッセージに返すでしょう。
The general format of all Service Agent messages is:
すべてのServiceエージェントメッセージの一般形式は以下の通りです。
<DATAGRAM MESSAGE HEADER>
<SERVICE AGENT HEADER>
<MESSAGE BODY>
<データグラムメッセージヘッダー><サービスエージェントヘッダー><メッセージボディー>。
The Protocol ID field in the datagram message header must be HAP_PROTO_SETUP (1) (see Appendix C) for messages sent to the Service Agent and will be HAP_PROTO_SETUP in messages received from the Service Agent. The Service Agent does not recognize or support use of other higher level protocols (e.g., IP), in setup messages, and will discard messages containing such headers.
データグラムメッセージヘッダーのプロトコルID分野は、メッセージのためのSETUP(1)(Appendix Cを見ます)がServiceエージェントに送ったHAP_プロト_でなければならなく、メッセージのSETUPがServiceエージェントから受けたHAP_プロト_になるでしょう。 Serviceエージェントは、セットアップメッセージにおける他の、より高い平らなプロトコル(例えば、IP)の使用を認識もしませんし、支持もしないで、そのようなヘッダーを含むメッセージを捨てるでしょう。
Illustrations of message formats below show only the Service Agent Header header and message body and do not include the datagram message header. As a reminder that the datagram header is not included, word offsets are prefixed with an "S".
以下のメッセージ・フォーマットのイラストは、ServiceエージェントHeaderヘッダーとメッセージ本体だけを示していて、データグラムメッセージヘッダーを含んでいません。 データグラムヘッダーが含まれていないということを思い出させるものとして、単語オフセットは「S」と共に前に置かれています。
The format of the Service Agent Header is illustrated in Figure 6. The body of the message will depend on the particular message type. Stream Request and Reply messages are described in Section 6.1. Group Request and Reply messages are described in Section 6.2. The format of Notifications is described in Section 6.3, and Setup Acknowledgments are described in Section 6.4. Information Request and Reply messages are described in Section 6.5.
ServiceエージェントHeaderの形式は図6で例証されます。 メッセージ欄は特定のメッセージタイプに頼るでしょう。 流れのRequestとReplyメッセージはセクション6.1で説明されます。 グループRequestとReplyメッセージはセクション6.2で説明されます。 Notificationsの形式はセクション6.3で説明されます、そして、Setup Acknowledgmentsはセクション6.4で説明されます。 情報RequestとReplyメッセージはセクション6.5で説明されます。
Edmond [Page 18] RFC 1221 HAP2 April 1991
エドモンド[18ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | MESSAGE TYPE | CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | MESSAGE ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| メッセージタイプ| コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| チェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| メッセージID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
SERVICE AGENT HEADER
Figure 6
サービスエージェントヘッダー数値6
S0[0-7] Message Type. This field determines the type of
message.
S0[0-7]メッセージタイプ。 この分野はメッセージのタイプを決定します。
0 = Setup Acknowledgment
1 = Setup Request
2 = Setup Reply
3 = Notification
4 = Information Request
5 = Information Reply
0 = セットアップセットアップセットアップ承認1=要求2=回答3=通知4は情報要求5=情報回答と等しいです。
S0[8-15] Code. For Setup Requests, this field identifies the
request type.
S0[8-15]コード。 Setup Requestsに関しては、この分野は要求タイプを特定します。
1 = Create group (multicast) address
2 = Delete group address
3 = Join group
4 = Leave group
5 = Create stream
6 = Delete stream
7 = Change stream
8 = Create shared stream
9 = Delete all streams owned by this host
10 = Add member to group
11 = Remove member from group
1=がアドレス2=が削除するグループ(マルチキャスト)を創設する、グループアドレス3=がグループ5=が作成するグループ4=休暇を接合する、流れ6の=が変化流れ8の=が作成する流れ7の=を削除する、分配している流れ9の=がグループ11=へのメンバーが免職するこのホスト10=によって所有されていた流れがメンバーを言い足すすべてを削除する、グループ
For Setup Replies, this field provides the Reply Code.
Some of the Reply Codes can be returned to any setup
request and others are request specific.
Setup Repliesのために、この分野はReply Codeを提供します。 どんなセットアップ要求にもいくつかのReply Codesを返すことができます、そして、他のものは要求特有です。
0 = Group or stream created
1 = Group or stream deleted
2 = Host added to group
3 = Host deleted from group
4 = Stream changed
0の=グループか流れが1つの=グループを創設したか、または流れは3=ホストを分類するために加えられた4=流れが変えたグループから削除された2=ホストを削除しました。
Edmond [Page 19] RFC 1221 HAP2 April 1991
エドモンド[19ページ]RFC1221HAP2 April 1991
5 = (Reserved)
6 = Request type invalid or unsupported
7 = (Reserved)
8 = Network trouble
9 = Bad group key
10 = Group address/stream ID nonexistent
11 = Not member of group/not creator of stream
12 = Stream precedence not being accepted
13 = (Reserved)
14 = (Reserved)
15 = (Reserved)
16 = Unable to add all the new hosts
17 = Insufficient network resources
18 = Requested bandwidth too large
19 = (Reserved)
20 = (Reserved)
21 = Maximum messages per interval too small
22 = Reply lost in network
23 = Illegal priority or precedence value
24 = Invalid address provided
5 =(予約される)6=要求タイプ病人かサポートされない7=(予約される)8=ネットワーク問題9が受け入れられた13=(予約される)14=(予約されます)15=(予約される)でない流れの流れ12の創造者ではなく、グループ/の悪いグループキー10=グループアドレス/ストリームIDの実在しない11=メンバーでない=先行と等しいです; 16 不十分なネットワーク資源18新しいホスト17==が1ネットワーク23で失われた小さ過ぎる22=回答が不法な優先権と等しい間隔あたりの最大の(予約される)の(予約される)の大き過ぎる19=20=21=メッセージに帯域幅を要求したか、または先行値24が無効のアドレスと等しいと言い足すことができない=が提供されました。
For Notifications, this field contains the Notification
Type. (See Section 6.3.)
Notificationsに関しては、この分野はNotification Typeを含んでいます。 (セクション6.3を見てください。)
For Setup Acknowledgments, this field contains the
Acknowledgment Type. (See Section 6.4.)
Setup Acknowledgmentsに関しては、この分野はAcknowledgment Typeを含んでいます。 (セクション6.4を見てください。)
For Information Requests, this field contains the
request type. (See Section 6.5.)
情報Requestsに関しては、この分野は要求タイプを含んでいます。 (セクション6.5を見てください。)
For Information Replies, this field contains the reply
type. (See Section 6.5.)
情報Repliesに関しては、この分野は回答タイプを含んでいます。 (セクション6.5を見てください。)
S1[0-15] Checksum. The checksum is the 2's-complement of the
2's-complement sum of the words in the Service Agent
Header (excluding the checksum word itself) and the
message body. Messages received with bad checksums
must be discarded.
S1[0-15]チェックサム。 チェックサムはServiceエージェントHeader(チェックサム単語自体を除いた)とメッセージ本体での単語の2の補数合計の2補数です。 悪いチェックサムで受け取られたメッセージを捨てなければなりません。
S2[0-15] Message ID. This field is assigned by the host to
uniquely identify outstanding requests (Request ID) and
by the Service Agent to uniquely identify outstanding
notifications (Notification ID).
S2[0-15]Message ID。 この分野は、唯一、傑出している通知(Notification ID)を特定するために唯一、傑出している要求(IDを要求する)を特定するホストとServiceエージェントによって割り当てられます。
6.1. Stream Setup Messages
6.1. 流れのセットアップメッセージ
Streams provide a means of reserving network resources for the delivery of traffic at a specified maximum throughput to a specified
流れは指定された最大のスループットで交通の配送のための指定されたaへのネットワーク資源を予約する手段を提供します。
Edmond [Page 20] RFC 1221 HAP2 April 1991
エドモンド[20ページ]RFC1221HAP2 April 1991
list of recipients. Traffic sent via a stream has priority over all non-stream traffic, and is delivered with the minimum end-to-end delay possible. Hosts use streams to support applications that have predictable traffic loads (such as packet voice or video or other continuous media traffic) or that require minimum transmission delay and lowest delay variance. Streams are typically used for traffic flows of moderate to long duration, where the cost of performing a stream Setup is acceptable.
受取人のリスト。 流れで送られた交通は、すべての非の流れの交通にわたって優先権を持って、終わりから終わりへの最小の遅れが可能な状態で果たされます。 ホストは、予測できるトラヒック負荷(パケット声、ビデオまたは他の連続したメディア交通などの)を持っているか、または最小のトランスミッション遅れと最も低い遅れ変化を必要とするアプリケーションを支持するのに流れを使用します。 流れは中道主義者の交通の流れに長い持続時間に通常使用されます、流れのSetupを実行する費用が許容できるところで。
Streams must be set up before stream data messages can flow. The stream setup messages, each of which has a Request and a Reply, are Create Stream, Delete Stream, Change Stream, and Delete All Streams. (Create Shared Stream Request is a planned future addition to the protocol.) The use of these messages is illustrated in the scenario of exchanges between a host and the Service Agent shown in Figure 7 where the host establishes a stream, sends some data, modifies the stream characteristics, sends some more data, and finally closes down the stream. Not illustrated, but implicit in this scenario, are the optional A/R indications associated with each of the stream Setup messages.
流れのデータメッセージが流れることができる前に流れをセットアップしなければなりません。 流れのセットアップメッセージ(それのそれぞれにはRequestとReplyがある)がCreate Streamと、Delete Streamと、Change Streamと、Delete All Streamsである、(作成、Shared Stream Requestがプロトコルへの計画された今後の追加である、) これらのメッセージの使用は、図7にホストがどこで流れを確立するかが示されたホストとServiceエージェントの間の交換のシナリオで例証されて、いくつかのデータを送って、流れの特性を変更して、それ以上のデータを送って、最終的に流れを閉鎖します。 このシナリオでイラスト入りではありませんが、暗黙であることは、それぞれに関する流れのSetupメッセージに関連している任意のA/R指摘です。
Service Other
Host Agent hosts
サービスOther Hostエージェントのホスト
Create Stream Request ---------->
Create Stream Reply <----------
Reply Acknowledgment ---------->
Stream Messages --------------------->
: :
Change Stream Request ---------->
Change Stream Reply <----------
Reply Acknowledgment ---------->
Stream Messages --------------------->
: :
Delete Stream Request ---------->
Delete Stream Reply <----------
Reply Acknowledgment ---------->
流れの要求を作成してください。---------->は流れの回答<を作成します。---------- 回答承認---------->流れのメッセージ--------------------->: : 変化流れの要求---------->変化流れの回答<。---------- 回答承認---------->流れのメッセージ--------------------->: : 流れの要求を削除してください。---------->は流れの回答<を削除します。---------- 回答承認---------->。
STREAM EXAMPLE
Figure 7
流れの例の図7
Streams have eight characteristic properties which are selected at stream setup time. These properties are: (1) data words per time interval, (2) time interval, (3) reliability, (4) reliability length, (5) precedence, (6) maximum messages per interval, (7) the list of recipients, and (8) the set of other streams with which this stream shares resources. To establish a stream, the host sends the Create
流れには、流れの準備時間に選択される8つの独特の特性があります。 これらの特性は以下の通りです。 (1) (2) (3) (4) (5) (6) (7) 時間間隔あたりのデータ・ワード、時間間隔、信頼性、信頼性の長さ、先行、1間隔あたりの最大のメッセージ、(8) この流れがリソースを共有する受取人のリスト、および他のセットは流れます。 流れを証明するために、ホストはCreateを送ります。
Edmond [Page 21] RFC 1221 HAP2 April 1991
エドモンド[21ページ]RFC1221HAP2 April 1991
Stream Request message (Figure 8) to the Service Agent. After the network has processed the Create Stream Request, the Service Agent will reply with a Create Stream Reply message (Figure 9). If the reply code in the Create Stream Reply indicates that the stream has been created successfully, the host may proceed to transmit stream data messages after sending a Reply Acknowledgment.
Requestメッセージ(エイト環)をServiceエージェントに流してください。 ネットワークがCreate Stream Requestを処理した後に、ServiceエージェントはCreate Stream Replyメッセージ(図9)で返答するでしょう。 Create Stream Replyの回答コードが、首尾よく流れを作成してあるのを示すなら、Reply Acknowledgmentを送った後に、ホストは流れのデータメッセージを送るかもしれなくしかけます。
During the lifetime of a stream, the host which created it may decide that some of its characteristic properties should be modified. All but one of the properties can be modified using the Change Stream Request message (Figure 10). The one property that cannot be changed is whether or not the stream is willing to share its resources with other streams. After the network has processed the Change Stream Request, the Service Agent will respond by sending a Change Stream Reply (Figure 11) to the host. A host requesting a reduced channel allocation should decrease its sending rate immediately without waiting for receipt of the Change Stream Reply. A host requesting an increased allocation should not proceed to transmit according to the new set of parameters without first having received a Reply Code indicating that the requested change has taken effect.
流れの生涯、それを作成したホストは、いくつかの独特の特性が変更されるべきであると決めるかもしれません。 Change Stream Requestメッセージ(図10)を使用することで特性の1つ以外のすべてを変更できます。 変えることができない1つの資産は流れが、他の流れとリソースを共有しても構わないと思っているかどうかということです。ネットワークがChange Stream Requestを処理した後にServiceエージェントは、Change Stream Reply(図11)をホストに送ることによって、応じるでしょう。 すぐChange Stream Replyの領収書を待たないで、減少しているチャンネル配分を要求するホストは送付レートを減少させるべきです。 最初に要求された変化が効いたのを示すReply Codeを受けていなくて、新しいセットのパラメタによると、増加する配分を要求するホストは伝わりかけるべきではありません。
When the host no longer needs the stream it created, it should first stop sending traffic via the stream and then send the Service Agent a Delete Stream Request message (Figure 12). After the network has processed the Delete Stream Request, the Service Agent will respond by sending a Delete Stream Reply (Figure 13) to the host.
ホストがもうそれが作成した流れを必要としないと、それは、最初に、流れで交通を送るのを止めて、Delete Stream Requestメッセージ(図12)をServiceエージェントに送るべきです。 ネットワークがDelete Stream Requestを処理した後に、Serviceエージェントは、Delete Stream Reply(図13)をホストに送ることによって、応じるでしょう。
If the host has crashed or restarted, it may no longer know what streams it owns. The host may use an Information Request (see Section 6.5) to determine what streams it owns, or the host may use a Delete All Streams Request (Figure 14) to discard whatever stream resources it may own. The format for the Delete All Streams Reply is shown in Figure 15.
ホストがクラッシュするか、または再開したなら、それは、もうどんな流れを所有しているかを知らないかもしれません。 ホストがそれがどんな流れを所有しているかを決定するのに、情報Request(セクション6.5を見る)を使用するかもしれませんか、またはどんな流れのリソースも所有していても、ホストは、捨てるのに、Delete All Streams Request(図14)を使用するかもしれません。 Delete All Streams Replyのための書式は図15に示されます。
Note that streams, like all other resources allocated by the Service Agent, may be reclaimed by the network if unused. Currently, if no traffic is sent to a stream in a 6 minute interval, and if the owner of the steam is down or unreachable, the stream may be deleted.
未使用であるなら流れがServiceエージェントによって割り当てられた他のすべてのリソースのようにネットワークによって取り戻されるかもしれないことに注意してください。 現在、蒸気の所有者が6分の間隔の流れに交通を全く送らないで、下がるか、または手が届かないなら、流れは削除されるかもしれません。
Edmond [Page 22] RFC 1221 HAP2 April 1991
エドモンド[22ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | MAX MES | PRE | INT | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | DATA WORDS PER INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S7-SN : DESTINATION ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 5 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| マックスMES| 前| INT| RLY| RLEN| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| 1間隔あたりのデータ・ワード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| 間隔| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| 0 | 住所録の長さ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | S7-SN: 目的地住所録: | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CREATE STREAM REQUEST
Figure 8
流れの要求エイト環を作成してください。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 5 (Create Stream).
S0[8-15]はタイプ=5を要求します(流れを作成してください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-3] Maximum Messages Per Interval (1-15). This field
specifies the maximum number of stream messages the
host will deliver to the WPS in any single stream
interval.
間隔(1-15)あたりのS3[0-3]の最大のメッセージ。 この分野はホストがどんな単一の流れの間隔のWPSにも渡す流れのメッセージの最大数を指定します。
S3[4-5] Precedence. This field specifies the precedence of the
stream. When there are insufficient network resources
to support all the requested streams, requests for
higher precedence streams will preempt existing lower
precedence streams, and requests for streams with
insufficient precedence will be rejected. Medium
precedence is recommended as the default choice.
S3[4-5]先行。 この分野は流れの先行を指定します。 すべての要求された流れを支持するために不十分なネットワーク資源があるとき、より高い先行の流れを求める要求は既存の下側の先行の流れを先取りするでしょう、そして、不十分な先行による流れを求める要求は拒絶されるでしょう。 中型の先行はデフォルト選択としてお勧めです。
Edmond [Page 23] RFC 1221 HAP2 April 1991
エドモンド[23ページ]RFC1221HAP2 April 1991
0 = Low Precedence
1 = Medium Precedence
2 = High Precedence
0 = 低い先行1は高い中型の先行2=先行と等しいです。
S3[6-7] Interval. This field specifies the interval, in
multiples of 21.22 milliseconds. (For backward
compatibility only. New applications should use 3.
Use of this field to specify an interval is being
phased out.)
S3[6-7]間隔。 この分野は21.22ミリセカンドの倍数で間隔を指定します。 (後方の互換性だけのために。 新しいアプリケーションは3を使用するべきです。 間隔を指定するこの分野の使用は段階的に廃止されています。)
0 = 21.22 milliseconds
1 = 42.44 milliseconds
2 = 84.88 milliseconds
3 = use interval in word S5
0 = 21.22 ミリセカンド3=が間隔を費やすミリセカンド1 = 42.44ミリセカンド2 = 84.88はS5を言い表します。
S3[8-9] Reliability. This field specifies the basic bit-error
rate requirement for the data portion of all messages
in the stream. The exact error rate obtained by each
choice is not specified.
S3[8-9] Reliability. This field specifies the basic bit-error rate requirement for the data portion of all messages in the stream. The exact error rate obtained by each choice is not specified.
0 = Low Reliability
1 = Medium-Low Reliability
2 = Medium-High Reliability
3 = High Reliability
0 = Low Reliability 1 = Medium-Low Reliability 2 = Medium-High Reliability 3 = High Reliability
S3[10-15] Reliability Length. This field specifies how many
words beyond the stream message header should be
transmitted at maximum reliability for all messages in
the host stream.
S3[10-15] Reliability Length. This field specifies how many words beyond the stream message header should be transmitted at maximum reliability for all messages in the host stream.
S4[0-15] Data words per interval. This field specifies the
maximum number of 16-bit words of this stream's data
the network will need to carry during each interval,
not counting HAP stream message header words. The
stream data may be carried in however many messages (up
to MAX MES) in each interval the host chooses.
S4[0-15] Data words per interval. This field specifies the maximum number of 16-bit words of this stream's data the network will need to carry during each interval, not counting HAP stream message header words. The stream data may be carried in however many messages (up to MAX MES) in each interval the host chooses.
S5[0-15] Interval (125 microsecond units). This field specifies
the time interval over which the <data words per
interval> data in <max mes> messages will be sent. For
backward compatibility, an interval of 0 selects an
interval of 169.76 milliseconds. This field is ignored
unless the INT field is 3.
S5[0-15] Interval (125 microsecond units). This field specifies the time interval over which the <data words per interval> data in <max mes> messages will be sent. For backward compatibility, an interval of 0 selects an interval of 169.76 milliseconds. This field is ignored unless the INT field is 3.
S6[0-7] Reserved. Must be zero.
S6[0-7] Reserved. Must be zero.
S6[8-15] Destination address list length. This field specifies
the number of entries in the Destination Address List
S6[8-15] Destination address list length. This field specifies the number of entries in the Destination Address List
Edmond [Page 24] RFC 1221 HAP2 April 1991
Edmond [Page 24] RFC 1221 HAP2 April 1991
field. Allowed values are 1-8.
field. Allowed values are 1-8.
S7-SN Destination address list. This list must specify, at
least indirectly, all the intended recipients of this
stream's traffic. At least one destination address
must be supplied. Any valid network address,
specifically including group addresses, may be used
(except the Service Agent's address, 0). Messages sent
in the stream are not limited to using the HAP
addresses listed. E.g., if the list consists of only
group address G, and host A is a member of G, a stream
message may be sent to A, which was not in the list.
S7-SN Destination address list. This list must specify, at least indirectly, all the intended recipients of this stream's traffic. At least one destination address must be supplied. Any valid network address, specifically including group addresses, may be used (except the Service Agent's address, 0). Messages sent in the stream are not limited to using the HAP addresses listed. E.g., if the list consists of only group address G, and host A is a member of G, a stream message may be sent to A, which was not in the list.
Caution: Group membership is only evaluated at setup time. Changes in group membership do not cause the stream to be modified.
Caution: Group membership is only evaluated at setup time. Changes in group membership do not cause the stream to be modified.
Caution: Stream creation involves allocation of specific network resources along specific routes for delivery of that traffic. A stream message sent to hosts other than those specified via Setup will probably be undeliverable. A stream message to a group address that has gained new members since the stream's last Setup may be undeliverable to the new members.
Caution: Stream creation involves allocation of specific network resources along specific routes for delivery of that traffic. A stream message sent to hosts other than those specified via Setup will probably be undeliverable. A stream message to a group address that has gained new members since the stream's last Setup may be undeliverable to the new members.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S5-SN : ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0 | 2 | REPLY CODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1 | SETUP CHECKSUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2 | REQUEST ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3 | 0 | STREAM ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4 | 0 | ADDRESS LIST LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | S5-SN : ADDRESS LIST : | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CREATE STREAM REPLY
Figure 9
CREATE STREAM REPLY Figure 9
S0[0-7] Setup Type = 2 (Reply).
S0[0-7] Setup Type = 2 (Reply).
Edmond [Page 25] RFC 1221 HAP2 April 1991
Edmond [Page 25] RFC 1221 HAP2 April 1991
S0[8-15] Reply Code. Any reply other than "Stream created"
means the stream was not created.
S0[8-15] Reply Code. Any reply other than "Stream created" means the stream was not created.
0 = Stream created
8 = Network trouble
12 = Stream precedence not being accepted
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Max. messages per interval too small
22 = Reply lost in network
23 = Illegal precedence value
24 = Invalid destination address in list
0 = Stream created 8 = Network trouble 12 = Stream precedence not being accepted 17 = Insufficient network resources 18 = Requested bandwidth too large 21 = Max. messages per interval too small 22 = Reply lost in network 23 = Illegal precedence value 24 = Invalid destination address in list
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID.
S2[0-15] Request ID.
S3[0-5] Reserved. Must be zero.
S3[0-5] Reserved. Must be zero.
S3[6-15] Stream ID. This field contains a stream ID assigned by
the network. It must be included in all stream data
messages sent by the host to allow the WPS to associate
the message with stored stream characteristics and the
resources reserved for that stream's traffic.
S3[6-15] Stream ID. This field contains a stream ID assigned by the network. It must be included in all stream data messages sent by the host to allow the WPS to associate the message with stored stream characteristics and the resources reserved for that stream's traffic.
S4[0-5] Reserved. Must be zero.
S4[0-5] Reserved. Must be zero.
S4[6-15] Address list length. The number of entries in the
Address List field.
S4[6-15] Address list length. The number of entries in the Address List field.
S5-SN Address list. This contains the destination addresses
from the Create Stream Request that were invalid or
unreachable. Unreachable destinations are listed as a
group if every member of the group was unreachable, or
individually otherwise; i.e., group addresses are
expanded and the unreachable members are included in
the list. The list of unreachable destinations will be
truncated, if needed, to limit this Reply to a single,
maximum length HAP message.
S5-SN Address list. This contains the destination addresses from the Create Stream Request that were invalid or unreachable. Unreachable destinations are listed as a group if every member of the group was unreachable, or individually otherwise; i.e., group addresses are expanded and the unreachable members are included in the list. The list of unreachable destinations will be truncated, if needed, to limit this Reply to a single, maximum length HAP message.
Edmond [Page 26] RFC 1221 HAP2 April 1991
Edmond [Page 26] RFC 1221 HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | MAX MES | PRE | INT | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | DATA WORDS PER INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | INTERVAL |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S7 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S8-SN : DESTINATION ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0 | 1 | 7 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1 | SETUP CHECKSUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2 | REQUEST ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3 | 0 | STREAM ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4 | MAX MES | PRE | INT | RLY | RLEN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5 | DATA WORDS PER INTERVAL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6 | INTERVAL | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S7 | 0 | ADDRESS LIST LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | S8-SN : DESTINATION ADDRESS LIST : | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CHANGE STREAM REQUEST
Figure 10
CHANGE STREAM REQUEST Figure 10
S0[0-7] Setup Type = 1 (Request).
S0[0-7] Setup Type = 1 (Request).
S0[8-15] Request Type = 7 (Change Stream).
S0[8-15] Request Type = 7 (Change Stream).
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID.
S2[0-15] Request ID.
S3[0-5] Reserved. Must be zero.
S3[0-5] Reserved. Must be zero.
S3[6-15] Stream ID.
S3[6-15] Stream ID.
S4[0-3] New Maximum Messages Per Interval.
S4[0-3] New Maximum Messages Per Interval.
S4[4-5] New Precedence.
S4[4-5] New Precedence.
S4[6-7] New Interval selection.
S4[6-7] New Interval selection.
S4[8-9] New Reliability.
S4[8-9] New Reliability.
Edmond [Page 27] RFC 1221 HAP2 April 1991
Edmond [Page 27] RFC 1221 HAP2 April 1991
S4[10-15] New Reliability Length.
S4[10-15] New Reliability Length.
S5[0-15] New Data Words Per Interval.
S5[0-15] New Data Words Per Interval.
S6[0-15] New Interval (ignored unless INT = 3).
S6[0-15] New Interval (ignored unless INT = 3).
S7[0-7] Reserved. Must be zero.
S7[0-7] Reserved. Must be zero.
S7[8-15] Destination Address List length. This field specifies
the number of entries in the new Destination Address
List. Allowed values are 0-8. Use zero (indicating no
addresses in the list) to avoid changing the list of
recipient hosts.
S7[8-15] Destination Address List length. This field specifies the number of entries in the new Destination Address List. Allowed values are 0-8. Use zero (indicating no addresses in the list) to avoid changing the list of recipient hosts.
S8-SN New Destination Address List. The new, complete, list
of recipient hosts. Membership of group addresses is
evaluated at setup execution time. Subsequent changes
in group membership do not cause the stream to be
modified. Note that using the same destination address
list in the Change Stream Request as was used in the
Create Stream Request can result in a change in the
list of recipient hosts if membership in a group has
changed.
S8-SN New Destination Address List. The new, complete, list of recipient hosts. Membership of group addresses is evaluated at setup execution time. Subsequent changes in group membership do not cause the stream to be modified. Note that using the same destination address list in the Change Stream Request as was used in the Create Stream Request can result in a change in the list of recipient hosts if membership in a group has changed.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | ADDRESS LIST LENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S4-SN : ADDRESS LIST :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0 | 2 | REPLY CODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1 | SETUP CHECKSUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2 | REQUEST ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3 | 0 | ADDRESS LIST LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | S4-SN : ADDRESS LIST : | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CHANGE STREAM REPLY
Figure 11
CHANGE STREAM REPLY Figure 11
S0[0-7] Setup Type = 2 (Reply).
S0[0-7] Setup Type = 2 (Reply).
Edmond [Page 28] RFC 1221 HAP2 April 1991
Edmond [Page 28] RFC 1221 HAP2 April 1991
S0[8-15] Reply Code. The number in parentheses indicates the
processing phase at the time of the error (see Caution
below). Phase zero and phase one errors leave the
stream unchanged; errors from later phases may leave
the stream partially modified.
S0[8-15] Reply Code. The number in parentheses indicates the processing phase at the time of the error (see Caution below). Phase zero and phase one errors leave the stream unchanged; errors from later phases may leave the stream partially modified.
4 = Stream changed
8 = (1) Network trouble
10 = (0) Stream ID nonexistent
11 = (0) Not creator of stream
12 = (0) Stream precedence not being accepted
16 = (3) Unable to add all the new recipients
17 = (2) Insufficient network resources
18 = (2) Requested bandwidth too large
21 = (0) Maximum messages per interval too small
22 = (2) Reply lost in network
23 = (0) Illegal precedence value
24 = (0) Invalid destination address in list
4 = Stream changed 8 = (1) Network trouble 10 = (0) Stream ID nonexistent 11 = (0) Not creator of stream 12 = (0) Stream precedence not being accepted 16 = (3) Unable to add all the new recipients 17 = (2) Insufficient network resources 18 = (2) Requested bandwidth too large 21 = (0) Maximum messages per interval too small 22 = (2) Reply lost in network 23 = (0) Illegal precedence value 24 = (0) Invalid destination address in list
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID.
S2[0-15] Request ID.
S3[0-5] Reserved. Must be zero.
S3[0-5] Reserved. Must be zero.
S3[6-15] Address list length. This field specifies the number
of addresses in the Address List.
S3[6-15] Address list length. This field specifies the number of addresses in the Address List.
S4-SN Address list. This contains the destination addresses
from the Change Stream Request that were invalid (phase
0 errors) or unreachable (phase 3 errors). Unreachable
destinations are listed as a group if every member of
the group was unreachable, or individually otherwise;
i.e., group addresses are expanded and the unreachable
members are included in the list. The list of
unreachable destinations will be truncated, if needed,
to limit this Reply to a single, maximum length HAP
message.
S4-SN Address list. This contains the destination addresses from the Change Stream Request that were invalid (phase 0 errors) or unreachable (phase 3 errors). Unreachable destinations are listed as a group if every member of the group was unreachable, or individually otherwise; i.e., group addresses are expanded and the unreachable members are included in the list. The list of unreachable destinations will be truncated, if needed, to limit this Reply to a single, maximum length HAP message.
Caution: The Change Stream Reply will indicate failure if any
aspect of the requested changes did not occur. However, the
stream may have been partially modified. Processing is performed
in the following phases:
0: check for invalid requests;
1: drop former recipients that are not in the latest list;
2: increase or decrease the stream's bandwidth allocation
(decreases are normally successful); then
3: extend the stream to any new recipients.
Caution: The Change Stream Reply will indicate failure if any aspect of the requested changes did not occur. However, the stream may have been partially modified. Processing is performed in the following phases: 0: check for invalid requests; 1: drop former recipients that are not in the latest list; 2: increase or decrease the stream's bandwidth allocation (decreases are normally successful); then 3: extend the stream to any new recipients.
Edmond [Page 29] RFC 1221 HAP2 April 1991
Edmond [Page 29] RFC 1221 HAP2 April 1991
If phase 2 fails, phase 3 is not performed, the Reply Code will
indicate an error and the stream parameters will be unchanged.
If phase 3 fails, the Address List will contain the destinations,
if any, from the latest list that the stream does not reach.
Phase 1 only fails if the stream has been suspended (see
Notifications) or the WPS is experiencing network connectivity
problems.
If phase 2 fails, phase 3 is not performed, the Reply Code will indicate an error and the stream parameters will be unchanged. If phase 3 fails, the Address List will contain the destinations, if any, from the latest list that the stream does not reach. Phase 1 only fails if the stream has been suspended (see Notifications) or the WPS is experiencing network connectivity problems.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0 | 1 | 6 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1 | SETUP CHECKSUM | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2 | REQUEST ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3 | 0 | STREAM ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE STREAM REQUEST
Figure 12
DELETE STREAM REQUEST Figure 12
S0[0-7] Setup Type = 1 (Request).
S0[0-7] Setup Type = 1 (Request).
S0[8-15] Request Type = 6 (Delete Stream).
S0[8-15] Request Type = 6 (Delete Stream).
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15] Setup Checksum. (See setup header description.)
S2[0-15] Request ID.
S2[0-15] Request ID.
S3[0-5] Reserved. Must be zero.
S3[0-5] Reserved. Must be zero.
S3[6-15] Stream ID.
S3[6-15] Stream ID.
Edmond [Page 30] RFC 1221 HAP2 April 1991
Edmond [Page 30] RFC 1221 HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE STREAM REPLY
Figure 13
ストリーム回答図13を削除してください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code. If the request was valid, the Service
Agent will have marked the stream for deletion even if
the stream resources have not actually been deleted
yet.
S0[8-15]回答コード。 要求が有効であり、ストリームリソースが実際にまだ削除されていなくても、Serviceエージェントは削除のためにストリームをマークしてしまうでしょう。
1 = Stream deleted
10 = Stream ID nonexistent
11 = Not creator of stream
1 = ストリーム削除された10=ストリームIDの実在しない11はストリームのどんなクリエイターとも等しくはありません。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 9 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 9 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE ALL STREAMS REQUEST
Figure 14
削除、すべてのストリームが図14を要求します。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 9 (Delete All Streams).
S0[8-15]はタイプ=9を要求します(すべてのストリームを削除してください)。
Edmond [Page 31] RFC 1221 HAP2 April 1991
エドモンド[31ページ]RFC1221HAP2 April 1991
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE ALL STREAMS REPLY
Figure 15
削除、すべてが回答図15を流します。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code. The Service Agent will have marked all of
the host's streams for deletion, even if the stream
resources have not actually been deleted yet.
S0[8-15]回答コード。 Serviceエージェントは削除のためにホストのストリームのすべてをマークしてしまうでしょう、ストリームリソースが実際にまだ削除されていなくても。
1 = Streams deleted
1 ストリームが削除した=
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
6.2. Group Setup Messages
6.2. グループセットアップメッセージ
Group (multicast) addressing allows a host to send the same message to N different hosts without having to send N copies of the message. The network duplicates the message as required. In addition to reducing the burden on the originating host, multicasting reduces the load on the network because the network no longer has to carry the duplicates along the common portions of the paths between the source and destinations. Multicasting is particularly recommended for multi-site conferencing and distributed simulations.
グループ(マルチキャスト)アドレシングで、メッセージのコピーN部を送る必要はなくて、ホストはN異なったホストに同じメッセージを送ることができます。 ネットワークは必要に応じてメッセージをコピーします。 送信元ホストで負担を減少させることに加えて、ネットワークがもうソースと目的地の間の経路の一般的な部分に沿って写しを運ぶ必要はないので、マルチキャスティングはネットワークで負荷を減少させます。 マルチキャスティングはマルチサイト会議と分配されたシミュレーションのために特に推薦されます。
Group addresses are dynamically created and deleted via setup messages exchanged between the hosts and the Service Agent. Membership in a group may be any arbitrary subset of the network hosts. A datagram message or stream message addressed to a group is delivered to all hosts that are members of that group (exception: stream messages sent to a group address that includes hosts the
グループアドレスは、ホストとServiceエージェントの間で交換されたセットアップメッセージで、ダイナミックに作成されて、削除されます。 グループにおける会員資格はネットワークホストのどんな任意の部分集合であるかもしれません。 グループに扱われたデータグラムメッセージかストリームメッセージがそのグループのメンバーであるすべてのホストに提供される、(例外: ストリームメッセージはホストを含んでいるグループアドレスに発信しました。
Edmond [Page 32] RFC 1221 HAP2 April 1991
エドモンド[32ページ]RFC1221HAP2 April 1991
stream was not set up to reach). The group setup messages, each of which has a Request and a Reply, are Create Group, Delete Group, Join Group, Leave Group, Add Group Member, and Remove Group Member.
ストリームが達するようにセットアップされなかった、) グループセットアップメッセージ(それのそれぞれにはRequestとReplyがある)は、Create Groupと、Delete Groupと、Join Groupと、Leave Groupと、Add Groupメンバーと、Remove Groupメンバーです。
Figure 16 shows a typical use of group setup messages. The figure illustrates a scenario of exchanges between three hosts and the Service Agent. In the scenario one host, Host A, creates a group which is joined by hosts B and C. The hosts then exchange some data messages using the group address. Note that multicast messages are not returned to their originator. Hosts A and C then leave the group, and Host B decides to delete the group. As in the scenario in Section 6.1, A/R indications have been omitted for clarity.
図16はグループセットアップメッセージの典型的な使用を示しています。 図は3人のホストとServiceエージェントの間の交換のシナリオを例証します。 シナリオでは、1人のホスト(Host A)がホストBによって加わられるグループを創設します、そして、次に、C. ホストはグループアドレスを使用することでいくつかのデータメッセージを交換します。 マルチキャストメッセージが彼らの創始者に返されないことに注意してください。 次に、ホストAとCはグループを残します、そして、Host Bはグループを削除すると決めます。 セクション6.1のシナリオのように、A/R指摘は明快ために省略されました。
Part of the group creation procedure involves the Service Agent returning to the creating host a 48-bit key along with the 16-bit group address. The creating host must pass the key along with the group address to other hosts that want to join the group. These other hosts must supply the key along with the group address in their Join Group Requests. The key is used by the network to authenticate these operations and thereby minimize the probability that unwanted hosts will deliberately or inadvertently become members of the group. The procedure used by a host to distribute the group address and key is not within the scope of HAP.
グループ作成手順の一部が16ビットのグループアドレスに伴う48ビットのキーを作成しているホストに返すServiceエージェントにかかわります。 作成しているホストはグループに加わりたがっている他のホストにグループアドレスに伴うキーを渡さなければなりません。 これらの他のホストは彼らのJoin Group Requestsのグループアドレスに伴うキーを供給しなければなりません。 キーは、これらの操作を認証して、その結果、求められていないホストが故意にかうっかりグループのメンバーになるという確率を最小にするのにネットワークによって使用されます。 HAPの範囲の中にグループアドレスとキーを配布するのにホストによって用いられた手順がありません。
In the figure below, the network Service Agent is pictured as a single entity for simplicity.
以下の図では、ネットワークServiceエージェントは簡単さのための単一体として描写されます。
Edmond [Page 33] RFC 1221 HAP2 April 1991
エドモンド[33ページ]RFC1221HAP2 April 1991
Service Host Host Host
Agent A B C
ホストホストホストエージェントにB Cでサービスを提供してください。
Create Group Request |<-------|
Create Group Reply |------->|
Reply Acknowledgment |<-------|
: :
Distribute Group Adr & Key |---->|
Distribute Group Adr & Key |---------->|
: :
Join Group Request (C) |<-------------------|
Join Group Reply |------------------->|
Reply Acknowledgment |<-------------------|
Join Group Request (B) |<-------------|
Join Group Reply |------------->|
Reply Acknowledgment |<-------------|
: :
Data Message 1 (A to B and C) |---->|---->|
Data Message 2 (B to A and C) |<----|---->|
Data Message 3 (C to A and B) |<----|<----|
: :
Leave Group Request (C) |<-------------------|
Leave Group Reply |------------------->|
Reply Acknowledgment |<-------------------|
Leave Group Request (A) |<-------|
Leave Group Reply |------->|
Reply Acknowledgment |<-------|
Delete Group Request |<-------------|
Delete Group Reply |------------->|
Reply Acknowledgment |<-------------|
グループ要求を作成してください。| <、-、-、-、-、-、--、| グループ回答を作成してください。|、-、-、-、-、-、--、>| 回答承認| <、-、-、-、-、-、--、| : : グループAdrとキーを配布してください。|、-、-、--、>| グループAdrとキーを配布してください。|、-、-、-、-、-、-、-、-、--、>| : : グループ要求(C)に参加してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| グループ回答に参加してください。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 回答承認| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| グループ要求(B)に参加してください。| <、-、-、-、-、-、-、-、-、-、-、-、--、| グループ回答に参加してください。|、-、-、-、-、-、-、-、-、-、-、-、--、>| 回答承認| <、-、-、-、-、-、-、-、-、-、-、-、--、| : : データメッセージ1(AからBとC)|、-、-、--、>|、-、-、--、>| データメッセージ2(BからAとC)| <、-、-、--、|、-、-、--、>| データメッセージ3(CからAとB)| <、-、-、--、| <、-、-、--、| : : グループ要求(C)を残してください。| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| グループ回答を残してください。|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 回答承認| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| グループ要求(A)を残してください。| <、-、-、-、-、-、--、| グループ回答を残してください。|、-、-、-、-、-、--、>| 回答承認| <、-、-、-、-、-、--、| グループ要求を削除してください。| <、-、-、-、-、-、-、-、-、-、-、-、--、| グループ回答を削除してください。|、-、-、-、-、-、-、-、-、-、-、-、--、>| 回答承認| <、-、-、-、-、-、-、-、-、-、-、-、--、|
GROUP EXAMPLE
Figure 16
グループ例の図16
An alternative method of adding and removing group members is the use of Add Group Member and Remove Group Member. These setup requests allow hosts that are already members of the group to add or delete other hosts.
グループのメンバーを加えて、免職する別法はAdd GroupメンバーとRemove Groupメンバーの使用です。 これらのセットアップ要求で、既にグループのメンバーであるホストは、他のホストを加えるか、または削除します。
The Setup requests Join Group, Leave Group, Add Group Member, Remove Group Member, and Delete Group are authenticated using the 48-bit key. Leave Group and Remove Group Member will remove a host from the group membership list but will not alter the existence of the group. Delete Group expunges all knowledge of the group from the network. HAP permits any host with the proper key to delete the group at any time. Thus, group addresses can be deleted even if the host which originally created the group has left the group or has crashed. Moreover, groups may exist for which there are currently no members
Setup要求のJoin Group、Leave Group、Add Groupメンバー、Remove Groupメンバー、およびDelete Groupは、48ビットのキーを使用することで認証されます。 Groupを残してください、Remove Groupメンバーは、グループ会員名簿からホストを免職しますが、グループの存在を変更しないでしょう。 Groupを削除してください。ネットワークからのグループに関するすべての知識を梢消します。 HAPは、適切なキーをもっているどんなホストもいつでもグループを削除するのを可能にします。 したがって、元々グループを創設したホストが仲間から抜けた、またはダウンしたとしても、グループアドレスを削除できます。 そのうえ、現在、メンバーが全くいないグループは存在するかもしれません。
Edmond [Page 34] RFC 1221 HAP2 April 1991
エドモンド[34ページ]RFC1221HAP2 April 1991
because each member has executed a Leave while none has executed a Delete. It is the responsibility of the hosts to coordinate and manage the use of group addresses.
なにもDeleteを実行していませんが、各メンバーがLeaveを実行したので。 グループアドレスの使用を調整して、管理するのは、ホストの責任です。
Note that group addresses, like all other resources allocated by the network, may be reclaimed by the network if unused for too long. Currently, if no traffic is sent to the group address in a 6 minute interval, the network may delete the group and notify all members that the group no longer exists.
あまりに長い間未使用であるならグループアドレスがネットワークによって割り当てられた他のすべてのリソースのようにネットワークによって取り戻されるかもしれないことに注意してください。 現在、6分の間隔のグループアドレスにトラフィックを全く送らないなら、ネットワークは、グループを削除して、グループがもう存在しないようにすべてのメンバーに通知するかもしれません。
The Create Group Request (Figure 17) is used to establish a multicast address. After the network has processed the Create Group Request, the Service Agent will respond by sending a Create Group Reply (Figure 18) to the host.
Create Group Request(図17)は、マルチキャストアドレスを証明するのに使用されます。 ネットワークがCreate Group Requestを処理した後に、Serviceエージェントは、Create Group Reply(図18)をホストに送ることによって、応じるでしょう。
A host may become a member of a group, once it knows the group address and the 48-bit key, by sending the Service Agent the Join Group Request message (Figure 19). The Service Agent will respond to the Join Group Request with a Join Group Reply (Figure 20). The host which creates a group automatically becomes a member of that group without any need for an explicit Join Group Request.
ホストはグループのメンバーになるかもしれません、いったんグループアドレスと48ビットのキーを知っていると、Join Group Requestメッセージ(図19)をServiceエージェントに送ることによって。 ServiceエージェントはJoin Group Reply(図20)と共にJoin Group Requestに応じるでしょう。 自動的にグループを創設するホストは明白なJoin Group Requestの少しも必要性なしでそのグループのメンバーになります。
A member host may add another host to the group by sending the Service Agent the Add Group Member Request message (Figure 21). The Service Agent will respond with an Add Group Member Reply (Figure 22).
メンバーホストは、Add GroupメンバーRequestメッセージ(図21)をServiceエージェントに送ることによって、別のホストをグループに追加するかもしれません。 ServiceエージェントはAdd GroupメンバーReply(図22)と共に応じるでしょう。
At any time after becoming a member of a group, a host may choose to drop out of the group. To do this, the host sends the Service Agent a Leave Group Request (Figure 23). The Service Agent will respond with a Leave Group Reply (Figure 24).
グループのメンバーになった後にいつでも、ホストは、グループを落第するのを選ぶかもしれません。 これをするために、ホストはLeave Group Request(図23)をServiceエージェントに送ります。 ServiceエージェントはLeave Group Reply(図24)と共に応じるでしょう。
One member host may expel another member of the group by sending the Service Agent the Remove Group Member Request message (Figure 25). The Service Agent will respond with a Remove Group Member Reply (Figure 26).
1人のメンバーホストが、Remove GroupメンバーRequestメッセージ(図25)をServiceエージェントに送ることによって、グループの別のメンバーを追放するかもしれません。 ServiceエージェントはRemove GroupメンバーReply(図26)と共に応じるでしょう。
A host can delete an existing group via a Delete Group Request (Figure 27). The Service Agent will respond with a Delete Group Reply (Figure 28). The Service Agent will also send the other members of the group, if any, a notification that the group has been deleted (see Section 6.3).
ホストはDelete Group Request(図27)を通して既存のグループを削除できます。 ServiceエージェントはDelete Group Reply(図28)と共に応じるでしょう。 また、Serviceエージェントはグループの他のメンバーを送るでしょう、もしあれば、グループが削除されたという(セクション6.3を見てください)通知。
Edmond [Page 35] RFC 1221 HAP2 April 1991
エドモンド[35ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 1 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CREATE GROUP REQUEST
Figure 17
グループ要求図17を創造してください。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 1 (Create Group).
S0[8-15]はタイプ=1を要求します(グループを創設してください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
CREATE GROUP REPLY
Figure 18
グループ回答図18を創造してください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
Edmond [Page 36] RFC 1221 HAP2 April 1991
エドモンド[36ページ]RFC1221HAP2 April 1991
S0[8-15] Reply Code.
S0[8-15]回答コード。
0 = Group created
8 = Network trouble
17 = Insufficient network resources
22 = Reply lost in network
0 = グループはネットワークで失われた不十分なネットワーク資源22=8=ネットワーク問題17=回答を作成しました。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-15] Group Address. This field contains the 16-bit
multicast address that any group member may use to
reach the other group members. Multicast addresses are
dynamically assigned by the network.
S3[0-15]はアドレスを分類します。 この分野はどんなグループのメンバーも他のグループのメンバーに届くのに使用するかもしれない16ビットのマルチキャストアドレスを含んでいます。 マルチキャストアドレスはネットワークによってダイナミックに割り当てられます。
S4-S6 Key. This field contains a 48-bit key assigned by the
network which is associated with the group address. It
must be provided for subsequent Join Group, Leave
Group, Add Group Member, Remove Group Member, and
Delete Group requests which reference the group
address.
S4-S6キー。 この分野はグループアドレスに関連しているネットワークによって割り当てられた48ビットのキーを含んでいます。 その後のJoin Groupにそれを提供しなければなりません、Leave Group、Add Groupメンバー、Remove Groupメンバー、そして、Delete Groupはグループが扱うどの参照を要求するか。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S7 | 0 | MGP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 3 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S7| 0 | MGP| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
JOIN GROUP REQUEST
Figure 19
グループ要求図19に加わってください。
Edmond [Page 37] RFC 1221 HAP2 April 1991
エドモンド[37ページ]RFC1221HAP2 April 1991
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 3 (Join Group).
S0[8-15]はタイプ=3を要求します(グループに加わってください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-15] Group Address. This is the group that the host wishes
to join. Upon successfully joining the group, the host
may send messages to the group and will receive
messages sent to the group when those messages have a
priority of MGP or higher.
S3[0-15]はアドレスを分類します。 これはホストが加わりたがっているグループです。 首尾よくグループに加わると、それらのメッセージにMGPか、より高いことの優先があるとき、ホストは、メッセージをグループに送るかもしれなくて、グループに送られたメッセージを受け取るでしょう。
S4-S6 Key. This is the key associated with the group
address.
S4-S6キー。 これはグループアドレスに関連しているキーです。
S7[0-13] Reserved. Must be zero.
予約されたS7[0-13]。 ゼロにならなければならなくなってください。
S7[14-15] Minimum group message priority. The host will not
receive messages sent to the group that have a message
priority less than MGP. Send another Join Group
Request message to change the minimum priority.
S7[14-15]の最小のグループメッセージ優先権。 ホストはMGPほどメッセージ優先を持っていないグループに送られたメッセージを受け取らないでしょう。 最小の優先権を変える別のJoin Group Requestメッセージを送ってください。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
JOIN GROUP REPLY
Figure 20
グループ回答図20に加わってください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code.
S0[8-15]回答コード。
2 = Host added to group
9 = Bad key
10 = Group address nonexistent
17 = Insufficient network resources
2 = 悪い主要な10=9を分類するために加えられたホスト=グループは不十分な実在しない17=ネットワーク資源を扱います。
Edmond [Page 38] RFC 1221 HAP2 April 1991
エドモンド[38ページ]RFC1221HAP2 April 1991
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 10 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S7 | HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 10 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S7| ホスト・アドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ADD GROUP MEMBER REQUEST
Figure 21
グループメンバー要求図21を加えてください。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 3 (Join Group).
S0[8-15]はタイプ=3を要求します(グループに加わってください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-15] Group Address. This is the group the host will join.
Upon successfully joining the group, the host may send
messages to the group and will receive messages sent to
the group by other hosts (the initial minimum priority
will be 0).
S3[0-15]はアドレスを分類します。 これはホストが加わるグループです。 首尾よくグループに加わると、ホストは、メッセージをグループに送るかもしれなくて、他のホストでグループに送られたメッセージを受け取るでしょう(初期の最小の優先権は0になるでしょう)。
S4-S6 Key. This is the key associated with the group
address.
S4-S6キー。 これはグループアドレスに関連しているキーです。
S7[0-15] Host address. The network address of the host to add
S7[0-15]はアドレスをホスティングします。 加えるホストのネットワーク・アドレス
Edmond [Page 39] RFC 1221 HAP2 April 1991
エドモンド[39ページ]RFC1221HAP2 April 1991
to the group.
グループに。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
ADD GROUP MEMBER REPLY
Figure 22
グループメンバー回答図22を加えてください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code.
S0[8-15]回答コード。
2 = Host added to group (or was already a member)
9 = Bad key
10 = Group address nonexistent
11 = Requestor is not a member of the group
17 = Insufficient network resources
22 = Reply lost in network
24 = Host address was invalid
2 ネットワーク24=ホスト・アドレスで失われた不十分なネットワーク資源22=ホストがグループアドレス実在しない11=悪い主要な9=10=要請者を分類する(または、既にメンバーであった)ためにグループ17のメンバーでないと言い足した==回答は無効でした。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
Edmond [Page 40] RFC 1221 HAP2 April 1991
エドモンド[40ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 4 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LEAVE GROUP REQUEST
Figure 23
グループ要求図23を残してください。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 4 (Leave Group).
S0[8-15]はタイプ=4を要求します(グループを出てください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-15] Group Address. This is the group that the host wishes
to cease being a member of. After leaving the group,
the host will cease receiving messages sent to the
group and will be unable to send to the group.
S3[0-15]はアドレスを分類します。 これはホストがメンバーであることをやめたがっているグループです。 仲間から抜けた後に、ホストは、グループに送られたメッセージを受け取りながらやんで、グループに発信できないでしょう。
S4-S6 Key. This is the key associated with the group
address.
S4-S6キー。 これはグループアドレスに関連しているキーです。
Edmond [Page 41] RFC 1221 HAP2 April 1991
エドモンド[41ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LEAVE GROUP REPLY
Figure 24
グループ回答図24を残してください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code.
S0[8-15]回答コード。
3 = Host deleted from group
9 = Bad key
10 = Invalid group address
11 = Not member of group
17 = Insufficient network resources
3 = 無効のグループ悪い主要なグループ9から削除されたホスト=10=アドレス11は不十分なグループ17=ネットワーク資源のどんなメンバーとも等しくはありません。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
Edmond [Page 42] RFC 1221 HAP2 April 1991
エドモンド[42ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 11 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S7 | HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 11 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S7| ホスト・アドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
REMOVE GROUP MEMBER REQUEST
Figure 25
グループメンバー要求図25を外してください。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 4 (Leave Group).
S0[8-15]はタイプ=4を要求します(グループを出てください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-15] Group Address. This is the group from which the host
should be removed. After leaving the group, that host
will cease receiving messages sent to the group and
will be unable to send to the group.
S3[0-15]はアドレスを分類します。 これはホストが免職されるべきであるグループです。 仲間から抜けた後に、そのホストは、グループに送られたメッセージを受け取りながらやんで、グループに発信できないでしょう。
S4-S6 Key. This is the key associated with the group
address.
S4-S6キー。 これはグループアドレスに関連しているキーです。
S7[0-15] Host address. The network address of the host to
remove from the group.
S7[0-15]はアドレスをホスティングします。 グループから免職するホストのネットワーク・アドレス。
Edmond [Page 43] RFC 1221 HAP2 April 1991
エドモンド[43ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
REMOVE GROUP MEMBER REPLY
Figure 26
グループメンバー回答図26を外してください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code.
S0[8-15]回答コード。
3 = Host deleted from group (or was not a member)
9 = Bad key
10 = Invalid group address
11 = Requestor is not a member of the group
17 = Insufficient network resources
22 = Reply lost in network
24 = Host address was invalid
3 = 無効のグループアドレス11=悪い主要なグループ(または、メンバーでなかった)9=10=要請者から削除されたホストはネットワーク24で失われた不十分なネットワーク資源22=グループ17のメンバー=回答=ホスト・アドレスが無効であったということではありません。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
Edmond [Page 44] RFC 1221 HAP2 April 1991
エドモンド[44ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 1 | 2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S4 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S5 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S6 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 1 | 2 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S4| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S5| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S6| キー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE GROUP REQUEST
Figure 27
グループ要求図27を削除してください。
S0[0-7] Setup Type = 1 (Request).
S0[0-7]はタイプ=1(要求します)をセットアップします。
S0[8-15] Request Type = 2 (Delete Group).
S0[8-15]はタイプ=2を要求します(グループを削除してください)。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
S3[0-15] Group Address. This is the multicast address to
delete. If the group is deleted, the other remaining
members of the group, if any, will be notified of the
group's deletion.
S3[0-15]はアドレスを分類します。 これは削除するマルチキャストアドレスです。 グループが削除されると、もしあればグループの他の残っているメンバーはグループの削除について通知されるでしょう。
S4-S6 Key.
S4-S6キー。
Edmond [Page 45] RFC 1221 HAP2 April 1991
エドモンド[45ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 2 | 回答コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| セットアップチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| IDを要求してください。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DELETE GROUP REPLY
Figure 28
グループ回答図28を削除してください。
S0[0-7] Setup Type = 2 (Reply).
S0[0-7]はタイプ=2(回答)をセットアップします。
S0[8-15] Reply Code.
S0[8-15]回答コード。
1 = Group deleted
8 = Network trouble
9 = Bad key
10 = Invalid group address
17 = Insufficient network resources
22 = Reply lost in network
1 = グループはネットワークで失われた不十分なネットワーク資源22=無効のグループ悪い主要な8=ネットワーク問題9=10=アドレス17=回答を削除しました。
S1[0-15] Setup Checksum. (See setup header description.)
S1[0-15]はチェックサムをセットアップします。 (セットアップヘッダ記述を見てください。)
S2[0-15] Request ID.
S2[0-15]はIDを要求します。
6.3. Notifications
6.3. 通知
Notifications are Setup exchanges initiated by the WPS to inform a host of changes in the status of a network resource. The format of Notification messages is shown in Figure 29.
通知はネットワーク資源の状態の多くの変化を知らせるためにWPSによって起こされたSetup交換です。 Notificationメッセージの書式は図29に示されます。
Edmond [Page 46] RFC 1221 HAP2 April 1991
エドモンド[46ページ]RFC1221HAP2 April 1991
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 3 | CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | NOTIFICATION ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | NOTIFICATION INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 3 | コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| チェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| 通知ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| 通知インフォメーション| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NOTIFICATION MESSAGE
Figure 29
通知メッセージ図29
S0[0-7] Message Type = 3 (Notification).
S0[0-7]メッセージタイプは3(通知)と等しいです。
S0[8-15] Code. This indicates what the Notification signifies.
S0[8-15]コード。 これはNotificationが意味することを示します。
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by a host
4 = Group deleted by network
5 = All streams deleted
6 = All groups deleted
7 = Group changed by a host
8 = Group changed by network
0 = 削除された3=グループが4=グループがネットワーク5で削除したホストで削除した再開している2=ストリーム=すべてが流す1つのストリーム吊した=ストリームが削除された7=グループがネットワークによって変えられたホスト8=グループで変えたすべての6=グループを削除しました。
S1[0-15] Checksum. (See Service Agent Header description.)
S1[0-15]チェックサム。 (ServiceエージェントHeader記述を見てください。)
S2[0-15] Notification ID.
S2[0-15]Notification ID。
S3[0-15] Notification Information.
S3[0-15]通知情報。
For notification types 0, 1, and 2, NOTIFICATION INFO
contains the following:
通知タイプ0、1、および2のために、NOTIFICATION INFOは以下を含んでいます:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | 0 | stream ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| 0 | ストリームID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
For notification types 3, 4, 7, and 8, NOTIFICATION
INFO contains the following:
通知タイプ3、4、7、および8のために、NOTIFICATION INFOは以下を含んでいます:
Edmond [Page 47] RFC 1221 HAP2 April 1991
エドモンド[47ページ]RFC1221HAP2 April 1991
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | group address |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
For notification types 5 and 6, which refer to all
streams or groups, NOTIFICATION INFO is zero.
通知タイプ5と6において、NOTIFICATION INFOはゼロです。(タイプはすべてのストリームかグループを参照します)。
6.4. Setup Acknowledgments
6.4. セットアップ承認
The host must acknowledge receipt of Setup Replies and Notifications from the Service Agent, as described earlier. The format for the Setup Acknowledgment message is shown in Figure 30.
ホストは、より早く説明されるようにServiceエージェントからSetup RepliesとNotificationsの領収書を受け取ったことを知らせなければなりません。 Setup Acknowledgmentメッセージのための書式は図30に示されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 0 | CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | MESSAGE ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 0 | コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| チェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| メッセージID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
SETUP ACKNOWLEDGMENT
Figure 30
セットアップ承認図30
S0[0-7] Message Type = 0 (Acknowledgment).
S0[0-7]メッセージタイプは0(承認)と等しいです。
S0[8-15] Code. This field indicates the type of acknowledgment.
S0[8-15]コード。 この分野は承認のタイプを示します。
0 = Reply acknowledgment
1 = Notification acknowledgment
0 = 回答承認1は通知承認と等しいです。
S1[0-15] Checksum. (See Service Agent Header description.)
S1[0-15]チェックサム。 (ServiceエージェントHeader記述を見てください。)
S2[0-15] Message ID. This is either a Request ID or a
Notification ID.
S2[0-15]Message ID。 これは、Request IDかNotification IDのどちらかです。
6.5. Information Request / Reply Messages
6.5. 情報要求/応答メッセージ
The host may obtain information about WPS state and about what resources the WPS currently has allocated for the host by sending an Information Request message to the Service Agent. The Information Reply that is returned will enable the host to determine 1) what
ホストは、情報RequestメッセージをServiceエージェントに送ることによって、WPS状態とWPSが現在ホストのためにどんなリソースを割り当てたかの情報を得るかもしれません。 返される情報Replyが、ホストが1を)決定するのを可能にする、何
Edmond [Page 48] RFC 1221 HAP2 April 1991
エドモンド[48ページ]RFC1221HAP2 April 1991
resources the WPS has allocated to the host, and 2) the current state of the network and, possibly, certain network parameters. This allows the host to refrain from trying to use resources it no longer has, and to regain information it may have lost on its network resources. This communication also informs the host of the network state so that it may make priority and routing decisions.
WPSがホスト、および2に割り当てたリソース) ネットワークの、そして、ことによるとある回路パラメータの現状。 これで、ホストは、それがもう持っていないリソースを使用して、それがネットワーク資源の上に失ったかもしれない情報を取り戻そうとするのを控えることができます。 また、このコミュニケーションは、優先権とルーティングを決定にすることができるように、ネットワーク状態についてホストに知らせます。
Each Information Request (Figure 31) and Information Reply (Figure 32) message deals with a single type of resource at a time. The header of the Information Reply message contains the number of entries within the message, the number of 16-bit words in each entry, and an instance of the appropriate information structure for each resource the Information Reply message describes. These information structures are described in Figures 33 and 34.
それぞれの情報Request(図31)と情報Reply(図32)メッセージは一度に、単独のタイプに関するリソースに対処します。 情報Replyメッセージのヘッダーはメッセージの中のエントリーの数、各エントリーにおける、16ビットの単語の数、および情報Replyメッセージが説明する各リソースのための適切な情報構造のインスタンスを含んでいます。 これらの情報構造は図33と34で説明されます。
Future versions of the HAP protocol may permit queries about network connectivity, estimated delay to a specified destination address under specified conditions, etc. This is a section of the protocol that is likely to expand in the future. Extensions are expected to be backward compatible provided implementors do not hard code the size of the returned information entries.
HAPプロトコルの将来のバージョンはネットワークの接続性、指定された状態の指定された送付先アドレスへのおよそ遅れなどに関して質問を可能にするかもしれません。 これは将来広がりそうなプロトコルのセクションです。 拡大は遅れているコンパチブル提供された作成者が返された情報エントリーのサイズをどんな困難なコードにもしないということであると予想されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 4 | CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | MESSAGE ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 4 | コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| チェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| メッセージID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
INFORMATION REQUEST MESSAGE
Figure 31
情報要求メッセージ図31
S0[0-7] Message type = 4 (Information Request).
S0[0-7]メッセージタイプ=4(情報Request)。
S0[8-15] Code. This field identifies the Information Request
Type.
S0[8-15]コード。 この分野は情報Request Typeを特定します。
1 = streams owned by host
2 = groups to which the host belongs
1 = ホスト2によって所有されていたストリームはホストが属するグループと等しいです。
S1[0-15] Checksum. (See Service Agent Header description.)
S1[0-15]チェックサム。 (ServiceエージェントHeader記述を見てください。)
Edmond [Page 49] RFC 1221 HAP2 April 1991
エドモンド[49ページ]RFC1221HAP2 April 1991
S2[0-15] Message ID. This field is assigned by the host to
uniquely identify outstanding requests (Request ID).
This ID is copied into Information Replies by the
Service Agent.
S2[0-15]Message ID。 この分野は、唯一、傑出している要求(IDを要求する)を特定するためにホストによって割り当てられます。 このIDはServiceエージェントによって情報Repliesにコピーされます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S0 | 5 | CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S1 | CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S2 | MESSAGE ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
S3 | NUMBER OF ENTRIES | WORDS PER ENTRY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
S4-SN : ENTRIES (0 or more) :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9、10 11 12 13 14 15、+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S0| 5 | コード| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S1| チェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S2| メッセージID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ S3| エントリーの数| 1エントリーあたりの単語| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | S4-SN: ENTRIES(0以上): | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
INFORMATION REPLY MESSAGE
Figure 32
情報応答メッセージ図32
S0[0-7] Message type = 5 (Information Reply).
S0[0-7]メッセージタイプ=5(情報Reply)。
S0[8-15] Code. This field identifies the Information Reply
Type.
S0[8-15]コード。 この分野は情報Reply Typeを特定します。
1 = streams owned by host
2 = groups to which the host belongs
3 = error in Information Request message
4 = network trouble
5 = access not allowed
1がストリームと等しい、ホストが属するホスト2=グループによって所有されていて、情報Requestメッセージ4における3=誤りは5=アクセスが許容しなかったネットワーク問題と等しいです。
S1[0-15] Checksum. (See Service Agent Header description.)
S1[0-15]チェックサム。 (ServiceエージェントHeader記述を見てください。)
S2[0-15] Message ID. This field is assigned by the host in the
Information Request message to uniquely identify
outstanding requests. This ID is copied into the
Information Reply message by the Service Agent.
S2[0-15]Message ID。 この分野は唯一傑出している要求を特定する情報Requestメッセージのホストによって割り当てられます。 このIDはServiceエージェントによって情報Replyメッセージにコピーされます。
S3[0-7] Number of entries included in the Information Reply
message.
情報ReplyメッセージにエントリーのS3[0-7]番号を含んでいます。
Edmond [Page 50] RFC 1221 HAP2 April 1991
エドモンド[50ページ]RFC1221HAP2 April 1991
S3[8-15] Number of 16-bit words per entry.
1エントリーあたりの16ビットの単語のS3[8-15]番号。
S4-SN Zero or more instances of either the stream information
or group information structure.
ストリーム情報かグループ情報構造のS4-SN Zeroか、より多くのインスタンス。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0 | STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | STREAM TYPE OF SERVICE WORD |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | STREAM SIZE (bits per interval) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | STREAM INTERVAL (in units of 0.125 ms.) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 0 | ストリームID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | サービスWordのストリーム型| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | STREAM SIZE(1間隔あたりのビット)| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | STREAM INTERVAL(ユニットの0.125原稿の) | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
STREAM INFORMATION
Figure 33
ストリーム情報図33
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | 0 | MGP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | グループアドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | 0 | MGP| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
GROUP INFORMATION
Figure 34
グループ情報図34
7. Host Access Link Monitoring
7. ホストアクセスリンクモニター
While the access link is operating, statistics on traffic load and error rate are maintained by the host and WPS. Once a second, the host and WPS exchange this information via Status messages (Figure 35). This periodic exchange of Status messages permits both ends of the link to monitor flows in both directions. The WPS also reports these monitoring statistics to the Network Operations Center (NOC). If either host or WPS fails to receive Status messages for ten seconds, the link will be restarted (see Section 8).
アクセスリンクが作動している間、トラヒック負荷と誤り率における統計はホストとWPSによって維持されます。Statusメッセージ(図35)で1秒に一度、ホストとWPSはこの情報を交換します。 Statusメッセージのこの周期的な交換は、リンクの両端が両方の方向の流れをモニターすることを許可します。 また、WPSはネットワーク運営センター(NOC)にこれらのモニターしている統計を報告します。 ホストかWPSのどちらかが10秒間、Statusメッセージを受け取らないと、リンクは再開されるでしょう(セクション8を見てください)。
Edmond [Page 51] RFC 1221 HAP2 April 1991
エドモンド[51ページ]RFC1221HAP2 April 1991
The link restart procedure initializes all internal WPS counts and statistics for that link to zero. As data and control messages are processed, counts are updated to reflect the total number of messages sent, messages received correctly, and messages received with different classes of errors since the last link restart. Whenever a Status message arrives, a snapshot is taken of the local WPS counts. The local receive counts, in conjunction with a sent count contained in the received Status message, permits the computation of traffic statistics in the one second update interval assuming that the set of counts at the time of the previous monitoring report have been saved. By including in the Status message sent (in the opposite direction) the receive counts and the received sent count that was used with them, the transmitting end of the access link as well as the receiving end can determine the link performance from sender to receiver.
リンク再開手順はすべての内部のWPSカウントを初期化します、そして、それのための統計はゼロにリンクされます。 データとコントロールメッセージを処理するとき、送られたメッセージの総数を反映するためにカウントをアップデートしました、そして、メッセージは正しく受信されました、そして、最後のリンク再開以来メッセージは異なったクラスの誤りで受信されました。 Statusメッセージが到着するときはいつも、地方のWPSカウントについてスナップを取ります。 地方は受信されたStatusメッセージに含まれた送られたカウントに関連してカウントを受けて、許可証は前のモニタリング報告書時点のカウントのセットが節約されたと仮定するアップデートの2分の1つの間隔でのトラフィック統計の計算です。 メッセージが送った(逆方向に)Statusが包含する、カウントとそれらと共に使用された、容認された送られたカウント、アクセスリンクの送信側を犠牲者が送付者から受信機までのリンク性能を決定できるのと同じくらいよく得てください。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | MOST RECENT A/R SENT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | STREAM CAPACITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | TIMESTAMP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SBU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | STU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | RNE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | RWE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | BHC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | HEI |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| 0 | 0 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 最新のA/Rは発信しました。| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | ストリーム容量| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4 | タイムスタンプ| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5 | SBU| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6 | スチュー| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 7 | RNE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 8 | RWE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 9 | BHC| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 10 | HEI| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
STATUS MESSAGE
Figure 35
ステータスメッセージ図35
Edmond [Page 52] RFC 1221 HAP2 April 1991
エドモンド[52ページ]RFC1221HAP2 April 1991
0[0] Message Class = 1 (Control Message).
0[0]メッセージのクラス=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-3] Go-Priority.
0[2-3]碁優先権。
0[4-11] Reserved. Must be zero.
予約された0[4-11]。 ゼロにならなければならなくなってください。
0[12-15] Control Message Type = 0 (Status).
0[12-15]コントロールメッセージタイプは0(状態)と等しいです。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-10 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-10(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2[0-15] Most Recent A/R Sent. This field is a duplicate of the
most recent acceptance/refusal word. It is included in
the periodic Status message in case previous
transmissions containing A/R information were lost.
2[0-15]の最新のA/Rは発信しました。 この分野は最新の承認/拒否単語の写しです。 A/R情報を含む前のトランスミッションが失われるといけなかったので、それは周期的なStatusメッセージに含まれています。
3[0-15] Stream Capacity. When sent by the WPS, this field
indicates how much stream capacity is unused, in units
of data bits per millisecond. There is no guarantee
that a request for a stream of this size will succeed.
Since available capacity depends directly on a variety
of parameters that can be selected by the user, the
value of this field is the maximum capacity that could
be achieved if existing streams were expanded at low
reliability. This field is not meaningful in messages
sent from the host to the WPS and must be set to zero.
3[0-15]流れの容量。 WPSによって送られると、この分野は、どのくらいの流れの容量が未使用であるかを示します、1ミリセカンドあたりのユニットのデータ・ビットで。 このサイズの流れを求める要求が成功するという保証が全くありません。 有効な容量が直接ユーザが選択できるさまざまなパラメタによるので、この分野の値は既存の流れが低信頼性で膨張するなら達成できる最大能力です。 この分野をホストからWPSに送られたメッセージで重要でなく、ゼロに設定しなければなりません。
4[0-15] Timestamp. This field indicates the time that the
Status message was generated. When sent by a WPS, the
time is in units of seconds since the last link
restart. The host should also timestamp its messages
in units of seconds.
4[0-15]タイムスタンプ。 この分野はStatusメッセージが発生した時間を示します。 WPSによって送られると、ユニットの秒に、最後のリンク再開以来時間があります。 また、ホストがそうするべきである、タイムスタンプ、ユニットの秒のそのメッセージ。
5[0-15] Sent By Us. Count of messages sent by us since the
last link restart (not including this one).
5[0-15]は私たちで発信しました。 最後のリンク再開(これを含んでいない)以来私たちによって送られたメッセージのカウント。
6[0-15] Sent To Us. Count of messages sent to us since the
last link restart. This is the count from word 5 of
the last Status message received.
6[0-15]は私たちに発信しました。 最後のリンク再開以来メッセージのカウントは私たちに発信しました。 これは最後の5つのStatusメッセージが受け取った言葉からのカウントです。
7[0-15] Received, No Errors. This is the count of messages
received without errors (since the last link restart)
at the time that the last Status message was received.
受け取られていている7[0-15]いいえ誤り。 これは最後のStatusメッセージを受け取ったという当時誤り(最後のリンク再開以来の)なしで受け取られたメッセージのカウントです。
8[0-15] Received With Errors. This is the count of messages
8[0-15]は誤りで受信されました。 これはメッセージのカウントです。
Edmond [Page 53] RFC 1221 HAP2 April 1991
エドモンド[53ページ]RFC1221HAP2 April 1991
received with errors (since the last link restart) at
the time the last Status message was received.
最後のStatusメッセージを受け取ったときの誤り(最後のリンク再開以来の)で、受け取られています。
9[0-15] Bad Header Checksums. This is the count of messages
received with bad header checksums (since the last link
restart) at the time the last Status message was
received.
9[0-15]の悪いHeader Checksumsこれは最後のStatusメッセージを受け取ったとき悪いヘッダーチェックサム(最後のリンク再開以来の)で受け取るメッセージのカウントです。
10[0-15] Hardware Error Indication. This is the count of
messages received with hardware CRC errors or hardware
interface error indications (since the last link
restart) at the time the last Status message was
received.
10[0-15]ハードウェア誤り表示。 これは最後のStatusメッセージを受け取ったときハードウェアCRC誤りかハードウェア・インタフェース誤り指摘(最後のリンク再開以来の)で受け取るメッセージのカウントです。
8. Initialization
8. 初期設定
The Host Access Protocol uses a number of state variables that must be initialized in order to function properly. These variables are associated with the send and receive message numbers used by the acceptance/refusal mechanism and the statistics maintained to support link monitoring. Link initialization should be carried out when a machine is initially powered up, when it does a system restart, when the ON state (see below) times out, when a loopback condition times out (see Section 9), or whenever the link transitions from non- operational to operational status.
Host Accessプロトコルは適切に機能するように初期化しなければならない多くの州の変数を使用します。 これらの変数が関連している、承認/拒否メカニズムによって使用されるメッセージ番号とリンクモニターを支持するために維持された統計を、送って、受け取ってください。 マシンが初めは上に動かされるとき、リンク初期化が行われるべきです、システムリスタートをすると、ループバック状態回のアウト(セクション9を見る)であるときに、ONが外に回を述べるか(以下を見ます)、リンクが非操作上から操作上の状態に移行するときはいつも。
Initialization is accomplished by the exchange of Restart Request (RR) and Restart Complete (RC) messages between a host and a WPS. Either end (or both ends) may send an initial RR, and both ends must have sent and received an RC message in order to declare the link up. Because the RC message is a reply (to an RR or RC), receipt of an RC message by both ends guarantees that the physical link is operating in both directions. The initialization state diagram that must be implemented by both WPS and host is shown in Figure 36. Five states are identified in the state diagram:
初期設定はホストとWPSの間のRestart Request(RR)とRestart Complete(RC)メッセージの交換で実行されます。どちらの終わり(または、両端)も初期のRRを送るかもしれなくて、両端は、上にリンクを申告するためにRCメッセージを送って、受け取ったに違いありません。 RCメッセージが回答(RRかRCへの)であるので、両端のそばのRCメッセージの領収書は、物理的なリンクが両方の方向に作動しているのを保証します。 WPSとホストの両方で実行しなければならない初期化州のダイヤグラムは図36で見せられます。 5つの州が州のダイヤグラムで特定されます:
OFF Entered upon recognition of a requirement to restart.
The interface in the Host or WPS can recognize this
requirement itself or be forced to restart by receipt
of an RR message from the other end while in the ON
state.
再開するという要件の認識でのOFF Entered。 ON状態にある間、HostかWPSのインタフェースは、この要件自体を認めるか、またはもう一方の端からのRRメッセージの領収書でやむを得ず再開できます。
INIT Local state variables have been initialized but no RC
messages have yet been sent or received. If receipt of
an RR initiated the restart, or if an RR has been
received since this restart began, send an RC
(optional, reduces startup time). Otherwise, send an
RR to alert the other end of the restart.
INIT Local州の変数が初期化されましたが、まだRCメッセージを全く送りもしませんし、受け取ってもいません。 RRの領収書が再開を開始したか、またはこの再開が始まって以来RRを受け取っているなら、RCを送ってください、(任意である、始動時間を減少させる、) さもなければ、RRを送って、再開のもう一方の端を警告してください。
Edmond [Page 54] RFC 1221 HAP2 April 1991
エドモンド[54ページ]RFC1221HAP2 April 1991
RR-SNT A request to reinitialize (RR) has been sent to the
other end, but no RR or RC messages have been received.
再初期化するというRR-シンニッタンのA要求(RR)をもう一方の端にもかかわらず、どんなRRにも送らないか、またはRCメッセージを受け取りました。
RC-SNT An RC has been sent to the other end in response to an
RR. The interface is waiting to receive an RC.
RRに対応してRC-シンニッタンAn RCをもう一方の端に送りました。 インタフェースは、RCを受け取るのを待っています。
ON RC messages have been both sent and received. Local
counters have been zeroed. Data and control messages
can now be exchanged between the WPS and host.
ON RCメッセージを送って、受け取りました。 地方のカウンタのゼロは合わせられました。 現在、WPSとホストの間でデータとコントロールメッセージを交換できます。
All states have 10-second timeouts (not illustrated) which return the protocol to the OFF state. The occurrence of any events other than those indicated in the diagram are ignored.
すべての州には、OFF状態にプロトコルを返す10秒のタイムアウト(例証されない)があります。 ダイヤグラムで、無視されますそれら以外のどんな出来事の発生も、示した。
Edmond [Page 55] RFC 1221 HAP2 April 1991
エドモンド[55ページ]RFC1221HAP2 April 1991
.-----.
Any Timeout or ----->| OFF |<----------------------------+
Device Down `--+--' |
| |
| (When I/O Device Up) |
V |
.-------. |
| INIT | |
`---+---' |
| |
(Yes) V (No) |
+---------RR Received?----------+ |
| | |
| Send RR |
| | |
| V |
| .--------. |
Send RC <-----+-------<--------+ RR-SNT | |
| | (Rcv RR) `---+----' |
| | | (Rcv RC) |
V | | |
.--------. | | |
| RC-SNT +--->--+ Send RC |
`----+---' (Rcv RR) | |
(Rcv RC) | | |
| | |
+------->------+-------<--------+ |
| |
Initialize Status Counters |
| |
V |
.-----. Rcv RR or |
Rcv Any +----->| ON +---------------------->------+
Other | `--+--' Fail to Rcv Status message
+---------+ for 10 seconds
.-----. またはどんなタイムアウト、も。----->| オフ| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ 装置下('--+--')| | | | (入出力装置が上昇すると) | V| .-------. | | イニット| | `---+---' | | | (はい) V(いいえ)| +---------受け取られたRR?----------+ | | | | | RRを送ってください。| | | | | V| | .--------. | RC<を送ってください。-----+-------<、-、-、-、-、-、-、--+ RR-シンニッタン| | | | (Rcv RR) `---+----' | | | | (Rcv RC) | V| | | .--------. | | | | RC-シンニッタン+--->--+はRCを送ります。| `----+---'(Rcv RR)'| | (Rcv RC) | | | | | | +------->、-、-、-、-、--+-------<、-、-、-、-、-、-、--+ | | | 状態カウンタを初期化してください。| | | V| .-----. またはRcv RR。| Rcvはあらゆる+です。----->| +に関して---------------------->、-、-、-、-、--+他です。| '--+--'Rcv Statusメッセージ+に失敗してください。---------+ 10秒間
HAP LINK RESTART STATE DIAGRAM
Figure 36
機会リンク再開州のダイヤグラムの数値36
The Restart Request control message (Figure 37) is sent by either a host or a WPS when it wishes to restart a link. The Restart Request causes all the monitoring statistics reported in the Status Message to be reset to zero and stops all traffic on the link in both directions. The Restart Complete message (Figure 38) is sent in response to a received Restart Request or Restart Complete to complete link initialization. The Restart Complete carries a field used by the host to enable or disable the acceptance/refusal
それがリンクを再開したがっているとき、Restart Requestコントロールメッセージ(図37)はホストかWPSのどちらかによって送られます。 Restart RequestはStatus Messageでゼロにリセットされると報告されたすべてのモニターしている統計を引き起こして、リンクにおけるすべての通行を両方の方向に止めます。 リンク初期化を終了するために、容認されたRestart RequestかRestart Completeに対応してRestart Completeメッセージ(図38)を送ります。 Restart Completeは承認/拒否を可能にするか、または無効にするのにホストによって使用された野原を運びます。
Edmond [Page 56] RFC 1221 HAP2 April 1991
エドモンド[56ページ]RFC1221HAP2 April 1991
mechanism for the link being restarted (see Section 5). After the Restart Complete is processed, traffic may flow on the link.
再開される(セクション5を見ます)リンクへのメカニズム。 Restart Completeが処理された後に、交通はリンクの上に流れるかもしれません。
The allocation and state of network resources (streams and groups) are separate from the state of the host's access link(s) to the WPS. The Information Request message (see Section 6.5) may be used by a host to determine what resources it has. If the "SL" bit is set in the Restart Complete message from the WPS, and if the host believes it has resources allocated to it, the host is strongly encouraged to use an Information Request to verify that it still has its resources.
配分とネットワークの状態リソース(流れとグループ)はホストのアクセスリンクの状態からWPSまで別々です。情報Requestメッセージ(セクション6.5を見る)は、それがどんなリソースを持っているかを決定するのにホストによって使用されるかもしれません。 "SL"ビットがWPSからの再開の完全なメッセージに設定されて、ホストが、それでリソースをそれに割り当てると信じているなら、ホストがそれにはリソースがまだあることを確かめるという情報要求を使用するよう強く奨励されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| 0 |VERSION | 0 | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb| 0 |バージョン| 0 | 3 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | ホスト・アドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | リンク番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
RESTART REQUEST
Figure 37
再開要求図37
0[0] Message Type = 1 (Control Message).
0[0]メッセージタイプ=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-4] Reserved. Must be zero.
予約された0[2-4]。 ゼロにならなければならなくなってください。
0[5-7] HAP version number. Use 1. Use of zero invokes
backward compatibility code (see Appendix B).
0[5-7] HAPバージョン番号。 1を使用してください。 ゼロの使用は後方の互換性コードを呼び出します(Appendix Bを見てください)。
0[8-11] Reserved. Must be zero.
予約された0[8-11]。 ゼロにならなければならなくなってください。
0[12-15] Control Message Type = 3 (Restart Request).
0[12-15]コントロールメッセージタイプ=3(再開要求)。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-3 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-3(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2[0-15] Host Address. The WPS inserts the primary network
address of the host. The host may insert any of its
2[0-15]ホスト・アドレス。 WPSはホストの第一のネットワーク・アドレスを挿入します。 ホストがいずれも挿入するかもしれない、それ
Edmond [Page 57] RFC 1221 HAP2 April 1991
エドモンド[57ページ]RFC1221HAP2 April 1991
network addresses in this field (hosts may have more
than one logical address per physical port). The WPS
will only bring up the HAP link if the host address is
valid for the port being used.
この分野でアドレスをネットワークでつないでください(ホストには、物理的なポートあたり1つ以上の論理アドレスがあるかもしれません)。 使用されるポートに、ホスト・アドレスが有効である場合にだけ、WPSはHAPリンクを持って来るでしょう。
3[0-15] Link Number. This field contains the sender's
identification of the physical link being used. This
information is used to identify the link when reporting
errors to the Network Operations Center (NOC).
3[0-15]リンク番号。 この分野は送付者の使用される物理的なリンクの識別を含んでいます。 この情報は、ネットワーク運営センター(NOC)に誤りを報告するとき、リンクを特定するのに使用されます。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| 0 |VERSION | 0 |SL|AR| 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb| 0 |バージョン| 0 |SL|アルゴン| 4 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | ホスト・アドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | リンク番号| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
RESTART COMPLETE
Figure 38
完全な図38を再出発してください。
0[0] Message Type = 1 (Control Message).
0[0]メッセージタイプ=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-4] Reserved. Must be zero.
予約された0[2-4]。 ゼロにならなければならなくなってください。
0[5-7] HAP version number. Use 1. Use of zero invokes
backward compatibility code (see Appendix B).
0[5-7] HAPバージョン番号。 1を使用してください。 ゼロの使用は後方の互換性コードを呼び出します(Appendix Bを見てください)。
0[8-9] Reserved. Must be zero.
予約された0[8-9]。 ゼロにならなければならなくなってください。
0[10] Service loss alert (boolean) (WPS to host only; host
must send zero). If the WPS has any reason to believe
that the resources allocated to the host may not match
what the host believes is allocated, SL is set to one.
If SL is one, a host that believes it owns any resources
is strongly encouraged to use an Information Request to
verify that the resources are still allocated. SL will
be one the first time a link is brought up after a WPS
is restarted, and may be set in other cases.
0[10]サービス損失警戒(論理演算子)(ホストだけ; ホストへのWPSはゼロを送らなければなりません)。 WPSに何かホストに割り当てられたリソースが割り当てられるホストが信じていることに合わないかもしれないと信じる理由があるなら、SLは1つに用意ができています。 SLが1歳であるなら、所有しているそれがどんなリソースもそれに信じているホストがリソースがまだ割り当てられていることを確かめるのに情報Requestを使用するよう強く奨励されます。 リンクが初めて持って来られるとき、WPSが再開されて、他の場合で用意ができたかもしれない後にSLは1歳になるでしょう。
Edmond [Page 58] RFC 1221 HAP2 April 1991
エドモンド[58ページ]RFC1221HAP2 April 1991
0[11] Acceptance/Refusal Control. This bit is used by the
host to enable or disable the acceptance/refusal
mechanism for all traffic on the link.
0[11]承認/拒否コントロール。 このビットは、リンクにおけるすべての交通への承認/拒否メカニズムを可能にするか、または無効にするのにホストによって使用されます。
0 = Disable acceptance/refusal
1 = Enable acceptance/refusal
=が無効にする0、承認/拒否1=は承認/拒否を可能にします。
0[12-15] Control Message Type = 4 (Restart Complete).
0[12-15]コントロールメッセージタイプ=4(完全な状態で、再開します)。
1[0-15] Header Checksum. Covers words 0-3.
1[0-15]ヘッダーチェックサム。 単語0-3をカバーしています。
2[0-15] Host Address.
2[0-15]ホスト・アドレス。
3[0-15] Link Number.
3[0-15]リンク番号。
9. Loopback Control
9. ループバックコントロール
The Host Access Protocol provides a Loopback Request control message which can be used by a WPS or a host to request the remote loopback of its HAP messages. Such requests are usually the result of operator intervention for purposes of system fault diagnosis. For clarity in the following discussion, the unit (WPS or host) requesting the remote loopback is referred to as the "transmitter" and the unit implementing (or rejecting) the loopback is referred to as the "receiver".
Host AccessプロトコルはWPSかホストがHAPメッセージのリモートループバックを要求するのに使用できるLoopback Requestコントロールメッセージを提供します。 通常、そのような要求はシステム欠点診断の目的のためのオペレータ介入の結果です。 以下の議論における明快において、リモートループバックを要求するユニット(WPSかホスト)は「送信機」と呼ばれます、そして、ループバックを実行する(または、拒絶)ユニットは「受信機」と呼ばれます。
When the host access link is remotely looped, all HAP messages will be returned, unmodified, over the access link by the receiver. (Messages that are too long to be valid HAP messages may be discarded instead of being returned.) The receiver will not send any of its own messages to the transmitter while it is implementing the loop. WPS-generated messages are distinguished from host-generated messages by means of the Loopback indicator that is in every HAP message header.
ホストアクセスリンクを離れて輪にするとき、すべてのHAPメッセージを返すでしょう、変更されないで、アクセスの上では. (返すことの代わりに有効なHAPメッセージが捨てられるかもしれないということであることで長過ぎるメッセージ)は受信機によってリンクされています。 受信機で、輪を実装している間、それ自身のメッセージのいずれも送信機に行かないでしょう。 WPSが発生しているメッセージはすべてのHAPメッセージヘッダーにあるLoopbackインディケータによってホストが発生しているメッセージと区別されます。
Two types of remote loopback may be requested: loopback at the receiver's interface hardware and loopback at the receiver's I/O driver software. HAP does not specify the manner in which the receiver should implement these loops; additionally, some receivers may use interface hardware which is incapable of looping the transmitter's messages, only allowing the receiver to provide software loops. A receiver may not be able to interpret the transmitter's messages as it is looping them back. If such interpretation is possible, however, the receiver will not act on any of the transmitter's messages other than requests to reinitialize the WPS-host link (Restart Request (RR) control messages; see Section 8.)
2つのタイプのリモートループバックは要求されているかもしれません: 受信機のインタフェースハードウェアのループバックと受信機の入出力ドライバソフトウェアにおけるループバック。 HAPは受信機がこれらの輪を実装するはずである方法を指定しません。 さらに、いくつかの受信機が送信機のメッセージを輪にすることができないインタフェースハードウェアを使用するかもしれません、受信機がソフトウェア輪を提供するのを許容するだけであって。 それらを輪にし返しているとき、受信機は送信機のメッセージを解釈できないかもしれません。 しかしながら、そのような解釈が受信機がWPS-ホストリンクを再初期化するという要求以外の送信機のメッセージのいずれにも影響しないのが可能であるなら(Request(RR)コントロールメッセージを再開してください; セクション8を見てください。)
When a receiver initiates a loopback condition in response to a
受信機がaに対応してループバック状態を開始するとき
Edmond [Page 59] RFC 1221 HAP2 April 1991
エドモンド[59ページ]RFC1221HAP2 April 1991
loopback request, it makes an implicit promise to maintain the condition for the duration specified in the Loopback Request message. However, if an unanticipated condition such as a system restart occurs in either the transmitter or the receiver, the affected unit will try to reinitialize the WPS-host link by sending an RR message to the other unit. If the RR message is recognized by the other unit, a link initialization sequence can be completed. This will restore the link to an unlooped condition even if the specified loop duration has not yet expired. If a receiver cannot interpret a transmitter's RR messages, and in the absence of operator intervention at the receiver, the loop will remain in place for its duration.
ループバック要求、それはLoopback Requestメッセージで指定された持続時間のための状態を維持する暗黙の約束をします。 しかしながら、システムリスタートなどの思いがけない状態が送信機か受信機のどちらかに現れると、影響を受けるユニットは、RRメッセージをもう片方のユニットに送ることによって、WPS-ホストリンクを再初期化しようとするでしょう。 RRメッセージがもう片方のユニットによって認識されるなら、リンク初期化系列は完了できます。 指定された輪の持続時間がまだ期限が切れないでも、これは非輪にされた状態へのリンクを返すでしょう。 受信機が送信機のRRメッセージを解釈できないで、輪が受信機のオペレータ介入がないとき持続時間のために適所に残るなら。
HAP does not specify the characteristics of any loopback conditions that may be locally implemented by a given unit. An example of such a condition is that obtained when a WPS commands its host interface to loop back its own messages. If such local loop conditions also cause the reflection of messages received from the remote unit, the remote unit will detect the condition via the HAP header Loopback indicator.
HAPは与えられたユニットによって局所的に満たされるどんなループバック条件の特性も指定しません。 WPSが、ホスト・インターフェースがそれ自身のメッセージを輪にし返すと命令するとき、そのような状態の例はそんなに得られます。 また、そのような回線折返し状態がリモート単位から受け取られたメッセージの反映を引き起こすと、リモート単位はHAPヘッダーLoopbackインディケータで状態を検出するでしょう。
A specific sequence must be followed for setting up a remote loopback. It begins after the HAP link has been initialized and a decision is made to request a remote loop. The transmitter then sends a Loopback Request message (Figure 39) to the receiver and waits for either (1) a 10-second timer to expire, (2) a "Can't implement loop" Unnumbered Response message from the receiver, or (3) one of its own reflected messages. If event (1) or (2) occurs the request has failed and the transmitter may, at its option, try again with a new Loopback Request message. If event (3) occurs, the remote loopback condition has been established. While waiting for one of these events, messages from the receiver are processed normally. Note that RR messages arriving from the receiver during this time will terminate the loopback request.
リモートループバックをセットアップするために特定の順序に従わなければなりません。 HAPリンクを初期化して、リモート折返しを要求するのを決定をした後にそれは始まります。 送信機は、次に、Loopback Requestメッセージ(図39)を受信機に送って、(2) 受信機からの(1) 吐き出す10秒のタイマ、「道具は輪にすることができない」Unnumbered Responseメッセージか(3) それ自身の反射したメッセージの1つのどちらかを待っています。 イベント(1)か(2)が起こるなら、要求は失敗しました、そして、送信機は新しいLoopback Requestメッセージで任意に再試行するかもしれません。 イベント(3)が起こるなら、リモートループバック状態は確立されました。 これらのイベントの1つを待っている間、通常、受信機からのメッセージは処理されます。 この間に受信機から到着するRRメッセージがループバック要求を終えることに注意してください。
When a receiver gets a Loopback Request message, it either implements the requested loop for the specified duration, or returns a "Can't implement loop" response without changing the state of the link. The latter response would be returned, for example, if a receiver is incapable of implementing a requested hardware loop. A receiver should initiate reinitialization of the link with an RR message(s) whenever a loopback condition times out.
受信機がLoopback Requestメッセージを得るとき、リンクの状態を変えないで、それは、指定された持続時間のために要求された輪を実装するか、または「道具は輪にすることができない」という応答を返します。 例えば、受信機が要求されたハードウェア輪を実装することができないなら、後者の応答を返すでしょう。 ループバックが外で回を条件とさせるときはいつも、受信機はRRメッセージとのリンクの再初期化を開始するはずです。
There is one asymmetry that is required in the above sequence to resolve the (unlikely) case where both WPS and host request a remote loopback at the same time. If a WPS receives a Loopback Request message from a host while it is itself waiting for an event of type (1)-(3), it will return a "Can't implement loop" response to the host
そこでは、1つがWPSとホストの両方が同時にリモートループバックを要求するところの(ありそうもない)のケースを決議するのに上の系列で必要である非対称ですか? WPSが受信するなら、ホストからのLoopback Requestメッセージはそれである間、タイプ(1)のイベントを待っています--(3) それはホストへの「道具は輪にすることができない」という応答を返すでしょう。
Edmond [Page 60] RFC 1221 HAP2 April 1991
エドモンド[60ページ]RFC1221HAP2 April 1991
and will continue to wait. A host in the converse situation, however, will abort its loopback request and will instead act on the WPS's loopback request.
そして、待ち続けるでしょう。 逆状況におけるホストは、しかしながら、ループバック要求を中止して、代わりにWPSのループバック要求に影響するでしょう。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | LOOP TYPE | 8 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | LOOP DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| 0 | 輪のタイプ| 8 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 輪の持続時間| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LOOPBACK REQUEST
Figure 39
ループバック要求図39
0[0] Message Type = 1 (Control Message).
0[0]メッセージタイプ=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-3] Go-Priority.
0[2-3]碁優先権。
0[4-7] Reserved. Must be zero.
予約された0[4-7]。 ゼロにならなければならなくなってください。
0[8-11] Loop Type. This field indicates the type of loop that
is being requested as follows:
0[8-11]輪のタイプ。 この分野は以下の通り要求されている輪のタイプを示します:
0 = Undefined
1 = Loop at interface (hardware loop)
2 = Loop at driver (software loop)
3-15 = Undefined
0 = 未定義の1はドライバー(ソフトウェア輪)3-15=のインタフェース(ハードウェア輪)2=輪で輪と未定義の状態で等しいです。
0[12-15] Control Message Type = 8 (Loopback Request).
0[12-15]コントロールメッセージタイプ=8(ループバック要求)。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-2 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-2(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2[0-15] Loop Duration. The transmitter of a Loopback Request
message uses this field to specify the number of
seconds that the loop is to be maintained by the
receiver.
2[0-15]輪の持続時間。 Loopback Requestメッセージの送信機は、受信機によって維持される輪がことである秒の数を指定するのにこの分野を使用します。
Edmond [Page 61] RFC 1221 HAP2 April 1991
エドモンド[61ページ]RFC1221HAP2 April 1991
10. Other Control Messages
10. 他のコントロールメッセージ
Before a WPS or a host voluntarily disables a WPS-host link, it should send at least one Link Going Down control message (Figure 40) over that link. HAP does not define the action(s) that should be taken by a WPS or a host when such a message is received; informing the Network Operations Center (NOC) and/or the network users of the impending event is a typical course of action. Note that each Link Going Down message only pertains to the WPS-host link that it is sent over; if a host and a WPS are connected by multiple links, these links may be selectively disabled.
WPSかホストが自発的にWPS-ホストリンクを無効にする前に、それは少なくとも1つのLink Going Downコントロールメッセージ(図40)をそのリンクの上に送るべきです。 HAPはそのようなメッセージが受信されているときWPSかホストによって取られるべきである行動を定義しません。 差し迫っているイベントについてネットワーク運営センター(NOC)、そして/または、ネットワーク利用者に知らせるのは、典型的な行動です。 それぞれのLink Going Downメッセージがそれが送られるWPS-ホストリンクに関係するだけであることに注意してください。 ホストとWPSが複数のリンクによって接されるなら、これらのリンクは選択的に無効にされるかもしれません。
A No Operation (NOP) control message (Figure 41) may be sent at any time by a WPS or a host. A NOP message contains up to 32 words of arbitrary data which are undefined by HAP. NOP messages may be required in some cases to clear the state of the WPS-host link hardware.
いいえOperation(NOP)コントロールメッセージ(図41)はいつでも、WPSかホストによって送られるかもしれません。 NOPメッセージはHAPで未定義の任意のデータの最大32の単語を含んでいます。 NOPメッセージが、いくつかの場合、WPS-ホストリンクハードウェアを状態から取り除くのに必要であるかもしれません。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| 0 | REASON | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | TIME UNTIL DOWN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | DOWN DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb|GOPRI| 0 | 理由| 7 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2 | 下にへの時間| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3 | 持続時間の下側に| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LINK GOING DOWN
Figure 40
図40を下って、リンクしてください。
0[0] Message Type = 1 (Control Message).
0[0]メッセージタイプ=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-3] Go-Priority.
0[2-3]碁優先権。
0[4-7] Reserved. Must be zero.
予約された0[4-7]。 ゼロにならなければならなくなってください。
0[8-11] Reason. This field is used by the WPS or the host to
indicate the reason for disabling this WPS-host link as
follows:
0[8-11]理由。 この分野は以下のこのWPS-ホストリンクを無効にする理由を示すのにWPSかホストによって使用されます:
Edmond [Page 62] RFC 1221 HAP2 April 1991
エドモンド[62ページ]RFC1221HAP2 April 1991
0 = Cancel previous notice, not going down
1 = Unspecified reason
2 = Scheduled PM
3 = Scheduled hardware work
4 = Scheduled software work
5 = Emergency restart
6 = Power outage
7 = Software breakpoint
8 = Hardware failure
9 = Not scheduled up
10 = Last warning: The WPS or host will disable
the link in 10 seconds
11-15 = Undefined
0 = 予告を中止してください、予定されているハードウェア仕事4予定されている2=PM3==が最後の10=警告に予定されていなかったソフトウェア仕事5=非常時再開6=パワー供給停止7=ソフトウェア区切り点8=ハードウェア故障9=の計画をした不特定の1=理由を下らないで: WPSかホストが10秒以降、11-15 =未定義の状態でリンクを無効にするでしょう。
0[12-15] Control Message Type = 7 (Link Going Down).
0[12-15]コントロールメッセージタイプ=7(落ちて、リンクします)。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-3 (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-3(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2[0-15] Time Until Down. This field specifies the amount of
time remaining until the WPS or host disables the link
(in minutes). An entry of zero indicates that there is
less than a minute remaining.
下にへの2[0-15]時間。 この分野はWPSかホストまで残っているのがリンク(数分間の)を無効にする時間に指定します。 ゼロのエントリーは、残っている1分未満があるのを示します。
3[0-15] Down Duration. This field specifies the amount of time
that the WPS-host link will be down (in minutes). An
entry of zero indicates that the down duration will be
less than a minute. An entry of -1 (all bits set)
indicates an indefinite down duration.
持続時間の下側への3[0-15]。 この分野はWPS-ホストリンクが下がる(数分間の)時間を指定します。 ゼロのエントリーは、下に持続時間が1分未満になるのを示します。 -1(すべてのビットがセットした)のエントリーは無期下に持続時間を示します。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| 0 | LENGTH | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
2-N : ARBITRARY DATA :
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0 | 1|lb| 0 | 長さ| 6 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 | ヘッダーチェックサム| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | 2-N: 任意のデータ: | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
NO OPERATION (NOP)
Figure 41
いいえ操作(NOP)図41
Edmond [Page 63] RFC 1221 HAP2 April 1991
エドモンド[63ページ]RFC1221HAP2 April 1991
0[0] Message Type = 1 (Control Message).
0[0]メッセージタイプ=1(コントロールメッセージ)。
0[1] Loopback indicator.
0[1]ループバックインディケータ。
0[2-6] Reserved. Must be zero.
予約された0[2-6]。 ゼロにならなければならなくなってください。
0[7-11] Length. The number of words of arbitrary data.
0[7-11]の長さ。 任意のデータのワード数。
0[12-15] Control Message Type = 6 (NOP).
0[12-15]コントロールメッセージタイプ=6(NOP)。
1[0-15] Header Checksum. The checksum is the 2's-complement of
the 2's-complement sum of words 0-N (excluding the
checksum word itself).
1[0-15]ヘッダーチェックサム。 チェックサムは単語0-N(チェックサム単語自体を除いた)の2の補数合計の2補数です。
2-N Arbitrary Data. Up to 32 words of data may be sent.
The data are undefined by HAP.
2-Nの任意のデータ。 データに関する最大32の知らせを送るかもしれません。 データはHAPで未定義です。
11. Appendix A -- Future Extensions
11. 付録A--今後の拡大
The extensions to HAP described below are included to provide additional context for the understanding of HAP's current capabilities, as well as suggest how HAP may be enhanced in the future to provide better support for multi-site conferencing. These capabilities are not supported by TWBNET.
以下で説明されたHAPへの拡大は、HAPの現在の能力の理解に追加文脈を提供して、HAPが将来マルチサイト会議の、より良いサポートを提供するためにどう高められるかもしれないかを示すために含まれています。 これらの能力はTWBNETによってサポートされません。
One change under consideration is the addition of a "conference" resource, which would own some number of streams and groups and improve the network's ability to meet the needs of video conference users. A single request to modify the "conference", such as to add a new member, would result in modifying all the streams in the conference to include the new member, modifying the conference's primary group address to add the new member, etc., in a single network operation. Such a capability would not only simplify conference resource management for hosts, but also reduce the number of network setup operations, permit more nearly "atomic" decisions of whether a particular conference modification is possible, and reduce the problem of recovery if modification is not possible.
考慮している1回の変化が「会議」リソースの追加です。(それは、何らかの数のストリームとグループを所有して、テレビ会議システムユーザの需要を満たすネットワークの能力を改良するでしょう)。 「会議」を変更するというただ一つの要求(新しいメンバーを加えるようなもの)は新しいメンバーを含むように会議ですべてのストリームを変更するのに結果として生じるでしょう、新しいメンバーを加える会議のプライマリグループアドレスなどを変更して、ただ一つのネットワーク操作で。 そのような能力はホストのための会議資源管理を簡素化するだけではないでしょう、また、ネットワークセットアップ操作の数を減少させて、特定の会議変更が可能であるかどうかに関する、より多くのほとんど「原子」の決定を可能にして、変更が可能でないなら回復の問題を減少させるのを除いて。
Another change under consideration is the addition of "shared streams." This capability would allow hosts to share a single allocation of network bandwidth (and other resources) wherever the streams shared a common communication path. Hosts using a shared stream must be willing to restrict their total transmission rate to the rate of the shared bandwidth. Multi-site conferences could use such a capability to avoid allocating full bandwidth for voice data for all conference members. Instead, bandwidth for, say, four active voices at once could be allocated and shared, and voice messages would only be lost when more than four people tried to talk at once.
考慮している別の変化は「共有されたストリーム」の追加です。This能力は、ホストがどこでも、ストリームが一般的な通信路を共有したところでネットワーク回線容量(そして、他のリソース)のただ一つの配分を共有するのを許容するでしょう。 共有されたストリームを使用しているホストは、彼らの総通信速度を共有された帯域幅のレートに制限しても構わないと思っているに違いありません。 マルチサイト会議はすべての加盟会社のために声のデータのために完全な帯域幅を割り当てるのを避けるそのような能力を使用できました。 代わりに、すぐにたとえば、4つの能動態のための帯域幅を割り当てて、共有できました、そして、4人以上の人がすぐに話そうとしたときだけ、音声メールは失われるでしょう。
Edmond [Page 64] RFC 1221 HAP2 April 1991
エドモンド[64ページ]RFC1221HAP2 April 1991
The Create Shared Stream Request would use a different request code than Create Stream Request, and the setup message would likely contain at least one additional field to identify the set of shared streams. Change and Delete Stream requests could be used for both shared and non-shared streams.
Create Shared Stream RequestはCreate Stream Requestと異なった要求コードを使用するでしょう、そして、セットアップメッセージは共有されたストリームのセットを特定するためにおそらく少なくとも1つの追加分野を含んでいるでしょう。共有されて非共有の両方にされたストリームに変化とDelete Stream要求は使用できました。
12. Appendix B -- Backward compatibility
12. 付録B--後方の互換性
The WPS will support the use of HAP version 0 by hosts until all hosts have upgraded to version 1. The WPS determines which HAP version the host is using by examining the Restart Request and/or Restart Complete control messages sent by the host to the WPS. If the host initiates a restart and thus sends both a Restart Request and a Restart Complete, and if the HAP version numbers in the two messages differ, the version number in the Restart Complete will prevail. The WPS will always set the version number to 1. If the host sends 0 in the version number field, version 0 compatiblity mode will be invoked.
すべてのホストがバージョン1にアップグレードするまで、WPSはホストによるHAPバージョン0の使用をサポートするでしょう。 WPSは、ホストがコントロールメッセージがホストでWPSに送ったRestart Request、そして/または、Restart Completeを調べることによってどのHAPバージョンを使用しているかを決定します。ホストが再開を開始して、その結果、Restart RequestとRestart Completeの両方を送って、2つのメッセージのHAPバージョン番号が異なると、Restart Completeのバージョン番号は広がるでしょう。 WPSはいつもバージョン番号を1に設定するでしょう。 ホストがバージョンナンバーフィールドで0を送ると、バージョン0compatiblityモードは呼び出されるでしょう。
Version 0 of HAP did not contain the PROTOCOL ID field in the datagram and stream message headers. Instead, the IL bit in the Type of Service word was used to indicate the presence or absence of an Internet Protocol (IP) header (any version number) following the HAP header. This is the original description of that bit:
HAPのバージョン0はデータグラムとストリームメッセージヘッダーにプロトコルID分野を含みませんでした。 代わりに、Service単語のTypeのILビットは、HAPヘッダーに続いて、インターネットプロトコル(IP)ヘッダー(どんなバージョン番号も)の存在か不在を示すのに使用されました。 これはそのビットのオリジナルの記述です:
3[1] Internet/Local Flag. This flag is set by a source host to
specify to a destination host whether the data portion of
the message contains an Internet Protocol (IP) header [3].
This field is passed transparently by the source and
destination WPSen for traffic between network hosts. This
field is examined by WPS Agents in order to support
Internet operation.
3[1]インターネット/ローカルの旗。 メッセージのデータ部がインターネットプロトコル(IP)ヘッダー[3]を含んでいるか否かに関係なく、この旗はあて先ホストに指定する送信元ホストによって設定されます。 この野原はトラフィックのためにネットワークホストの間をソースと目的地WPSenによって透過的に通り過ぎられます。 この分野は、インターネットが操作であるとサポートするためにWPSエージェントによって調べられます。
0 = Internet
1 = Local
0はインターネット1と=地方であることで等しいです。
Conversion Algorithms
変換アルゴリズム
Link control messages (e.g., Restart Request) do not require conversion. Datagram and stream messages sent by or to a host running HAP version 0 will be converted by the WPS. Message conversion will probably cause the maximum throughput of hosts using HAP version 0 to be somewhat lower than that of hosts using HAP version 1.
リンク制御メッセージ(例えば、Restart Request)は変換を必要としません。 バージョンかホスト実行HAPバージョン0に送られたデータグラムとストリームメッセージはWPSによって変換されるでしょう。メッセージ変換は、HAPバージョン0を使用しているホストの最大のスループットがホストのものよりいくらか低いことをたぶんHAPバージョン1を使用することで引き起こすでしょう。
HAP version 0 used the IL bit in the HAP Type of Service word to indicate the presence or absence of an IP header. Version 1 uses the Protocol ID field. To convert host-to-WPS messages, the IL bit will
HAPバージョン0は、IPヘッダーの存在か不在を示すのにService単語のHAP TypeでILビットを使用しました。 バージョン1はプロトコルID分野を使用します。 メッセージ、ILビットが変換するホストからWPSを変換するために
Edmond [Page 65] RFC 1221 HAP2 April 1991
エドモンド[65ページ]RFC1221HAP2 April 1991
be cleared, and the protocol ID field will be inserted, with the value indicated:
きれいにされてください。そうすれば、値が示されている状態で、プロトコルID野原は挿入されるでしょう:
IL was Destination Protocol ID set to:
------ ------------- ---------------------
0 any HAP_PROTO_IP (0x800)
1 Service Agent HAP_PROTO_SETUP (1)
1 other HAP_PROTO_NONE (0)
イリノイは以下に設定されたDestination Protocol IDでした。 ------ ------------- --------------------- 0 _どんな(1) 他の1HAPの_IP(0×800)1ServiceのHAP_プロトエージェントHAP_プロト_SETUP_プロトNONE(0)
To convert WPS-to-host messages, the protocol ID field will be
deleted, and the IL bit will be set by:
IL = (protocol_id was HAP_PROTO_IP) ? 0 : 1;
WPSからホストへのメッセージを変換するために、プロトコルID分野は削除されるでしょう、そして、ILビットは以下によって設定されるでしょう。 IL=(プロトコル_イドはHAP_プロト_IPでした)?0: 1;
HAP_PROTO_IP (see Appendix C) will be used for IP "versions" 3
(GG protocol), 4 (IP), and 5 (ST).
HAP_プロト_IP(Appendix Cを見る)はIP「バージョン」3(GGは議定書を作ります)、4(IP)と5(ST)に使用されるでしょう。
The datagram message header fields TTL and PRI have been swapped in HAP version 0 compared to version 1. The conversion code swaps the contents of these two fields for hosts running version 0.
バージョン1と比べて、データグラムメッセージヘッダーフィールドのTTLとPRIはHAPバージョン0で交換されました。 換算相場はこれらの2つの分野のコンテンツをバージョン0を実行するホストに交換します。
The stream message header field TTL in HAP version 0 was replaced by the PRE field in version 1. Since the only permitted value of TTL was 1, and it is a valid PRE value, no conversion is necessary.
HAPバージョン0のストリームメッセージヘッダーフィールドTTLをバージョン1のPRE分野に取り替えました。 TTLの唯一の受入れられた値が1であり、それが有効なPRE値であるので、どんな変換も必要ではありません。
In HAP version 0, messages between a host and the Service Agent were allowed to contain Internet Protocol headers. No hosts use that capability, so no provision will be made to accommodate IP headers in Setups between hosts and the Service Agent.
HAPバージョン0では、ホストとServiceエージェントの間のメッセージはインターネットプロトコルヘッダーを含むことができました。 どんなホストもその能力を使用しないので、ホストとServiceエージェントの間にSetupsにIPヘッダーを収容するのを設備を全くしないでしょう。
In version 0, the Restart Request control message contained a "reason for restart" field. That field was ignored in all current implementations and has been eliminated in version 1.
バージョン0では、Restart Requestコントロールメッセージは「再開の理由」分野を含みました。 その分野は、すべての現在の実装で無視されて、バージョン1で排除されました。
Current implementations expect the WPS to insert an "incarnation count" in bits 5-10 of the first word of both Restart Request and Restart Complete messages. This functionality has been replaced by the "SL" bit in the Restart Complete message in version 1. Compatibility code will be added if needed, but it is expected that none will be needed.
現在の実装は、WPSがRestart RequestとRestart Completeメッセージの両方の最初の単語のビット5-10に「肉体化カウント」を挿入すると予想します。 この機能性をバージョン1の再開で噛み付いた"SL"完全なメッセージに取り替えました。 必要であるなら、互換性コードは加えられるでしょうが、なにも必要でないと予想されます。
13. Appendix C -- HAP Protocol ID Assigned Numbers
13. 付録C--機会プロトコルID規定番号
This section lists the values of the PROTOCOL ID field. This part of the specification will be obsolete when a version of the Assigned Numbers RFC containing HAP protocol ID numbers is issued.
このセクションはプロトコルID分野の値を記載します。 Assigned民数記RFCがHAPプロトコルID番号を含むバージョンを発行するとき、仕様のこの部分は時代遅れになるでしょう。
HAP adopts the Ether-type numbers in the 1500-65535 range. Protocol IDs 256-511 identify ISO protocols. Zero indicates the absence of a
HAPは1500-65535範囲にEther-形式数を採用します。 プロトコルID256-511はISOプロトコルを特定します。 ゼロはaの不在を示します。
Edmond [Page 66] RFC 1221 HAP2 April 1991
エドモンド[66ページ]RFC1221HAP2 April 1991
higher level protocol header. Other protocol IDs are reserved for future assignment.
より高い平らなプロトコルヘッダー。 他のプロトコルIDは将来の課題のために予約されます。
Protocol ID Indicates
----------- ---------
0 No higher level protocol
1 For Network Service Agent messages
2-255 Reserved
256-511 ISO protocol identifier + 256
512-1499 Reserved
1500-65535 Identical to Ether-type [10].
IDが示すプロトコル----------- --------- 0 どんなより高い平らなプロトコル1For Network Serviceエージェントメッセージ2-255Reserved256-511ISOも識別子+256 512-1499Reserved1500-65535IdenticalについてEther-タイプ[10]に議定書の中で述べません。
HAP PROTOCOL ID NUMBERS
Figure 42
機会プロトコルID番号は42について計算します。
REFERENCES
参照
1. Falk, G., Groff, S., Koolish, R., and W. Milliken, "PSAT
Technical Report", BBN Technical Report No. 4469, Chapter 4, May
1981.
1. BBN技術報告書No.4469、第4章がそうするフォークとG.とグルフとS.とKoolish、R.とW.ミリケン、「PSAT技術報告書」1981。
2. Rees, T., Editor, "A Host Access Protocol Specification", BBN
Laboratories, Inc., May 1987. (A revision of RFC 907 that was
distributed to DARPA and the WBNET user community but not
resubmitted as an RFC.)
2. レース、T.(「ホストアクセスプロトコル仕様」、BBN研究所Inc.のエディタ)は1987がそうするかもしれません。 (DARPAとWBNETユーザーコミュニティに分配されましたが、RFCとして再提出されなかったRFC907の改正。)
3. Postel, J., Editor, "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/Information Sciences
Institute, September 1981.
3. ポステル、J.、エディタ、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC791、科学が1981年9月に設けるUSC/情報。
4. Topolcic, C., Editor, "Experimental Internet Stream Protocol,
Version 2 (ST-II)", RFC 1190, Bolt Beranek and Newman, Inc.,
October 1990.
4. Topolcic、C.、エディタ、「実験インターネットストリームプロトコル、バージョン2、(第-、II、)、」、RFC1190とボルトBeranekとニューマンInc.、10月1990日
5. Edmond, W., Seo, K., Leib, M., and C. Topolcic, "The DARPA
Wideband Network Dual Bus Protocol", Proceedings of ACM SIGCOMM
'90, pages 79-89, September 24-27, 1990.
5. エドモンド、W.、Seo、K.、ライプ、M.、およびC.Topolcic、「DARPAの広帯域のネットワークの二元的なバスプロトコル」、ACM SIGCOMM90年、79-89ページ(1990年9月24日〜27日)のProceedings。
6. "Host/SATNET Protocol", Internet Engineering Note (IEN) 192, July
1981.
6. 「ホスト/SATNETプロトコル」、インターネット工学注意(IEN)192、1981年7月。
7. Evenchik, L., McNeill, D., Bressler, R., Owen, A., Rice, Jr., R.,
Trout, G., Pavey, C., Damer, R., Deckelman, F., and T. Hughes,
"MATNET, An Experimental Navy Shipboard Satellite Communications
Network", Proceedings of INFOCOM '82, pages 3-11, March 30 -
April 1, 1982.
7. 3月30日--INFOCOM82年、3-11ページ、1982年4月1日のEvenchikとL.とマクニールとD.とBresslerとR.とオーエンとA.とライスとJr.とR.とTroutとG.とPaveyとC.とデイマーとR.とDeckelman、F.とT.ヒューズ、「MATNET、実験海軍船舶衛星通信ネットワーク」Proceedings。
Edmond [Page 67] RFC 1221 HAP2 April 1991
エドモンド[67ページ]RFC1221HAP2 April 1991
8. Falk, G., Groff, J., Milliken, W., Nodine, M., Blumenthal, S.,
and W. Edmond, "Integration of Voice and Data in the Wideband
Packet Satellite Network", IEEE Journal on Selected Areas in
Communications, Vol. SAC-1, No. 6, December 1983.
8. コミュニケーションの選択された領域、Vol.嚢-1、No.6(1983年12月)に関するフォークとG.とグルフとJ.とミリケンとW.とNodineとM.とブルーメンソル、S.とW.エドモンド、「広帯域パケット衛星ネットワークにおける声とデータの統合」IEEEジャーナル。
9. "Interface Message Processor: Specifications for the
Interconnection of a Host and an IMP", BBN Technical Report No.
1822, October 1980.
9. 「メッセージプロセッサを連結してください」 「ホストと悪童のインタコネクトのための仕様」、BBN技術報告書No.1822、1980年10月。
10. Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
10. USC/情報科学が1990年3月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、RFC1060。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Winston Edmond Bolt Beranek and Newman, Inc. Network Technologies Department 10 Moulton Street Cambridge, Massachusetts 02138
ウィンストンエドモンドボルトBeranekとニューマンInc.は部10のモールトン・通りケンブリッジ、Technologiesマサチューセッツ 02138をネットワークでつなぎます。
Phone: (617) 873-3000
以下に電話をしてください。 (617) 873-3000
EMail: wbe@bbn.com
メール: wbe@bbn.com
Edmond [Page 68]
エドモンド[68ページ]
一覧
スポンサーリンク
