RFC1190 日本語訳
1190 Experimental Internet Stream Protocol: Version 2 (ST-II). C.Topolcic. October 1990. (Format: TXT=386909 bytes) (Obsoletes IEN 119) (Obsoleted by RFC1819) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group CIP Working Group Request for Comments: 1190 C. Topolcic, Editor Obsoletes: IEN-119 October 1990
コメントを求めるワーキンググループCIPワーキンググループ要求をネットワークでつないでください: 1190C.Topolcic、エディタは以下を時代遅れにします。 IEN-119 1990年10月
Experimental Internet Stream Protocol, Version 2 (ST-II)
実験インターネット流れのプロトコル、バージョン2(第-、II、)
Status of this Memo
このMemoの状態
This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモは実験からの結果に基づいて改良のためのオリジナルバージョン、その後の要求、議論、および提案で元々IEN-119[8]で定義されたインターネットStreamプロトコルの改訂版を定義します。 これは株式会社使用Experimentalプロトコルです。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
1. Abstract
1. 要約
This memo defines the Internet Stream Protocol, Version 2 (ST-II), an IP-layer protocol that provides end-to-end guaranteed service across an internet. This specification obsoletes IEN 119 "ST - A Proposed Internet Stream Protocol" written by Jim Forgie in 1979, the previous specification of ST. ST-II is not compatible with Version 1 of the protocol, but maintains much of the architecture and philosophy of that version. It is intended to fill in some of the areas left unaddressed, to make it easier to implement, and to support a wider range of applications.
このメモはインターネットStreamプロトコルを定義します、バージョン2(ST-II)、インターネットの向こう側に終わりから終わりに対する保証されたサービスを提供するIP-層のプロトコル。 提案されたインターネットの流れは議定書を作ります。この仕様がIEN119を時代遅れにする、「第--、」 1979年にジムForgieによって書かれて、ST. ST-IIの前の仕様は、プロトコルのバージョン1と互換性がありませんが、構造の多く、そのバージョンの哲学を維持します。 宛名がない状態で残っている領域のいくつかに記入して、それを実行するのが、より簡単にして、より広い範囲のアプリケーションを支持するのは意図しています。
CIP Working Group [Page 1] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[1ページ]RFC1190インターネット流れのプロトコル1990年10月
1.1. Table of Contents
1.1. 目次
Status of this Memo . . . . . . . . . . . . 1
1. Abstract . . . . . . . . . . . . . . . 1
1.1. Table of Contents . . . . . . . . . . . 2
1.2. List of Figures . . . . . . . . . . . . 4
このMemo. . . . . . . . . . . . 1 1の状態。 要約. . . . . . . . . . . . . . . 1 1.1。 目次. . . . . . . . . . . 2 1.2。 数字. . . . . . . . . . . . 4のリスト
2. Introduction . . . . . . . . . . . . . . 7
2.1. Major Differences Between ST and ST-II . . . . 8
2.2. Concepts and Terminology . . . . . . . . . 9
2.3. Relationship Between Applications and ST . . . . 11
2.4. ST Control Message Protocol . . . . . . . . 12
2.5. Flow Specifications . . . . . . . . . . . 14
2. 序論. . . . . . . . . . . . . . 7 2.1。 第そして、間の主要な違い、第-、II、.82.2 概念と用語. . . . . . . . . 9 2.3。 そして、アプリケーションの間の関係、.112.4番目 メッセージプロトコル. . . . . . . . 12 2.5を第制御してください。 流れ仕様. . . . . . . . . . . 14
3. ST Control Message Protocol Functional Description . 17
3.1. Stream Setup . . . . . . . . . . . . . 18
3.1.1. Initial Setup at the Origin . . . . . . . 18
3.1.2. Invoking the Routing Function . . . . . . 19
3.1.3. Reserving Resources . . . . . . . . . . 19
3.1.4. Sending CONNECT Messages . . . . . . . . 20
3.1.5. CONNECT Processing by an Intermediate Agent . . 22
3.1.6. Setup at the Targets . . . . . . . . . 23
3.1.7. ACCEPT Processing by an Intermediate Agent . . 24
3.1.8. ACCEPT Processing by the Origin . . . . . . 26
3.1.9. Processing a REFUSE Message . . . . . . . 27
3.2. Data Transfer . . . . . . . . . . . . . 30
3.3. Modifying an Existing Stream . . . . . . . . 31
3.3.1. Adding a Target . . . . . . . . . . . 31
3.3.2. The Origin Removing a Target . . . . . . . 33
3.3.3. A Target Deleting Itself . . . . . . . . 35
3.3.4. Changing the FlowSpec . . . . . . . . . 36
3.4. Stream Tear Down . . . . . . . . . . . . 36
3.5. Exceptional Cases . . . . . . . . . . . 37
3.5.1. Setup Failure due to CONNECT Timeout . . . . 37
3.5.2. Problems due to Routing Inconsistency . . . . 38
3.5.3. Setup Failure due to a Routing Failure . . . 39
3.5.4. Problems in Reserving Resources . . . . . . 41
3.5.5. Setup Failure due to ACCEPT Timeout . . . . 41
3.5.6. Problems Caused by CHANGE Messages . . . . . 42
3.5.7. Notification of Changes Forced by Failures . . 42
3.6. Options . . . . . . . . . . . . . . . 44
3.6.1. HID Field Option . . . . . . . . . . . 44
3.6.2. PTP Option . . . . . . . . . . . . . 44
3.6.3. FDx Option . . . . . . . . . . . . . 45
3.6.4. NoRecovery Option . . . . . . . . . . 46
3.6.5. RevChrg Option . . . . . . . . . . . 46
3.6.6. Source Route Option . . . . . . . . . . 46
3.7. Ancillary Functions . . . . . . . . . . . 48
3.7.1. Failure Detection . . . . . . . . . . 48
3.7.1.1. Network Failures . . . . . . . . . . 48
3.7.1.2. Detecting ST Stream Failures . . . . . . 49
3.7.1.3. Subset . . . . . . . . . . . . . 51
3. メッセージのプロトコルの機能的な記述. 17 3.1を第制御してください。 セットアップ. . . . . . . . . . . . . 18 3.1.1を流してください。 起源. . . . . . . 18 3.1.2でセットアップに頭文字をつけてください。 経路選択機能. . . . . . 19 3.1.3を呼び出します。 リソース. . . . . . . . . . 19 3.1.4を予約します。 発信して、メッセージ. . . . . . . . 20 3.1.5を接続してください。 処理を中間的エージェント. . 22 3.1.6接続してください。 目標. . . . . . . . . 23 3.1で.7にセットアップしてください。 処理を中間的エージェント. . 24 3.1.8受け入れてください。 処理を起源. . . . . . 26 3.1.9で受け入れてください。 廃物メッセージ. . . . . . . 27 3.2を処理します。 データ転送. . . . . . . . . . . . . 30 3.3。 既存の流れ. . . . . . . . 31 3.3の.1を変更します。 目標. . . . . . . . . . . 31 3.3.2を加えます。 目標. . . . . . . 33 3.3.3を取り除く起源。 .353.3に.4にそれ自体を削除する目標 FlowSpec. . . . . . . . . 36 3.4を変えます。 .363.5の下側に裂け目を流してください。 例外的なケース. . . . . . . . . . . 37 3.5.1。 CONNECT Timeout. . . . 37 3.5.2のためFailureをセットアップしてください。 問題はルート設定Inconsistency. . . . 38 3.5.3がそうします。 ルート設定Failure. . . 39 3.5.4のためFailureをセットアップしてください。 リソース. . . . . . 41 3.5.5を予約することにおける問題。 ACCEPT Timeout. . . . 41 3.5.6のためFailureをセットアップしてください。 変化メッセージ. . . . . 42 3.5.7引き起こされた問題。 失敗. . 42 3.6で無理矢理の変化の通知。 オプション. . . . . . . . . . . . . . . 44 3.6.1。 分野オプション. . . . . . . . . . . 44 3.6.2を隠しました。 PTPオプション. . . . . . . . . . . . . 44 3.6.3。 FDxオプション. . . . . . . . . . . . . 45 3.6.4。 NoRecoveryオプション. . . . . . . . . . 46 3.6.5。 RevChrgオプション. . . . . . . . . . . 46 3.6.6。 送信元経路オプション. . . . . . . . . . 46 3.7。 補助的機能. . . . . . . . . . . 48 3.7.1。 失敗検出. . . . . . . . . . 48 3.7.1.1。 ネットワーク失敗. . . . . . . . . . 48 3.7.1.2。 第流れ失敗. . . . . . 49 3.7.1の.3を検出します。 部分集合. . . . . . . . . . . . . 51
CIP Working Group [Page 2] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[2ページ]RFC1190インターネット流れのプロトコル1990年10月
3.7.2. Failure Recovery . . . . . . . . . . . 51
3.7.2.1. Subset . . . . . . . . . . . . . 55
3.7.3. A Group of Streams . . . . . . . . . . 56
3.7.3.1. Group Name Generator . . . . . . . . 57
3.7.3.2. Subset . . . . . . . . . . . . . 57
3.7.4. HID Negotiation . . . . . . . . . . . 58
3.7.4.1. Subset . . . . . . . . . . . . . 64
3.7.5. IP Encapsulation of ST . . . . . . . . . 64
3.7.5.1. IP Multicasting . . . . . . . . . . 65
3.7.6. Retransmission . . . . . . . . . . . 66
3.7.7. Routing . . . . . . . . . . . . . . 67
3.7.8. Security . . . . . . . . . . . . . 67
3.8. ST Service Interfaces . . . . . . . . . . 68
3.8.1. Access to Routing Information . . . . . . 69
3.8.2. Access to Network Layer Resource Reservation . 70
3.8.3. Network Layer Services Utilized . . . . . . 71
3.8.4. IP Services Utilized . . . . . . . . . 71
3.8.5. ST Layer Services Provided . . . . . . . 72
3.7.2. 失敗回復. . . . . . . . . . . 51 3.7.2.1。 部分集合. . . . . . . . . . . . . 55 3.7.3。 Aは.1に流れ. . . . . . . . . . 56 3.7の.3を分類します。 グループ名ジェネレータ. . . . . . . . 57 3.7.3.2。 部分集合. . . . . . . . . . . . . 57 3.7.4。 .1に交渉. . . . . . . . . . . 58 3.7.4を隠しました。 部分集合. . . . . . . . . . . . . 64 3.7.5。 IPカプセル化、.643.7 .5 .1番目。 IPマルチキャスティング. . . . . . . . . . 65 3.7.6。 Retransmission. . . . . . . . . . . 66 3.7.7。 ルート設定. . . . . . . . . . . . . . 67 3.7.8。 セキュリティ. . . . . . . . . . . . . 67 3.8。 .1にインタフェース. . . . . . . . . . 68 3.8を第修理してください。 情報. . . . . . 69 3.8.2にルート設定にアクセスしてください。 資源予約. 70 3.8.3にネットワーク層にアクセスしてください。 ネットワーク層サービスは.4に.713.8を利用しました。 IPサービスは.5に.713.8を利用しました。 層のサービスは.72を第提供しました。
4. ST Protocol Data Unit Descriptions . . . . . . . 75
4.1. Data Packets . . . . . . . . . . . . . 76
4.2. ST Control Message Protocol Descriptions . . . . 77
4.2.1. ST Control Messages . . . . . . . . . . 79
4.2.2. Common SCMP Elements . . . . . . . . . 80
4.2.2.1. DetectorIPAddress . . . . . . . . . 80
4.2.2.2. ErroredPDU . . . . . . . . . . . . 80
4.2.2.3. FlowSpec & RFlowSpec . . . . . . . . 81
4.2.2.4. FreeHIDs . . . . . . . . . . . . 84
4.2.2.5. Group & RGroup . . . . . . . . . . 85
4.2.2.6. HID & RHID . . . . . . . . . . . . 86
4.2.2.7. MulticastAddress . . . . . . . . . . 86
4.2.2.8. Name & RName . . . . . . . . . . . 87
4.2.2.9. NextHopIPAddress . . . . . . . . . . 88
4.2.2.10. Origin . . . . . . . . . . . . . 88
4.2.2.11. OriginTimestamp . . . . . . . . . . 89
4.2.2.12. ReasonCode . . . . . . . . . . . . 89
4.2.2.13. RecordRoute . . . . . . . . . . . 94
4.2.2.14. SrcRoute . . . . . . . . . . . . 95
4.2.2.15. Target and TargetList . . . . . . . . 96
4.2.2.16. UserData . . . . . . . . . . . . 98
4.2.3. ST Control Message PDUs . . . . . . . . 99
4.2.3.1. ACCEPT . . . . . . . . . . . . . 100
4.2.3.2. ACK . . . . . . . . . . . . . . 102
4.2.3.3. CHANGE-REQUEST . . . . . . . . . . 103
4.2.3.4. CHANGE . . . . . . . . . . . . . 104
4.2.3.5. CONNECT . . . . . . . . . . . . . 105
4.2.3.6. DISCONNECT . . . . . . . . . . . . 110
4.2.3.7. ERROR-IN-REQUEST . . . . . . . . . . 111
4.2.3.8. ERROR-IN-RESPONSE . . . . . . . . . 112
4.2.3.9. HELLO . . . . . . . . . . . . . 113
4.2.3.10. HID-APPROVE . . . . . . . . . . . 114
4.2.3.11. HID-CHANGE-REQUEST . . . . . . . . . 115
4. データ単位記述. . . . . . . 75 4.1について第議定書の中で述べてください。 データ・パケット. . . . . . . . . . . . . 76 4.2。 .1にメッセージプロトコル記述. . . . 77 4.2を第制御してください。 .2にメッセージ. . . . . . . . . . 79 4.2を第制御してください。 一般的なSCMP要素. . . . . . . . . 80 4.2.2.1。 DetectorIPAddress、.804.2 .2 .2。 ErroredPDU、.804.2 .2 .3。 FlowSpec&RFlowSpec. . . . . . . . 81 4.2.2、.4 FreeHIDs、.844.2 .2 .5。 グループとRGroup. . . . . . . . . . 85 4.2.2、.6 隠す、RHID、.864.2 .2 .7。 MulticastAddress、.864.2 .2 .8。 名前とRName. . . . . . . . . . . 87 4.2.2、.9 NextHopIPAddress、.884.2 .2 .10。 起源、.884.2 .2 .11。 OriginTimestamp、.894.2 .2 .12。 ReasonCode、.894.2 .2 .13。 RecordRoute、.944.2 .2 .14。 SrcRoute、.954.2 .2 .15。 目標とTargetList. . . . . . . . 96 4.2.2、.16 UserData. . . . . . . . . . . . 98 4.2.3。 .1にメッセージPDUs. . . . . . . . 99 4.2.3を第制御してください。 .100 4.2に.2に.3を受け入れてください。 ACK、.102 4.2 .3 .3。 .103 4.2を変化で要求してください。.3 .4。 .104 4.2に.5に.3を変えてください。 .105 4.2に.6に.3を接続してください。 .110 4.2に.7に.3を外してください。 要求における誤り.111 4.2、.3 .8。 応答における誤り.112 4.2、.3 .9。 こんにちは、.113 4.2 .3 .10。 隠す、-承認してください、.114 4.2 .3 .11。 変更要求を隠している.115
CIP Working Group [Page 3] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[3ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.3.12. HID-CHANGE . . . . . . . . . . . . 116
4.2.3.13. HID-REJECT . . . . . . . . . . . . 118
4.2.3.14. NOTIFY . . . . . . . . . . . . . 120
4.2.3.15. REFUSE . . . . . . . . . . . . . 122
4.2.3.16. STATUS . . . . . . . . . . . . . 124
4.2.3.17. STATUS-RESPONSE . . . . . . . . . . 126
4.3. Suggested Protocol Constants . . . . . . . . 127
4.2.3.12. 変化を隠している.116 4.2、.3 .13。 廃棄物を隠している.118 4.2、.3 .14。 .120 4.2に.15に.3に通知してください。 .122 4.2に.16に.3を拒否してください。 状態、.124 4.2 .3 .17。 状態応答.126 4.3。 提案されたプロトコル定数. . . . . . . . 127
5. Areas Not Addressed . . . . . . . . . . . . 131
5. 領域は.131を記述しませんでした。
6. Glossary . . . . . . . . . . . . . . . 135
6. 用語集. . . . . . . . . . . . . . . 135
7. References . . . . . . . . . . . . . . . 143
7. 参照. . . . . . . . . . . . . . . 143
8. Security Considerations. . . . . . . . . . . 144
8. セキュリティ問題。 . . . . . . . . . . 144
9. Authors' Addresses . . . . . . . . . . . . 145
9. 作者のアドレス. . . . . . . . . . . . 145
Appendix 1. Data Notations . . . . . . . . . . 147
付録1。 データ記法. . . . . . . . . . 147
1.2. List of Figures
1.2. 数字のリスト
Figure 1. Protocol Relationships . . . . . . . . . 6
Figure 2. Topology Used in Protocol Exchange Diagrams . . 16
Figure 3. Virtual Link Identifiers for SCMP Messages . . 16
Figure 4. HIDs Assigned for ST User Packets . . . . . 18
Figure 5. Origin Sending CONNECT Message . . . . . . 21
Figure 6. CONNECT Processing by an Intermediate Agent . . 22
Figure 7. CONNECT Processing by the Target . . . . . . 24
Figure 8. ACCEPT Processing by an Intermediate Agent . . 25
Figure 9. ACCEPT Processing by the Origin . . . . . . 26
Figure 10. Sending REFUSE Message . . . . . . . . . 28
Figure 11. Routing Around a Failure . . . . . . . . 29
Figure 12. Addition of Another Target . . . . . . . . 32
Figure 13. Origin Removing a Target . . . . . . . . 34
Figure 14. Target Deleting Itself . . . . . . . . . 35
Figure 15. CONNECT Retransmission after a Timeout . . . . 38
Figure 16. Processing NOTIFY Messages . . . . . . . . 43
Figure 17. Source Routing Option . . . . . . . . . 47
Figure 18. Typical HID Negotiation (No Multicasting) . . . 60
Figure 19. Multicast HID Negotiation . . . . . . . . 61
Figure 20. Multicast HID Re-Negotiation . . . . 62
Figure 21. ST Header . . . . . . . . . . . . . 75
Figure 22. ST Control Message Format . . . . . . . . 77
Figure 23. ErroredPDU . . . . . . . . . . . . . 80
Figure 24. FlowSpec & RFlowSpec . . . . . . . . . . 81
Figure 25. FreeHIDs . . . . . . . . . . . . . . 85
Figure 26. Group & RGroup . . . . . . . . . . . . 85
Figure 27. HID & RHID . . . . . . . . . . . . . 86
Figure 28. MulticastAddress . . . . . . . . . . . 86
Figure 29. Name & RName . . . . . . . . . . . . 87
Figure 30. NextHopIPAddress . . . . . . . . . . . 88
図1。 関係. . . . . . . . . 6図2について議定書の中で述べてください。 トポロジーはプロトコル交換ダイヤグラムで.16図3を使用しました。 SCMPメッセージ. . 16のための仮想のリンク識別子は4について計算します。 HIDsはユーザ第パケット. . . . . 18のために図5を選任しました。 起源発信はメッセージ. . . . . . 21図6に接します。 仲介物質.22図7で処理を接続してください。 目標. . . . . . 24エイト環で処理を接続してください。 仲介物質.25図9で処理を受け入れてください。 起源. . . . . . 26図10で処理を受け入れてください。 廃物メッセージ. . . . . . . . . 28図11を送ります。 失敗. . . . . . . . 29図12の周りで掘ります。 別の目標. . . . . . . . 32数値13の添加。 目標. . . . . . . . 34数値14を取り除く起源。 .35図15自体を削除する目標。 タイムアウト. . . . 38図16の後にRetransmissionを接続してください。 処理して、メッセージ. . . . . . . . 43図17に通知してください。 ソースルート設定オプション. . . . . . . . . 47は18について計算します。 典型的である、交渉(マルチキャスティングがない).60図19を隠しました。 マルチキャストは交渉. . . . . . . . 61図20を隠しました。 マルチキャストは再交渉.62図21を隠しました。 ヘッダー. . . . . . . . . . . . . 75は22に第計算します。 メッセージ・フォーマット. . . . . . . . 77図23を第監督してください。 ErroredPDU. . . . . . . . . . . . . 80は24について計算します。 FlowSpec&RFlowSpec. . . . . . . . . . 81は25について計算します。 FreeHIDs. . . . . . . . . . . . . . 85は26について計算します。 グループとRGroup. . . . . . . . . . . . 85は27について計算します。 隠す、RHID. . . . . . . . . . . . . 86は28に計算します。 MulticastAddress. . . . . . . . . . . 86は29について計算します。 名前とRName. . . . . . . . . . . . 87は30について計算します。 NextHopIPAddress. . . . . . . . . . . 88
CIP Working Group [Page 4] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[4ページ]RFC1190インターネット流れのプロトコル1990年10月
Figure 31. Origin . . . . . . . . . . . . . . 88
Figure 32. OriginTimestamp . . . . . . . . . . . 89
Figure 33. ReasonCode . . . . . . . . . . . . . 89
Figure 34. RecordRoute . . . . . . . . . . . . . 94
Figure 35. SrcRoute . . . . . . . . . . . . . . 95
Figure 36. Target . . . . . . . . . . . . . . 97
Figure 37. TargetList . . . . . . . . . . . . . 97
Figure 38. UserData . . . . . . . . . . . . . . 98
Figure 39. ACCEPT Control Message . . . . . . . . . 101
Figure 40. ACK Control Message . . . . . . . . . . 102
Figure 41. CHANGE-REQUEST Control Message . . . . . . 103
Figure 42. CHANGE Control Message . . . . . . . . . 105
Figure 43. CONNECT Control Message . . . . . . . . . 109
Figure 44. DISCONNECT Control Message . . . . . . . . 110
Figure 45. ERROR-IN-REQUEST Control Message . . . . . . 111
Figure 46. ERROR-IN-RESPONSE Control Message . . . . . 112
Figure 47. HELLO Control Message . . . . . . . . . 113
Figure 48. HID-APPROVE Control Message . . . . . . . 114
Figure 49. HID-CHANGE-REQUEST Control Message . . . . . 115
Figure 50. HID-CHANGE Control Message . . . . . . . . 117
Figure 51. HID-REJECT Control Message . . . . . . . . 119
Figure 52. NOTIFY Control Message . . . . . . . . . 121
Figure 53. REFUSE Control Message . . . . . . . . . 123
Figure 54. STATUS Control Message . . . . . . . . . 125
Figure 55. STATUS-RESPONSE Control Message . . . . . . 126
Figure 56. Transmission Order of Bytes . . . . . . . 147
Figure 57. Significance of Bits . . . . . . . . . . 147
図31。 発生源. . . . . . . . . . . . . . 88は32について計算します。 OriginTimestamp. . . . . . . . . . . 89は33について計算します。 ReasonCode. . . . . . . . . . . . . 89は34について計算します。 RecordRoute. . . . . . . . . . . . . 94は35について計算します。 SrcRoute. . . . . . . . . . . . . . 95は36について計算します。 .97図37を狙ってください。 TargetList. . . . . . . . . . . . . 97は38について計算します。 UserData. . . . . . . . . . . . . . 98は39について計算します。 コントロールメッセージ. . . . . . . . . 101図40を受け入れてください。 ACKはメッセージ. . . . . . . . . . 102図41を監督します。 変更要求コントロールメッセージ. . . . . . 103は42について計算します。 コントロールメッセージ. . . . . . . . . 105図43を変えてください。 コントロールメッセージ. . . . . . . . . 109図44に接してください。 コントロールメッセージ. . . . . . . . 110が図45であると切断してください。 要求における誤りコントロールメッセージ. . . . . . 111は46について計算します。 応答制御における誤りメッセージ. . . . . 112は47について計算します。 こんにちは、メッセージ. . . . . . . . . 113図48を監督してください。 隠す、-承認してください、メッセージ. . . . . . . 114図49を監督してください。 変更要求を隠しているコントロールメッセージ. . . . . 115は50について計算します。 変化を隠しているコントロールメッセージ. . . . . . . . 117は51について計算します。 廃棄物を隠しているコントロールメッセージ. . . . . . . . 119は52について計算します。 コントロールメッセージ. . . . . . . . . 121図53に通知してください。 コントロールメッセージ. . . . . . . . . 123図54を拒否してください。 状態コントロールメッセージ. . . . . . . . . 125は55について計算します。 状態応答制御メッセージ. . . . . . 126は56について計算します。 バイト. . . . . . . 147数値57のトランスミッション命令。 ビット. . . . . . . . . . 147の意味
CIP Working Group [Page 5] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[5ページ]RFC1190インターネットストリームプロトコル1990年10月
+--------------------+
| Conference Control |
+--------------------+
|
+-------+ +-------+ |
| Video | | Voice | | +-----+ +------+ +-----+ +-----+ Application
| Appl | | Appl | | | SNMP| |Telnet| | FTP | ... | | Layer
+-------+ +-------+ | +-----+ +------+ +-----+ +-----+
| | | | | | |
V V | | | | | ------------
+-----+ +-----+ | | | | |
| PVP | | NVP | | | | | |
+-----+ +-----+ + | | | |
| \ | \ \ | | | |
| +-----|--+-----+ | | | |
| Appl.|control V V V V V
| ST data | +-----+ +-------+ +-----+
| & control| | UDP | | TCP | ... | | Transport
| | +-----+ +-------+ +-----+ Layer
| /| / | \ / / | / /|
|\ / | +------+--|--\-----+-/--|--- ... -+ / |
| \ / | | | \ / | / |
| \ / | | | \ +----|--- ... -+ | -----------
| \ / | | | \ / | |
| V | | | V | |
| +------+ | | | +------+ | +------+ |
| | SCMP | | | | | ICMP | | | IGMP | | Internet
| +------+ | | | +------+ | +------+ | Layer
| | | | | | | | |
V V V V V V V V V
+-----------------+ +-----------------------------------+
| STream protocol |->| Internet Protocol |
+-----------------+ +-----------------------------------+
| \ / |
| \ / |
| X | ------------
| / \ |
| / \ |
VV VV
+----------------+ +----------------+
| (Sub-) Network |...| (Sub-) Network | (Sub-)Network
| Protocol | | Protocol | Layer
+----------------+ +----------------+
+--------------------+ | コンファレンスコントロール| +--------------------+ | +-------+ +-------+ | | ビデオ| | 声| | +-----+ +------+ +-----+ +-----+ アプリケーション| Appl| | Appl| | | SNMP| |telnet| | FTP| ... | | 層+-------+ +-------+ | +-----+ +------+ +-----+ +-----+ | | | | | | | V V| | | | | ------------ +-----+ +-----+ | | | | | | PVP| | NVP| | | | | | +-----+ +-----+ + | | | | | \ | \ \ | | | | | +-----|--+-----+ | | | | | Appl| コントロールV対V V V| STデータ| +-----+ +-------+ +-----+ | コントロール| | UDP| | TCP| ... | | 輸送| | +-----+ +-------+ +-----+ 層| /| / | \ / / | / /| |\ / | +------+--|--\-----+-/--|--- ... -+ / | | \ / | | | \ / | / | | \ / | | | \ +----|--- ... -+ | ----------- | \ / | | | \ / | | | V| | | V| | | +------+ | | | +------+ | +------+ | | | SCMP| | | | | ICMP| | | IGMP| | インターネット| +------+ | | | +------+ | +------+ | 層| | | | | | | | | +に対するV V V V V V V V-----------------+ +-----------------------------------+ | STreamプロトコル|、-、>| インターネットプロトコル| +-----------------+ +-----------------------------------+ | \ / | | \ / | | X| ------------ | / \ | | / \ | VV VV+----------------+ +----------------+ | (サブ、) ネットワーク|...| (サブ、) ネットワーク| (サブ、)ネットワーク| プロトコル| | プロトコル| 層+----------------+ +----------------+
Figure 1. Protocol Relationships
図1。 プロトコル関係
CIP Working Group [Page 6] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[6ページ]RFC1190インターネットストリームプロトコル1990年10月
2. Introduction
2. 序論
ST has been developed to support efficient delivery of streams of packets to either single or multiple destinations in applications requiring guaranteed data rates and controlled delay characteristics. The motivation for the original protocol was that IP [2] [15] did not provide the delay and data rate characteristics necessary to support voice applications.
STは、保証されたデータ信号速度と制御遅れの特性を必要としながらアプリケーションでパケットの流れの効率的な配送を単一であるか複数の目的地にサポートするために開発されました。 オリジナルのプロトコルに関する動機はIP[2][15]が声がアプリケーションであるとサポートするのに必要な特性を遅れとデータ信号速度に提供しなかったということでした。
ST is an internet protocol at the same layer as IP, see Figure 1. ST differs from IP in that IP, as originally envisioned, did not require routers (or intermediate systems) to maintain state information describing the streams of packets flowing through them. ST incorporates the concept of streams across an internet. Every intervening ST entity maintains state information for each stream that passes through it. The stream state includes forwarding information, including multicast support for efficiency, and resource information, which allows network or link bandwidth and queues to be assigned to a specific stream. This pre-allocation of resources allows data packets to be forwarded with low delay, low overhead, and a low probability of loss due to congestion. The characteristics of a stream, such as the number and location of the endpoints, and the bandwidth required, may be modified during the lifetime of the stream. This allows ST to give a real time application the guaranteed and predictable communication characteristics it requires, and is a good vehicle to support an application whose communications requirements are relatively predictable.
図1は、STがIPと同じ層のインターネットプロトコルであると考えます。 STはIPがそれらを通して流れるパケットの流れについて説明する州の情報を保守するために、元々思い描かれるとしてルータ(または、中間システム)を必要としなかったという点においてIPと異なっています。 STはインターネットの向こう側にストリームの概念を組み込みます。 あらゆる介入しているST実体がそれを通り抜ける各ストリームのための州の情報を保守します。 ストリーム州は、情報を転送するのを含めます、ネットワークかリンク帯域幅と待ち行列が特定のストリームに割り当てられるのを許容する効率のマルチキャストサポート、およびリソース情報を含んでいて。 リソースのこのプレ配分は、データ・パケットが混雑による損失の低い遅れ、低いオーバーヘッド、および低い確率と共に進められるのを許容します。 数や、終点の位置や、必要である帯域幅などのストリームの特性はストリームの生涯変更されるかもしれません。 これは、STがそれが必要とする保証されて予測できる通信特性をリアルタイムのアプリケーションに与えるのを許容して、コミュニケーション要件が比較的予測できるアプリケーションをサポートする良い乗り物です。
ST proved quite useful in several early experiments that involved voice conferences in the Internet. Since that time, ST has also been used to support point-to-point streams that include both video and voice. Recently, multimedia conferencing applications have been developed that need to exchange real-time voice, video, and pointer data in a multi-site conferencing environment. Multimedia conferencing across an internet is an application for which ST provides ideal support. Simulation and wargaming applications [14] also place similar requirements on the communication system. Other applications may include scientific visualization between a number of workstations and one or more remote supercomputers, and the collection and distribution of real-time sensor data from remote sensor platforms. ST may also be useful to support activities that are currently supported by IP, such as bulk file transfer using TCP.
STは声の会議にインターネットにかかわったいくつかの早めの実験でかなり有用であることが分かりました。 また、その時以来、STは、ビデオと声の両方を含んでいる二地点間ストリームをサポートするのに使用されています。 最近、マルチサイト会議環境におけるリアルタイムの声、ビデオ、およびポインタデータを交換する必要があるマルチメディア会議アプリケーションを開発してあります。 インターネットの向こう側のマルチメディア会議はSTが理想的なサポートを提供するアプリケーションです。 また、シミュレーションとアプリケーション[14]について机上で検討すると、同様の要件は通信系に置かれます。 他のアプリケーションは多くのワークステーションと1つ以上のリモートスーパーコンピュータの間のサイエンティフィック・ビジュアライゼーション、および遠く離れたセンサプラットホームからのリアルタイムのセンサデータの集散を含むかもしれません。また、STも現在IPによってサポートされる活動をサポートするために役に立つかもしれません、TCPを使用する大容量ファイル転送などのように。
Transport protocols above ST include the Packet Video Protocol (PVP) [5] and the Network Voice Protocol (NVP) [4], which are end-to-end protocols used directly by applications. Other transport layer protocols that may be used over ST include TCP [16], VMTP [3], etc. They provide the user interface, flow control, and packet ordering. This specification does not describe these higher layer protocols.
STの上のトランスポート・プロトコルはPacket Videoプロトコル(PVP)[5]とNetwork Voiceプロトコル(NVP)[4]を含んでいます。([4]は終わりから終わりへの直接アプリケーションで使用されるプロトコルです)。 STの上で使用されるかもしれない他のトランスポート層プロトコルはTCP[16]、VMTP[3]などを含んでいます。 彼らはユーザーインタフェース、フロー制御、およびパケット注文を提供します。 この仕様はこれらのより高い層のプロトコルについて説明しません。
CIP Working Group [Page 7] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[7ページ]RFC1190インターネットストリームプロトコル1990年10月
2.1. Major Differences Between ST and ST-II
2.1. 第そして、間の主要な違い、第-、II
ST-II supports a wider variety of applications than did the
original ST. The differences between ST and ST-II are fairly
straight forward yet provide great improvements. Four of the more
notable differences are:
ST-IIはオリジナルのSTより広いバラエティーのアプリケーションをサポートします。STとST-IIの違いは、前方でかなりまっすぐですが、かなりの改良を提供します。 4つのより注目に値する違いは以下の通りです。
1 ST-II is decoupled from the Access Controller (AC). The
AC, as well as providing a rudimentary access control
function, also served as a centralized repository and
distributor of the conference information. If an AC is
necessary, it should be an entity in a higher layer
protocol. A large variety of applications such as
conferencing, distributed simulations, and wargaming can
be run without an explicit AC.
標準時1IIはAccess Controller(西暦)から衝撃を吸収されます。 また、初歩的なアクセス制御機能を提供することと同様に、西暦は会議情報の集結された倉庫とディストリビュータとして勤めました。 西暦が必要であるなら、それは、より高い層のプロトコルの実体であるべきです。 明白な西暦なしで会議や、分配されたシミュレーションや、机上で検討などのさまざまなアプリケーションを実行されることができます。
2 The basic stream construct of ST-II is a directed tree
carrying traffic away from a source to all the
destinations, rather than the original ST's omniplex
structure. For example, a conference is composed of a
number of such trees, one for traffic from each
participant. Although there are more (simplex) streams in
ST-II, each is much simpler to manage, so the aggregate is
much simpler. This change has a minimal impact on the
application.
2 ST-IIの基本的なストリーム構造物はソースからオリジナルのSTのomniplex構造よりむしろすべての目的地までトラフィックを運び去る指示された木です。 例えば、会議はそのような多くの木、各関係者からのトラフィックのためのもので構成されます。 より多くの(シンプレクス)ストリームがST-IIにありますが、それぞれは管理するのがはるかに簡単であるので、集合ははるかに簡単です。 この変化は最小量の影響力をアプリケーションに持っています。
3 ST-II defines a number of the robustness and recovery
mechanisms that were left undefined in the original ST
specification. In case of a network or ST Agent failure,
a stream may optionally be repaired automatically (i.e.,
without intervention from the user or the application)
using a pruned depth first search starting at the ST Agent
immediately preceding the failure.
標準時3IIは当初のST仕様で未定義の状態で残された多くの丈夫さと回収機構を定義します。 ネットワークかSTエージェントの故障の場合には、ストリームは、すぐに失敗に先行するSTエージェントで始まる深さの剪定された第1検索を使用することで任意に自動的(すなわち、ユーザかアプリケーションからの介入なしで)に修理されるかもしれません。
4 ST-II does not make an inherent distinction between
streams connecting only two communicants and streams among
an arbitrary number of communicants.
標準時4IIは、聖餐拝受者の特殊活字の数字の中で2人の聖餐拝受者とストリームだけに接しながら、ストリームの間で固有の区別をしません。
This memo is the specification for the ST-II Protocol. Since
there should be no ambiguity between the original ST specification
and the specification herein, the protocol is simply called ST
hereafter.
このメモはST-IIプロトコルのための仕様です。 当初のST仕様と仕様の間には、あいまいさが全くここにあるべきでないので、プロトコルは単に今後STと呼ばれます。
ST is the protocol used by ST entities to exchange information.
The same protocol is used for communication among all ST entities,
whether they communicate with a higher layer protocol or forward
ST packets between attached networks.
STはST実体によって使用される、情報交換するプロトコルです。 同じプロトコルはすべてのST実体の中のコミュニケーションに使用されます、それらが付属ネットワークの間の、より高い層のプロトコルか前進のSTパケットで交信するか否かに関係なく。
The remainder of this section gives a brief overview of the ST
Protocol. Section 3 (page 17) provides a detailed description of
the operations required by the protocol. Section 4 (page 75)
provides descriptions of the ST Protocol Data Units exchanged
このセクションの残りはSTプロトコルの簡潔な概要を与えます。 セクション3(17ページ)はプロトコルによって必要とされた操作の詳述を提供します。 セクション4(75ページ)はプロトコルData Unitsが交換したSTの記述を提供します。
CIP Working Group [Page 8] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[8ページ]RFC1190インターネットストリームプロトコル1990年10月
between ST entities. Issues that have not yet been fully
addressed are presented in Section 5 (page 131). A glossary and
list of references are in Sections 6 (page 135) and 7 (page 143),
respectively.
ST実体の間で。 まだ完全に扱われるというわけではなかった問題はセクション5(131ページ)に提示されます。 それぞれセクション6(135ページ)と7(143ページ)には用語集と参考文献一覧があります。
This memo also defines "subsets" of ST that can be implemented. A
subsetted implementation does not have full ST functionality, but
it can interoperate with other similarly subsetted
implementations, or with a full implementation, in a predictable
and consistent manner. This approach allows an implementation to
be built and provide service with minimum effort, and gives it an
immediate and well defined growth path.
また、このメモは実装することができるSTの「部分集合」を定義します。 subsetted実装には、完全なSTの機能性がありませんが、他の同様にsubsettedされた実装、または完全な実施で共同利用できます、予測できて一貫した方法で。 このアプローチは、実装が組み込まれて、最小努力をサービスに提供するのを許容して、即座の、そして、よく定義された成長経路をそれに与えます。
2.2. Concepts and Terminology
2.2. 概念と用語
The ST packet header is not constrained to be compatible with the
IP packet header, except for the IP Version Number (the first four
bits) that is used to distinguish ST packets (IP Version 5) from
IP packets (IP Version 4). The ST packets, or protocol data units
(PDUs), can be encapsulated in IP either to provide connectivity
(possibly with degraded service) across portions of an internet
that do not provide support for ST, or to allow access to services
such as security that are not provided directly by ST.
STパケットのヘッダーはIPパケットのヘッダーと互換性があるのが抑制されません、IPパケット(IPバージョン4)とSTパケット(IPバージョン5)を区別するのに使用されるIPバージョンNumber(最初の4ビット)を除いて。 接続性(ことによると降格しているサービスがある)をSTのサポートを提供しないインターネットの部分の向こう側に提供するか、または直接STによって提供されないセキュリティなどのサービスへのアクセスを許すために、IPでSTパケット、またはプロトコルデータ単位(PDUs)をカプセルに入れることができます。
An internet entity that implements the ST Protocol is called an
"ST Agent". We refer to two kinds of ST agents: "host ST
agents", also called "host agents" and "intermediate ST agents",
also called "intermediate agents". The ST agents functioning as
hosts are sourcing or sinking data to a higher layer protocol or
application, while ST agents functioning as intermediate agents
are forwarding data between directly attached networks. This
distinction is not part of the protocol, but is used for
conceptual purposes only. Indeed, a given ST agent may be
simultaneously performing both host and intermediate roles. Every
ST agent should be capable of delivering packets to a higher layer
protocol. Every ST agent can replicate ST data packets as
necessary for multi-destination delivery, and is able to send
packets whether received from a network interface or a higher
layer protocol. There are no other kinds of ST agents.
STがプロトコルであると実装するインターネット実体は「第エージェント」と呼ばれます。 私たちは2種類のSTエージェントについて言及します: また、「仲介物質」と、また、「ホストエージェントと中間的STエージェント」と呼ばれた「ホストSTエージェント」は呼びました。 ホストとして機能するSTエージェントは、より高い層のプロトコルかアプリケーションにデータを出典を明示するか、または沈めています、仲介物質として機能するSTエージェントが直接付属しているネットワークの間にデータを転送している間。 この区別は、プロトコルの一部ではありませんが、概念的な目的だけに使用されます。 本当に、与えられたSTエージェントは同時に、ホストと中間的役割の両方を実行するかもしれません。 すべてのSTエージェントが、より高い層のプロトコルにパケットを提供できるべきです。 すべてのSTエージェントが、マルチの目的地配送に必要に応じてSTデータ・パケットを模写できて、ネットワーク・インターフェースか、より高い層のプロトコルから受け取るか否かに関係なく、パケットを送ることができます。 STエージェントの他の種類が全くありません。
ST provides applications with an end-to-end flow oriented service
across an internet. This service is implemented using objects
called "streams". ST data packets are not considered to be
totally independent as are IP data packets. They are transmitted
only as part of a point-to-point or point-to-multi- point stream.
ST creates a stream during a setup phase before data is
transmitted. During the setup phase, routes are selected and
internetwork resources are reserved. Except for explicit changes
to the stream, the routes remain in effect until the stream is
explicitly torn down.
STはインターネットの向こう側に終わりから終わりへの流動に伴うアプリケーションに指向のサービスを提供します。 このサービスは、「ストリーム」と呼ばれるオブジェクトを使用することで実装されます。 STデータ・パケットがIPデータ・パケットのように完全に独立していると考えられません。 それらは単にポイントからポイントツーポイントかマルチポイントへのストリームの一部として伝えられます。 データが送られる前にSTはセットアップ段階の間、ストリームを作成します。 セットアップ段階の間、ルートは選択されます、そして、インターネットワークリソースは予約されています。 ストリームへの明白な変化を除いて、ルートは明らかに小川を取りこわすまで有効なままで残っています。
CIP Working Group [Page 9] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[9ページ]RFC1190インターネットストリームプロトコル1990年10月
An ST stream is:
STストリームは以下の通りです。
o the set of paths that data generated by an application
entity traverses on its way to its peer application
entity(s) that receive it,
o データがアプリケーション実体で生成した経路のセットは受信される同輩アプリケーション実体への途中にそれを横断します。
o the resources allocated to support that transmission of
data, and
o そしてリソースがデータのその伝達をサポートに割り当てた。
o the state information that is maintained describing that
transmission of data.
o データのその伝達について説明しながら保守される州の情報。
Each stream is identified by a globally unique "Name"; see
Section 4.2.2.8 (page 87). The Name is specified in ST control
operations, but is not used in ST data packets. A set of streams
may be related as members of a larger aggregate called a "group".
A group is identified by a "Group Name"; see Section 3.7.3 (page
56).
各ストリームはグローバルにユニークな「名前」によって特定されます。 セクション4.2を見てください。.2 .8(87ページ)。 NameはST制御機能で指定されますが、STデータ・パケットで使用されません。 「グループ」と、より大きい集合のメンバーが呼んだように1セットの流れは関係づけられるかもしれません。 グループは「グループ名」によって特定されます。 セクション3.7.3(56ページ)を見てください。
The end-users of a stream are called the "participants" in the
stream. Data travels in a single direction through any given
stream. The host agent that transmits the data into the stream is
called the "origin", and the host agents that receive the data are
called the "targets". Thus, for any stream one participant is the
origin and the others are the targets.
ストリームのエンドユーザはストリームの「関係者」と呼ばれます。 データはどんな与えられたストリームを通ってもただ一つの方向に移動します。 データをストリームに送るホストエージェントは「発生源」と呼ばれます、そして、データを受信するホストエージェントは「目標」と呼ばれます。 したがって、1人の関係者がどんなストリームのための、発生源です、そして、他のものは目標です。
A stream is "multi-destination simplex" since data travels across
it in only one direction: from the origin to the targets. A
stream can be viewed as a directed tree in which the origin is the
root, all the branches are directed away from the root toward the
targets, which are the leaves. A "hop" is an edge of that tree.
The ST agent that is on the end of an edge in the direction toward
the origin is called the "previous-hop ST agent", or the
"previous-hop". The ST agents that are one hop away from a
previous-hop ST agent in the direction toward the targets are
called the "next-hop ST agents", or the "next-hops". It is
possible that multiple edges between a previous-hop and several
next-hops are actually implemented by a network level multicast
group.
データがそれの向こう側に一方向だけに移動するので、ストリームは「マルチの目的地シンプレクス」です: 発生源から目標まで。 発生源が根である指示された木としてストリームを見なすことができて、すべてのブランチが根から遠くに目標に向けられます。(目標は葉です)。 「ホップ」はその木の縁です。 発生源に向かった方向への縁の端にいるSTエージェントは「前のホップSTエージェントか、前のホップ」と呼ばれます。 遠くで目標に向かった方向に前のホップSTエージェントからワンバウンドであることのSTエージェントは「次のホップSTエージェントか、次のホップ」と呼ばれます。 前のホップといくつかの次のホップの間の複数の縁が実際にネットワークレベルマルチキャストグループによって実装されるのは、可能です。
Packets travel across a hop for one of two purposes: data or
control. For ST data packet handling, hops are marked by "Hop
IDentifiers" (HIDs) used for efficient forwarding instead of the
stream's Name. A HID is negotiated among several agents so that
data forwarding can be done efficiently on both a point-to-point
and multicast basis. All control message exchange is done on a
point-to-point basis between a pair of agents. For control
message handling, Virtual Link Identifiers are used to quickly
dispatch the control messages to the proper stream's state
machine.
パケットは2つの目的の1つのためにホップの向こう側に移動します: データかコントロール。 STデータ・パケット取り扱いにおいて、ストリームのNameの代わりに効率的な推進に使用される「ホップ識別子」(HIDs)によってホップはマークされます。 HIDは、データ推進が交渉されるように、数人のエージェントの中で交渉されます。効率的に、両方では、ポイントツーポイントとマルチキャスト基礎をします。 1組のエージェントの間の二地点間ベースですべてのコントロール交換処理をします。 コントロールメッセージハンドリングにおいて、Virtual Link Identifiersは、すばやく適切なストリームの州のマシンにコントロールメッセージを派遣するのに使用されます。
CIP Working Group [Page 10] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[10ページ]RFC1190インターネットストリームプロトコル1990年10月
ST requires routing decisions to be made at several points in the
stream setup and management process. ST assumes that an
appropriate routing algorithm exists to which ST has access; see
Section 3.8.1 (page 69). However, routing is considered to be a
separate issue. Thus neither the routing algorithm nor its
implementation is specified here. A routing algorithm may attempt
to minimize the number of hops to the target(s), or it may be more
intelligent and attempt to minimize the total internet resources
consumed. ST operates equally well with any reasonable routing
algorithm. The availability of a source routing option does not
eliminate the need for an appropriate routing algorithm in ST
agents.
STは、数ポイントでストリームセットアップと管理過程で作られているという決定を発送するのを必要とします。 STは、適切なルーティング・アルゴリズムがどのSTにアクセスがあるかに存在すると仮定します。 セクション3.8.1(69ページ)を見てください。 しかしながら、ルーティングは別個問題であると考えられます。 したがって、ルーティング・アルゴリズムもその実装もここで指定されません。 ルーティング・アルゴリズムが、ホップの数を目標に最小にするのを試みるかもしれないか、それは、より知的であり、リソースが消費した総インターネットを最小にするのを試みるかもしれません。 STはどんな合理的なルーティング・アルゴリズムでも等しく井戸を操作します。 ソースルーティングオプションの有用性はSTエージェントで適切なルーティング・アルゴリズムの必要性を排除しません。
2.3. Relationship Between Applications and ST
2.3. 第そしてアプリケーションの間の関係。
It is the responsibility of an ST application entity to exchange
information among its peers, usually via IP, as necessary to
determine the structure of the communication before establishing
the ST stream. This includes:
STストリームを確立する前にコミュニケーションの構造を決定するのは、同輩の中の交換情報と通常必要に応じてIPを通したSTアプリケーション実体の責任です。 これは:
o identifying the participants,
o 関係者を特定します。
o determining which are targets for which origins,
o どれがどの発生源のための目標であるかを決定します。
o selecting the characteristics of the data flow between any
origin and its target(s),
o どんな発生源とその目標の間のデータフローの特性を選択します。
o specifying the protocol that resides above ST,
o STの上にあるプロトコルを指定します。
o identifying the Service Access Point (SAP), port, or
socket relevant to that protocol at every participant, and
o そしてすべての関係者でそのプロトコルに関連しているService Access Point(SAP)、ポート、またはソケットを特定する。
o ensuring security, if necessary.
o 必要なら、セキュリティを確実にします。
The protocol layer above ST must pass such information down to the
ST protocol layer when creating a stream.
ストリームを作成するとき、STの上のプロトコル層はそのような情報をSTプロトコル層まで通過しなければなりません。
ST uses a flow specification, abbreviated herein as "FlowSpec", to
describe the required characteristics of a stream. Included are
bandwidth, delay, and reliability parameters. Additional
parameters may be included in the future in an extensible manner.
The FlowSpec describes both the desired values and their minimal
allowable values. The ST agents thus have some freedom in
allocating their resources. The ST agents accumulate information
that describes the characteristics of the chosen path and pass
that information to the origin and the targets of the stream.
STは、ストリームの必要な特性について説明するのに"FlowSpec"がここに簡略化された流れ仕様を使用します。 含まれているのは、帯域幅と、遅れと、信頼性特性値です。 追加パラメタは将来、広げることができる方法に含まれるかもしれません。 FlowSpecは目標値とそれらの最小量の許容量の両方について説明します。 その結果、STエージェントは彼らのリソースを割り当てる際に何らかの自由を持っています。 STエージェントは、選んだ道の特性について説明する情報を蓄積して、ストリームの発生源と目標にその情報を通過します。
ST stream setup control messages carry some information that is
not specifically relevant to ST, but is passed through the
interface to the protocol that resides above ST. The "next
STストリームセットアップコントロールメッセージは明確にSTに関連していませんが、インタフェースをST「次」の上にあるプロトコルに通り抜ける何らかの情報を運びます。
CIP Working Group [Page 11] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[11ページ]RFC1190インターネットストリームプロトコル1990年10月
protocol identifier" ("NextPcol") allows ST to demultiplex streams
to a number of possible higher layer protocols. The SAP
associated with each participant allows the higher layer protocol
to further demultiplex to a specific application entity. A
UserData parameter is provided; see Section 4.2.2.16 (page 98).
「プロトコル識別子」("NextPcol")は多くの可能なより高い層のプロトコルへの「反-マルチプレックス」ストリームにSTを許容します。 各関係者に関連しているSAPは、特定のアプリケーション実体に「反-マルチプレックス」を促進するために、より高い層のプロトコルを許容します。 UserDataパラメタを提供します。 セクション4.2を見てください。.2 .16(98ページ)。
2.4. ST Control Message Protocol
2.4. メッセージプロトコルを第制御してください。
ST agents create and manage a stream using the ST Control Message
Protocol (SCMP). Conceptually, SCMP resides immediately above ST
(as does ICMP above IP) but is an integral part of ST. Control
messages are used to:
STエージェントは、ST Control Messageプロトコル(SCMP)を使用することでストリームを作成して、管理します。 概念的に、SCMPはST(IPの上のICMPのような)のすぐ上に住んでいますが、STの不可欠の部分です。コントロールメッセージは以下のことに使用されます。
o create streams,
o ストリームを作成してください。
o refuse creation of a stream,
o ストリームの作成を拒否してください。
o delete a stream in whole or in part,
o 全体か一部ストリームを削除してください。
o negotiate or change a stream's parameters,
o ストリームのパラメタを交渉するか、または変えてください。
o tear down parts of streams as a result of router or
network failures, or transient routing inconsistencies,
and
o そしてルータ、ネットワーク失敗、または一時的なルーティング矛盾の結果、ストリームの部品を取りこわしてください。
o reroute around network or component failures.
o ネットワークかコンポーネント失敗の周りでコースを変更してください。
SCMP follows a request-response model. SCMP reliability is
ensured through use of retransmission after timeout; see Section
3.7.6 (page 66).
SCMPは要求応答モデルに従います。 SCMPの信頼性はタイムアウトの後に「再-トランスミッション」の使用で確実にされます。 セクション3.7.6(66ページ)を見てください。
An ST application that will transmit data requests its local ST
agent, the origin, to create a stream. While only the origin
requests creation of a stream, all the ST agents from the origin
to the targets participate in its creation and management. Since
a stream is simplex, each participant that wishes to transmit data
must request that a stream be created.
データを送るSTアプリケーションは、ストリームを作成するよう地元のSTエージェント、発生源に要求します。 発生源だけがストリームの作成を要求している間、すべての発生源から目標までのSTエージェントがその作成と管理に参加します。 ストリームがシンプレクスであるので、データを送りたがっている各関係者は、ストリームが作成されるよう要求しなければなりません。
An ST agent that receives an indication that a stream is being
created must:
ストリームが作成されているという指示を受けるSTエージェントはそうしなければなりません:
1 negotiate a HID with the previous-hop identifying the
stream,
1 ストリームを特定する前のホップとHIDを交渉してください。
2 map the list of targets onto a set of next-hop ST agents
through the routing function,
2は経路選択機能を通して1セットの次のホップSTエージェントに目標のリストを写像します。
3 reserve the local and network resources required to
support the stream,
3は地方を予約します、そして、ネットワーク資源がストリームをサポートするのが必要です。
CIP Working Group [Page 12] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[12ページ]RFC1190インターネットストリームプロトコル1990年10月
4 update the FlowSpec, and
そして4がFlowSpecをアップデートする。
5 propagate the setup information and partitioned target
list to the next-hop ST agents.
5はセットアップ情報と仕切られた目標リストを次のホップSTエージェントに伝播します。
When a target receives the setup message, it must inquire from the
specified application process whether or not it is willing to
accept the stream, and inform the origin accordingly.
目標がセットアップメッセージを受け取るとき、それは、指定されたアプリケーション・プロセスからストリームを受け入れる、それに従って、発生源を知らせても構わないと思っているかどうか問い合わせなければなりません。
Once a stream is established, the origin can safely send data. ST
and its implementations are optimized to allow fast and efficient
forwarding of data packets by the ST agents using the HIDs, even
at the cost of adding overhead to stream creation and management.
Specifically, the forwarding decisions, that is, determining the
set of next-hop ST agents to which a data packet belonging to a
particular stream will be sent, are made during the stream setup
phase. The shorthand HIDs are negotiated at that time, not only
to reduce the data packet header size, but to access efficiently
the stream's forwarding information. When possible, network-layer
multicast is used to forward a data packet to multiple next-hop ST
agents across a network. Note that when network-layer multicast
is used, all members of the multicast group must participate in
the negotiation of a common HID.
ストリームがいったん確立されると、発生源は安全にデータを送ることができます。 STとその実装はHIDsを使用することでSTエージェントによるデータ・パケットの速くて効率的な推進を許すために最適化されます、作成と管理を流すためにオーバーヘッドを加える費用でさえ。 明確に、すなわち、特定のストリームに属すデータ・パケットが送られる次のホップSTエージェントのセットを決定して、ストリームセットアップ段階の間、推進決定をします。 速記HIDsは、その時、データ・パケットヘッダーサイズを単に減少させるのではなく、効率的にストリームの推進情報にアクセスするために交渉されます。 可能であるときに、ネットワーク層マルチキャストは、ネットワークの向こう側に複数の次のホップSTエージェントにデータ・パケットを送るのに使用されます。 ネットワーク層マルチキャストが使用されているとき、マルチキャストグループのすべてのメンバーが一般的なHIDの交渉に参加しなければならないことに注意してください。
An established stream can be modified by adding or deleting
targets, or by changing the network resources allocated to it. A
stream may be torn down by either the origin or the targets. A
target can remove itself from a stream leaving the others
unaffected. The origin can similarly remove any subset of the
targets from its stream leaving the remainder unaffected. An
origin can also remove all the targets from the stream and
eliminate the stream in its entirety.
目標を加えるか、削除すること、またはそれに割り当てられたネットワーク資源を変えることによって、確立したストリームを変更できます。 発生源か目標のどちらかは小川を取りこわすかもしれません。 他のものを影響を受けないままにして、目標はストリームから立ち退くことができます。 残りを影響を受けないままにして、発生源はストリームから目標のどんな部分集合も同様に取り除くことができます。 発生源は、また、ストリームからすべての目標を取り外して、ストリームを全体として排除できます。
A stream is monitored by the involved ST agents. If they detect a
failure, they can attempt recovery. In general, this involves
tearing down part of the stream and rebuilding it to bypass the
failed component(s). The rebuilding always occurs from the origin
side of the failure. The origin can optionally specify whether
recovery is to be attempted automatically by intermediate ST
agents or whether a failure should immediately be reported to the
origin. If automatic recovery is selected but an intermediate
agent determines it cannot effect the repair, it propagates the
failure information backward until it reaches an agent that can
effect repair. If the failure information propagates back to the
origin, then the application can decide if it should abort or
reattempt the recovery operation.
ストリームはかかわったSTエージェントによってモニターされます。 失敗を検出するなら、彼らは回復を試みることができます。 一般に、これは、ストリームの一部を取りこわして、失敗したコンポーネントを迂回させるためにそれを再建することを伴います。 再建は失敗の発生源側からいつも起こります。 発生源は、回復が中間的STエージェントによって自動的に試みられるかどうかことであるまたは失敗がすぐに発生源に報告されるべきであるかどうか任意に指定できます。 自動復旧が選択されますが、仲介物質が、修理に作用できないと決心しているなら、それは修理に作用できるエージェントに届くまで失敗情報を後方に伝播します。 失敗情報が発生源に伝播して戻られるなら、アプリケーションが、それが中止になるべきであるかどうか決めることができますか、または「再-試み」は回復動作について決めます。
CIP Working Group [Page 13] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[13ページ]RFC1190インターネットストリームプロトコル1990年10月
Although ST supports an arbitrary connection structure, we
recognize that certain stream topologies will be common and
justify special features, or options, which allow for optimized
support. These include:
STは任意の接続構造を支えますが、私たちは、あるストリームtopologiesが一般的になると認めて、最適化されたサポートを考慮する特徴、またはオプションを正当化します。 これらは:
o streams with only a single target (see Section 3.6.2 (page
44)), and
o そしてただ一つの目標(セクション3.6.2(44ページ)を見る)だけがあるストリーム。
o pairs of streams to support full duplex communication
between two points (see Section 3.6.3 (page 45)).
o ストリームの組は2の間のサポート全二重通信に指します(セクション3.6.3(45ページ)を見てください)。
These features allow the most frequently occurring topologies to
be supported with less setup delay, with fewer control messages,
and with less overhead than the more general situations.
これらの特徴で、最も頻繁に起こっているtopologiesは、より少ないセットアップ遅れ、より少ないコントロールメッセージ、および、より一般的な状況より少ないオーバーヘッドでサポートします。
2.5. Flow Specifications
2.5. 流れ仕様
Real time data, such as voice and video, have predictable
characteristics and make specific demands of the networks that
must transfer it. Specifically, the data may be transmitted in
packets of a constant size that are produced at a constant rate.
Alternatively, the bandwidth may vary, due either to variable
packet size or rate, with a predefined maximum, and perhaps a
non-zero minimum. The variation may also be predictable based on
some model of how the data is generated. Depending on the
equipment used to generate the data, the packet size and rate may
be negotiable. Certain applications, such as voice, produce
packets at the given rate only some of the time. The networks
that support real time data must add minimal delay and delay
variance, but it is expected that they will be non-zero.
声やビデオなどのリアルタイムのデータは、予測できる特性を持って、それを移さなければならないネットワークの特定の要求をします。 明確に、データは一定の割合で作り出される一定のサイズのパケットで送られるかもしれません。 あるいはまた、帯域幅は異なるかもしれません、どちらか可変パケットサイズかレートに当然です、事前に定義された最大、および恐らく非ゼロ最小限で。 また、変化もデータがどう発生しているかに関するモデルに基づいて予測できるかもしれません。 データを生成するのに使用される設備、パケットサイズ、およびレートに依存するのは交渉可能であるかもしれません。 声などのあるアプリケーションは与えられたレートで時々だけパケットを作り出します。 リアルタイムのデータをサポートするネットワークは最小量の遅れと遅れ変化を加えなければなりませんが、それらが非ゼロになると予想されます。
The FlowSpec is used for three purposes. First, it is used in the
setup message to specify the desired and minimal packet size and
rate required by the origin. This information is used by ST
agents when they attempt to reserve the resources in the
intervening networks. Second, when the setup message reaches the
target, the FlowSpec contains the packet size and rate that was
actually obtained along the path from the origin, and the accrued
mean delay and delay variance expected for data packets along that
path. This information is used by the target to determine if it
wishes to accept the connection. The target may reduce reserved
resources if it wishes to do so and if the possibility is still
available. Third, if the target accepts the connection, it
returns the updated FlowSpec to the origin, so that the origin can
decide if it still wishes to participate in the stream with the
characteristics that were actually obtained.
FlowSpecは3つの目的に使用されます。 まず最初に、それは発生源によって必要とされた必要で最小量のパケットサイズとレートを指定するセットアップメッセージで使用されます。 彼らが、いつ介入しているネットワークでリソースを予約するのを試みるかというこの情報はSTエージェントによって使用されます。 2番目に、セットアップメッセージが目標に達すると、FlowSpecは発生源からの経路に沿って実際に得られたパケットサイズとレートを保管していて、その経路に沿ってデータ・パケットのために予想された生じた意地悪な遅れと遅れ変化を保管しています。 この情報は目標によって使用されて、それが接続を受け入れたがっているかどうか決定します。 そうしたがっていて、可能性がまだ利用可能であるなら、目標は予約されたリソースを減らすかもしれません。 3番目、目標が接続を受け入れるなら、アップデートされたFlowSpecを発生源に返します、発生源が、それが実際に得られた特性でまだストリームに参加していたがっているかどうか決めることができるように。
CIP Working Group [Page 14] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[14ページ]RFC1190インターネットストリームプロトコル1990年10月
When the data transmitted by stream users is generated at varying
rates, including bursts of varying rate and duration, there is an
opportunity to provide service to more subscribers by providing
guaranteed service for the average data rate of each stream, and
reserving additional network capacity, shared among all streams,
to service the bursts. This concept has been recognized by analog
voice network providers leading to the principle of time assigned
speech interpolation (TASI) in which only the talkspurts of a
speech conversation are transmitted, and, during silence periods,
the circuit can be used to send the talkspurts of other
conversations. The FlowSpec is intended to assist algorithms that
perform similar kinds of functions. We do not propose such
algorithms here, but rather expect that this will be an area for
experimentation. To allow for experiments, and a range of ways
that application traffic might be characterized, a "DutyFactor" is
included in the FlowSpec and we expect that a "burst descriptor"
will also be needed.
ストリームユーザによって送られたデータが異なったレートと持続時間の炸裂を含むある異なったレートで生成されるとき、提供することによって、より多くの加入者に対するサービスを提供する機会は各ストリームと、炸裂を修理するためにすべてのストリームの中で共有された追加ネットワーク容量を予約する平均したデータ信号速度のためにアフターサービスを保証しました。 スピーチの会話のtalkspurtsだけが伝えられる音声挿入(TASI)が割り当てられた時間の原則につながるアナログの声のネットワーク内の提供者でこの概念を認識しました、そして、沈黙の期間、他の会話のtalkspurtsを送るのに回路を使用できます。 FlowSpecが同様の種類の関数を実行するアルゴリズムを補助することを意図します。 私たちはここでそのようなアルゴリズムを提案しませんが、これが実験のために領域になるとむしろ予想してください。 実験、およびアプリケーショントラフィックが特徴付けられるかもしれないさまざまな方法を考慮するために、"DutyFactor"はFlowSpecで入れられています、そして、私たちはまた、「炸裂記述子」が必要であると予想します。
The FlowSpec will need to be revised as experience is gained with
connections involving numerous participants using multiple media
across heterogeneous internetworks. We feel a change of the
FlowSpec does not necessarily require a new version of ST, it only
requires the FlowSpec version number be updated and software to
manage the new FlowSpec to be distributed. We further suggest
that if the change to the FlowSpec involves additional information
for improved operation, such as a burst descriptor, that it be
added to the end of the FlowSpec and that the current parameters
be maintained so that obsolete software can be used to process the
current parameters with minimum modifications.
FlowSpecは、異種のインターネットワークの向こう側にマルチメディアを使用することで接続が多数の関係者にかかわっていて経験するのに従って改訂される必要があるでしょう。 アップデートしてください。私たちが、FlowSpecの変化が必ずSTの新しいバージョンを必要とするというわけではないと感じて、FlowSpecバージョン番号を必要とするだけである、そして、分配されるために新しさFlowSpecを管理するソフトウェア。 FlowSpecへの変化が炸裂記述子などの改良された操作のためのそれがFlowSpecの端に加えられて、現在のパラメタが最小の変更で現在のパラメタを処理するのに一般的に使われなくなったソフトウェアを使用できるように維持されるという追加情報にかかわるなら、私たちはさらにそれを勧めます。
CIP Working Group [Page 15] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[15ページ]RFC1190インターネットストリームプロトコル1990年10月
**** ****
* * ST Agent 1 * * +---+
* *------- o ---------* *-------+ B |
* * * * +---+
* * ****
+---+ * * |
| | * * |
| A +---------* * o ST Agent 3
| | * * |
+---+ * * |
* * ***
* * * * +---+
* * ST Agent 2 * *-------+ C |
* *------- o --------* * +---+
* * * *
**** * *
* *
+---+ * * +---+
| E +--------* *-------+ D |
+---+ * * +---+
***
**** **** * * エージェント1*第*+---+ * *------- o ---------* *-------+ B| * * * * +---+ * * **** +---+ * * | | | * * | | +---------* * o 第エージェント3| | * * | +---+ * * | * * *** * * * * +---+ **第エージェント2**-------+ C| * *------- o --------* * +---+ * * * * **** * * * * +---+ * * +---+ | E+--------* *-------+ D| +---+ * * +---+ ***
Figure 2. Topology Used in Protocol Exchange Diagrams
図2。 プロトコル交換ダイヤグラムで使用されるトポロジー
**** ST Agent 1 ****
* +--+---14--- o -----15--+----+--44---+---+
* | +-+--11--- -----16--+-+ * | B |
* | | * * |+-+--45---+---+
* | | * *++*
+---+ * | | * 34 ||32
| +----4----+--+ | * ||
| A +----6----+----+ * o ST Agent 3
| +----5----+---+ * |
+---+ * | * | 33
* | * ST *+*
* | * Agent * | *
* | * 2 -----24-+--+ * +---+
* +--+--23--- o -----25-+-----+--54---+ C |
* * -----26-+---+ * +---+
**** -----27-+-+ | *
* | | *
+---+ * | | * +---+
| E +---74---+-+ +-+--64---+ D |
+---+ * * +---+
***
**** エージェント1*****+第--、+---14--- o -----15--+----+--44---+---+ * | +-+--11--- -----16--+-+ * | B| * | | * * |+-+--45---+---+ * | | * *++* +---+ * | | * 34 ||32 | +----4----+--+ | * || | +----6----+----+ *o STエージェント3| +----5----+---+ * | +---+ * | * | 33 * | * *+*第*| * エージェント*| * * | * 2 -----24-+--+ * +---+ * +--+--23--- o -----25-+-----+--54---+ C| * * -----26-+---+ * +---+ **** -----27-+-+ | * * | | * +---+ * | | * +---+ | E+---74---+-+ +-+--64---+ D| +---+ * * +---+ ***
Figure 3. Virtual Link Identifiers for SCMP Messages
図3。 SCMPメッセージのための仮想のリンク識別子
CIP Working Group [Page 16] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[16ページ]RFC1190インターネット流れのプロトコル1990年10月
3. ST Control Message Protocol Functional Description
3. メッセージのプロトコルの機能的な記述を第制御してください。
This section contains a functional description of the ST Control Message Protocol (SCMP); Section 4 (page 75) specifies the formats of the control message PDUs. We begin with a description of stream setup. Mechanisms used to deal with the exceptional cases are then presented. Complications due to options that an application or a ST agent may select are then detailed. Once a stream has been established, the data transfer phase is entered; it is described. Once the data transfer phase has been completed, the stream must be torn down and resources released; the control messages used to perform this function are presented. The resources or participants of a stream may be changed during the lifetime of the stream; the procedures to make changes are described. Finally, the section concludes with a description of some ancillary functions, such as failure detection and recovery, HID negotiation, routing, security, etc.
このセクションはST Control Messageプロトコル(SCMP)の機能的な記述を含みます。 セクション4(75ページ)はコントロールメッセージPDUsの形式を指定します。 私たちは流れのセットアップの記述で始めます。 そして、例外的なケースに対処するのに使用されるメカニズムは提示されます。 アプリケーションかSTエージェントが選択するかもしれないオプションによる複雑さはその時、詳細です。 流れがいったん確立されると、データ転送段階は入れられます。 それは説明されます。 そして、いったんデータ転送段階を完成すると、小川を取りこわさなければならない、発表されたリソース。 この機能を実行するのに使用されるコントロールメッセージは提示されます。 流れの生涯流れのリソースか関係者を変えるかもしれません。 変更を行う手順は説明されます。 最終的に、セクションはいくつかの補助的機能の記述で締めくくります、失敗検出や回復、HID交渉、ルーティング、セキュリティなどのように
To help clarify the SCMP exchanges used to setup and maintain ST streams, we have included a series of figures in this section. The protocol interactions in the figures assume the topology shown in Figure 2. The figures, taken together,
STの流れをセットアップして、維持するのに使用されるSCMP交換をはっきりさせるのを助けるために、私たちはこのセクションの一連の数字を入れました。 数字におけるプロトコル相互作用は図2に示されたトポロジーを仮定します。 一緒に取られた数字
o Create a stream from an application at A to three peers at B,
C and D,
o B、C、およびDでAのアプリケーションから3人の同輩までの流れを作成してください。
o Add a peer at E,
o Eで同輩を加えてください。
o Disconnect peers B and C, and
o そして同輩BとCを外してください。
o D drops out of the stream.
o Dは流れを脱落します。
Other figures illustrate exchanges related to failure recovery.
他の数字は失敗回復に関連する交換を例証します。
In order to make the dispatch function within SCMP more uniform and efficient, each end of a hop is assigned, by the agent at that end, a Virtual Link Identifier that uniquely (within that agent) identifies the hop and associates it with a particular stream's state machine(s). The identifier at the end of a link that is sending a message is called the Sender Virtual Link Identifier (SVLId); that at the receiving end is called the Receiver Virtual Link Identifier (RVLId). Whenever one agent sends a control message for the other to receive, the sender will place the receiver's identifier into the RVLId field of the message and its own identifier in the SVLId field. When a reply to the message is sent, the values in SVLId and RVLId fields will be reversed, reflecting the fact the sender and receiver roles are reversed. VLIds with values zero through three are received and should not be assigned in response to CONNECT messages. Figure 3 shows the hops that will be used in the examples and summarizes the VLIds that will be assigned to them.
SCMPの中で、より一定であって、効率的な状態で発信機能を作るために、ホップの各端は割り当てられます、その終わりのエージェントで、唯一ホップを特定して(そのエージェントの中で)、特定の流れの州のマシンにそれを関連づけるVirtual Link Identifier。 メッセージを送るリンクの端の識別子はSender Virtual Link Identifier(SVLId)と呼ばれます。 犠牲者のそれはReceiver Virtual Link Identifier(RVLId)と呼ばれます。 1人のエージェントがもう片方が受信されるコントロールメッセージを送るときはいつも、送付者はSVLId分野にメッセージとそれ自身の識別子のRVLId分野に受信機の識別子を置くでしょう。 メッセージに関する回答を送るとき、SVLIdの値とRVLId分野を逆にするでしょう、送付者と受信機の役割が逆にされるという事実を反映して。 値ゼロ〜threeがあるVLIdsを受け取られていて、CONNECTメッセージに対応して割り当てるべきではありません。 図3は、例で使用されるホップを示していて、彼らに割り当てられるVLIdsをまとめます。
CIP Working Group [Page 17] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[17ページ]RFC1190インターネット流れのプロトコル1990年10月
Similarly, Figure 4 summarizes the HIDs that will eventually be negotiated as the stream is created.
同様に、図4は流れが作成されるとき結局交渉されるHIDsをまとめます。
**** ST Agent 1 ****
* +>+--1200-> o -------->+--->+-3600->+---+
* ^ * * * | B |
* | * * +->+-6000->+---+
* | * *+**
+---+ * | * ^
| +-------->+-->+ * |
| A | * * o St Agent 3
| +-------->+-->+ * ^
+---+ * | * | 4801
* | * *+*
* V * ST Agent 2 * ^ * +---+
* +>+--2400-> o ------->+->+->+-4800->+ C |
**** * | * 4801 +---+
* | *
+---+ * V * +---+
| E +<-4800--+<-+->+-4800->+ D |
+---+ * * 4801 +---+
***
**** STエージェント1*****+>+--1200>o-------->+----3600>+>+---+ * ^ * * * | B| * | * * -6000+->+>+---+ * | * *+** +---+ * | * ^ | +-------->+-->+*| | A| * * o 通りのエージェント3| +-------->+-->+ * ^ +---+ * | * | 4801 * | * *+* * V * ST Agent 2 * ^ * +---+ *+>+--2400>o------->+-4800>+>+>+C| **** * | * 4801 +---+ * | * +---+ *V*+---+ | E+<-4800--+ -4800<-+>+>+D| +---+ * * 4801 +---+ ***
Figure 4. HIDs Assigned for ST User Packets
図4。 ユーザ第パケットのために割り当てられたHIDs
Some of the diagrams that follow form a progression. For example, the steps required initially to establish a connection are spread across five figures. Within a progression, the actions on the first diagram are numbered 1.1, 1.2, etc.; within the second diagram they are numbered 2.1, 2.2, etc. Points where control leaves one diagram to enter another are identified with a continuation arrow "-->>", and are continued with "[a.b] >>-->" in the other diagram. The number in brackets shows the label where control left the earlier diagram. The reception of simple acknowledgments, e.g., ACKs, in one figure from another is omitted for clarity.
従うダイヤグラムのいくつかが進行を形成します。 例えば、初めは取引関係を築くのに必要であったステップは5つの数字の向こう側に広げられます。 進行の中では、最初のダイヤグラムへの動作は番号付の1.1、1.2ですなど。 2番目のダイヤグラムの中では、それらは番号付の2.1、2.2ですなど。 コントロールが別のものに入るために1個のダイヤグラムを残すポイントが継続矢と同一視されている、「--、>>、」、続行される、「[a.b]>>--、>、」 もう片方のダイヤグラムで。 括弧の数は、コントロールがどこに以前のダイヤグラムを残したかをラベルに示します。 簡単な承認、例えば、別のものからの1つの図のACKsのレセプションは明快ために省略されます。
3.1. Stream Setup
3.1. 流れのセットアップ
This section presents a description of stream setup assuming that
everything succeeds -- HIDs are approved, any required resources
are available, and the routing is correct.
このセクションはすべてが成功すると仮定する流れのセットアップの記述を提示します--HIDsは承認されています、そして、どんな必要なリソースも利用可能です、そして、ルーティングは正しいです。
3.1.1. Initial Setup at the Origin
3.1.1. 起源における初期のセットアップ
As described in Section 2.3 (page 11), the application has
collected the information necessary to determine the
セクション2.3(11ページ)で説明されるように、アプリケーションは決定する必要情報を集めました。
CIP Working Group [Page 18] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[18ページ]RFC1190インターネット流れのプロトコル1990年10月
participants in the communication before passing it to the host
ST agent at the origin. The host ST agent will take this
information, allocate a Name for the stream (see Section
4.2.2.8 (page 87)), and create a stream.
起源でホストSTエージェントにそれを渡す前のコミュニケーションの関係者。 セクション4.2を見てください。ホストSTエージェントがこの情報を取って、流れのためにa Nameを割り当ててください、(.2 .8 (87を)呼び出してください、そして、流れを作成してください。
3.1.2. Invoking the Routing Function
3.1.2. 経路選択機能を呼び出します。
An ST agent that is setting up a stream invokes a routing
function to find a path to reach each of the targets specified
in the TargetList. This is similar to the routing decision in
IP. However, in this case the route is to a multitude of
targets rather than to a single destination.
流れをセットアップしているSTエージェントは、TargetListで指定されたそれぞれの目標に達するように経路を見つけるために経路選択機能を呼び出します。 これはIPでのルーティング決定と同様です。 しかしながら、この場合、単一の目的地にというよりむしろ目標の多数にはルートがあります。
The set of next-hops that an ST agent would select is not
necessarily the same as the set of next hops that IP would
select given a number of independent IP datagrams to the same
destinations. The routing algorithm may attempt to optimize
parameters other than the number of hops that the packets will
take, such as delay, local network bandwidth consumption, or
total internet bandwidth consumption.
STエージェントが選択する次のホップのセットは必ず同じ目的地への多くの独立しているIPデータグラムを考えて、IPが選択する次のホップのセットと同じであるというわけではありません。 ルーティング・アルゴリズムは、パケットが取るホップの数以外のパラメタを最適化するのを試みるかもしれません、遅れ、地方のネットワーク回線容量消費、または総インターネット帯域幅消費などのように。
The result of the routing function is a set of next-hop ST
agents and the parameters of the intervening network(s). The
latter permit the ST agent to determine whether the selected
network has the resources necessary to support the level of
service requested in the FlowSpec.
経路選択機能の結果は、1セットの次のホップSTエージェントと介入しているネットワークのパラメタです。 後者は、STエージェントが、選択されたネットワークがリソースをFlowSpecで要求されたサービスのレベルを支持するのに必要にするかどうかと決心していることを許可します。
3.1.3. Reserving Resources
3.1.3. リソースを予約します。
The intent of ST is to provide a guaranteed level of service by
reserving internet resources for a stream during a setup phase
rather than on a per packet basis. The relevant resources are
not only the forwarding information maintained by the ST
agents, but also packet switch processor bandwidth and buffer
space, and network bandwidth and multicast group identifiers.
Reservation of these resources can help to increase the
reliability and decrease the delay and delay variance with
which data packets are delivered. The FlowSpec contains all
the information needed by the ST agent to allocate the
necessary resources. When and how these resources are
allocated depends on the details of the networks involved, and
is not specified here.
STの意図はパケット基礎あたりのaでというよりむしろセットアップ段階の間、流れのためのインターネットリソースを予約することによって保証されたレベルのサービスを提供することです。 関連リソースは、STエージェントによって保守された推進情報だけではなく、パケット交換機プロセッサ帯域幅と、バッファ領域と、ネットワーク回線容量とマルチキャストグループ識別子でもあります。 これらのリソースの予約は、信頼性を増加させて、データ・パケットが届けられる遅れと遅れ変化を減少させるのを助けることができます。 FlowSpecは必要なリソースを割り当てるためにSTエージェントによって必要とされたすべての情報を含んでいます。 かかわったネットワークの細部にいつ、どうこれらのリソースを割り当ててよって、ここで指定されません。
If an ST agent must send data across a network to a single
next-hop ST agent, then only the point-to-point bandwidth needs
to be reserved. If the agent must send data to multiple next-
hop agents across one network and network layer multicasting is
not available, then bandwidth must be reserved for all of them.
This will allow the ST agent to
STエージェントがネットワークの向こう側に独身の次のホップSTエージェントにデータを送らなければならないなら、二地点間帯域幅だけが、予約される必要があります。 エージェントが1つのネットワークの向こう側に複数の次期ホップエージェントにデータを送らなければならなくて、ネットワーク層マルチキャスティングが利用可能でないなら、彼らのすべてのために帯域幅を控えなければなりません。 これはSTエージェントを許容するでしょう。
CIP Working Group [Page 19] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[19ページ]RFC1190インターネット流れのプロトコル1990年10月
use replication to send a copy of the data packets to each
next-hop agent.
模写を使用して、それぞれの次のホップエージェントにデータ・パケットのコピーを送ってください。
If multicast is supported, its use will decrease the effort
that the ST agent must expend when forwarding packets and also
reduces the bandwidth required since one copy can be received
by all next-hop agents. However, the setup phase is more
complicated. A network multicast address must be allocated
that contains all those next-hop agents, the sender must have
access to that address, the next-hop agents must be informed of
the address so they can join the multicast group identified by
it (see Section 4.2.2.7 (page 86)), and a common HID must be
negotiated.
マルチキャストが支持されるなら、使用は、パケットを進めるときSTエージェントが費やさなければならない努力を減少させて、また、すべての次のホップエージェントがコピー1部を受け取ることができるので必要である帯域幅を減少させます。 しかしながら、セットアップフェーズは、より複雑です。 それらのすべての次のホップエージェントを含むネットワークマルチキャストアドレスを割り当てなければならなくて、送付者はそのアドレスに近づく手段を持たなければならなくて、彼らがそれによって特定されたマルチキャストグループに加わることができるように、次のホップエージェントはアドレスにおいて知識がなければなりません。(セクション4.2.2の.7(86ページ)、およびa一般的なHID必須が交渉されるのを確実にしてください。
The network should consider the bandwidth and multicast
requirements to determine the amount of packet switch
processing bandwidth and buffer space to reserve for the
stream. In addition, the membership of a stream in a Group may
affect the resources that have to be allocated; see Section
3.7.3 (page 56).
ネットワークは、帯域幅とマルチキャストがパケット交換機処理帯域幅の量を測定するという要件と流れのために予約するバッファ領域であると考えるべきです。 さらに、Groupの流れの会員資格は割り当てられなければならないリソースに影響するかもしれません。 セクション3.7.3(56ページ)を見てください。
Few networks in the Internet currently offer resource
reservation, and none that we know of offer reservation of all
the resources specified here. Only the Terrestrial Wideband
Network (TWBNet) [7] and the Atlantic Satellite Network
(SATNET) [9] offer(ed) bandwidth reservation. Multicasting is
more widely supported. No network provides for the reservation
of packet switch processing bandwidth or buffer space. We hope
that future networks will be designed to better support
protocols like ST.
インターネットのわずかなネットワークしか現在資源予約を提供しません、そして、私たちがすべてのリソースの申し出の予約を知っているなにもここで指定しませんでした。 Terrestrial Wideband Network(TWBNet)[7]と大西洋Satellite Network(SATNET)[9]は(教育)帯域幅の予約を提供するだけです。 マルチキャスティングは、より広く支持されます。 どんなネットワークもパケット交換機処理帯域幅かバッファ領域の予約に備えません。 将来のネットワークがSTのようなプロトコルをよりよくサポートするように設計されることを願っています。
Effects similar to reservation of the necessary resources may
be obtained even when the network cannot provide direct support
for the reservation. Certainly if total reservations are a
small fraction of the overall resources, such as packet switch
processing bandwidth, buffer space, or network bandwidth, then
the desired performance can be honored if the degree of
confidence is consistent with the requirements as stated in the
FlowSpec. Other solutions can be designed for specific
networks.
ネットワークが予約のダイレクトサポートを提供さえできないとき、必要なリソースの予約と同様の効果を得るかもしれません。 確かに、総予約がパケット交換機処理帯域幅などの総合的なリソースのわずかな部分である、スペースをバッファリングするか、または帯域幅をネットワークでつなぐなら、信用の度合いがFlowSpecの述べられるとしての要件と一致しているなら、必要な性能を光栄に思うことができます。 他の解決策は特定のネットワークのために設計される場合があります。
3.1.4. Sending CONNECT Messages
3.1.4. 発信して、メッセージを接続してください。
A VLId and a proposed HID must be selected for each next-hop
agent. The control packets for the next-hop must carry the
VLId in the SVLId field. The data packets transmitted in the
stream to the next-hop must carry the HID in the ST Header.
それぞれの次のホップエージェントのためにVLIdと提案されたHIDを選択しなければなりません。 次のホップのためのコントロールパケットはSVLId分野でVLIdを運ばなければなりません。 流れで次のホップに伝えられたデータ・パケットはST HeaderでHIDを運ばなければなりません。
The ST agent sends a CONNECT message to each of the ST agents
identified by the routing function. Each CONNECT message
contains the VLId, the proposed HID (the HID Field option bit
STエージェントは経路選択機能によって特定されたSTエージェントの各人にCONNECTメッセージを送ります。 それぞれのCONNECTメッセージがVLId、提案されたHIDを含んでいる、(HID Fieldオプションに噛み付きました。
CIP Working Group [Page 20] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[20ページ]RFC1190インターネット流れのプロトコル1990年10月
must be set, see Section 3.6.1 (page 44)), an updated FlowSpec,
and a TargetList. In general, the HID, FlowSpec, and
TargetList will depend on both the next-hop and the intervening
network. Each TargetList is a subset of the received (or
original) TargetList, identifying the targets that are to be
reached through the next-hop to which the CONNECT message is
being sent. Note that a CONNECT message to a single next-hop
might have to be fragmented into multiple CONNECTs if the
single CONNECT is too large for the intervening network's MTU;
fragmentation is performed by further dividing the TargetList.
用意ができて、セクション3.6.1(44ページ)、アップデートされたFlowSpec、およびTargetListを見なければなりません。 一般に、HID、FlowSpec、およびTargetListは次のホップと介入しているネットワークの両方に頼るでしょう。 各TargetListは受け取られているのと(オリジナル)の部分集合です。 次のホップを通ってCONNECTメッセージが送られる達することになっている目標を特定するTargetList。 介入しているネットワークのMTUには、独身のCONNECTが大き過ぎるなら単一の次のホップへのCONNECTメッセージが複数のCONNECTsに断片化されなければならないかもしれないことに注意してください。 断片化は、さらにTargetListを分割することによって、実行されます。
If multiple next-hops are to be reached through a network that
supports network level multicast, a different CONNECT message
must nevertheless be sent to each next-hop since each will have
a different TargetList; see Section 4.2.3.5 (page 105).
However, since an identical copy of each ensuing data packet
will reach each member of the multicast group, all the CONNECT
messages must propose the same HID. See Section 3.7.4 (page
58) for a detailed discussion on HID selection.
複数の次のホップにネットワークを通して達するつもりであると、サポートが平らなマルチキャストをネットワークでつないで、それにもかかわらず、以来に異なったCONNECTメッセージをそれぞれの次のホップに送らなければならないのにおいて、それぞれ異なったTargetListがあるでしょう。 セクション4.2を見てください。.3 .5(105ページ)。 しかしながら、同一の複製物のそれぞれ続いているデータ・パケットがマルチキャストグループの各メンバーに届くので、すべてのCONNECTメッセージが同じHIDを提案しなければなりません。 HID選択の詳細な論議に関してセクション3.7.4(58ページ)を見てください。
In the example of Figure 2, the routing function might return
that B is reachable via Agent 1 and C and D are reachable via
Agent 2. Thus A would create two CONNECT messages, one each
for Agents 1 and 2, as illustrated in Figure 5. Assuming that
the proposed HIDs are available in the receiving agents, they
would each send a responding HID-APPROVE back to Agent A.
図2に関する例では、Bはリターンですが、経路選択機能はエージェント1を通して届いた状態で届くかもしれません、そして、CとDはエージェント2を通して届いています。 したがって、Aは図5で例証されるように2つのCONNECTメッセージ、エージェント1と2のためのそれぞれものを作成するでしょう。 提案されたHIDsが受信エージェントで利用可能であると仮定する場合、彼らはそれぞれ応じるHID-APPROVEをエージェントAに送り返すでしょう。
Application Agent A Agent 1 Agent 2
アプリケーションエージェントは1人のエージェントのエージェント2です。
1.1. (open B,C,D)
V
1.2. +-> (routing to B,C,D)
V
1.3. +->(reserve resources from A to Agent 1)
| V
1.4. | +-> CONNECT B --------->>
| <RVLId=0><SVLId=4>
| <Ref=10><HID=1200>
V
1.5. +->(reserve resources from A to Agent 2)
V
1.6. +-> CONNECT C,D ------------------>>
<RVLId=0><SVLId=5>
<Ref=15><HID=2400>
1.1. (戸外B、C、D) V1.2。 +->(B、C、Dへのルーティング)V1.3。 +->(Aからエージェント1までの蓄えのリソース)| V1.4。 | +->はBを接続します。--------->>| <RVLId=0><SVLId=4>。| <審判=10><は= 1200>V1.5隠れました。 +->(Aからエージェント2までの蓄えのリソース)V1.6。 D、+->はCを接続します。------------------SVLId=5><審判=15><が隠した>><RVLId=0><は2400>と等しいです。
Figure 5. Origin Sending CONNECT Message
図5。 起源発信はメッセージを接続します。
CIP Working Group [Page 21] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[21ページ]RFC1190インターネット流れのプロトコル1990年10月
3.1.5. CONNECT Processing by an Intermediate Agent
3.1.5. 仲介物質による処理を接続してください。
An ST agent receiving a CONNECT message should, assuming no
errors, quickly select a VLId and respond to the previous-hop
with either an ACK, a HID-REJECT, or a HID-APPROVE message, as
is appropriate. This message must identify the CONNECT to
which it corresponds by including the CONNECT's Reference
number in its Reference field. Note that the VLId that this
agent selects is placed in the SVLId of the response, and the
previous-hop's VLId (which is contained in the SVLId of the
CONNECT) is copied into the RVLId of the response. If the
agent is not a target, it must then invoke the routing
function, reserve resources, and send a CONNECT message(s) to
its next-hop(s), as described in Sections 3.1.2-4 (pages 19-
20).
CONNECTメッセージを受け取るSTエージェントは、そのままなACK、HID-REJECT、またはHID-APPROVEメッセージが当てるどちらかで誤りを全く仮定しないで、すぐにVLIdを選択して、前のホップに応じるべきです。 このメッセージはそれがReference分野にCONNECTのReference番号を含んでいることによって相当するCONNECTを特定しなければなりません。 このエージェントが選択するVLIdが応答のSVLIdに置かれて、前のホップのVLId(CONNECTのSVLIdに含まれている)が応答のRVLIdにコピーされることに注意してください。 エージェントが目標でないなら、次に、経路選択機能を呼び出して、リソースを予約して、CONNECTメッセージを次のホップに送らなければなりません、セクション3.1.2-4(19- 20ページ)で説明されるように。
Agent A Agent 1 Agent B
エージェントはエージェントの1人のエージェントBです。
[1.4] >>-> CONNECT B -------->+--+
<RVLId=0><SVLId=4> | V
2.1. <Ref=10><HID=1200> | (routing to B)
| V
2.2. V +->(reserve resources from 1 to B)
2.3. +<- HID-APPROVE <------+ V
2.4. <RVLId=4><SVLId=14> +-> CONNECT B ---------->>
<Ref=10><HID=1200> <RVLId=0><SVLId=15>
<Ref=110><HID=3600>
[1.4] >>->はBを接続します。-------->+--+ <RVLId=0><SVLId=4>。| V2.1。 10><が隠した<審判=は1200>と等しいです。| (Bへのルーティング) | V2.2。 V+->(1〜Bまでの蓄えのリソース)2.3。 + <、-、隠す、-承認してください、<。------+ V2.4。 <RVLId=4><SVLId=14>+->はBを接続します。---------->><審判=10><は3600<が隠した1200年の=><RVLId=0><SVLId=15><審判=110>=>を隠しました。
Agent A Agent 2 Agent C
エージェントはエージェントの2エージェントCです。
[1.6] >>-> CONNECT C,D ------>+-+
<RVLId=0><SVLId=5> | V
2.5. <Ref=15><HID=2400> | (routing to C,D)
| V
2.6. V +-->(reserve resources from 2 to C)
2.7. +<- HID-APPROVE <------+ | V
2.8. <RVLId=5><SVLId=23> | +-> CONNECT C ---------->>
<Ref=15><HID=2400> | <RVLId=0><SVLId=25>
| <Ref=210><HID=4800>
|
| Agent D
V
2.9. +->(reserve resources from 2 to D)
V
2.10. +-> CONNECT D ---------->>
<RVLId=0><SVLId=26>
<Ref=215><HID=4800>
[1.6] D、>>->はCを接続します。------>++<RVLId=0><SVLId=5>。| V2.5。 15><が隠した<審判=は2400>と等しいです。| (C、Dへのルーティング) | V2.6。 V+-->(2〜Cまでの蓄えのリソース)2.7。 + <、-、隠す、-承認してください、<。------+ | V2.8。 <RVLId=5><SVLId=23>。| +->はCを接続します。----------15><が隠した>><審判=は2400>と等しいです。| <RVLId=0><SVLId=25>。| 210><が隠した<審判=は4800>と等しいです。| | エージェントD V2.9。 +->(2〜Dまでの蓄えのリソース)V2.10。 +->はDを接続します。----------SVLId=26><審判=215><が隠した>><RVLId=0><は4800>と等しいです。
Figure 6. CONNECT Processing by an Intermediate Agent
図6。 仲介物質による処理を接続してください。
CIP Working Group [Page 22] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[22ページ]RFC1190インターネット流れのプロトコル1990年10月
The resources listed as Desired in a received FlowSpec may not
correspond to those actually reserved in either the ST agent
itself or in the network(s) used to reach the next-hop
agent(s). As long as the reserved resources are sufficient to
meet the specified Limits, the copy of the FlowSpec sent to a
next-hop must have the Desired resources updated to reflect the
resources that were actually obtained. For example, the
Desired bandwidth might be reduced because the network to the
next-hop could not provide all of the desired bandwidth. Also,
the delay and delay variance are appropriately increased, and
the link MTU may require that the DesPDUBytes field be reduced.
(The minimum requirements that the origin had entered into the
FlowSpec Limits fields cannot be altered by the intermediate or
target agents.)
容認されたFlowSpecのDesiredが実際にそれらに対応しないかもしれないリストアップされたリソースは、どちらかでSTエージェント自身を予約したか、またはネットワークに次のホップエージェントを範囲に使用しました。 予約されたリソースが指定されたLimitsに会うことができる限り、次のホップに送られたFlowSpecのコピーは、実際に得られたリソースを反映するためにDesiredリソースをアップデートしなければなりません。 例えば、次のホップへのネットワークが必要な帯域幅のすべてを提供できなかったので、Desired帯域幅は減少するかもしれません。 また、遅れと遅れ変化は適切に増加します、そして、リンクMTUはDesPDUBytes分野が減少するのを必要とするかもしれません。 (中間介在物か目標エージェントが起源がFlowSpec Limits分野に入ったという最小の要件を変更できません。)
3.1.6. Setup at the Targets
3.1.6. 目標でのセットアップ
An ST agent that is the target of a CONNECT, whether from an
intermediate ST agent, or directly from the origin host ST
agent, must respond first (assuming no errors) with either a
HID-REJECT or HID-APPROVE. After inquiring from the specified
application process whether or not it is willing to accept the
connection, the agent must also respond with either an ACCEPT
or a REFUSE.
中間的STエージェント、または、直接起源ホストSTエージェントにかかわらずCONNECTの目標であるSTエージェントは最初に、HID-REJECTかHID-APPROVEのどちらかと共に応じなければなりません(誤りを全く仮定しません)。 また、指定されたアプリケーション・プロセスからそれが、接続を受け入れても構わないと思っているかどうか問い合わせた後に、エージェントはACCEPTかREFUSEのどちらかと共に応じなければなりません。
In particular, the application must be presented with
parameters from the CONNECT, such as the Name, FlowSpec,
Options, and Group, to be used as a basis for its decision.
The application is identified by a combination of the NextPcol
field and the SAP field in the (usually) single remaining
Target of the TargetList. The contents of the SAP field may
specify the "port" or other local identifier for use by the
protocol layer above the host ST layer. Subsequently received
data packets will carry a short hand identifier (the HID) that
can be mapped into this information and be used for their
delivery.
特に、決定の基礎として使用されるためにCONNECTからのNameや、FlowSpecや、Optionsや、Groupなどのパラメタをアプリケーションに与えなければなりません。 アプリケーションはTargetListの(通常)独身の残っているTargetのNextPcol分野とSAP分野の組み合わせで特定されます。 SAP分野のコンテンツはホストST層の上のプロトコル層のそばで使用のための「ポート」か他のローカルの識別子を指定するかもしれません。 次に、受信データパケットはこの情報に写像して、彼らの配送に使用できる短い手の識別子(HID)を運ぶでしょう。
The responses to the CONNECT message are sent to the previous-
hop from which the CONNECT was received. An ACCEPT contains
the Name of the stream and the updated FlowSpec. Note that the
application might have reduced the desired level of service in
the received FlowSpec before accepting it. The target must not
send the ACCEPT until HID negotiation has been successfully
completed.
CONNECTが受け取られた前のホップにCONNECTメッセージへの応答を送ります。 ACCEPTは流れのNameとアップデートされたFlowSpecを含んでいます。 それを受け入れる前にアプリケーションが容認されたFlowSpecで必要なレベルのサービスを抑えたかもしれないことに注意してください。 HID交渉が首尾よく終了するまで、目標はACCEPTを送ってはいけません。
Since the ACCEPT or REFUSE message must be acknowledged by the
previous-hop, it is assigned a new Reference number that will
be returned in the ACK. The CONNECT to which the ACCEPT or
REFUSE is a reply is identified by placing the CONNECT's
Reference number in the LnkReference field of the ACCEPT or
REFUSE.
前のホップでACCEPTかREFUSEメッセージを承認しなければならないので、ACKで返される新しいReference番号はそれに割り当てられます。 ACCEPTかREFUSEが回答であるCONNECTは、ACCEPTかREFUSEのLnkReference分野にCONNECTのReference番号を置くことによって、特定されます。
CIP Working Group [Page 23] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[23ページ]RFC1190インターネット流れのプロトコル1990年10月
Agent 1 Agent B Application B
3.1. (proc B listening)
[2.4] >>-> CONNECT B ---------->+------------------+
<RVLId=0><SVLId=15> | |
3.2. <Ref=110><HID=3600> V (proc B accepts)
3.3. +<- HID-APPROVE <--------+ |
<RVLId=15><SVLId=44> |
<Ref=110><HID=3600> V
3.4. (wait until HID negotiated) <---+
V
3.5. <<--+<- ACCEPT B <-----------+
<RVLId=15><SVLId=44>
<Ref=410><LnkRef=110>
エージェント1人のエージェントBアプリケーションB3.1。 (proc B聴取) [2.4] >>->はBを接続します。---------->+------------------+ <RVLId=0><SVLId=15>。| | 3.2. <審判は110><HID=3600>V(proc Bは受け入れます)3.3と等しいです。 + <、-、隠す、-承認してください、<。--------+ | <RVLId=15><SVLId=44>。| <審判=110><は= 3600>V3.4隠れました。 (HIDが交渉するまでの待ち) <--+ V3.5。 <<--+はB<を<受け入れます。-----------+ <RVLId=15><SVLId=44><審判=410><LnkRef=110>。
Agent 2 Agent C Application C
3.6. (proc C listening)
[2.8] >>-> CONNECT C ---------->+------------------+
<RVLId=0><SVLId=25> | |
3.7. <Ref=210><HID=4800> V (proc C accepts)
3.8. +<- HID-APPROVE <--------+ |
<RVLId=25><SVLId=54> |
<Ref=210><HID=4800> V
3.9. (wait until HID negotiated) <---+
V
3.10. <<--+<- ACCEPT C <-----------+
<RVLId=25><SVLId=54>
<Ref=510><LnkRef=210>
エージェント2エージェントCアプリケーションC3.6。 (proc C聴取) [2.8] >>->はCを接続します。---------->+------------------+ <RVLId=0><SVLId=25>。| | 3.7. <審判=210><HID=4800>V(proc Cは受け入れます)3.8。 + <、-、隠す、-承認してください、<。--------+ | <RVLId=25><SVLId=54>。| <審判=210><は= 4800>V3.9隠れました。 (HIDが交渉するまでの待ち) <--+ V3.10。 <<--+はC<を<受け入れます。-----------+ <RVLId=25><SVLId=54><審判=510><LnkRef=210>。
Agent 2 Agent D Application D
3.11. (proc D listening)
[2.10] >>-> CONNECT D ---------->+------------------+
<RVLId=0><SVLId=26> | |
3.12. <Ref=215><HID=4800> V (proc D accepts)
3.13. +<- HID-APPROVE <--------+ |
<RVLId=26><SVLId=64> |
<Ref=215><HID=4800> V
3.14. (wait until HID negotiated) <---+
V
3.15. <<--+<- ACCEPT D <-----------+
<RVLId=26><SVLId=64>
<Ref=610><LnkRef=215>
エージェント2エージェントDアプリケーションD3.11。 (proc D聴取) [2.10]>>->はDを接続します。---------->+------------------+ <RVLId=0><SVLId=26>。| | 3.12. <審判は215><HID=4800>V(proc Dは受け入れます)3.13と等しいです。 + <、-、隠す、-承認してください、<。--------+ | <RVLId=26><SVLId=64>。| <審判=215><は= 4800>V3.14隠れました。 (HIDが交渉するまでの待ち) <--+ V3.15。 <<--+はD<を<受け入れます。-----------+ <RVLId=26><SVLId=64><審判=610><LnkRef=215>。
Figure 7. CONNECT Processing by the Target
図7。 目標で処理を接続してください。
3.1.7. ACCEPT Processing by an Intermediate Agent
3.1.7. 仲介物質による処理を受け入れてください。
When an intermediate ST agent receives an ACCEPT, it first
verifies that the message is a response to an earlier CONNECT.
If not, it responds to the next-hop ST agent with an ERROR-IN-
REPLY (LnkRefUnknown) message. Otherwise, it responds to the
next-hop ST agent with an ACK, and propagates
中間的STエージェントがACCEPTを受け取るとき、それは、最初に、メッセージが以前のCONNECTへの応答であることを確かめます。 そうでなければ、それはERROR-IN REPLY(LnkRefUnknown)メッセージで次のホップSTエージェントに応じます。 さもなければ、それは、ACKの次のホップSTエージェントに応じて、伝播されます。
CIP Working Group [Page 24] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[24ページ]RFC1190インターネット流れのプロトコル1990年10月
the ACCEPT message to the previous-hop along the same path
traced by the CONNECT but in the reverse direction toward the
origin. The ACCEPT should not be propagated until all HID
negotiations with the next-hop agent(s) have been successfully
completed.
CONNECTによってたどられた同じ経路にもかかわらず、起源に向かった反対の方向への前のホップへのACCEPTメッセージ。 次のホップエージェントとのすべてのHID交渉が首尾よく終了するまで、ACCEPTを伝播するべきではありません。
The FlowSpec is included in the ACCEPT message so that the
origin and intermediate ST agents can gain access to the
information that was accumulated as the CONNECT traversed the
internet. Note that the resources, as specified in the
FlowSpec in the ACCEPT message, may differ from the resources
that were reserved by the agent when the CONNECT was
FlowSpecは、起源と中間的STエージェントがCONNECTがインターネットを横断したとき蓄積された情報へのアクセスを得ることができるように、ACCEPTメッセージに含まれています。 CONNECTが異なっていたとき、ACCEPTメッセージのFlowSpecで指定されるリソースがエージェントによって予約されたリソースと異なるかもしれないことに注意してください。
Agent A Agent 1 Agent B
エージェントはエージェントの1人のエージェントBです。
+<-+<- ACCEPT B <-------<< [3.5]
V | <RVLId=15><SVLId=44>
4.1. (wait for ACCEPTS) V <Ref=410><LnkRef=110>
4.2. V +-> ACK --------------->+
4.3. (wait until HID negotiated)<-+ <RVLId=44><SVLId=15>
V <Ref=410>
4.4. <<--+<-- ACCEPT B <---------+
<RVLId=4><SVLId=14>
<Ref=115><LnkRef=10>
+、<-+はB<を<受け入れます。-------<<[3.5]V| <RVLId=15><SVLId=44>4.1。 (待っている、受諾、) V<審判は410><LnkRef=110>4.2と等しいです。 V+->ACK--------------->+4.3。 (HIDが交渉するまでの待ち)<。+ <RVLId=44><SVLId=15>V<審判は410>4.4と等しいです。 <<--+ <--B<を受け入れてください。---------+ <RVLId=4><SVLId=14><審判=115><LnkRef=10>。
Agent A Agent 2 Agent C
エージェントはエージェントの2エージェントCです。
+<-+<- ACCEPT C <------<< [3.10]
| | <RVLId=25><SVLId=54>
| V <Ref=510><LnkRef=210>
4.5. | +-> ACK --------------->+
| <Ref=510>
| <RVLId=54><SVLId=25>
|
| Agent D
V
+<-+<- ACCEPT D <------<< [3.15]
V | <RVLId=26><SVLId=64>
4.6. (wait for ACCEPTS) V <Ref=610><LnkRef=215>
4.7. V +-> ACK --------------->+
4.8. (wait until HID negotiated)<-+ <RVLId=64><SVLId=26>
V <Ref=610>
4.9. <<--+<- ACCEPT C <----------+
<RVLId=5><SVLId=23> |
<Ref=220><LnkRef=15>|
V
4.10. <<--+<- ACCEPT D <----------+
<RVLId=5><SVLId=23>
<Ref=225><LnkRef=15>
+、<-+はC<を<受け入れます。------<<[3.10]| | <RVLId=25><SVLId=54>。| V<審判は510><LnkRef=210>4.5と等しいです。 | +->ACK--------------->+| <審判=510>。| <RVLId=54><SVLId=25>。| | DエージェントV+<+はD<を<受け入れます。------<<[3.15]V| <RVLId=26><SVLId=64>4.6。 (待っている、受諾、) V<審判は610><LnkRef=215>4.7と等しいです。 V+->ACK--------------->+4.8。 (HIDが交渉するまでの待ち)<。+ <RVLId=64><SVLId=26>V<審判は610>4.9と等しいです。 <<--+はC<を<受け入れます。----------+ <RVLId=5><SVLId=23>。| <審判=220><LnkRef=15>| V4.10。 <<--+はD<を<受け入れます。----------+ <RVLId=5><SVLId=23><審判=225><LnkRef=15>。
Figure 8. ACCEPT Processing by an Intermediate Agent
エイト環。 仲介物質による処理を受け入れてください。
CIP Working Group [Page 25] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[25ページ]RFC1190インターネット流れのプロトコル1990年10月
originally processed. However, the agent does not adjust the
reservation in response to the ACCEPT. It is expected that any
excess resource allocation will be released for use by other
stream or datagram traffic through an explicit CHANGE message
initiated by the application at the origin if it does not wish
to be charged for any excess resource allocations.
元々、処理されています。 しかしながら、エージェントはACCEPTに対応して予約を調整しません。 どんな余分な資源配分も使用のためにそれをどんな余分な資源配分のためにも請求されたくないなら起源でアプリケーションで開始された明白なCHANGEメッセージを通して他の流れかデータグラム交通でリリースされると予想されます。
3.1.8. ACCEPT Processing by the Origin
3.1.8. 起源で処理を受け入れてください。
The origin will eventually receive an ACCEPT (or REFUSE or
ERROR-IN-REQUEST) message from each of the targets. As each
ACCEPT is received, the application should be notified of the
target and the resources that were successfully allocated along
the path to it, as specified in the FlowSpec contained in the
ACCEPT message. The application may then use the information
to either adopt or terminate the portion of the stream to each
target. When ACCEPTs (or failures) from all targets have been
received at the origin, the application is notified that stream
setup is complete, and that data may be sent.
起源は結局、それぞれの目標からACCEPT(または、REFUSEかERROR IN REQUEST)メッセージを受け取るでしょう。 それぞれのACCEPTが受け取られているとき、アプリケーションは経路に沿って首尾よくそれに割り当てられた目標とリソースについて通知されるべきです、ACCEPTメッセージに含まれたFlowSpecで指定されるように。 そして、アプリケーションは、各目標への流れの一部を採用するか、または終えるのに情報を使用するかもしれません。 起源ですべての目標からのACCEPTs(または、失敗)を受け取ったとき、流れのセットアップが完全であり、データが送られるかもしれないようにアプリケーションに通知します。
Application A Agent A Agent 1 Agent 2
1人のアプリケーションAエージェントのAエージェントのエージェント2
+<-- ACCEPT B <--------<< [4.4]
| <RVLId=4><SVLId=14>
V <Ref=115><LnkRef=10>
5.1. +--> ACK ----------------->+
| <RVLId=14><SVLId=4>
V <Ref=115>
5.2. +<-- (inform A of B's FlowSpec)
| +<-- ACCEPT C <----------------<< [4.9]
| | <RVLId=5><SVLId=23>
| V <Ref=220><LnkRef=15>
5.3. | +--> ACK ------------------------->+
| | <RVLId=23><SVLId=5>
| V <Ref=220>
5.4. +<-- (inform A of C's FlowSpec)
| +<-- ACCEPT D <----------------<< [4.10]
| | <RVLId=5><SVLId=23>
| V <Ref=225><LnkRef=15>
5.5. | +--> ACK ------------------------->+
| | <RVLId=23><SVLId=5>
| V <Ref=225>
5.6. +<-- (inform A of D's FlowSpec)
V
5.7. (wait until HIDs negotiated)
V
5.8. (inform A open to B,C,D)
+ <--B<を受け入れてください。--------<<[4.4]| <RVLId=4><SVLId=14>V<審判は115><LnkRef=10>5.1と等しいです。 +-->ACK----------------->+| <RVLId=14><SVLId=4>V<審判は115>5.2と等しいです。 +<--、(ビーズFlowSpecのAを知らせます)| + <--C<を受け入れてください。----------------<<[4.9]| | <RVLId=5><SVLId=23>。| V<審判は220><LnkRef=15>5.3と等しいです。 | +-->ACK------------------------->+| | <RVLId=23><SVLId=5>。| V<審判は220>5.4と等しいです。 +<--、(CのFlowSpecのAを知らせます)| + <--D<を受け入れてください。----------------<<[4.10]| | <RVLId=5><SVLId=23>。| V<審判は225><LnkRef=15>5.5と等しいです。 | +-->ACK------------------------->+| | <RVLId=23><SVLId=5>。| V<審判は225>5.6と等しいです。 +<--(DのFlowSpecのAを知らせます) V5.7。 (HIDsが交渉するまでの待ち) V5.8。 (D、A戸外をB、Cに知らせてください)
Figure 9. ACCEPT Processing by the Origin
図9。 起源で処理を受け入れてください。
CIP Working Group [Page 26] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[26ページ]RFC1190インターネット流れのプロトコル1990年10月
There are several pieces of information contained in the
FlowSpec that the application must combine before sending data
through the stream. The PDU size should be computed from the
minimum value of the DesPDUBytes field from all ACCEPTs and the
protocol layers above ST should be informed of the limit. It
is expected that the next higher protocol layer above ST will
segment its PDUs accordingly. Note, however, that the MTU may
decrease over the life of the stream if new targets are
subsequently added. Whether the MTU should be increased as
targets are dropped from a stream is left for further study.
流れでデータを送る前にアプリケーションが結合しなければならないというFlowSpecに含まれた情報のいくつかの断片があります。 PDUサイズはDesPDUBytes分野の最小値からすべてのACCEPTsから計算されるべきです、そして、STの上のプロトコル層は限界において知識があるべきです。 STの上の次の、より高いプロトコル層がそれに従って、PDUsを区分すると予想されます。 しかしながら、新しい目標が次に加えられるならMTUが流れの人生の間減少するかもしれないことに注意してください。 目標が流れから落とされるのに従ってMTUを増加させるべきであるようにさらなる研究に発たれます。
The available bandwidth and packet rate limits must also be
combined. In this case, however, it may not be possible to
select a pair of values that may be used for all paths, e.g.,
one path may have selected a low rate of large packets while
another selected a high rate of small packets. The application
may remedy the situation by either tearing down the stream,
dropping some participants, or creating a second stream.
また、利用可能な帯域幅とパケットレート限界を結合しなければなりません。 しかしながら、この場合すべての経路に使用されるかもしれない1組の値を選択するのが可能でないかもしれない、例えば、別のものが高い率の小型小包を選択していた間、1つの経路が大きいパケットの低率を選択したかもしれません。 アプリケーションは、流れを取りこわすか、何人かの関係者を落とすか、または2番目の流れを作成することによって、事態を改善するかもしれません。
After any differences have been resolved (or some targets have
been deleted by the application to permit resolution), the
application at the origin should send a CHANGE message to
release any excess resources along paths to those targets that
exceed the resolved parameters for the stream, thereby reducing
the costs that will be incurred by the stream.
どんな違いも決議された(いくつかの目標が解決を可能にするためにアプリケーションで削除されました)後に、起源におけるアプリケーションは経路に沿ってどんな余分なリソースも発表するCHANGEメッセージを流れのための決心しているパラメタを超えているそれらの目標に送るべきです、その結果、流れで被られるコストを削減します。
3.1.9. Processing a REFUSE Message
3.1.9. 廃物メッセージを処理します。
REFUSE messages are used to indicate a failure to reach an
application at a target; they are propagated toward the origin
of a stream. They are used in three situations:
REFUSEメッセージは目標でアプリケーションに達しないことを示すのに使用されます。 それらは流れの起源に向かって伝播されます。 それらは3つの状況で使用されます:
1 during stream setup or expansion to indicate that there
is no satisfactory path from an ST agent to a target,
1 流れのセットアップか拡大の間、STエージェントから目標までそこでそれを示すのは、満足できる経路ではありません。
2 when the application at the target either does not
exist does not wish to be a participant, or wants to
cease being a participant, and
そして2 目標での利用がいつ存在しないかが、関係者であることを願いたくないか、または関係者であることをやめたがっている。
3 when a failure has been detected and the agents are
trying to find a suitable path around the failure.
3 失敗がいつ、検出されるか、そして、エージェントは失敗の周りの適当な経路を見つけようとしています。
The cases are distinguished by the ReasonCode field and an
agent receiving a REFUSE message must examine that field in
order to determine the proper action to be taken. In
particular, if the ReasonCode indicates that the CONNECT
message reached the target then the REFUSE should be propagated
back to the origin, releasing resources as appropriate along
the way. If the ReasonCode indicates that
ケースはReasonCode分野によって区別されます、そして、REFUSEメッセージを受け取るエージェントは適切な行動が取られることを決定するためにその分野を調べなければなりません。 ReasonCodeが、CONNECTメッセージが目標に達したのを示すなら、特に、REFUSEは起源に伝播して戻されるべきです、道に沿って適宜リソースを発表して。 ReasonCodeがそれを示すなら
CIP Working Group [Page 27] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[27ページ]RFC1190インターネット流れのプロトコル1990年10月
the CONNECT message did not reach the target then the
intermediate (origin) ST agent(s) should check for alternate
routes to the target before propagating the REFUSE back another
hop toward the origin. This implies that an agent must keep
track of the next-hops that it has tried, on a target by target
basis, in order not to get caught in a loop.
CONNECTメッセージは目標に達しないで、REFUSEを伝播して戻す前に、次に、(s)が補欠がないかどうかチェックするべきである中間的(起源)STエージェントは起源に向かった別のホップを目標に発送します。 これは、エージェントがそれが試した次のホップの動向をおさえなければならないのを含意します、目標基礎による目標の上で、輪に捕らえさせない命令で。
An ST agent that receives a REFUSE message must acknowledge it
by sending an ACK to the next-hop. The REFUSE must also be
propagated back to the previous-hop ST agent. Note that the ST
agent may not have any information about the target in
REFUSEメッセージを受け取るSTエージェントは、次のホップにACKを送ることによって、それを承認しなければなりません。 また、前のホップSTエージェントにREFUSEを伝播して戻さなければなりません。 STエージェントが目標の少しの情報も持っていない注意
Appl. Agent A Agent 2 Agent E
(proc E NOT listening)
1. (add E)
2. +----->+-> CONNECT E ---------->+->+
<RVLId=23><SVLId=5> | |
<Ref=65> V |
3. +<-- ACK <---------------+ |
<RVLId=5><SVLId=23> V
4. <Ref=65> (routing to E)
V
5. (reserve resources 2 to E)
V
6. +--> CONNECT E --------->+
<RVLId=0><SVLId=27> |
<Ref=115><HID=4600> |
V
7. +<-+<- REFUSE B <-----------+
| | <RVLId=27><SVLId=74>
| | <Ref=705><LnkRef=115>
| V <RC=SAPUnknown>
8. | +-> ACK ---------------->+
| | <RVLId=74><SVLId=27> |
| V <Ref=705> |
9. | (free link 27) V
10. V (free link 74)
11. +<- REFUSE B <-----------+
| <RVLId=5><SVLId=23> |
| <Ref=550><LnkRef=65> V
12. | <RC=SAPUnknown> (free resources 2 to E)
V
13. +-> ACK --------------->+
| <RVLId=23><SVLId=5> |
| <Ref=550> V
14. V (keep link 23 for C,D)
15. (keep link 5 for C,D)
V
16. (inform application failed SAPUnknown)
Appl。 エージェントのAエージェントの2エージェントE(proc Eが聴かれないで)1。 (Eを加えます) 2. +----->+->はEを接続します。---------->+->+<RVLId=23><SVLId=5>。| | <審判=65>V| 3. +<--ACK<。---------------+ | <RVLId=5><SVLId=23>V4。 <審判は65>(Eへのルーティング)V5と等しいです。 (Eへの蓄えのリソース2) V6。 +-->はEを接続します。--------->+<RVLId=0><SVLId=27>。| 115><が隠した<審判=は4600>と等しいです。| V7。 + <-+<-廃物B<。-----------+ | | <RVLId=27><SVLId=74>。| | <審判=705><LnkRef=115>。| V<RC=SAPUnknown>8。 | +->ACK---------------->+| | <RVLId=74><SVLId=27>。| | V<審判=705>。| 9. | (無料のリンク27) V10。 V(無料のリンク74)11。 + <-廃物B<。-----------+ | <RVLId=5><SVLId=23>。| | <審判は550><LnkRef=65>V12と等しいです。 | <RC=SAPUnknown>(Eへの無料のリソース2)V13。 +->ACK--------------->+| <RVLId=23><SVLId=5>。| | <審判は550>V14と等しいです。 V(D、Cのためにリンク23を保つ)15。 (D、Cのためにリンク5を保ってください) V16。 (アプリケーションの失敗したSAPUnknownに知らせます)
Figure 10. Sending REFUSE Message
図10。 送付廃物メッセージ
CIP Working Group [Page 28] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[28ページ]RFC1190インターネット流れのプロトコル1990年10月
the TargetList. This may result from interacting DISCONNECT
and REFUSE messages and should be logged and silently ignored.
TargetList。 これは、DISCONNECTに相互作用して、REFUSEメッセージから生じるかもしれなくて、登録されて、静かに無視されるべきです。
If, after deleting the specified target, the next-hop has no
remaining targets, then those resources associated with that
next-hop agent may be released. Note that network resources
may not actually be released if network multicasting is being
指定された目標を削除した後に、次のホップに残っている目標が全くないなら、その次のホップエージェントに関連しているそれらのリソースは発表されるかもしれません。 ネットワーク資源がネットワークマルチキャスティングが存在であるなら実際にリリースされないかもしれないことに注意してください。
Appl. Agent A Agent 2 Agent 1 Agent 3 Agent B
Appl。 エージェントはエージェントの2エージェント1のエージェントの3エージェントBです。
1. (network from 1 to B fails)
2. (add B)
3. +-> CONNECT B ----------------->+
<RVLId=0><SVLId=6> |
<Ref=35><HID=100> |
3. +<- HID-APPROVE <---------------+
<RVLId=6><SVLId=11> |
<Ref=35><HID=100> V
4. (routing to B: no route)
V
5. +<-+-- REFUSE B ----------------+
| | <RVLId=6><SVLId=11>
| | <Ref=155><LnkRef=35>
| V <RC=NoRouteToDest>
6. | +-> ACK -------------------->+
| | <RVLId=11><SVLId=6> V
7. | V <Ref=155> (drop link 6)
8. V (drop link 11)
9. (find alternative route: via agent 2)
10. (resources from A to 2 already allocated:
V reuse control link & HID, no additional resources required)
11. +-> CONNECT B -------->+->+
<RVLId=23><SVLId=5>| |
<Ref=40> V |
12. +<- ACK <--------------+ |
<RVLId=5><SVLId=23> V
13. <Ref=40> (routing to B: via agent 3)
V
14. +-> CONNECT B -->+
15. <RVLId=0><SVLId=24> +-> CONNECT B --------->+
<Ref=245><HID=4801> V <RVLId=0><SVLId=32> |
16. +<- HID-APPROVE -+ <Ref=310><HID=6000> |
<RVLId=24><SVLId=33> |
<Ref=245><HID=4801> V
17. +<- HID-APPROVE --------+
<RVLId=32><SVLId=45>|
<Ref=310><HID=6000> V
18. (ACCEPT handling follows normally to complete stream setup)
1. (1〜Bまでのネットワークは行き詰まります) 2. (Bを加えます) 3. +->はBを接続します。----------------->+<RVLId=0><SVLId=6>。| <審判=35><は=100>を隠しました。| 3. + <、-、隠す、-承認してください、<。---------------+ <RVLId=6><SVLId=11>。| <審判=35><は=100>V4を隠しました。 (B: ルートがないことへのルーティング) V5。 + <-+--Bを拒否してください。----------------+ | | <RVLId=6><SVLId=11>。| | <審判=155><LnkRef=35>。| V<RC=NoRouteToDest>6。 | +->ACK-------------------->+| | <RVLId=11><SVLId=6>V7。 | V<審判=155>(リンク6を落とす)8。 V(リンク11を落とす)9。 (代替手段がエージェント2を通して以下を発送するのがわかります) 10. (既に2に割り当てられたA: V再利用コントロールリンクとHIDからのリソース、必要でないどんな追加リソースも) 11. +->はBを接続します。-------->+->+<RVLId=23><SVLId=5>|、| <審判=40>V| 12. + <-ACK、<。--------------+ | <RVLId=5><SVLId=23>V13。 <審判は40>(エージェント3を通して以下をBに掘る)V14と等しいです。 +->はBを接続します-->+15。 <RVLId=0><SVLId=24>+->はBを接続します。--------->+<審判=245><は=4801>V<RVLId=0><SVLId=32>を隠しました。| 16. + <、-、隠す、-承認してください、310><が隠した-+<審判=は6000>と等しいです。| <RVLId=24><SVLId=33>。| <審判=245><は= 4801>V17隠れました。 + <、-、隠す、-承認してください。--------+ <RVLId=32><SVLId=45>| <審判=310><は= 6000>V18隠れました。 (通常、取り扱いが流れのセットアップを終了するために続くACCEPT)
Figure 11. Routing Around a Failure
図11。 失敗の周りのルート設定
CIP Working Group [Page 29] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[29ページ]RFC1190インターネット流れのプロトコル1990年10月
used since they may still be required for traffic to other
next-hops in the multicast group.
それらがまだマルチキャストグループにおける他の次のホップへの交通に必要であるかもしれないので、使用されます。
When the REFUSE reaches a origin, the origin sends an ACK and
notifies the application via the next higher layer protocol
that the target listed in the TargetList is no longer part of
the stream and also if the stream has no remaining targets. If
there are no remaining targets, the application may wish to
terminate the stream.
REFUSEが起源に達すると、起源は、ACKを送って、TargetListに記載された目標がもう流れの一部とまた、流れでは残っている目標が全くないかどうかということであるようにアプリケーションに次の、より高い層のプロトコルで通知します。 残っている目標が全くなければ、アプリケーションは流れを終えたがっているかもしれません。
Figure 10 illustrates the protocol exchanges for processing a
REFUSE generated at the target, either because the target
application is not running or that the target application
rejects membership in the stream. Figure 11 illustrates the
case of rerouting around a failure by an intermediate agent
that detects a failure or receives a refuse. The protocol
exchanges used by an application at the target to delete itself
from the stream is discussed in Section 3.3.3 (page 35).
図10は、目標アプリケーションが動きでないのでREFUSEが目標で発生させた処理へのプロトコル交換と、目標アプリケーションが流れで会員資格を拒絶するのを例証します。 図11は失敗の周りで失敗を検出するか、または廃物を受ける仲介物質でコースを変更するケースを例証します。 セクション3.3.3(35ページ)で交換が流れからそれ自体を削除するのに目標のアプリケーションで使用したプロトコルについて議論します。
3.2. Data Transfer
3.2. データ転送
At the end of the connection setup phase, the origin, each target,
and each intermediate ST agent has a database entry that allows it
to forward the data packets from the origin to the targets and to
recover from failures of the intermediate agents or networks. The
database should be optimized to make the packet forwarding task
most efficient. The time critical operation is an intermediate
agent receiving a packet from the previous-hop agent and
forwarding it to the next-hop agent(s). The database entry must
also contain the FlowSpec, utilization information, the address of
the origin and previous-hop, and the addresses of the targets and
next-hops, so it can perform enforcement and recover from
failures.
接続設定フェーズの終わりでは、起源、各目標、およびそれぞれの中間的STエージェントはそれが起源から目標までデータ・パケットを進めて、仲介物質かネットワークの失敗から回復するデータベースエントリーを、持っています。 データベースは、パケット推進タスクを最も効率的にするように最適化されるべきです。 時間の批判的な操作は前のホップエージェントからパケットを受けて、次のホップエージェントにそれを送る仲介物質です。 また、データベースエントリーがFlowSpec、利用情報、起源と前のホップのアドレスを含まなければならないので、目標と次のホップのアドレスであり、それは、実施を実行して、障害を修復できます。
An ST agent receives data packets encapsulated by an ST header. A
data packet received by an ST agent contains the non-zero HID
assigned to the stream for the branch from the previous-hop to
itself. This HID was selected so that it is unique at the
receiving ST agent and thus can be used, e.g., as an index into
the database, to obtain quickly the necessary replication and
forwarding information.
STエージェントはSTヘッダーによってカプセルに入れられたデータ・パケットを受けます。 STエージェントによって受け取られたデータ・パケットはブランチのために前のホップからそれ自体まで流れに割り当てられた非ゼロHIDを含んでいます。 その結果、このHIDは選択されて、受信STエージェントでユニークであり、すぐに必要な模写を得るのに例えば、データベースへのインデックスとして使用されて、情報を転送できます。
The forwarding information will be network and implementation
specific, but must identify the next-hop agent or agents and their
respective HIDs. It is suggested that the cached information for
a next-hop agent include the local network address of the next-
hop. If the data packet must be forwarded to multiple next-hops
across a single network that supports multicast, the database may
specify a single HID and may identify the next-hops by a (local
network) multicast address.
推進情報は、ネットワークと実現特有ですが、次のホップエージェントかエージェントと彼らのそれぞれのHIDsを特定しなければなりません。 次のホップエージェントへのキャッシュされた情報が次のホップの企業内情報通信網アドレスを含んでいることが提案されます。 マルチキャストを支持するただ一つのネットワークの向こう側に複数の次のホップにデータ・パケットを送らなければならないなら、データベースは、独身のHIDを指定して、(企業内情報通信網)マルチキャストアドレスで次のホップを特定するかもしれません。
CIP Working Group [Page 30] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[30ページ]RFC1190インターネット流れのプロトコル1990年10月
If the network does not support multicast, or the next-hops are on
different networks, then the database must indicate multiple
(next-hop, HID) tuples. When multiple copies of the data packet
must be sent, it may be necessary to invoke a packet replicator.
ネットワークがマルチキャストを支持しないか、または次のホップが異なったネットワークにあるなら、データベースは複数の(次のホップ、HID)tuplesを示さなければなりません。 データ・パケットの複本を送らなければならないとき、パケット反復子を呼び出すのが必要であるかもしれません。
Data packets should not require fragmentation as the next higher
protocol layer at the origin was informed of the minimum MTU over
all paths in the stream and is expected to segment its PDUs
accordingly. However, it may be the case that a data packet that
is being rerouted around a failed network component may be too
large for the MTU of an intervening network. This should be a
transient condition that will be corrected as soon as the new
minimum MTU has been propagated back to the origin. Disposition
by a mechanism other than dropping of the too large PDUs is left
for further study.
起源における次の、より高いプロトコル層がすべての経路にわたって最小のMTUにおいて流れで知識があって、それに従って、PDUsを区分すると予想されるとき、データ・パケットは断片化を必要とするはずがありません。 しかしながら、介入しているネットワークのMTUには、失敗したネットワーク要素の周りで別ルートで送られているデータ・パケットが大き過ぎるかもしれないのは、事実であるかもしれません。 これは新しい最小のMTUが起源に伝播して戻されるとすぐに、修正される一時的な状態であるべきです。 大き過ぎるPDUsを落とすのを除いたメカニズムによる気質はさらなる研究に発たれます。
3.3. Modifying an Existing Stream
3.3. 既存の流れを変更します。
Some applications may wish to change the parameters of a stream
after it has been created. Possible changes include adding or
deleting targets and changing the FlowSpec. These are described
below.
それを作成してある後にいくつかのアプリケーションが流れのパラメタを変えたがっているかもしれません。 可能な変化は、加えるか、目標を削除して、またはFlowSpecを変えるのを含んでいます。 これらは以下で説明されます。
3.3.1. Adding a Target
3.3.1. 目標を加えます。
It is possible for an application to add a new target to an
existing stream any time after ST has incorporated information
about the stream into its database. At a high level, the
application entities exchanges whatever information is
necessary. Although the mechanism or protocol used to
accomplish this is not specified here, it is necessary for the
higher layer protocol to inform the host ST agent at the origin
of this event. The host ST agent at the target must also be
informed unless this had previously been done. Generally, the
transfer of a target list from an ST agent to another, or from
a higher layer protocol to a host ST agent, will occur
atomically when the CONNECT is received. Any information
concerning a new target received after this point can be viewed
as a stream expansion by the receiving ST agent. However, it
may be possible that an ST agent can utilize such information
if it is received before it makes the relevant routing
decisions. These implementation details are not specified
here, but implementations must be prepared to receive CONNECT
messages that represent expansions of streams that are still in
the process of being setup.
アプリケーションがSTが流れの情報をデータベースに組み入れた後にいつでも既存の流れに新しい目標を加えるのは、可能です。 高いレベル、アプリケーション実体交換のいかなる必要な情報。 これを達成するのに使用されるメカニズムかプロトコルがここで指定されませんが、より高い層のプロトコルがこの出来事の起源でホストSTエージェントに知らせるのが必要です。 また、以前にこれをしていなかったなら、目標のホストSTエージェントも知識があるに違いありません。 CONNECTが受け取られているとき、一般に、目標リストのSTエージェントから別のものまでより高い層のプロトコルからホストSTエージェントまでの転送は原子論的に起こるでしょう。 流れの拡大として受信STエージェントによってこのポイントを見なされたことができた後に新しい目標のどんな情報も受信されました。 しかしながら、関連ルーティング決定をする前にそれが受け取られているならSTエージェントがそのような情報を利用できるのは、可能であるかもしれません。 これらの実現の詳細はここで指定されませんが、まだセットアップであることの途中にある流れの膨張を表すCONNECTメッセージを受け取るように実現を準備しなければなりません。
To expand an existing stream, the origin issues one or more
CONNECT messages that contain the Name, the VLId, the FlowSpec,
and the TargetList specifying the new target or targets. The
origin issues multiple CONNECT messages if
既存の流れを膨張させるように、起源は新しい目標か目標を指定するName、VLId、FlowSpec、およびTargetListを含む1つ以上のCONNECTメッセージを発行します。 起源は複数のCONNECTメッセージを発行します。
CIP Working Group [Page 31] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[31ページ]RFC1190インターネット流れのプロトコル1990年10月
either the targets are to be reached through different next-hop
agents, or a single CONNECT message is too large for the
network MTU. The HID Field option is not set since the HID has
already been (or is being) negotiated for the hop;
consequently, the CONNECT is acknowledged with an ACK instead
of a HID-REJECT or HID-APPROVE.
目標が異なった次のホップエージェントを通して達することであるまたはネットワークMTUには、ただ一つのCONNECTメッセージは大き過ぎます。 HIDがホップのために既に交渉されたので(または、存在です)、HID Fieldオプションは設定されません。 その結果、CONNECTはHID-REJECTかHID-APPROVEの代わりにACKと共に承認されます。
Application Agent A Agent 2 Agent E
アプリケーションエージェントはエージェントの2エージェントEです。
1. (open E)
2. V (proc E listening)
3. +->(routing to E)
V
4. +-> (check resources from A to Agent 2: already allocated,
V reuse control link & HID, no additional resources needed)
5. +-> CONNECT E --------->+->+
<RVLId=23><SVLId=5> | V
6. <Ref=20> V (routing to E)
7. +<- ACK <---------------+ V
<RVLId=5><SVLId=23> +->(reserve resources 2 to E)
<Ref=20> V
8. +-> CONNECT E --------->+
<RVLId=0><SVLId=27> |
<Ref=230><HID=4800> |
9. +<- HID-APPROVE <-------+
<RVLId=27><SVLId=74>|
<Ref=230><HID=4800> V
10. (proc E accepts)
11. (wait until HID negotiated)
V
12. +<-+<- ACCEPT E <----------+
V | <RVLId=27><SVLId=74>
13. (wait for ACCEPTS) V <Ref=710><LnkRef=230>
14. V +-> ACK --------------->+
15. (wait until HID negotiated)<-+ <RVLId=74><SVLId=27>
V <Ref=710>
16. +<- ACCEPT E <-------+
| <RVLId=5><SVLId=23>
V <Ref=235><LnkRef=20>
17. +-> ACK ------------>+
| <RVLId=23><SVLId=5>
V <Ref=235>
18. +<-(inform A of E's FlowSpec)
V
19. +<-(wait for ACCEPTS)
V
20. +<-(wait until HID negotiated)
V
21. (inform A open to E)
1. (戸外E) 2. V(proc E聴取)3。 +->(Eへのルーティング)V4。 +->(Aからエージェント2までのチェックリソース: コントロールリンクとHID、どんな追加リソースも必要としなかった既に割り当てられたV再利用)5。 +->はEを接続します。--------->+->+<RVLId=23><SVLId=5>。| V6。 <審判=20>V(Eへのルーティング)7。 + <-ACK、<。---------------+ V<RVLId=5><SVLId=23>+->(Eへの蓄えのリソース2)<Ref=20>V8。 +->はEを接続します。--------->+<RVLId=0><SVLId=27>。| 230><が隠した<審判=は4800>と等しいです。| 9. + <、-、隠す、-承認してください、<。-------+ <RVLId=27><SVLId=74>| <審判=230><は= 4800>V10隠れました。 (Eが受け入れるproc) 11. (HIDが交渉するまでの待ち) V12。 +、<-+はE<を<受け入れます。----------+ V| <RVLId=27><SVLId=74>13。 (待っている、受諾、) V<審判は710><LnkRef=230>14と等しいです。 V+->ACK--------------->+15。 (HIDが交渉するまでの待ち)<。+ <RVLId=74><SVLId=27>V<審判は710>16と等しいです。 +はE<を<受け入れます。-------+ | <RVLId=5><SVLId=23>V<審判は235><LnkRef=20>17と等しいです。 +->ACK------------>+| <RVLId=23><SVLId=5>V<審判は235>18と等しいです。 + <、-、(EのFlowSpecのAを知らせます)V19 + <、-、(待っている、受諾、)、V20 + <、-、(HIDが交渉するまで、待っています)V21 (A戸外をEに知らせます)
Figure 12. Addition of Another Target
図12。 別の目標の添加
CIP Working Group [Page 32] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[32ページ]RFC1190インターネット流れのプロトコル1990年10月
An ST agent that is already a node in the stream recognizes the
RVLId and verifies that the Name of the stream is the same. It
then checks if the intersection of the TargetList and the
targets of the established stream is empty. If this is not the
case, then the receiver responds with an ERROR-IN-REQUEST with
the appropriate reason code (RouteLoop) that contains a
TargetList of those targets that were duplicates; see Section
4.2.3.5 (page 106).
既に流れのノードであるSTエージェントは、RVLIdを認識して、流れのNameが同じであることを確かめます。 そして、それは、TargetListの交差点と確立した流れの目標に人影がないかどうかチェックします。 これがそうでないなら、受信機はERROR IN REQUESTと共に写しであったそれらの目標のTargetListを含む適切な理由コード(RouteLoop)で応じます。 セクション4.2を見てください。.3 .5(106ページ)。
For each new target in the TargetList, processing is much the
same as for the original CONNECT; see Sections 3.1.2-4 (pages
19-20). The CONNECT must be acknowledged, propagated, and
network resources must be reserved. However, it may be
possible to route to the new targets using previously allocated
paths or an existing multicast group. In that case, additional
resources do not need to be reserved but more next-hop(s) might
have to be added to an existing multicast group.
TargetListのそれぞれの新しい目標において、処理はオリジナルのCONNECTのように似たり寄ったりです。 セクション3.1.2-4(19-20ページ)を見てください。 CONNECTは承認されて、伝播していなければなりません、そして、ネットワーク資源を予約しなければなりません。 しかしながら、それは、新しい目標に発送するのにおいて以前に割り当てられた経路か既存のマルチキャストグループを使用することで可能であるかもしれません。 その場合、追加リソースによって予約される必要はありませんが、次のホップが加えられるために持っているかもしれない以上は既存のマルチキャストに分類されます。
Nevertheless, the origin, or any intermediate ST agent that
receives a CONNECT for an existing stream, can make a routing
decision that is independent of any it may have made
previously. Depending on the routing algorithm that is used,
the ST agent may decide to reach the new target by way of an
established branch, or it may decide to create a new branch.
The fact that a new target is being added to an existing stream
may result in a suboptimal overall routing for certain routing
algorithms. We take this problem to be unavoidable since it is
unlikely that the stream routing can be made optimal in
general, and the only way to avoid this loss of optimality is
to redefine the routing of potentially the entire stream, which
would be too expensive and time consuming.
それにもかかわらず、起源、または既存の流れのためにCONNECTを受け取るどんな中間的STエージェントもそれが以前に作ったかもしれないいずれからも独立しているルーティング決定をすることができます。 使用されたルーティング・アルゴリズムによって、STエージェントが、設立されたブランチを通して新しい目標に達すると決めるかもしれませんか、またはそれは、新しいブランチを創設すると決めるかもしれません。 新しい目標が既存の流れに加えられているという事実はあるルーティング・アルゴリズムのための準最適の総合的なルーティングをもたらすかもしれません。最適のこの損失を避ける唯一の方法は流れのルーティングを一般に、最適にすることができるのがありそうもないので私たちが避けられなくなるようにこの問題を取って、潜在的に全体の流れのルーティングを再定義することです。(流れは、高価過ぎて、時間がかかっているでしょう)。
3.3.2. The Origin Removing a Target
3.3.2. 目標を取り外す起源
The application at the origin specifies a set of targets that
are to be removed from the stream and an appropriate reason
code (ApplDisconnect). The targets are partitioned into
multiple DISCONNECT messages based on the next-hop to the
individual targets. As with CONNECT messages, an ST agent that
is sending a DISCONNECT must make sure that the message fits
into the MTU for the intervening network. If the message is
too large, the TargetList must be further partitioned into
multiple DISCONNECT messages.
起源におけるアプリケーションは流れと適切な理由コード(ApplDisconnect)から取り外されることになっている1セットの目標を指定します。 目標は個々の目標への次のホップに基づく複数のDISCONNECTメッセージに仕切られます。 CONNECTメッセージなら、DISCONNECTを送るSTエージェントは、メッセージが介入しているネットワークのためのMTUに収まるのを確実にしなければなりません。 メッセージが大き過ぎるなら、さらに複数のDISCONNECTメッセージにTargetListを仕切らなければなりません。
An ST agent that receives a DISCONNECT message must acknowledge
it by sending an ACK back to the previous-hop. The DISCONNECT
must also be propagated to the relevant next-hop ST agents.
Before propagating the message, however, the TargetList should
be partitioned based on next-hop ST
DISCONNECTメッセージを受け取るSTエージェントは、前のホップにACKを送り返すことによって、それを承認しなければなりません。 また、関連次のホップSTエージェントにDISCONNECTを伝播しなければなりません。 しかしながら、メッセージを伝播する前に、TargetListは次のホップSTに基づいて仕切られるべきです。
CIP Working Group [Page 33] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[33ページ]RFC1190インターネット流れのプロトコル1990年10月
agent and MTU, as described above. Note that there may be
targets in the TargetList for which the ST agent has no
information. This may result from interacting DISCONNECT and
REFUSE messages and should be logged and silently ignored.
上で説明されるとしてのエージェントとMTU。 目標がSTエージェントが情報を全く持っていないTargetListにあるかもしれないことに注意してください。 これは、DISCONNECTに相互作用して、REFUSEメッセージから生じるかもしれなくて、登録されて、静かに無視されるべきです。
If, after deleting the specified targets, any next-hop has no
remaining targets, then those resources associated with that
next-hop agent may be released. Note that network resources
may not actually be released if network multicasting is being
used since they may still be required for traffic to other
next-hops in the multicast group.
指定された目標を削除した後に、どんな次のホップにも残っている目標が全くないなら、その次のホップエージェントに関連しているそれらのリソースは発表されるかもしれません。 それらがまだマルチキャストグループにおける他の次のホップへの交通に必要であるかもしれないのでネットワークマルチキャスティングが使用されているならネットワーク資源が実際にリリースされないかもしれないことに注意してください。
Application Application
Agent A Agent 1 Agent 2 Agent B C
アプリケーションアプリケーションエージェントはエージェント1人のエージェント2エージェントB Cです。
1. (close B,C ApplDisconnect)
V
2. +->+-+-> DISCONNECT B ----->+
3. | | <RVLId=14><SVLId=4>+-+-> DISCONNECT B ------>+
| | <Ref=25> | | <RVLId=44><SVLId=15>|
| V <RC=ApplDisconnect>| | <Ref=120> |
4. | (free A to 1 resrc.) | V <RC=ApplDisconnect> |
5. | V (free 1 to B resrc.) |
6. | +<- ACK <--------------+ V
7. | | <RVLId=4><SVLId=14>| +<- ACK <---------------+
| V <Ref=25> | | <RVLId=15><SVLId=44>|
8. | (free link 4) V | <Ref=120> |
9. | (free link 14) V |
10. | (free link 15) V
11. | (inform B that stream closed ApplDisconnect)
12. | (free link 44)
V
13. +<-+-+-> DISCONNECT C ---------->+
14. | | <RVLId=23><SVLId=5> +-+-> DISCONNECT C ------>+
| | <Ref=30> | | <RVLId=54><SVLId=25>|
| V <RC=ApplDisconnect> | | <Ref=240> |
15. | (keep A to 2 resrc for | V <RC=ApplDisconnect> |
16. | data going to D,E) | (free 2 to C resrc.) |
| V |
17. | +<- ACK <-------------------+ V
18. | | <RVLId=5><SVLId=23> | +<- ACK <---------------+
| V <Ref=30> | | <RVLId=25><SVLId=54>|
19. | (keep link 5 for D,E) V | <Ref=240> |
20. | (keep link 23 for D,E) V |
21. | (free link 25) V
22. | (inform C that stream closed ApplDisconnect>)
23. V (free link 54)
24. (inform A closed to B,C ApplDisconnect)
1. (閉鎖B、C ApplDisconnect) V2。 +>++->はBを外します。----->+3。 | | <RVLId=14><SVLId=4>++->はBを外します。------>+| | <審判=25>。| | <RVLId=44><SVLId=15>|、| V<RC=ApplDisconnect>|、| <審判=120>。| 4. | (1resrcにAを解放してください。) | V<RC=ApplDisconnect>。| 5. | V(B resrcに1を解放してください。) | 6. | + <-ACK、<。--------------+ V7。 | | <RVLId=4><SVLId=14>| + <-ACK、<。---------------+ | V<審判=25>。| | <RVLId=15><SVLId=44>| 8. | (無料のリンク4) V| <審判=120>。| 9. | (無料のリンク14) V| 10. | (無料のリンク15) V11。 | (流れがApplDisconnectを閉じたことをBに知らせます) 12. | (無料のリンク44) V13。 +、<-++->はCを外します。---------->+14。 | | <RVLId=23><SVLId=5>++>分離C------>+| | <審判=30>。| | <RVLId=54><SVLId=25>|、| V<RC=ApplDisconnect>。| | <審判=240>。| 15. | (E、|Dに行く<RC=ApplDisconnect>|16|データに対して2resrcへのAを保ってください) | (C resrcに2を解放してください。) | | V| 17. | + <-ACK、<。-------------------+ V18。 | | <RVLId=5><SVLId=23>。| + <-ACK、<。---------------+ | V<審判=30>。| | <RVLId=25><SVLId=54>| 19. | (E、Dのためにリンク5を保ってください) V| <審判=240>。| 20. | (E、Dのためにリンク23を保ってください) V| 21. | (無料のリンク25) V22。 | (流れがApplDisconnect>を閉じたことをCに知らせます) 23. V(無料のリンク54)24。 (C ApplDisconnect、Bに閉じられたAを知らせてください)
Figure 13. Origin Removing a Target
図13。 目標を取り外す起源
CIP Working Group [Page 34] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[34ページ]RFC1190インターネット流れのプロトコル1990年10月
When the DISCONNECT reaches a target, the target sends an ACK
and notifies the application that it is no longer part of the
stream and the reason. The application should then inform ST
to terminate the stream, and ST should delete the stream from
its database after performing any necessary management and
accounting functions.
DISCONNECTが目標に達すると、目標は、ACKを送って、それがもう流れと理由の一部でないようにアプリケーションに通知します。 次に、アプリケーションは流れを終えるためにSTに知らせるべきです、そして、どんな必要な管理と会計機能も実行した後に、STはデータベースから流れを削除するはずです。
3.3.3. A Target Deleting Itself
3.3.3. それ自体を削除する目標
The application at the target may inform ST that it wants to be
removed from the stream and the appropriate reason code
(ApplDisconnect). The agent then forms a REFUSE message with
itself as the only entry in the TargetList. The REFUSE is sent
back to the origin via the previous-hop. If a stream has
multiple targets and one target leaves the stream using this
REFUSE mechanism, the stream to the other targets is not
affected; the stream continues to exist.
目標のアプリケーションは、それを流れと適切な理由コード(ApplDisconnect)から取り除かれたいことをSTに知らせるかもしれません。 そして、エージェントはTargetListにおける唯一のエントリーとしてそれ自体でREFUSEメッセージを形成します。 前のホップを通した起源はREFUSEに送り返されます。 流れにはマルチターゲットがあって、1個の目標がこのREFUSEメカニズムを使用することで流れを残すなら、他の目標への流れは影響を受けません。 流れは存続します。
An ST agent that receives such a REFUSE message must
acknowledge it by sending an ACK to the next-hop. The target
is deleted and, if the next-hop has no remaining targets, then
the those resources associated with that next-hop agent may be
released. Note that network resources may not actually be
released if network multicasting is being used since they may
still be required for traffic to other next-hops in the
multicast group. The REFUSE must also be propagated back to
the previous-hop ST agent.
そのようなREFUSEメッセージを受け取るSTエージェントは、次のホップにACKを送ることによって、それを承認しなければなりません。 目標が削除される、次のホップに残っている目標が全くないときのその時、その次のホップエージェントに関連しているそれらのリソースは発表されるかもしれません。 それらがまだマルチキャストグループにおける他の次のホップへの交通に必要であるかもしれないのでネットワークマルチキャスティングが使用されているならネットワーク資源が実際にリリースされないかもしれないことに注意してください。 また、前のホップSTエージェントにREFUSEを伝播して戻さなければなりません。
Agent A Agent 2 Agent E
エージェントはエージェントの2エージェントEです。
1. (close E ApplDisconnect)
V
2. +<- REFUSE E --+
| <RVLId=27><SVLId=74>
| <Ref=720>
V <RC=ApplDisconnect>
3. +<-+-> ACK ------>+
| | <RVLId=74><SVLId=27>
4. V V <Ref=720>
5. +<-+<- REFUSE E --+ (prune allocations)
| | <RVLId=5><SVLId=23>
| | <Ref=245>
| V <RC=ApplDisconnect>
6. | +-> ACK ------>+
| | <RVLId=23><SVLId=5>
| V <Ref=245>
7. V (prune allocations)
8. (inform application closed E ApplDisconnect)
1. (近いE ApplDisconnect) V2。 + <廃物E--+| <RVLId=27><SVLId=74>。| <審判は720>V<RC=ApplDisconnect>3と等しいです。 + <-+>、ACK------>+| | <RVLId=74><SVLId=27>4。 V V<審判は720>5と等しいです。 + <-+<REFUSE E--+ (プルーンの配分)| | <RVLId=5><SVLId=23>。| | <審判=245>。| V<RC=ApplDisconnect>6。 | +->ACK------>+| | <RVLId=23><SVLId=5>。| V<審判は245>7と等しいです。 V(プルーンの配分)8。 (アプリケーションの閉じているE ApplDisconnectに知らせます)
Figure 14. Target Deleting Itself
図14。 目標削除自体
CIP Working Group [Page 35] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[35ページ]RFC1190インターネット流れのプロトコル1990年10月
When the REFUSE reaches the origin, the origin sends an ACK and
notifies the application that the target listed in the
TargetList is no longer part of the stream. If the stream has
no remaining targets, the application may choose to terminate
the stream.
REFUSEが起源に達すると、起源は、ACKを送って、TargetListに記載された目標がもう流れの一部でないようにアプリケーションに通知します。 流れに残っている目標が全くないなら、アプリケーションは、流れを終えるのを選ぶかもしれません。
3.3.4. Changing the FlowSpec
3.3.4. FlowSpecを変えます。
An application may wish to change the FlowSpec of an
established stream. To do so, it informs ST of the new
FlowSpec and the list of targets that are to be changed. The
origin ST agent then issues one or more CHANGE messages with
the new FlowSpec and sends them to the relevant next-hop
agents. CHANGE messages are structured and processed similarly
to CONNECT messages. A next-hop agent that is an intermediate
agent and receives a CHANGE message similarly determines if it
can implement the new FlowSpec along the hop to each of its
next-hop agents, and if so, it propagates the CHANGE messages
along the established paths. If this process succeeds, the
CHANGE messages will eventually reach the targets, which will
each respond with an ACCEPT message that is propagated back to
the origin.
アプリケーションは確立した流れのFlowSpecを変えたがっているかもしれません。 そうするために、それは変えられることになっている目標の新しいFlowSpecとリストについてSTに知らせます。 起源STエージェントは、次に、新しいFlowSpecと共に1CHANGEにメッセージを発行して、関連次のホップエージェントにそれらを送ります。 CHANGEメッセージは、同様にCONNECTメッセージに構造化されて、処理されます。 仲介物質であり、同様にCHANGEメッセージを受け取る次のホップエージェントは、それがホップに沿って次のホップエージェントの各人に新しいFlowSpecを実行できるかどうかと決心しています、そして、そうだとすれば、それは確立した経路に沿ってCHANGEメッセージを伝播します。 この過程が成功すると、CHANGEメッセージは結局、目標に達するでしょう。(それぞれ、目標は起源に伝播して戻されるACCEPTメッセージで応じるでしょう)。
Note that since a CHANGE may be sent containing a FlowSpec with
a range of permissible values for bandwidth, delay, and/or
error rate, and the actual values returned in the ACCEPTs may
differ, then another CHANGE may be required to release excess
resources along some of the paths.
次に、CHANGEに帯域幅、遅れ、そして/または、誤り率のためにさまざまな許容値があるFlowSpecを含ませるかもしれなくて、ACCEPTsで返された実価が異なるかもしれないので別のCHANGEが経路のいくつかに沿って余分なリソースを発表しなければならないかもしれないことに注意してください。
3.4. Stream Tear Down
3.4. 裂け目を滴り落ちさせてください。
A stream is usually terminated by the origin when it has no
further data to send, but may also be partially torn down by the
individual targets. These cases will not be further discussed
since they have already been described in Sections 3.3.2-3 (pages
33-35).
小川をそれに送らない詳しいデータが全くあると起源で通常終えますが、また、個々の目標は部分的に取りこわすかもしれません。 それらがセクション3.3.2-3(33-35ページ)で既に説明されるので、さらにこれらのケースについて議論しないでしょう。
A stream is also torn down if the application should terminate
abnormally. Processing in this case is identical to the previous
descriptions except that the appropriate reason code is different
(ApplAbort).
また、アプリケーションが異常に終わるなら取りこわして、流れはそうです。 適切な理由コードが異なっているのを除いて(ApplAbort)、この場合、処理は前の記述と同じです。
When all targets have left a stream, the origin notifies the
application of that fact, and the application then is responsible
for terminating the stream. Note, however, that the application
may decide to add a target(s) to the stream instead of terminating
it.
すべての目標が流れを残したとき、起源はその事実の適用に通知します、そして、次に、アプリケーションは流れを終えるのに原因となります。 しかしながら、アプリケーションが、それを終えることの代わりに流れに目標を加えると決めるかもしれないことに注意してください。
CIP Working Group [Page 36] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[36ページ]RFC1190インターネット流れのプロトコル1990年10月
3.5. Exceptional Cases
3.5. 例外的なケース
The previous descriptions covered the simple cases where
everything worked. We now discuss what happens when things do not
succeed. Included are situations where messages are lost, the
requested resources are not available, the routing fails or is
inconsistent.
前の記述はすべてが働いていた簡単なケースをカバーしました。 私たちは、現在、いろいろなことが成功しないと何が起こるかと議論します。 含まれているのは、メッセージが無くなる、要求されたリソースが利用可能でない、ルーティングが失敗するか、または矛盾している状況です。
In order for the ST Control Message Protocol to be reliable over
an unreliable internetwork, the problems of corruption,
duplication, loss, and ordering must be addressed. Corruption is
handled through use of checksumming, as described in Section 4
(page 76). Duplication of control messages is detected by
assigning a transaction number (Reference) to each control
message; duplicates are discarded. Loss is detected using a
timeout at the sender; messages that are not acknowledged before
the timeout expires are retransmitted; see Section 3.7.6 (page
66). If a message is not acknowledged after a few retransmissions
a fault is reported. The protocol does not have significant
ordering constraints. However, minor sequencing of control
messages for a stream is facilitated by the requirement that the
Reference numbers be monotonically increasing; see Section 4.2
(page 78).
ST Control Messageプロトコルが頼り無いインターネットワークの上で信頼できるように、不正、複製、損失、および注文の問題を記述しなければなりません。 不正はセクション4(76ページ)で説明されるようにchecksummingすることの使用で扱われます。 コントロールメッセージの複製は取引番号(参照)をそれぞれのコントロールメッセージに割り当てることによって、検出されます。 写しは捨てられます。 損失は送付者でタイムアウトを使用するのが検出されます。 タイムアウトが期限が切れる前に承認されないメッセージは再送されます。 セクション3.7.6(66ページ)を見てください。 メッセージがいくつかの「再-トランスミッション」の後に承認されないなら、欠点は報告されます。 プロトコルには、重要な注文規制がありません。 しかしながら、増加して、Reference番号が単調にそうであるという要件によって流れへのコントロールメッセージの小さい方の配列は容易にされます。 セクション4.2(78ページ)を見てください。
3.5.1. Setup Failure due to CONNECT Timeout
3.5.1. CONNECT TimeoutによるセットアップFailure
If a response (an ERROR-IN-REQUEST, an ACK, a HID-REJECT, or a
HID-APPROVE) has not been received within time ToConnect, the
ST agent should retransmit the CONNECT message. If no response
has been received within NConnect retransmissions, then a fault
occurs and a REFUSE message with the appropriate reason code
(RetransTimeout) is sent back in the direction of the origin,
and, in place of the CONNECT, a DISCONNECT is sent to the
next-hop (in case the response to the CONNECT is the message
that was lost). The agent will expect an ACK for both the
REFUSE and the DISCONNECT messages. If it does not receive an
ACK after retransmission time ToRefuse and ToDisconnect
respectively, it will resend the REFUSE/DISCONNECT message. If
it does not receive ACKs after sending NRefuse/ NDisconnect
consecutive REFUSE/DISCONNECT messages, then it simply gives up
trying.
応答(ERROR IN REQUEST、ACK、HID-REJECT、またはHID-APPROVE)が時間ToConnect中に受けられていないなら、STエージェントはCONNECTメッセージを再送するべきです。 NConnect retransmissionsの中で応答を全く受けていないなら、欠点は起こります、そして、起源の向きに適切な理由コード(RetransTimeout)があるREFUSEメッセージを返送します、そして、CONNECTに代わって、次のホップにDISCONNECTを送ります(CONNECTへの応答が失われたメッセージであるといけないので)。 エージェントはREFUSEとDISCONNECTメッセージの両方のためにACKを予想するでしょう。 それぞれ「再-トランスミッション」時間のToRefuseとToDisconnectの後にACKを受けないと、それはREFUSE/DISCONNECTメッセージを再送するでしょう。 連続したREFUSE/DISCONNECTメッセージをNRefuse/ NDisconnectに送った後にACKsを受けないなら、それは、試みるのを単にやめます。
CIP Working Group [Page 37] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[37ページ]RFC1190インターネット流れのプロトコル1990年10月
Sending Agent Receiving Agent
エージェント受信にエージェントを送ります。
1. ->+----> CONNECT X ------>//// (message lost or garbled)
| <RVLId=0><SVLId=99>
V <Ref=1278><HID=1234>
2. (timeout)
V
3. +----> CONNECT X ------------>+
4. | <RVLId=0><SVLId=99> +----> CONNECT X ----------->+
| <Ref=1278><HID=1234> V <RVLId=0><SVLId=1010> |
5. | //<- HID-APPROVE <----------+ <Ref=6666><HID=6666> V
6. | <RVLId=99><SVLId=88> +<- HID-APPROVE <---------+
V <Ref=1278><HID=1234> <RVLId=1010><SVLId=1111>
7. (timeout) <Ref=6666><HID=6666>
V
8. +----> CONNECT X ------------>+
<RVLId=0><SVLId=99> |
<Ref=1278><HID=1234> V
9. +<-+<- HID-APPROVE <----------+
| <RVLId=99><SVLId=88>
V <Ref=1278><HID=1234>
(cancel timer)
1. ->+---->はXを接続します。------>////(失われているか、または誤り伝えられたメッセージ)| <RVLId=0><SVLId=99>V<審判=1278><は=1234>2を隠しました。 (タイムアウト) V3。 +---->はXを接続します。------------>+4。 | <RVLId=0><SVLId=99>+---->はXを接続します。----------->+| <審判=1278><は=1234>V<RVLId=0><SVLId=1010>を隠しました。| 5. | //<、隠す、-承認してください、<。----------6666>+ <審判=<は= 6666>V6隠しました。 | <RVLId=99><SVLId=88>+<、-、隠す、-承認してください、<。---------+ V<審判は1234><RVLId=1010><SVLId=1111<が隠した1278>=>7と等しいです。 (タイムアウト) <審判=6666><は= 6666>V8隠れました。 +---->はXを接続します。------------>+<RVLId=0><SVLId=99>。| <審判=1278><は= 1234>V9隠れました。 + <-+<、-、隠す、-承認してください、<。----------+ | <審判=1278><が隠した<RVLId=99><SVLId=88>Vは1234>と等しいです。(キャンセルタイマ)
Figure 15. CONNECT Retransmission after a Timeout
図15。 タイムアウトの後にRetransmissionを接続してください。
3.5.2. Problems due to Routing Inconsistency
3.5.2. ルート設定Inconsistencyによる問題
When an intermediate agent receives a CONNECT, it selects the
next-hop agents based on the TargetList and the networks to
which it is connected. If the resulting next-hop to any of the
targets is across the same network from which it received the
CONNECT (but not the previous-hop itself), there may be a
routing problem. However, the routing algorithm at the
previous-hop may be optimizing differently than the local
algorithm would in the same situation. Since the local ST
agent cannot distinguish the two cases, it should permit the
setup but send back to the previous-hop agent an informative
NOTIFY message with the appropriate reason code (RouteBack),
pertinent TargetList, and in the NextHopIPAddress element the
address of the next-hop ST agent returned by its routing
algorithm.
仲介物質がCONNECTを受け取るとき、それはTargetListに基づく次のホップエージェントと関連しているネットワークを選択します。 目標のどれかへの結果として起こる次のホップがそれがCONNECT(しかし、前のホップ自体でない)を受けたのと同じネットワークのむこうにあるなら、ルーティング問題があるかもしれません。 しかしながら、前のホップのルーティング・アルゴリズムはローカルのアルゴリズムと異なって最適化することであるかもしれません。同じ状況で、そうするでしょう。 地元のSTエージェントが2つのケースを区別できないので、セットアップを可能にしますが、適切な理由コード(RouteBack)で有益なNOTIFYメッセージを前のホップエージェントに送り返すべきです、適切なTargetList、そして、NextHopIPAddress要素では、ルーティング・アルゴリズムで次のホップSTエージェントのアドレスは戻りました。
The agent that receives such a NOTIFY should ACK it. If the
agent is using an algorithm that would produce such behavior,
no further action is taken; if not, the agent should send a
DISCONNECT to the next-hop agent to correct the problem.
そのようなNOTIFYを受け取るエージェントがそうするべきである、ACK、それ。 エージェントがそのような振舞いを起こすアルゴリズムを使用しているなら、さらなる行動を全く取りません。 そうでなければ、エージェントは、問題を修正するために次のホップエージェントにDISCONNECTを送るべきです。
Alternatively, if the next-hop returned by the routing function
is in fact the previous-hop, a routing inconsistency has been
detected. In this case, a REFUSE is sent back to
あるいはまた、事実上、経路選択機能によって返された次のホップが前のホップであるなら、ルーティング矛盾は検出されました。 この場合、REFUSEは送り返されます。
CIP Working Group [Page 38] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[38ページ]RFC1190インターネット流れのプロトコル1990年10月
the previous-hop agent containing an appropriate reason code
(RouteInconsist), pertinent TargetList, and in the
NextHopIPAddress element the address of the previous-hop. When
the previous-hop receives the REFUSE, it will recompute the
next-hop for the affected targets. If there is a difference in
the routing databases in the two agents, they may exchange
CONNECT and REFUSE messages again. Since such routing errors
in the internet are assumed to be temporary, the situation
should eventually stabilize.
適切な理由コード(RouteInconsist)を含む前のホップエージェント、適切なTargetList、およびNextHopIPAddress要素の前のホップのアドレス。 前のホップがREFUSEを受けるとき、それは影響を受ける目標のために次のホップを再計算するでしょう。 ルーティングデータベースの違いが2人のエージェントにあれば、彼らは再びCONNECTとREFUSEメッセージを交換するかもしれません。 インターネットにおけるそのようなルーティング誤りが一時的であると思われるので、状況は結局、安定するべきです。
3.5.3. Setup Failure due to a Routing Failure
3.5.3. ルート設定FailureによるセットアップFailure
It is possible for an agent to receive a CONNECT message that
contains a known Name, but from an agent other than the
previous-hop agent of the stream with that Name. This may be:
それは、知られているNameを含むCONNECTメッセージを受け取るエージェントにとって可能ですが、そのNameとの流れの前のホップエージェント以外のエージェントから可能です。 これは以下の通りです。
1 that two branches of the tree forming the stream have
joined back together,
1 流れを形成する木の2つの枝が結合し返しました。
2 a deliberate source routing loop,
2 慎重なソースルーティング輪
3 the result of an attempted recovery of a partially
failed stream, or
または3 部分的に失敗した流れの試みられた回収の結果。
4 an erroneous routing loop.
4 誤ったルーティング輪。
The TargetList is used to distinguish the cases 1 and 2 (see
also Section 4.2.3.5 (page 107)) by comparing each newly
received target with those of the previously existing stream:
TargetListは、ケース1と2を区別するのに使用されます。(また、新たに受け取られたそれぞれを比較するのによる.5(107ページ)が以前に既存の流れのもので狙うセクション4.2.3を見てください:
o if the IP address of the targets differ, it is case 1;
o 目標のIPアドレスであるなら、異なってください、そして、それはケース1です。
o if the IP address of the targets match but the source
route(s) are different, it is case 2;
o 目標のIPアドレスが合っていますが、送信元経路が異なるなら、それはケース2です。
o if the target (including any source route) matches a
target (including any source route) in the existing
stream, it may be case 3 or 4.
o 目標(どんな送信元経路も含んでいる)が既存の流れで目標(どんな送信元経路も含んでいる)に合っているなら、それはケース3か4であるかもしれない。
It is expected that the joining of branches will become more
common as routing decisions are based on policy issues and not
just simple connectivity. Unfortunately, there is no good way
to merge the two parts of the stream back into a single stream.
They must be treated independently with respect to processing
in the agent. In particular, a separate state machine is
required, the Virtual Link Identifiers and HIDs from the
previous-hops and to the next-hops must be different, and
duplicate resources must be reserved in both the agent and in
any next-hop networks. Processing is the same for a deliberate
source routing loop.
ルーティング決定が簡単な接続性だけではなく、政策問題に基づいているときブランチの接合が、より一般的になると予想されます。 残念ながら、流れの2つの一部分をただ一つの流れの中に合併して戻す早道が全くありません。 エージェントで処理に関して独自にそれらを扱わなければなりません。 別々の州のマシンが特に、必要です、そして、前のホップと、そして、次のホップへのVirtual Link IdentifiersとHIDsは異なるに違いありません、そして、両方でエージェントとどんな次のホップネットワークでも写しリソースを予約しなければなりません。 慎重なソースルーティング輪に、処理は同じです。
CIP Working Group [Page 39] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[39ページ]RFC1190インターネット流れのプロトコル1990年10月
The remaining cases requiring recovery, a partially failed
stream and an erroneous routing loop, are not easily
distinguishable. In attempting recovery of a failed stream, an
agent may issue new CONNECT messages to the affected targets;
for a full explanation see also Section 3.7.2 (page 51),
Failure Recovery. Such a CONNECT may reach an agent downstream
of the failure before that agent has received a DISCONNECT from
the neighborhood of the failure. Until that agent receives the
DISCONNECT, it cannot distinguish between a failure recovery
and an erroneous routing loop. That agent must therefore
respond to the CONNECT with a REFUSE message with the affected
targets specified in the TargetList and an appropriate reason
code (StreamExists).
回復を必要とする残っているケース(部分的に失敗した流れと誤ったルーティング輪)は、容易に区別可能ではありません。 失敗した流れの回収を試みる際に、エージェントは新しいCONNECTメッセージを影響を受ける目標に発行するかもしれません。 Failure Recovery、また、詳報に関しては、セクション3.7.2(51ページ)を見てください。 そのエージェントが失敗の近所からDISCONNECTを受け取る前にそのようなCONNECTは失敗のエージェント川下に達するかもしれません。 そのエージェントがDISCONNECTを受け取るまで、それは失敗回復と誤ったルーティング輪を見分けることができません。 したがって、影響を受ける目標がTargetListと適切な理由コード(StreamExists)で指定されている状態で、そのエージェントはREFUSEメッセージでCONNECTに応じなければなりません。
The agent immediately preceding that point, i.e., the latest
agent to send the CONNECT message, will receive the REFUSE
message. It must release any resources reserved exclusively
for traffic to the listed targets. If this agent was not the
one attempting the stream recovery, then it cannot distinguish
between a failure recovery and an erroneous routing loop. It
should repeat the CONNECT after a ToConnect timeout. If after
NConnect retransmissions it continues to receive REFUSE
messages, it should propagate the REFUSE message toward the
origin, with the TargetList that specifies the affected
targets, but with a different error code (RouteLoop).
そのポイント、すなわち、最新のエージェントのすぐにCONNECTメッセージを送るために上位であるエージェントはREFUSEメッセージを受け取るでしょう。 それは排他的な記載された目標への交通に予約されたどんなリソースも発表しなければなりません。 このエージェントが流れの回復を試みるものでなかったなら、それは失敗回復と誤ったルーティング輪を見分けることができません。 それはToConnectタイムアウトの後にCONNECTを繰り返すべきです。 NConnect retransmissionsの後にREFUSEメッセージを受け取り続けているなら、それは影響を受ける目標を指定するTargetListにもかかわらず、異なったエラーコード(RouteLoop)で起源に向かったREFUSEメッセージを伝播するべきです。
The REFUSE message with this error code (RouteLoop) is
propagated by each ST agent without retransmitting any CONNECT
messages. At each agent, it causes any resources reserved
exclusively for the listed targets to be released. The REFUSE
will be propagated to the origin in the case of an erroneous
routing loop. In the case of stream recovery, it will be
propagated to the ST agent that is attempting the recovery,
which may be an intermediate agent or the origin itself. In
the case of a stream recovery, the agent attempting the
recovery may issue new CONNECT messages to the same or to
different next-hops.
どんなCONNECTメッセージも再送しないで、このエラーコード(RouteLoop)があるREFUSEメッセージはそれぞれのSTエージェントによって伝播されます。 各エージェントでは、それは記載された目標がリリースされるために排他的に予約されたどんなリソースも引き起こします。 REFUSEは誤ったルーティング輪の場合で起源に伝播されるでしょう。 流れの回復の場合では、それは仲介物質か起源自体であるかもしれない回復を試みているSTエージェントに伝播されるでしょう。 流れの回復の場合では、回復を試みるエージェントは同じくらい、または、異なった次のホップに新しいCONNECTメッセージを発行するかもしれません。
If an agent receives both a REFUSE message and a DISCONNECT
message with a target in common then it can release the
relevant resources and propagate neither the REFUSE nor the
DISCONNECT (however, we feel that it is unlikely that most
implementations will be able to detect this situation).
エージェントがREFUSEメッセージと中に目標があるDISCONNECTメッセージの次に、一般的な両方を受け取るなら、それは、関連リソースを発表して、REFUSEもDISCONNECTも伝播できません(しかしながら、私たちは、ほとんどの実現がこの状況を検出できるのが、ありそうもないと感じます)。
If the origin receives such a REFUSE message, it should attempt
to send a new CONNECT to all the affected targets. Since
routing errors in an internet are assumed to be temporary, the
new CONNECTs will eventually find acceptable routes to the
targets, if one exists. If no further routes exist after
NRetryRoute tries, the application should be
起源がそのようなREFUSEメッセージを受け取るなら、それは、すべての影響を受ける目標に新しいCONNECTを送るのを試みるべきです。 インターネットにおけるルーティング誤りが一時的であると思われて、新しいCONNECTsは結局許容できるルートを目標に見つけるでしょう、1つが存在しているなら。 NRetryRouteが試みた後にさらなるルートが全く存在していないなら、アプリケーションは存在するべきです。
CIP Working Group [Page 40] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[40ページ]RFC1190インターネット流れのプロトコル1990年10月
informed so that it may take whatever action it deems
necessary.
必要であると考えるどんな行動も取ることができるように、知らされます。
3.5.4. Problems in Reserving Resources
3.5.4. リソースを予約することにおける問題
If the network or ST agent resources are not available, an ST
agent may preempt one or more streams that have lower
precedence than the one being created. When it breaks a lower
precedence stream, it must issue REFUSE and DISCONNECT messages
as described in Sections 4.2.3.15 (page 122) and 4.2.3.6 (page
110). If there are no streams of lower precedence, or if
preempting them would not provide sufficient resources, then
the stream cannot be accepted by the ST agent.
ネットワークかSTエージェントリソースが利用可能でないなら、STエージェントは作成されるものより低い先行を持っている1つ以上の流れを先取りするかもしれません。 壊れると下側の先行が流れて、それは、セクション4.2.3で.15(122ページ)について説明するときREFUSEとDISCONNECTが通信させる必須問題と4.2です。.3 .6(110ページ)。 下側の先行の流れが全くないことができないか、それらを先取りするなら十分なリソースを提供しないで、次に、STエージェントが小川を受け入れることができないなら。
If an intermediate agent detects that it cannot allocate the
necessary resources, then it sends a REFUSE that contains an
appropriate reason code (CantGetResrc) and the pertinent
TargetList to the previous-hop ST agent. For further study are
issues of reporting what resources are available, whether the
resource shortage is permanent or transitory, and in the latter
case, an estimate of how long before the requested resources
might be available.
仲介物質がそれを検出するなら、それは必要なリソースを割り当てることができないで、次に、適切な理由コード(CantGetResrc)を含むREFUSEと適切なTargetListを前のホップSTエージェントに送ります。 さらなる研究には、リソース不足が永久的であるか、または一時的であることにかかわらずどんなリソースが利用可能であるか、そして、要求されたリソースが利用可能になるかもしれない前の後者の場合における、どれくらい長さの見積りを報告するか問題があります。
3.5.5. Setup Failure due to ACCEPT Timeout
3.5.5. ACCEPT TimeoutによるセットアップFailure
An ST agent that propagates an ACCEPT message backward toward
the origin expects an ACK from the previous-hop. If it does
not receive an ACK within a timeout, called ToAccept, it will
retransmit the ACCEPT. If it does not receive an ACK after
sending a number, called NAccept, of ACCEPT messages, then it
will replace the ACCEPT with a REFUSE, and will send a
DISCONNECT in the direction toward the target. Both the REFUSE
and DISCONNECT will identify the affected target(s) and specify
an appropriate reason code (AcceptTimeout). Both are also
retransmitted until ACKed with timeout ToRefuse/ ToDisconnect
and retransmit count NRefuse/NDisconnect. If they are not
ACKed, the agent simply gives up, letting the failure detection
mechanism described in Section 3.7.1 (page 48) take care of any
cleanup.
ACCEPTメッセージを後方に伝播するSTエージェントは前のホップから起源に向かってACKを予想します。 ToAcceptは、タイムアウトの中でACKを受けないとACCEPTを再送すると呼びました。 ACCEPTメッセージのNAcceptと呼ばれる数を送った後にACKを受けないと、それは、ACCEPTをREFUSEに取り替えて、目標に向かった方向にDISCONNECTを送るでしょう。 REFUSEとDISCONNECTの両方が、影響を受ける目標を特定して、適切な理由コード(AcceptTimeout)を指定するでしょう。 両方が、また、タイムアウトToRefuse/ ToDisconnectと共にACKedまで再送されて、カウントNRefuse/NDisconnectを再送します。 それらがACKedでないなら、エージェントは単にあきらめます、(48ページ)がどんなクリーンアップにも注意するセクション3.7.1で説明された失敗検出メカニズムをさせて。
CIP Working Group [Page 41] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[41ページ]RFC1190インターネット流れのプロトコル1990年10月
3.5.6. Problems Caused by CHANGE Messages
3.5.6. 変化メッセージによって引き起こされた問題
An application must exercise care when changing a FlowSpec to
prevent a failure. A CHANGE might fail for two reasons. The
request may be for a larger amount of network resources when
those resources are not available; this failure may be
prevented by requiring that the current level of service be
contained within the ranges of the FlowSpec in the CHANGE.
失敗を防ぐためにFlowSpecを変えるとき、アプリケーションは注意しなければなりません。 CHANGEは2つの理由で失敗するかもしれません。 それらのリソースが利用可能でないときに、要求は多く以上の量のネットワーク資源のためのものであるかもしれません。 現在のレベルのサービスがFlowSpecの範囲の中に保管されているのを必要とすることによって、この失敗はCHANGEで防がれるかもしれません。
Alternatively, the local network might require all the former
resources to be released before the new ones are requested and,
due to unlucky timing, an unrelated request for network
resources might be processed between the time the resources are
released and the time the new resources are requested, so that
the former resources are no longer available. There is not
much that an application or ST can do to prevent such failures.
あるいはまた、新しい方が要求されていて、ネットワーク資源を求める関係ない要求が不運のタイミングのためリソースが発表される時、新しいリソースが要求される時の間で処理されるかもしれない前に企業内情報通信網は、すべての前のリソースが発表されるのを必要とするかもしれません、前のリソースがもう利用可能でないように。 アプリケーションかSTがそのような失敗を防ぐためにできる多くのことがありません。
If the attempt to change the FlowSpec fails then the ST agent
where the failure occurs must intentionally break the stream
and invoke the stream recovery mechanism using REFUSE and
DISCONNECT messages; see Section 3.7.2 (page 51). Note that
the reserved resources after the failure of a CHANGE may not be
the same as before, i.e., the CHANGE may have been partially
completed. The application is responsible for any cleanup
(another CHANGE).
FlowSpecを変える試みが失敗するなら、失敗が起こるところに、STエージェントは、REFUSEとDISCONNECTメッセージを使用することで故意に流れを壊して、流れの回収機構を呼び出さなければなりません。 セクション3.7.2(51ページ)を見てください。 すなわち、CHANGEが以前部分的に完成したことがあるとき、CHANGEの失敗の後の予約されたリソースが同じでないかもしれないことに注意してください。 アプリケーションはどんなクリーンアップ(別のCHANGE)にも原因となります。
3.5.7. Notification of Changes Forced by Failures
3.5.7. 失敗で無理矢理の変化の通知
NOTIFY is issued by a an ST Agent to inform upsteam agents and
the origin that resource allocation changes have occurred after
a stream was established. These changes occur when network
components fail and when competing streams preempt resources
previously reserved by a lower precedence stream. We also
anticipate that NOTIFY can be used in the future when
additional resources become available, as is the case when
network components recover or when higher precedence streams
are deleted.
NOTIFYが発行される、STエージェント、流れが確立された後に資源配分変化が持っているupsteamエージェントと起源を知らせるのは起こりました。 ネットワーク要素が失敗して、競争している流れが以前に下側の先行の流れで予約されたリソースを先取りするとき、これらの変化は起こります。 また、私たちは、ネットワーク要素が回収されるとき、そうであるように追加リソースが利用可能になるか、または、より高い先行の流れが削除される未来にNOTIFYを使用できると予期します。
NOTIFY is also used to inform upstream agents that a routing
anomaly has occurred. Such an example was cited in Section
3.5.2 (page 38), where an agent notices that the next-hop agent
is on the same network as the previous-hop agent; the anomaly
is that the previous-hop should have connected directly to the
next-hop without using an intermediate agent. Delays in
propagating host status and routing information can cause such
anomalies to occur. NOTIFY allows ST to correct automatically
such mistakes.
また、NOTIFYは、ルーティング異常が起こったことを上流のエージェントに知らせるのに使用されます。 そのような例はセクション3.5.2(38ページ)で引用されました。(そこではエージェントが次のホップエージェントが前のホップエージェントと同じネットワークの一員であるのに気付きます)。 異常は前のホップが仲介物質を使用しないで直接次のホップに接続するはずであったということです。 ホスト状態とルーティング情報を伝播する遅れで、そのような例外は起こることができます。 NOTIFYはSTにそのような誤りを自動的に修正させます。
NOTIFY reports a FlowSpec that reflects that revised guarantee
that can be promised to the stream. NOTIFY also
NOTIFYは流れに約束できるその改訂された保証を反映するFlowSpecを報告します。 NOTIFYも
CIP Working Group [Page 42] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[42ページ]RFC1190インターネット流れのプロトコル1990年10月
identifies those targets affected by the change. In this way,
NOTIFY is similar to ACCEPT. NOTIFY includes a ReasonCode to
identify the event that triggered the notification. It also
includes a TargetList, rather than a single Target, since a
single event can affect a branch leading to several targets.
変化で影響を受けるそれらの目標を特定します。 このように、NOTIFYはACCEPTと同様です。 NOTIFYは、通知の引き金となった出来事を特定するためにReasonCodeを含んでいます。 また、それは独身のTargetよりむしろTargetListを含んでいます、単一の出来事が数個の目標に通じるブランチに影響できるので。
NOTIFY is relayed by the ST agents back toward the origin,
along the path established by the CONNECT but in the reverse
direction. NOTIFY must be acknowledged with an ACK at each
hop. If intermediate agent corrects the situation without
causing any disruption to the data flow or guarantees, it can
choose to drop the notification message before it reaches the
origin. If the originating agent receives a NOTIFY, it is then
expected to adjust its own processing and data rates, and to
submit any required CHANGE requests. As with ACCEPT, the
FlowSpec is not modified on this trip from the target back to
the origin. It is up to the origin to decide whether a CHANGE
should be submitted. (However, even though the FlowSpec has
not been modified, the situation reported in the
NOTIFYはしかしエージェントが反対の方向でCONNECTによって確立された経路に沿った起源に向かって支持するSTによってリレーされます。 各ホップのACKと共にNOTIFYを承認しなければなりません。 仲介物質がデータフローか保証のどんな分裂も引き起こさないで状況を正すなら、それは、起源に達する前に通知メッセージを落とすのを選ぶことができます。 由来しているエージェントがNOTIFYを受け取るなら、それは、それ自身の処理とデータ信号速度を調整して、どんな必要なCHANGE要求も提出すると予想されます。 ACCEPTのように、FlowSpecはこの目標から起源までの旅行で変更されません。 CHANGEを提出するべきであるかどうか決めるのが起源まで達しています。 (しかしながら、FlowSpecは変更されていませんでしたが、状況は詳細に報告しました。
Application Agent A Agent 1 Agent B
アプリケーションエージェントはエージェントの1人のエージェントBです。
1. (high precedence request preempts 10K of
the stream's original 30Kb bandwidth
allocated to the hop from 1 to B)
|
V
2. +<------+-- NOTIFY -------------+
| | <RVLId=4><SVLId=14>
| | <Ref=150>
| V <FlowSpec=20Kb,...><TargList=B>
3. | +-> ACK --------------->+
| <RVLId=14><SVLId=4>
V <Ref=150>
4. (inform application)
....
5. change(FlowSpec=20Kb,...)
V
6. +---------> CHANGE B ---------->+
7. <RVLId=14><SVLId=4> +--> CHANGE B ------------>+->+
<Ref=60> | <RVLId=44><SVLId=15> | |
<FlowSpec=20Kb,...> V <Ref=160> | |
8. +<- ACK ----------------+ <FlowSpec=20Kb,...> | |
<RVLId=4><SVLId=14> V |
9. <Ref=60> +--- ACK ------------------+ |
<RVLId=15><SVLId=44> |
<Ref=160> V
... perform normal ACCEPT processing ... <-----+
1. (高い先行要求は1〜Bまでホップに割り当てられた流れの30KBの元の10Kの帯域幅を先取りします) | V2。 + <。------+--通知してください。-------------+ | | <RVLId=4><SVLId=14>。| | <審判=150>。| V<FlowSpecは20KBと等しいです…><TargList=B>3。 | +->ACK--------------->+| <RVLId=14><SVLId=4>V<審判は150>4と等しいです。 (アプリケーションを知らせます) .... 5. 変化してください(FlowSpecは20KBと等しいです…)。 V6。 +--------->変化B---------->+7。 <RVLId=14><SVLId=4>+-->変化B------------>+->+<審判=60>。| <RVLId=44><SVLId=15>。| | <FlowSpecは20KBと等しいです…>V<審判=160>。| | 8. + <-ACK----------------+ <FlowSpecは20KBと等しいです…>|| <RVLId=4><SVLId=14>V| 9. <審判=60>+--- ACK------------------+ | <RVLId=15><SVLId=44>。| <審判=160>Vは通常のACCEPT処理を実行します…… <、-、-、-、--+
Figure 16. Processing NOTIFY Messages
図16。 処理して、メッセージに通知してください。
CIP Working Group [Page 43] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[43ページ]RFC1190インターネット流れのプロトコル1990年10月
notify may have prevented the ST agents from meeting the
original guarantees.)
通知してください。STエージェントがオリジナルの保証を満たすのを防いでもよかった、)
3.6. Options
3.6. オプション
Several options are defined in the CONNECT message. The special
processing required to support each will be described in the
following sections. The options are independent, i.e., can be set
to one (1, TRUE) or zero (0, FALSE) in any combination. However,
the effect and implementation of the options is NOT necessarily
independent, and not all combinations are supported.
いくつかのオプションがCONNECTメッセージで定義されます。 それぞれを支持するのに必要である特別な処理は以下のセクションで説明されるでしょう。 オプションは独立しています、すなわち、どんな組み合わせでも1(1、TRUE)かゼロ(0、FALSE)に設定できます。 しかしながら、オプションの効果と実現は必ず独立しているというわけではありません、そして、すべての組み合わせがサポートされるというわけではありません。
3.6.1. HID Field Option
3.6.1. 分野オプションを隠しました。
The sender of a CONNECT message may or not specify an HID in
the HID field. If the HID Field option of the CONNECT message
is not set (the H bit is 0), then the HID field does not
contain relevant information and should be ignored.
CONNECTメッセージの送付者が指定するかもしれない、HID分野でHIDを指定しません。 CONNECTメッセージのHID Fieldオプションが設定されないなら(Hビットは0です)、HID分野は、関連情報を含んでいなくて、無視されるべきです。
If this option is set (the H bit is 1), then the HID field
contains a relevant value. If this option is set and the HID
field of the CONNECT contains a non-zero value, that value
represents a proposed HID that initiates the HID negotiation.
このオプションが設定されるなら(Hビットは1です)、HID分野は関連値を含んでいます。 このオプションが設定されて、CONNECTのHID分野が非ゼロ値を含んでいるなら、その値はHID交渉を開始する提案されたHIDを表します。
If the HID Field option is set but the HID field of the CONNECT
message contains a zero, this means that the sender of that
CONNECT message has chosen to defer selection of the HID to the
next-hop agent (the receiver of a CONNECT message). This
choice can allow a more efficient mechanism for selecting HIDs
and possibly a more efficient mechanism for forwarding data
packets in the case when the previous-hop does not need to
select the HID; see also Section 4.2.3.5 (page 105).
HID Fieldオプションが設定されますが、CONNECTメッセージのHID分野がゼロを含んでいるなら、これは、そのCONNECTメッセージの送付者が、次のホップエージェント(CONNECTメッセージの受信機)にHIDの選択を延期するのを選んだことを意味します。 前のホップがHIDを選択する必要はないとき、この選択はHIDsを選択するための、より効率的なメカニズムと場合でデータ・パケットを進めるためのことによるとより効率的なメカニズムを許容できます。 また、セクション4.2を見てください。.3 .5(105ページ)。
Upon receipt of a CONNECT message with the HID Field option set
and the HID field set to zero, a next-hop agent selects the HID
for the hop, enters it into its appropriate data structure, and
returns it in the HID field of the HID-APPROVE message. The
previous-hop takes the HID from the HID-APPROVE message and
enters it into its appropriate data structure.
HID Fieldオプションセットとゼロに設定されたHID分野があるCONNECTメッセージを受け取り次第、次のホップエージェントは、ホップのためにHIDを選択して、適切なデータ構造にそれに入って、HID-APPROVEメッセージのHID分野でそれを返します。 前のホップは、HID-APPROVEメッセージからHIDを連れて行って、適切なデータ構造にそれを入れます。
3.6.2. PTP Option
3.6.2. PTPオプション
The PTP option (Point-to-Point) is used to indicate that the
stream will never have more than a single target. It
consequently implies that the stream will never need to support
any form of multicasting. Use of the PTP option may thus allow
efficiencies in the way the stream is built or is
PTPオプション(ポイントを示す)は、流れにはただ一つの目標以上が決してないのを示すのに使用されます。 その結果、それは、流れが、決してどんなフォームのマルチキャスティングも支持する必要でないのを含意します。 その結果、PTPオプションの使用は流れが組立しているか、またはある方法で効率を許容するかもしれません。
CIP Working Group [Page 44] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[44ページ]RFC1190インターネット流れのプロトコル1990年10月
managed. Specifically, the ST agents do not need to request
that the intervening networks allocate multicast groups to
support this stream.
管理にされる。 明確に、STエージェントは、介入しているネットワークがこの流れを支持するためにマルチキャストグループを割り当てるよう要求する必要はありません。
The PTP option can only be set to one (1) by the origin, and
must be the same for the entire stream (i.e., propagated by ST
agents). The details of what this option does are
implementation specific, and do not affect the protocol very
much.
PTPオプションは、起源で1つ(1)に設定できるだけであって、全体の流れ(すなわち、STエージェントが伝播される)に、同じであるに違いありません。 このオプションがすることに関する詳細は、実現特有であり、プロトコルにあまり影響しません。
If the application attempts to add a new target to an existing
stream that was created with the PTP option set to one (1), the
application should be informed of the error with an ERROR-IN-
REQUEST message with the appropriate reason code. If a CONNECT
is received whose TargetList contains more than a single entry,
an ERROR-IN-REQUEST message with the appropriate reason code
(PTPError) should be returned to the previous-hop agent (note
that such a CONNECT should never be received if the origin both
implements the PTP option and is functioning properly).
アプリケーションが、REQUESTメッセージが適切な理由コードでERROR-INとの誤りについて知らされる状態で既存の流れへのPTPオプションセットで1つ(1)に作成されています、利用がそうあるべきであるということであった新しい目標を加えるのを試みるなら。 CONNECTが受け取られているなら、だれのTargetListはコード(PTPError)が前のホップエージェントに返されるべきであるという(起源の両方がPTPオプションを実行して、適切に機能しているならそのようなCONNECTが決して受け取られるべきでないことに注意してください)適切な理由で単一のエントリー以上、ERROR IN REQUESTメッセージを含んでいますか?
As implied in the last paragraph, a subsetted implementation
might choose not to implement the PTP option.
最後のパラグラフで含意されるように、subsetted実現は、PTPオプションを実行しないのを選ぶかもしれません。
3.6.3. FDx Option
3.6.3. FDxオプション
The FDx option is used to indicate that a second stream in the
reverse direction, from the target to the origin, should
automatically be created. This option is most likely to be
used when the TargetList has only a single entry. If used when
the TargetList has multiple entries, the resulting streams
would allow bi-directional communication between the origin and
the various targets, but not among the targets. The FDx option
can only be invoked by the origin, and must be propagated by
intermediate agents.
FDxオプションは、反対の方向への2番目の流れが目標から起源まで自動的に作成されるべきであるのを示すのに使用されます。 TargetListに単一のエントリーしかないとき、このオプションは最も使用されそうです。 TargetListに多回入国があると使用されるなら、結果として起こる流れは、起源と様々な目標との双方向のコミュニケーションを許容しますが、目標の中に許容しないでしょう。 FDxオプションを起源で呼び出すことができるだけであって、仲介物質は伝播しなければなりません。
This option is specified by inclusion of both an RFlowSpec and
an RHID parameter in the CONNECT message (possibly with an
optional RGroup parameter).
このオプションはCONNECTメッセージ(ことによると任意のRGroupパラメタがある)でのRFlowSpecとRHIDパラメタの両方の包含で指定されます。
Any ST agent that receives a CONNECT message with both an
RFlowSpec and an RHID parameter will create database entries
for streams in both directions and will allocate resources in
both directions for them. By this we mean that an ST agent
will reserve resources to the next-hop agent for the normal
stream and resources back to the previous-hop agent for the
reverse stream. This is necessary since it is expected that
network reservation interfaces will require the destination
address(es) in order to make reservations, and because all ST
agents must use the same reservation model.
RFlowSpecとRHIDパラメタの両方でCONNECTメッセージを受け取るどんなSTエージェントも、流れのためのデータベースエントリーを両方の方向に作成して、それらのための両方の方向にリソースを割り当てるでしょう。 これで、私たちは、STエージェントが通常の流れのための次のホップエージェントへのリソースと逆の流れのための前のホップエージェントへのリソースを予約すると言っています。 ネットワーク予約インタフェースが予約をするように、送付先アドレス(es)を必要とすると予想されて、すべてのSTエージェントが同じ予約モデルを使用しなければならないのでこれが必要です。
CIP Working Group [Page 45] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[45ページ]RFC1190インターネット流れのプロトコル1990年10月
The target agent will select a Name for the reverse stream and
return it (in the RName parameter) and the resulting FlowSpec
(in the RFlowSpec parameter) of the ACCEPT message. Each agent
that processes the ACCEPT will update its partial stream
database entry for the reverse stream with the Name contained
in the RName parameter. We assume that the next higher
protocol layer will use the same SAP for both streams.
目標エージェントは、逆の流れのためにNameを選択して、それ(RNameパラメタの)とACCEPTメッセージの結果として起こるFlowSpec(RFlowSpecパラメタの)を返すでしょう。 NameがRNameパラメタに含まれている状態で、ACCEPTを処理する各エージェントが逆の流れのための部分的な流れのデータベースエントリーをアップデートするでしょう。 私たちは、次の、より高いプロトコル層が両方の流れに同じSAPを使用すると思います。
3.6.4. NoRecovery Option
3.6.4. NoRecoveryオプション
The NoRecovery option is used to indicate that ST agents should
not attempt recovery in case of network or component failure.
If a failure occurs, the origin will be notified via a REFUSE
message and the target(s) via a DISCONNECT, with an appropriate
reason code of "failure" (i.e., one of DropFailAgt,
DropFailHst, DropFailIfc, DropFailNet, IntfcFailure,
NetworkFailure, STAgentFailure, FailureRecovery). They can
then decide whether to wait for the failed component to be
fixed, or drop the target via DISCONNECT/REFUSE messages. The
NoRecovery option can only be set to one (1) by the origin, and
must be the same for the entire stream.
NoRecoveryオプションは、STエージェントがネットワークかコンポーネント故障の場合に回復を試みるべきでないのを示すのに使用されます。 失敗が起こると、REFUSEメッセージと目標で起源はDISCONNECTを通して通知されるでしょう、「失敗」(すなわち、DropFailAgtの1つ、DropFailHst、DropFailIfc、DropFailNet、IntfcFailure、NetworkFailure、STAgentFailure、FailureRecovery)の適切な理由コードで。 そして、彼らは、失敗したコンポーネントが修理されるのを待っているか、またはDISCONNECT/REFUSEメッセージで目標を落とすかを決めることができます。 NoRecoveryオプションは、起源で1つ(1)に設定できるだけであって、全体の流れに、同じであるに違いありません。
3.6.5. RevChrg Option
3.6.5. RevChrgオプション
The RevChrg option bit in the FlowSpec is set to one (1) by the
origin to request that the target(s) pay any charges associated
with the stream (to the target(s)); see Section 4.2.2.3 (page
83). If the target is not willing to accept charges, the bit
should be set to zero (0) by the target before returning the
FlowSpec to the origin in an ACCEPT message.
起源によって1つ(1)にFlowSpecのRevChrgオプションビットが、目標が流れに関連しているどんな料金も支払うよう要求するように設定される、(目標(s))に。 セクション4.2を見てください。.2 .3(83ページ)。 目標が料金を受け入れることを望んでいないなら、ACCEPTメッセージの起源にFlowSpecを返す前にビットが目標で(0)のゼロに合うように設定されるべきです。
If the FDx option is also specified, the target pays charges
for both streams.
また、FDxオプションが指定されるなら、目標は両方の流れの料金を支払います。
3.6.6. Source Route Option
3.6.6. 送信元経路オプション
The Source Route Option may be used both for diagnostic
purposes, and, in those hopefully infrequent cases where the
standard routing mechanisms do not produce paths that satisfy
some policy constraint, to allow the origin to prespecify the
ST agents along the path to the target(s). The idea is that
the origin can explicitly specify the path to a target, either
strictly hop-by-hop or more loosely by specification of one or
more agents through which the path must pass.
そして、Source Route Optionは標準のルーティングメカニズムが起源が経路に沿ってSTエージェントを目標に前指定するのを許容するために何らかの方針規制を満たす経路を生産しないそれらの願わくは珍しい場合にともに診断目的で使用されるかもしれません。 考えは起源が経路が通り過ぎなければならない1人以上のエージェントの仕様で明らかに厳密にホップごとにより緩く目標に経路を指定できるということです。
CIP Working Group [Page 46] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[46ページ]RFC1190インターネット流れのプロトコル1990年10月
The option is specified by including source routing information
in the Target structure. A target may contain zero or more
SrcRoute options; when multiple options are present, they are
processed in the order in which they occur. The parameter code
indicates whether the portion of the path contained in the
parameter is of the strict or loose variety.
オプションは、Target構造にソースルーティング情報を含んでいることによって、指定されます。 目標はゼロか、より多くのSrcRouteオプションを含むかもしれません。 複数のオプションが存在しているとき、それらは起こるオーダーで処理されます。 パラメタコードは、パラメタに含まれた経路の部分が厳しいかゆるいバラエティーのものであるかを示します。
Since portions of a path may pass through portions of an
internet that does not support ST agents, there are also forms
of the SrcRoute option that are converted into the
経路の部分がSTエージェントを支持しないインターネットの部分を通り抜けるかもしれないので、変換されるSrcRouteオプションのフォームもあります。
Application Agent A Agent 2 Agent 3 Agent B
アプリケーションエージェントはエージェントの2エージェントの3エージェントBです。
1. (open B<SR=2,3>)
2. V (proc B listening)
3. (source routed to 2)
V
4. (check resources from A to Agent 2: already allocated,
V reuse control link & HID, no additional resources needed)
5. +-> CONNECT B<SR=2,3>->-+-+
<RVLId=23><SVLId=5> | |
6. <Ref=50> V |
7. +<- ACK ----------------+ |
<RVLId=5><SVLId=23> |
<Ref=50> V
8. (source routed to 3)
V
9. (reserve resources 2 to 3)
V
10. +-> CONNECT B<SR=3> ---->+
<RVLId=0><SVLId=24> |
<Ref=280><HID=4801> V
11. +<- HID-APPROVE <--------+
<RVLId=24><SVLId=33> |
<Ref=280><HID=4801> |
V
(routing to B)
V
(reserve resources from 3 to B)
V
12. +-> CONNECT B ---------->+
<RVLId=0><SVLId=32> |
<Ref=330><HID=6000> V
13. +<- HID-APPROVE <--------+
<RVLId=32><SVLId=45> |
<Ref=330><HID=6000> V
14. (proc B accepts)
V
... perform normal ACCEPT processing ... <-----+
1. (開いているB<SR=2、3>) 2. V(proc B聴取)3。 (2に発送されたソース) V4。 (Aからエージェント2までのチェックリソース: コントロールリンクとHID、どんな追加リソースも必要としなかった既に割り当てられたV再利用) 5. +->はB<SR=2、3>>-++<RVLId=23><SVLId=5>を接続します。| | 6. <審判=50>V| 7. + <-ACK----------------+ | <RVLId=5><SVLId=23>。| <審判は50>V8と等しいです。 (3に発送されたソース) V9。 (蓄えのリソース2〜3) V10。 +->はB<SR=3>を接続します。---->+<RVLId=0><SVLId=24>。| <審判=280><は= 4801>V11隠れました。 + <、-、隠す、-承認してください、<。--------+ <RVLId=24><SVLId=33>。| 280><が隠した<審判=は4801>と等しいです。| V(Bへのルーティング)V(3〜Bまでの蓄えのリソース)V12。 +->はBを接続します。---------->+<RVLId=0><SVLId=32>。| <審判=330><は= 6000>V13隠れました。 + <、-、隠す、-承認してください、<。--------+ <RVLId=32><SVLId=45>。| <審判=330><は= 6000>V14隠れました。 (Bが受け入れるproc) V… 通常のACCEPT処理を実行してください… <、-、-、-、--+
Figure 17. Source Routing Option
図17。 ソースルート設定オプション
CIP Working Group [Page 47] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[47ページ]RFC1190インターネット流れのプロトコル1990年10月
corresponding IP Source Routing options by the ST agent that
performs the encapsulation.
カプセル化を実行するSTエージェントによる対応するIP Sourceルート設定オプション。
The SrcRoute option is usually selected by the origin, but may
be used by intermediate agents if specified as a result of the
routing function.
SrcRouteオプションは、起源によって通常選択されますが、経路選択機能の結果、指定されるなら、仲介物質によって使用されるかもしれません。
For example, in the topology of Figure 2, if A wants to add B
back into the stream, its routing function might decide that
the best path is via Agent 3. Since the data is already being
multicast across the network connected to C, D, and E, the
route via Agent 3 might cost less than having A replicate the
data packets and send them across A's network a second time.
例えば、図2のトポロジーでは、Aが流れの中にBを加えて戻したいなら、経路選択機能が、エージェント3を通して最も良い経路があると決めるかもしれません。 データが既にC、D、およびEに接続されたネットワークの向こう側のマルチキャストであるので、エージェント3を通したルートはAがデータ・パケットを模写して、もう一度Aのネットワークの向こう側にそれらを送るのを持っている以下かかるかもしれません。
3.7. Ancillary Functions
3.7. 補助的機能
There are several functions and procedures that are required by
the ST Protocol. They are described in subsequent sections.
STプロトコルによって必要とされるいくつかの機能と手順があります。 それらはその後のセクションで説明されます。
3.7.1. Failure Detection
3.7.1. 失敗検出
The ST failure detection mechanism is based on two assumptions:
ST失敗検出メカニズムは2つの仮定に基づいています:
1 If a neighbor of an ST agent is up, and has been up
without a disruption, and has not notified the ST agent
of a problem with streams that pass through both, then
the ST agent can assume that there has not been any
problem with those streams.
1 STエージェントの隣人が上がって、分裂なしで上がって、両方を通り抜ける流れに関する問題についてSTエージェントに通知していないなら、STエージェントは、それらの流れに関するどんな問題もなかったと仮定できます。
2 A network through which an ST agent has routed a stream
will notify the ST agent if there is a problem that
affects the stream data packets but does not affect the
control packets.
2 流れのデータ・パケットに影響しますが、コントロールパケットは影響しない問題があると、STエージェントが流れを発送したネットワークがSTエージェントに通知するでしょう。
The purpose of the robustness protocol defined here is for ST
agents to determine that the streams through a neighbor have
been broken by the failure of the neighbor or the intervening
network. This protocol should detect the overwhelming majority
of failures that can occur. Once a failure is detected,
recovery procedures are initiated.
ここで定義された丈夫さプロトコルの目的はSTエージェントが、隣人を通した流れが隣人か介入しているネットワークの失敗によって壊されたと決心することです。 このプロトコルは起こることができる失敗の圧倒的多数を検出するべきです。 失敗がいったん検出されると、リカバリ手順は着手されます。
3.7.1.1. Network Failures
3.7.1.1. ネットワーク失敗
In this memo, a network is defined to be the protocol
layer(s) below ST. This function can be implemented in a
hardware module separate from the ST agent, or as software
modules within the ST agent itself, or as a combination of
このメモでは、STの下のプロトコル層になるようにネットワークを定義します。STエージェント自身の中のソフトウェア・モジュールとして、または、STエージェントか、組み合わせとしてモジュールが分離するハードウェアでこの機能を実行できます。
CIP Working Group [Page 48] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[48ページ]RFC1190インターネット流れのプロトコル1990年10月
both. This specification and the robustness protocol do not
differentiate between these alternatives.
ともに。 この仕様と丈夫さプロトコルはこれらの代替手段を区別しません。
An ST agent can detect network failures by two mechanisms;
the network can report a failure, or the ST agent can
discover a failure by itself. They differ in the amount of
information that ST agent has available to it in order to
make a recovery decision. For example, a network may be
able to report that reserved bandwidth has been lost and the
reason for the loss and may also report that connectivity to
the neighboring ST agent remains intact. In this case, the
ST agent may request the network to allocate bandwidth anew.
On the other hand, an ST agent may discover that
communication with a neighboring ST agent has ceased because
it has not received any traffic from that neighbor in some
time period. If an ST agent detects a failure, it may not
be able to determine if the failure was in the network while
the neighbor remains available, or the neighbor has failed
while the network remains intact.
STエージェントは2つのメカニズムでネットワーク失敗を検出できます。 ネットワークが失敗を報告できますか、またはSTエージェント自身は失敗を発見できます。 彼らはSTエージェントが回復決定をするようにそれに利用可能にする情報量において異なります。 例えば、ネットワークは、予約された帯域幅が失われたと報告できて損失の理由であるかもしれなく、また、隣接しているSTエージェントの残りへのその接続性が完全であると報告するかもしれません。 この場合、STエージェントは、新たに帯域幅を割り当てるようネットワークに要求するかもしれません。 他方では、STエージェントは、いつかの期間にまだその隣人からの交通を受けていないので隣接しているSTエージェントとのコミュニケーションがやんだと発見するかもしれません。 STエージェントが失敗を検出するなら、隣人が利用可能なままで残っているか、ネットワークが元の状態のままになりますが、または隣人が失敗している間、ネットワークで失敗があったかを決定できないかもしれません。
3.7.1.2. Detecting ST Stream Failures
3.7.1.2. 流れの第失敗を検出します。
Each ST agent periodically sends each neighbor with which it
shares a stream a HELLO message. A HELLO message is ACKed
if the Reference field is non-zero. This message exchange
is between ST agents, not entities representing streams or
applications (there is no Name field in a HELLO message).
That is, an ST agent need only send a single HELLO message
to a neighbor regardless of the number of streams that flow
between them. All ST agents (host as well as intermediate)
must participate in this exchange. However, only agents
that share active streams need to participate in this
exchange.
それぞれのSTエージェントは定期的にそれが流れを共有する各隣人にHELLOメッセージを送ります。 HELLOメッセージはReference分野が非ゼロであるならACKedです。 流れかアプリケーションを表す実体ではなく、STエージェントの間には、この交換処理はあります(HELLOメッセージにName分野が全くありません)。 すなわち、STエージェントはそれらの間を流れる流れの数にかかわらずただ一つのHELLOメッセージを隣人に送るだけでよいです。 すべてのSTエージェント(中間的と同様に、接待します)がこの交換に参加しなければなりません。 しかしながら、活発な流れを共有するエージェントだけが、この交換に参加する必要があります。
To facilitate processing of HELLO messages, an
implementation may either create a separate Virtual Link
Identifier for each neighbor having an active stream, or may
use the reserved identifier of one (1) for the SVLId field
in all its HELLO messages.
HELLOメッセージの処理、実現を容易にするために、活発な流れを持っている各隣人のために別々のVirtual Link Identifierを作成するか、またはSVLId分野にすべてのHELLOメッセージで1つ(1)に関する予約済み識別子を使用するかもしれません。
An implementation that wishes to send its HELLO messages via
a data path instead of the control path may setup a separate
stream to its neighbor agent for that purpose. The HELLO
message would contain a HID of zero, indicating a control
message, but would be identified to the next lower protocol
layer as being part of the separate stream.
コントロール経路の代わりにデータ経路を通してHELLOメッセージを送りたがっている実現はそのために隣人エージェントに別々の流れをセットアップするかもしれません。 HELLOメッセージはゼロのHIDを含んでいるでしょう、コントロールメッセージを示して別々の流れの一部であるとして次の低級プロトコル層に特定されて。
As well as identifying the sender, the HELLO message has two
fields; a HelloTimer field that is in units of milliseconds
modulo the maximum for the field size, and a
送付者を特定することと同様に、HELLOメッセージには、2つの分野があります。 a HelloTimerがそれをさばく、ユニットのミリセカンド法には、最大が分野サイズ、およびaのためにあります。
CIP Working Group [Page 49] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[49ページ]RFC1190インターネット流れのプロトコル1990年10月
Restarted bit specifying that the ST agent has been
restarted recently. The HelloTimer must appear to be
incremented every millisecond whether a HELLO message is
sent or not, but it is allowable for an ST agent to create a
new HelloTimer only when it sends a HELLO message. The
HelloTimer wraps around to zero after reaching the maximum
value. Whenever an ST agent suffers a catastrophic event
that may result in it losing ST state information, it must
reset its HelloTimer to zero and must set the Restarted bit
for the following HelloTimerHoldDown seconds.
STエージェントが最近再出発されたと指定するビットを再開しました。 HELLOメッセージを送るか否かに関係なく、HelloTimerは、ミリセカンド毎に増加されるように見えなければなりませんが、HELLOメッセージを送るときだけ、STエージェントが新しいHelloTimerを作成するのは、許容できます。 最大値に達した後に、HelloTimerはゼロに巻きつけます。 STエージェントがST州の情報を失いながらそれをもたらすかもしれない大惨事を受けるときはいつも、ゼロにHelloTimerをリセットしなければならなくて、以下のHelloTimerHoldDown秒にRestartedビットを設定しなければなりません。
An ST agent must send HELLO messages to its neighbor with a
period shorter than the smallest RecoveryTimeout parameter
of the FlowSpecs of all the active streams that pass between
the two agents, regardless of direction. This period must
be smaller by a factor, called HelloLossFactor, which is at
least as large as the greatest number of consecutive HELLO
messages that could credibly be lost while the communication
between the two ST agents is still viable.
期間が2人のエージェントの間を通るすべての活発な流れのFlowSpecsの最も小さいRecoveryTimeoutパラメタより短い状態でSTエージェントは隣人へのメッセージをHELLOに送らなければなりません、指示にかかわらず。 この期間は2人のSTエージェントのコミュニケーションがまだ実行可能である間に確かに失うことができた連続したHELLOメッセージの最大数よりHelloLossFactorと呼ばれる少なくとも同じくらい大きい要素で小さいに違いありません。
An ST agent may send simultaneous HELLO messages to all its
neighbors at the rate necessary to support the smallest
RecoveryTimeout of any active stream. Alternately, it may
send HELLO messages to different neighbors independently at
different rates corresponding to RecoveryTimeouts of
individual streams.
STエージェントはどんな活発な流れの最も小さいRecoveryTimeoutも支持するのに必要なレートで同時のHELLOメッセージをすべての隣人に送るかもしれません。 交互に、それは個々の流れのRecoveryTimeoutsに対応する異なったレートで独自に異なった隣人へのメッセージをHELLOに送るかもしれません。
The agent that receives a HELLO message expects to receive
at least one new HELLO message from a neighbor during the
RecoveryTimeout of every active stream through that
neighbor. It can detect duplicate or delayed HELLO messages
by saving the HelloTimer field of the most recent valid
HELLO message from that neighbor and comparing it with the
HelloTimer field of incoming HELLO messages. It will only
accept an incoming HELLO message from that neighbor if it
has a HelloTimer field that is greater than the most recent
valid HELLO message by the time elapsed since that message
was received plus twice the maximum likely delay variance
from that neighbor. If the ST agent does not receive a
valid HELLO message within the RecoveryTimeout of a stream,
it must assume that the neighboring ST agent or the
communication link between the two has failed and it must
initiate stream recovery activity.
HELLOメッセージを受け取るエージェントは、あらゆる活発な流れのRecoveryTimeoutの間の隣人からその隣人まで少なくとも1つの新しいHELLOメッセージを受け取ると予想します。 それは、その隣人からの最新の有効なHELLOメッセージのHelloTimer分野を節約して、入って来るHELLOメッセージのHelloTimer分野とそれを比べることによって、写しか遅れたHELLOメッセージを検出できます。 そのメッセージ以来経過している時までに最新の有効なHELLOメッセージを受け取ったより大きいHelloTimer分野とその隣人からの最大のありそうな遅れ変化の2倍がある場合にだけ、それはその隣人から入って来るHELLOメッセージを受け入れるでしょう。 STエージェントが流れのRecoveryTimeoutの中に有効なHELLOメッセージを受け取らないなら、それは隣接しているSTエージェントか2つの間の通信リンクが失敗して、流れの回復活動を開始しなければならないと仮定しなければなりません。
Furthermore, if an ST agent receives a HELLO message that
contains the Restarted bit set, it must assume that the
sending ST agent has lost its ST state. If it shares
streams with that neighbor, it must initiate stream recovery
activity. If it does not share streams with that neighbor,
it should not attempt to create one until that
その上、STエージェントがRestartedビットセットを含むHELLOメッセージを受け取るなら、それは、送付STエージェントがST状態を失ったと仮定しなければなりません。 その隣人と流れを共有するなら、それは流れの回復活動を開始しなければなりません。 その隣人と流れを共有しないなら、それは、それまで1つを作成するのを試みるべきではありません。
CIP Working Group [Page 50] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[50ページ]RFC1190インターネット流れのプロトコル1990年10月
bit is no longer set. If an ST agent receives a CONNECT
message from a neighbor whose Restarted bit is still set, it
must respond with ERROR-IN-REQUEST with the appropriate
reason code (RemoteRestart). If it receives a CONNECT
message while its own Restarted bit is set, it must respond
with ERROR-IN-REQUEST with the appropriate reason code
(RestartLocal).
ビットはもう設定されません。 STエージェントがRestartedビットがまだ設定されている隣人からCONNECTメッセージを受け取るなら、それはERROR IN REQUESTと共に適切な理由コード(RemoteRestart)で応じなければなりません。 それ自身のRestartedビットが設定されますが、CONNECTメッセージを受け取るなら、それはERROR IN REQUESTと共に適切な理由コード(RestartLocal)で応じなければなりません。
3.7.1.3. Subset
3.7.1.3. 部分集合
This failure detection mechanism subsets by reducing the
complexity of the timing and decisions. A subsetted ST
agent sends HELLO messages to all its ST neighbors
regardless of whether there is an active ST stream between
them or not. The RecoveryTimeout parameter of the FlowSpec
is ignored and is assumed to be the DefaultRecoveryTimeout.
Note that this implies that a REFUSE should be sent for all
CONNECT or CHANGE messages whose RecoveryTimeout is less
than DefaultRecoveryTimeout. An ST agent will accept an
incoming HELLO message if it has a HelloTimer field that is
greater than the most recent valid HELLO message by
DefaultHelloFactor times the time elapsed since that message
was received.
タイミングと決定の複雑さを減少させるのによるこの失敗検出メカニズム部分集合。 彼らの間には、活発なSTの流れがあることにかかわらずsubsetted STエージェントはすべてのST隣人へのメッセージをHELLOに送ります。 FlowSpecのRecoveryTimeoutパラメタは、無視されて、DefaultRecoveryTimeoutであると思われます。 これが、REFUSEがRecoveryTimeoutがDefaultRecoveryTimeout以下であるすべてのCONNECTかCHANGEメッセージのために送られるべきであるのを含意することに注意してください。 それにそのメッセージ以来時間が経過したというDefaultHelloFactor回の最新の有効なHELLOメッセージを受け取ったより大きいHelloTimer分野があると、STエージェントは入って来るHELLOメッセージを受け入れるでしょう。
3.7.2. Failure Recovery
3.7.2. 失敗回復
Streams can fail from various causes; an ST agent can break, a
network can break, or an ST agent can intentionally break a
stream in order to give the stream's resources to a higher
precedence stream. We can envision several approaches to
recovery of broken streams, and we consider the one described
here the simplest and therefore the most likely to be
implemented and work.
流れはいろいろな理由で失敗できます。 STエージェントが中断できますか、ネットワークが中断できますか、またはSTエージェントは、より高い先行の流れに流れのリソースを与えるために故意に流れを壊すことができます。 ものが最も簡単であって、実行されて、したがって、ここで説明された中で最も働きそうであると私たちは中断した流れの回収へのいくつかのアプローチを思い描くことができて、考えます。
If an intermediate agent fails or a network or part of a
network fails, the previous-hop agent and the various next-hop
agents will discover the fact by the failure detection
mechanism described in Section 3.7.1 (page 48). An ST agent
that intentionally breaks a stream obviously knows of the
event.
仲介物質が失敗するか、またはネットワークのネットワークか一部が行き詰まると、前のホップエージェントと様々な次のホップエージェントはセクション3.7.1(48ページ)で説明された失敗検出メカニズムで事実を発見するでしょう。 故意に流れを壊すSTエージェントは明らかに出来事を知っています。
The recovery of an ST stream is a relatively complex and time
consuming effort because it is designed in a general manner to
operate across a large number of networks with diverse
characteristics. Therefore, it may require information to be
distributed widely, and may require relatively long timers. On
the other hand, since a network is a homogeneous system,
failure recovery in the network may be a relatively faster and
simpler operation. Therefore an ST agent that detects a
failure should attempt to fix the network failure before
それが多くのネットワークの向こう側にさまざまの特性で作動するように一般的な方法で設計されているので、STの流れの回収は比較的複雑で時間がかかった努力です。 したがって、それは、情報が広く分配されるのが必要であり、比較的長いタイマを必要とするかもしれません。 他方では、ネットワークが均一系であるので、ネットワークでの失敗回復は比較的速くて、より簡単な操作であるかもしれません。 したがって、失敗を検出するSTエージェントは、以前ネットワーク失敗を修正するのを試みるべきです。
CIP Working Group [Page 51] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[51ページ]RFC1190インターネット流れのプロトコル1990年10月
attempting recovery of the ST stream. If the stream that
existed between two ST agents before the failure cannot be
reconstructed by network recovery mechanisms alone, then the ST
stream recovery mechanism must be invoked.
STの流れの回収を試みます。 ネットワーク回収機構で単独で失敗の前に2人のSTエージェントの間に存在した流れを再建できないなら、ST流れの回収機構を呼び出さなければなりません。
If stream recovery is necessary, the different ST agents may
need to perform different functions, depending on their
relation to the failure.
流れの回復が必要であるなら、異なったSTエージェントは、異なった機能を実行する必要があるかもしれません、失敗との彼らの関係によって。
An intermediate agent that breaks the stream intentionally
sends DISCONNECT messages with the appropriate reason code
(StreamPreempted) toward the affected targets. If the
NoRecovery option is selected, it sends a REFUSE message with
the appropriate reason code(StreamPreempted) toward the origin.
If the NoRecovery option is not selected, then this agent
attempts recovery of the stream, as described below.
流れを壊す仲介物質は故意に影響を受ける目標に向かった適切な理由コード(StreamPreempted)があるメッセージをDISCONNECTに送ります。 NoRecoveryオプションが選択されるなら、それは適切な理由コード(StreamPreempted)があるREFUSEメッセージを起源に向かって送ります。 NoRecoveryオプションが選択されないなら、このエージェントは以下で説明されるように流れの回収を試みます。
A host agent that is a target of the broken stream or is itself
the next-hop of the failed component should release resources
that are allocated to the stream, but should maintain the
internal state information describing the stream. It should
inform any next higher protocol of the failure. It is
appropriate for that protocol to expect that the stream will be
fixed shortly by some alternate path and so maintain, for some
time period, whatever information in the ST layer, the next
higher layer, and the application is necessary to reactivate
quickly entries for the stream as the alternate path develops.
The agent should use a timeout to delete all the stream
information in case the stream cannot be fixed in a reasonable
time.
失敗したコンポーネントの次のホップ自体が流れに割り当てられるリソースを発表するはずであるということですが、中断した流れの目標である、または流れについて説明する内部の州の情報を保守するべきであるホストエージェント。 それは失敗のどんな次の、より高いプロトコルも知らせるべきです。 以上、そのプロトコルが流れがすぐ何らかの代替パスによって修理されると予想して、そう主張するためには、しばらく間の、ST層、次の、より高い層のいかなる情報も、アプリケーションが代替パスが展開するときすばやく流れのためのエントリーを現役に戻すのに必要であることは、適切です。 エージェントは、妥当な時間で流れを修理できないといけないのですべての流れの情報を削除するのにタイムアウトを使用するべきです。
An intermediate agent that is a next-hop of a failure that was
not due to a preemption should first verify that there was a
failure. It can do this using STATUS messages to query its
upstream neighbor. If it cannot communicate with that
neighbor, then it should first send a REFUSE message with the
appropriate reason code of "failure" to the neighbor to speed
up the failure recovery in case the hop is unidirectional,
i.e., the neighbor can hear the agent but the agent cannot hear
the neighbor. The ST agent detecting the failure must then
send DISCONNECT messages with the same reason code toward the
targets. The intermediate agents process this DISCONNECT
message just like the DISCONNECT that tears down the stream.
However, a target ST agent that receives a DISCONNECT message
with the appropriate reason code (StreamPreempted, or
"failure") will maintain the stream state and notify the next
higher protocol of the failure. In effect, these DISCONNECT
messages tear down the stream from the point of the failure to
the targets, but inform the targets that the stream may be
fixed shortly.
先取りのためでなかった失敗の次のホップである仲介物質は、最初に、失敗があったことを確かめるべきです。 それは、上流の隣人について質問するSTATUSメッセージを使用することでこれができます。 その隣人とコミュニケートできないなら、それは最初に、ホップが単方向であるといけないので失敗回復を早くするために「失敗」の適切な理由コードがあるREFUSEメッセージを隣人に送るべきですが、すなわち、隣人はエージェントの声を聞くことができますが、エージェントは隣人の声を聞くことができません。 そして、失敗を検出するSTエージェントは目標に向かった同じ理由コードがあるメッセージをDISCONNECTに送らなければなりません。 仲介物質はまさしく流れを取りこわすDISCONNECTのようにこのDISCONNECTメッセージを処理します。 しかしながら、適切な理由コード(StreamPreempted、または「失敗」)でDISCONNECTメッセージを受け取る目標STエージェントは、流れの状態を維持して、失敗の次の、より高いプロトコルに通知するでしょう。 事実上、これらのDISCONNECTメッセージは、失敗のポイントから目標までの流れを取りこわしますが、流れがまもなく固定されるかもしれない目標を知らせます。
CIP Working Group [Page 52] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[52ページ]RFC1190インターネット流れのプロトコル1990年10月
An ST agent that is the previous-hop before the failed
component first verifies that there was a failure by querying
the downstream neighbor using STATUS messages. If the neighbor
has lost its state but is available, then the ST agent may
reconstruct the stream if the NoRecovery option is not
selected, as described below. If it cannot communicate with
the next-hop, then the agent detecting the failure releases any
resources that are dedicated exclusively to sending data on the
broken branch and sends a DISCONNECT message with the
appropriate reason code ("failure") toward the affected
targets. It does so to speed up failure recovery in case the
communication may be unidirectional and this message might be
delivered successfully.
失敗したコンポーネントの前の前のホップ1番目であるSTエージェントは、STATUSメッセージを使用することで川下の隣人について質問するのによる失敗があったことを確かめます。 隣人が状態を失いましたが、手があいて、NoRecoveryオプションが選択されないなら、STエージェントは流れを再建するかもしれません、以下で説明されるように。 次のホップで交信できないなら、失敗を検出するエージェントは、折れているブランチでデータを送りながら排他的にどんなひたむきなリソースにも発表して、適切な理由コード(「失敗」)があるDISCONNECTメッセージを影響を受ける目標に向かって送ります。 失敗回復は、コミュニケーションが単方向であるかもしれなく、首尾よくこのメッセージを送るといけないかもしれないので、そう加速します。
If the NoRecovery option is selected, then the ST agent that
detects the failure sends a REFUSE message with the appropriate
reason code ("failure") to the previous-hop. If it is breaking
the stream intentionally, it sends a REFUSE message with the
appropriate reason code (StreamPreempted) to the previous-hop.
The TargetList in these messages contains all the targets that
were reached through the broken branch. Multiple REFUSE
messages may be required if the PDU is too long for the MTU of
the intervening network. The REFUSE message is propagated all
the way to the origin, which can attempt recovery of the stream
by sending a new CONNECT to the affected targets. The new
CONNECT will be treated by intermediate ST agents as an
addition of new targets into the established stream.
NoRecoveryオプションが選択されるなら、失敗を検出するSTエージェントは適切な理由コード(「失敗」)があるREFUSEメッセージを前のホップに送ります。 故意に流れを壊しているなら、それは適切な理由コード(StreamPreempted)があるREFUSEメッセージを前のホップに送ります。 これらのメッセージのTargetListは折れている支店を通って達したすべての目標を含んでいます。 介入しているネットワークのMTUには、PDUが長過ぎるなら、複数のREFUSEメッセージが必要であるかもしれません。 REFUSEメッセージは起源までのいっぱいに伝播されます。(起源は、新しいCONNECTを影響を受ける目標に送ることによって、流れの回収を試みることができます)。 新しいCONNECTは新しい目標の添加として中間的STエージェントによって確立した流れの中に扱われるでしょう。
If the NoRecovery option is not selected, the ST agent that
breaks the stream intentionally or is the previous-hop before
the failed component can attempt recovery of the stream. It
does so by issuing a new CONNECT message to the affected
targets. If the ST agent cannot find new routes to some
targets, or if the only route to some targets is through the
previous-hop, then it sends one or more REFUSE messages to the
previous-hop with the appropriate reason code ("failure" or
StreamPreempted) specifying the affected targets in the
TargetList. The previous-hop can then attempt recovery of the
stream by issuing a CONNECT to those targets. If it cannot
find an appropriate route, it will propagate the REFUSE message
toward the origin.
NoRecoveryオプションが選択されないなら、故意に流れを壊すか、失敗したコンポーネントの前の前のホップであるSTエージェントは流れの回収を試みることができます。 それは、新しいCONNECTメッセージを影響を受ける目標に発行することによって、そうします。 STエージェントがいくつかの目標に新しいルートを見つけることができないか、または前のホップを通していくつかの目標への唯一のルートがあるなら、それは適切な理由コード(「失敗」かStreamPreempted)がTargetListの影響を受ける目標を指定している前のホップに1つ以上のREFUSEメッセージを送ります。 そして、前のホップは、それらの目標にCONNECTを発行することによって、流れの回収を試みることができます。 適切なルートを見つけることができないと、それはREFUSEメッセージを起源に向かって伝播するでしょう。
Regardless of which agent attempts recovery of a damaged
stream, it will issue one or more CONNECT messages to the
affected targets. These CONNECT messages are treated by
intermediate ST agents as additions of new targets into the
established stream. The FlowSpecs of the new CONNECT messages
should be the same as the ones contained in the most recent
CONNECT or CHANGE messages that the ST agent had sent toward
the affected targets when the stream was operational.
どのエージェントが破損している流れの回収を試みるかにかかわらず、それは1つ以上のCONNECTメッセージを影響を受ける目標に発行するでしょう。 これらのCONNECTメッセージは新しい目標の追加として中間的STエージェントによって確立した流れの中に扱われます。 新しいCONNECTメッセージのFlowSpecsはものが最新のCONNECTかCHANGEに流れが操作上であったときに、STエージェントが影響を受ける目標に向かって発信したというメッセージを含んだのと同じであるべきです。
CIP Working Group [Page 53] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[53ページ]RFC1190インターネット流れのプロトコル1990年10月
The reconstruction of a broken stream may not proceed smoothly.
Since there may be some delay while the information concerning
the failure is propagated throughout an internet, routing
errors may occur for some time after a failure. As a result,
the ST agent attempting the recovery may receive REFUSE or
ERROR-IN-REQUEST messages for the new CONNECTs that are caused
by internet routing errors. The ST agent attempting the
recovery should be prepared to resend CONNECTs before it
succeeds in reconstructing the stream. If the failure
partitions the internet and a new set of routes cannot be found
to the targets, the REFUSE messages will eventually be
propagated to the origin, which can then inform the application
so it can decide whether to terminate or to continue to attempt
recovery of the stream.
中断した流れの再構成はスムーズに続かないかもしれません。 失敗の情報がインターネット中で伝播されている間、何らかの遅れがあるかもしれないので、ルーティング誤りは失敗の後にしばらく発生するかもしれません。 その結果、回復を試みるSTエージェントはインターネットルーティング誤りで引き起こされる新しいCONNECTsへのREFUSEかERROR IN REQUESTメッセージを受け取るかもしれません。 回復を試みるSTエージェントは流れを再建するのに成功する前にCONNECTsを再送する用意ができているべきです。 失敗がインターネットを仕切って、新しいセットのルートを目標に見つけることができないと、REFUSEメッセージは結局、起源に伝播されるでしょう。(次に、それは、終わるか、または流れの回収を試み続けているかを決めることができるようにアプリケーションを知らせることができます)。
The new CONNECT may at some point reach an ST agent downstream
of the failure before the DISCONNECT does. In this case, the
agent that receives the CONNECT is not yet aware that the
stream has suffered a failure, and will interpret the new
CONNECT as resulting from a routing failure. It will respond
with an ERROR-IN-REQUEST message with the appropriate reason
code (StreamExists). Since the timeout that the ST agents
immediately preceding the failure and immediately following the
failure are approximately the same, it is very likely that the
remnants of the broken stream will soon be torn down by a
DISCONNECT message with the appropriate reason code
("failure"). Therefore, the ST agent that receives the ERROR-
IN-REQUEST message with reason code (StreamExists) should
retransmit the CONNECT message after the ToConnect timeout
expires. If this fails again, the request will be retried for
NConnect times. Only if it still fails will the ST agent send
a REFUSE message with the appropriate reason code (RouteLoop)
to its previous-hop. This message will be propagated back to
the ST agent that is attempting recovery of the damaged stream.
That ST agent can issue a new CONNECT message if it so chooses.
The REFUSE is matched to a CONNECT message created by a
recovery operation through the LnkReference field in the
CONNECT.
新しいCONNECTはDISCONNECTの前での失敗のSTエージェント川下がする何らかのポイント範囲でそうするかもしれません。 この場合、CONNECTを受け取るエージェントは流れが失敗を受けて、ルーティング失敗から生じると新しいCONNECTを解釈するのをまだ意識していません。 それは適切な理由コード(StreamExists)があるERROR IN REQUESTメッセージで応じるでしょう。 すぐに、失敗に先行して、すぐに失敗の後をつけるSTエージェントがおよそそうであるタイムアウト以来、同じように、適切な理由コード(「失敗」)があるDISCONNECTメッセージはすぐ、中断した流れの残りを非常に取りこわしそうでしょう。 したがって、ToConnectタイムアウトが期限が切れた後に理由コード(StreamExists)でERROR IN-REQUESTメッセージを受け取るSTエージェントはCONNECTメッセージを再送するべきです。 これが再び失敗すると、要求はNConnect回のために再試行されるでしょう。 まだ失敗している場合にだけ、STエージェントは適切な理由コード(RouteLoop)があるREFUSEメッセージを前のホップに送るでしょうか? このメッセージは破損している流れの回収を試みているSTエージェントに伝播して戻されるでしょう。 そう選ぶなら、そのSTエージェントは新しいCONNECTメッセージを発行できます。 REFUSEはCONNECTのLnkReference分野を通る回復動作で作成されたCONNECTメッセージに合わせられています。
ST agents that have propagated a CONNECT message and have
received a REFUSE message should maintain this information for
some period of time. If an agent receives a second CONNECT
message for a target that recently resulted in a REFUSE, that
agent may respond with a REFUSE immediately rather than
attempting to propagate the CONNECT. This has the effect of
pruning the tree that is formed by the propagation of CONNECT
messages to a target that is not reachable by the routes that
are selected first. The tree will pass through any given ST
agent only once, and the stream setup phase will be completed
faster.
CONNECTメッセージを伝播して、REFUSEメッセージを受け取ったSTエージェントはいつかの期間の間、この情報を保守するべきです。 エージェントが最近REFUSEをもたらした目標への2番目のCONNECTメッセージを受け取るなら、CONNECTを伝播するのを試みるよりそのエージェントはすぐに、REFUSEと共にむしろ応じるかもしれません。 これには、CONNECTメッセージの伝播で最初に選択されるルートで届いていない目標に形成される木を剪定するという効果があります。 木は一度だけどんな与えられたSTエージェントも通り抜けるでしょう、そして、流れのセットアップフェーズは、より速く完成するでしょう。
CIP Working Group [Page 54] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[54ページ]RFC1190インターネット流れのプロトコル1990年10月
The time period for which the failure information is maintained
must be consistent with the expected lifetime of that
information. Failures due to lack of reachability will remain
relevant for time periods large enough to allow for network
reconfigurations or repairs. Failures due to routing loops
will be valid only until the relevant routing information has
propagated, which can be a short time period. Lack of
bandwidth resulting from over-allocation will remain valid
until streams are terminated, which is an unpredictable time,
so the time that such information is maintained should also be
short.
失敗情報が保守される期間はその情報の予想された生涯と一致しているに違いありません。 可到達性の不足による失敗はネットワーク再構成か修理を考慮できるくらい大きい期間、関連していたままで残るでしょう。 関連ルーティング情報(短い期間であるかもしれない)が伝播されるまでしか、ルーティング輪による失敗は有効にならないでしょう。 流れが終えられるまで過剰配分から生じる帯域幅の不足が有効なままで残るので、(予測できない時間です)また、そのような情報が保守される間も短いはずです。
If a CONNECT message reaches a target, the target should as
efficiently as possible use the state that it has saved from
before the stream failed during recovery of the stream. It
will then issue an ACCEPT message toward the origin. The
ACCEPT message will be intercepted by the ST agent that is
attempting recovery of the damaged stream, if not the origin.
If the FlowSpec contained in the ACCEPT specifies the same
selection of parameters as were in effect before the failure,
then the ST agent that is attempting recovery will not
propagate the ACCEPT. If the selections of the parameters are
different, then the agent that is attempting recovery will send
the origin a NOTIFY message with the appropriate reason code
(FailureRecovery) that contains a FlowSpec that specifies the
new parameter values. The origin may then have to change its
data generation characteristics and the stream's parameters
with a CHANGE message to use the newly recovered subtree.
CONNECTメッセージに達するなら、目標、目標はできるだけ効率的に使用するべきです。流れが流れの回収の間、失敗する前にそれが節約した状態を使用してください。 そして、それは起源に向かってACCEPTメッセージを発行するでしょう。 ACCEPTメッセージはまして、破損している流れ、起源の回復を試みているSTエージェントによって傍受されるでしょう。 ACCEPTに含まれたFlowSpecが失敗の前に有効であったようにパラメタの同じ品揃えを指定すると、回復を試みているSTエージェントはACCEPTを伝播しないでしょう。 パラメタの品揃えが異なると、回復を試みているエージェントは新しいパラメタ値を指定するFlowSpecを含む適切な理由コード(FailureRecovery)があるNOTIFYメッセージを起源に送るでしょう。 そして、起源は新たに回復している下位木を使用するCHANGEメッセージでデータ生成の特性と流れのパラメタを変えなければならないかもしれません。
3.7.2.1. Subset
3.7.2.1. 部分集合
Subsets of this mechanism may reduce the functionality in
the following ways. A host agent might not retain state
describing a stream that fails with a DISCONNECT message
with the appropriate reason code ("failure" or
StreamPreempted).
このメカニズムの部分集合は以下の方法で機能性を減らすかもしれません。 ホストエージェントは適切な理由コード(「失敗」かStreamPreempted)に応じてDISCONNECTメッセージで失敗する流れについて説明する州を保有しないかもしれません。
An agent might force the NoRecovery option always to be set.
In this case, it will allow the option to be propagated in
the CONNECT message, but will propagate the REFUSE message
with the appropriate reason code ("failure" or
StreamPreempted) without attempting recovery of the damaged
stream.
エージェントは、設定されるためにいつもNoRecoveryオプションを強制するかもしれません。 この場合、破損している流れの回収を試みないで、それは、オプションがCONNECTメッセージで伝播されるのを許容しますが、適切な理由コード(「失敗」かStreamPreempted)でREFUSEメッセージを伝播するでしょう。
If an ST agent allows stream recovery and attempts recovery
of a stream, it might choose a FlowSpec to specify exactly
the current values of the parameters, with no ranges or
options.
STエージェントが流れの回復を許して、流れの回収を試みるなら、まさにパラメタの現行価値を指定するためにFlowSpecを選ぶかもしれません、範囲もオプションなしで。
CIP Working Group [Page 55] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[55ページ]RFC1190インターネット流れのプロトコル1990年10月
3.7.3. A Group of Streams
3.7.3. 流れのグループ
There may be a need to associate related streams. The Group
mechanism is simply an association technique that allows ST
agents to identify the different streams that are to be
associated. Streams are in the same Group if they have the
same Group Name in the GroupName field of the (R)Group
parameter. At this time there are no ST control messages that
modify Groups. Group Names have the same format as stream
Names, and can share the same name space. A stream that is a
member of a Group can specify one or more (Subgroup Identifier,
Relation) tuples. The Relation specifies how the members of
the Subgroup of the Group are related. The Subgroups
Identifiers need only be unique within the Group.
関連する流れを関連づける必要があるかもしれません。Groupメカニズムは単にSTエージェントが関連させていることになっている異なった流れを特定できる協会のテクニックです。 (R)グループパラメタのGroupName分野に同じGroup Nameを持っているなら、流れが同じGroupにあります。 このとき、Groupsを変更するSTコントロールメッセージが全くありません。 グループNamesは流れのNamesと同じ形式を持って、同じ名前スペースを共有できます。 Groupのメンバーである流れは1(サブグループIdentifier、Relation)tuplesを指定できます。 RelationはGroupのSubgroupのメンバーがどう関係づけられるかを指定します。 Subgroups IdentifiersはGroupの中でユニークであるだけでよいです。
Streams can be associated into Groups to support activities
that deal with a number of streams simultaneously. The
operation of Groups of streams is a matter for further study,
and this mechanism is provided to support that study. This
mechanism allows streams to be identified as belonging to a
given Group and Subgroup, but in order to have any effect, the
behavior that is expected of the Relation must be implemented
in the ST agents. Possible applications for this mechanism
include the following:
同時に多くの流れに対処する活動を支持するために小川をGroupsに関連づけることができます。 流れのGroupsの操作はさらなる研究への問題です、そして、その研究をサポートするためにこのメカニズムを提供します。 このメカニズムは、流れが与えられたGroupとSubgroupに属すとして特定されるのを許容しますが、どんな効果も持つために、STエージェントでRelationに予想される振舞いを実行しなければなりません。 このメカニズムの可能なアプリケーションは以下を含んでいます:
o Associating streams that are part of a floor-controlled
conference. In this case, only one origin can send data
through its stream at any given time. Therefore, at any
point where more than one stream passes through a branch
or network, only enough bandwidth for one stream needs
to be allocated.
o 床で制御された会議の一部である流れを関連づけます。 この場合、1つの起源だけがその時々で流れでデータを送ることができます。 したがって、1つ以上の流れがブランチかネットワークを通り抜ける任意な点では、1つの流れのための十分な帯域幅だけが、割り当てられる必要があります。
o Associating streams that cannot exist independently. An
example of this may be the various streams that carry
the audio, video, and data components of a conference,
or the various streams that carry data from the
different participants in a conference. In this case,
if some ST agent must preempt more than a single stream,
and it has selected any one of the streams so
associated, then it should also preempt the rest of the
members of that Subgroup rather than preempting any
other streams.
o 独自に存在できない流れを関連づけます。 この例は、会議のオーディオ、ビデオ、およびデータ構成要素を運ぶ様々な流れ、または会議の異なった関係者からデータを運ぶ様々な流れであるかもしれません。 また、この場合、STエージェントがただ一つの流れ以上を先取りしなければならなくて、とても関連している流れのどれかを選択したなら、それはいかなる他の流れも先取りするよりむしろそのSubgroupのメンバーの残りを先取りするべきです。
o Associating streams that must not be completed
independently. This example is similar to the preceding
one, but relates to the stream setup phase. In this
example, any single member of a Subgroup of streams need
not be completed unless the rest are also completed.
Therefore, if one stream becomes blocked, all the others
will also be blocked. In this case, if there are not
enough resources to support all the conferences that are
attempted, some number of the conferences will complete
o 独自に終了してはいけない流れを関連づけます。 この例は、前のものと同様ですが、流れのセットアップフェーズに関連します。 この例では、また、残りが完成されない場合、流れのSubgroupのどんな独身のメンバーも完成する必要はありません。 したがって、また、1つの流れが妨げられるようになると、すべての他のものが妨げられるでしょう。 この場合、すべての試みられた会議は支持できるくらいのリソースがないと、会議の何らかの数が完成するでしょう。
CIP Working Group [Page 56] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[56ページ]RFC1190インターネット流れのプロトコル1990年10月
and other will be blocked, rather than all conferences
be partially completed and partially blocked.
そして、もう一方は部分的に終了していて、部分的に妨げられたすべての会議よりむしろ妨げられるでしょう。
This document assumes that the creation and membership of the
Group will be managed by the next protocol above ST, with the
assistance of ST. For example, the next higher protocol
would request ST to create a unique Group Name and a set of
Subgroups with specified characteristics. The next higher
protocol would distribute this information to the other
participants that were to be members of the Group. Each
would transfer the Group Name, Subgroups, and Relations to
the ST layer, which would simply include them in the stream
state.
このドキュメントは、Groupの創造と会員資格がSTの上で次のプロトコルによって管理されると仮定します、STの支援で。例えば、次の、より高いプロトコルは、指定された特性があるSubgroupsのユニークなGroup Nameとセットを創設するようSTに要求するでしょう。 次の、より高いプロトコルはGroupのメンバーであることになっていた他の関係者にこの情報を分配するでしょう。 それぞれがGroup Name、Subgroups、およびRelationsをST層に移すでしょう。(単に、それは、流れの状態に彼らを含んでいるでしょう)。
3.7.3.1. Group Name Generator
3.7.3.1. グループ名ジェネレータ
This facility is provided so that an application or higher
layer protocol can obtain a unique Group Name from the ST
layer. This is a mechanism for the application to request
the allocation of a Group Name that is independent of the
request to create a stream. The Group Name is used by the
application or higher layer protocol when creating the
streams that are to be part of a group. All that is
required is a function of the form:
アプリケーションか、より高い層のプロトコルがST層からユニークなGroup Nameを入手できるように、この施設を提供します。 これはアプリケーションが流れを作成するよう要求から独立しているGroup Nameの配分に要求するメカニズムです。 グループの一部であることになっている流れを作成するとき、Group Nameはアプリケーションか、より高い層のプロトコルによって使用されます。 必要であるすべてがフォームの関数です:
AllocateGroupName()
-> result, GroupName
AllocateGroupName()->結果、GroupName
A corresponding function to release a Group Name is also
desirable; its form is:
また、Group Nameをリリースする対応する機能も望ましいです。 フォームは以下の通りです。
ReleaseGroupName( GroupName )
-> result
ReleaseGroupName(GroupName)->結果
3.7.3.2. Subset
3.7.3.2. 部分集合
Since Groups are currently intended to support
experimentation, and it is not clear how best to use them,
it is appropriate for an implementation not to support
Groups. At this time, a subsetted ST agent may ignore the
Group parameter. It is expected that in the future, when
Groups transition from being an experimental concept to an
operational one, it may be the case that such subsetting
will no longer be acceptable. At that time, a new
subsetting option may be defined.
現在、Groupsが実験を支持することを意図して、どのように彼らを最もよく使用するかが明確でないので、実現がGroupsを支持しないのは、適切です。 このとき、subsetted STエージェントはGroupパラメタを無視するかもしれません。 将来実験概念であるのからの操作上のものへのGroups変遷であるときに、そのような副設定がもう許容できないのが、事実であるかもしれないと予想されます。 その時、新しい副設定オプションは定義されるかもしれません。
CIP Working Group [Page 57] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[57ページ]RFC1190インターネット流れのプロトコル1990年10月
3.7.4. HID Negotiation
3.7.4. 交渉を隠しました。
Each data packet must carry a value to identify the stream to
which it belongs, so that forwarding can be performed.
Conceptually, this value could be the Name of the stream. A
shorthand identifier is desirable for two reasons. First,
since each data packet must carry this identifier, network
bandwidth efficiency suggests that it be as small as
possible. This is particularly important for applications
that use small data packets, and that use low bandwidth
networks, such as voice across packet radio networks.
Second, the operation of mapping this identifier into a data
object that contains the forwarding information must be
performed at each intermediate ST agent in the stream. To
minimize delay and processing overhead, this operation should
be as efficient as possible. Most likely, this identifier
will be used to index into an internal table. To meet these
goals, ST has chosen to use a 16-bit hop-by-hop identifier
(HID). It is large enough to handle the foreseen number of
streams during the expected life of the protocol while small
enough not to preclude its use as a forwarding table index.
Note, however, that HID 0 is reserved for control messages,
and that HIDs 1-3 are also reserved for future use.
各データ・パケットはそれが属する流れを特定するために値を運ばなければなりません、推進を実行できるように。 概念的に、この値は流れのNameであるかもしれません。 速記識別子は2つの理由で望ましいです。 各データ・パケットがこの識別子を運ばなければならないので、まず最初に、ネットワーク回線容量効率は、それができるだけ小さいと示唆します。 小さいデータ・パケットを使用して、低い帯域幅ネットワークを使用するアプリケーションには、これは特に重要です、パケット無線ネットワークの向こう側の声などのように。 2番目に、それぞれの中間的STエージェントで流れで推進情報を含むデータ・オブジェクトにこの識別子を写像する操作を実行しなければなりません。 遅れと処理オーバヘッド、この操作を最小にするのはできるだけ効率的であるべきです。 たぶん、この識別子は、内部のテーブルに索引をつけるのに使用されるでしょう。 これらの目標を達成するために、STは、ホップごとの16ビットの識別子(HID)を使用するのを選びました。 それは小さく推進テーブルとして使用を排除しないほど索引をつける、しかし、プロトコルの期待耐用年数の間流れの見通された数を扱うことができるくらい大きいです。 しかしながら、HID0がコントロールメッセージのために予約されて、また、HIDs1-3が今後の使用のために予約されることに注意してください。
When ST makes use of multicast ability in networks that
provide it, a data packet multicast by an ST agent will be
received identically by several next-hop ST agents. In a
multicast environment, the HID must be selected either by
some network-wide mechanism that selects unique identifiers,
or it must be selected by the sender of the CONNECT message.
Since we feel any network-wide mechanism is outside the scope
of this protocol, we propose that the previous-hop agent
select the HID and send it in the CONNECT message (with the
HID Field option set, see Section 3.6.1 (page 44)) subject to
the approval of the next-hop agents. We call this "HID
negotiation".
STがそれを提供するネットワークでマルチキャスト能力を利用すると、STエージェントによるデータ・パケットマルチキャストは同様に数人の次のホップSTエージェントによって受け取られるでしょう。 マルチキャスト環境で、ユニークな識別子を選択する何らかのネットワーク全体のメカニズムがHIDを選択しなければなりませんか、またはCONNECTメッセージの送付者はそれを選択しなければなりません。 このプロトコルの範囲の外にどんなネットワーク全体のメカニズムもあると感じて、私たちは、前のホップエージェントがCONNECTメッセージ(HID Fieldオプションセットで、セクション3.6.1(44ページ)を見る)で次のホップエージェントの承認を条件としてHIDを選択して、それを送るよう提案します。 私たちは、これを「HID交渉」と呼びます。
As an origin ST agent is creating a stream or as an
intermediate agent is propagating a CONNECT message, it must
make a routing decision to determine which targets will be
reached through which next-hop ST agents. In some cases,
several next-hops can be reached through a network that
supports multicast delivery. If so, those next-hops will be
made members of a multicast group and data packets will be
sent to the group. Different CONNECT messages are sent to
the several next-hops even if the data packets will be sent
to the multicast group, because the CONNECT messages contain
different TargetLists and are acknowledged and accepted
separately. However, the HID contained by the different
CONNECT message must be identical. The ST agent selects a
16-bit quantity to be the HID and inserts it into each
起源STエージェントが流れを作成しているか、または仲介物質がCONNECTメッセージを伝播しているとき、それはどの目標にどの次のホップSTエージェントを通して達するかを決定するというルーティング決定をしなければなりません。 いくつかの場合、いくつかの次のホップにマルチキャスト配送を支持するネットワークを通して達することができます。 そうだとすれば、それらの次のホップはマルチキャストグループの成功確実なメンバーになるでしょう、そして、データ・パケットをグループに送るでしょう。 マルチキャストグループにデータ・パケットを送っても、異なったCONNECTメッセージをいくつかの次のホップに送ります、別々にCONNECTメッセージを異なったTargetListsを含んでいて、承認して、受け入れるので。 しかしながら、異なったCONNECTメッセージによって含まれたHIDは同じであるに違いありません。 STエージェントは、16ビットの量がHIDであることを選択して、それをそれぞれに挿入します。
CIP Working Group [Page 58] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[58ページ]RFC1190インターネット流れのプロトコル1990年10月
CONNECT message that is then sent to the appropriate
next-hop.
次に適切な次のホップに送られるCONNECTメッセージ。
The next-hop agents that receive the CONNECT messages must
propagate the CONNECT messages toward the targets, but must
also look at the HID and decide whether they can approve it.
An ST agent can only receive data packets with a given HID if
they belong to a single stream. If the ST agent already has
an established stream that uses the proposed HID, this is a
HID collision, and the agent cannot approve the HID for the
new stream. Otherwise the agent can approve the HID. If it
can approve the HID, then it must make note of that HID and
it must respond with a HID-APPROVE message (unless it can
immediately respond with an ERROR-IN-REQUEST or a REFUSE).
If it cannot approve the HID then it must respond with a
HID-REJECT message.
CONNECTメッセージを受け取る次のホップエージェントはCONNECTメッセージを目標に向かって伝播しなければなりません、また、HIDを見て、彼らがそれを承認できるかどうか決めなければならないのを除いて。 ただ一つの流れに属す場合にだけ、STエージェントは与えられたHIDと共にデータ・パケットを受けることができます。 STエージェントに提案されたHIDを使用する確立した流れが既にあるなら、これはHID衝突です、そして、エージェントは新しい流れのためにHIDを承認できません。 さもなければ、エージェントはHIDを承認できます。 HIDを承認できるなら、そのHIDのメモを作らなければなりません、そして、HID-APPROVEメッセージで応じなければなりません(すぐにERROR IN REQUESTかREFUSEと共に応じることができないなら)。 HIDを承認できないなら、それはHID-REJECTメッセージで応じなければなりません。
An agent that sends a CONNECT message with the H bit set
awaits its acknowledgment message (which could be a
HID-ACCEPT, HID-REJECT, or an ERROR-IN-REQUEST) from the
next-hops independently of receiving ACCEPT messages. If it
does not receive an acknowledgment within timeout ToConnect,
it will resend the CONNECT. If each next-hop agent responds
with a HID-ACCEPT, this implies that they have each approved
of the HID, so it can be used for all subsequent data
packets. If one or more next-hops respond with an
HID-REJECT, then the agent that selected the HID must select
another HID and send it to each next-hop in a set of
HID-CHANGE messages. The next-hop agents must respond to
(and thus acknowledge) these HID-CHANGE messages with either
a HID-ACCEPT or a HID-REJECT (or, in the case of an error, an
ERROR-IN-REQUEST, or a REFUSE if the next-hop agent wants to
abort the HID negotiation process after rejecting NHIDAbort
proposed HIDs). If the agent does not receive such a
response within timeout ToHIDChange, it will resend the
HID-CHANGE up to NHIDChange times. If any next-hop agents
respond with a REFUSE message that specifies all the targets
that were included in the corresponding CONNECT, then that
next-hop is removed from the negotiation. The overall
negotiation is complete only when the agent receives a
HID-ACCEPT to the same proposed HID from all the next-hops
that do not respond with an ERROR-IN-REQUEST or a REFUSE.
ACCEPTメッセージを受け取ることの如何にかかわらずHビットがセットした状態でCONNECTメッセージを送るエージェントは次のホップからの承認メッセージ(HID-ACCEPT、HID-REJECT、またはERROR IN REQUESTであるかもしれない)を待ちます。 タイムアウトToConnectの中で承認を受けないと、それはCONNECTを再送するでしょう。 それぞれの次のホップエージェントがHID-ACCEPTと共に応じるなら、これが、彼らがそれぞれHIDに賛成したのを含意するので、すべての順次データパケットにそれを使用できます。 1つ以上の次のホップがHID-REJECTと共に応じるなら、HIDを選択したエージェントは、HID-CHANGEメッセージのセットにおけるそれぞれの次のホップに別のHIDを選択して、それを送らなければなりません。 次のホップエージェントが応じなければならない、(その結果、承認、)、HID-ACCEPTかHID-REJECTのどちらかがあるこれらのHID-CHANGEメッセージ(誤りに関するケース、ERROR IN REQUEST、またはREFUSEでは、次のホップエージェントが中止になりたいなら、NHIDAbortを拒絶した後のHID交渉の過程はHIDsを提案しました)。 エージェントがタイムアウトToHIDChangeの中でそのような応答を受けないと、それはHID-CHANGEをNHIDChange回まで再送するでしょう。 どれか次のホップエージェントが対応するCONNECTに含まれていたすべての目標を指定するREFUSEメッセージで応じるなら、交渉からその次のホップを取り除きます。 エージェントがERROR IN REQUESTかREFUSEと共に応じるというわけではないすべての次のホップからHID-ACCEPTを同じ提案されたHIDに受け取るときだけ、総合的な交渉は完全です。
This negotiation may continue an indeterminate length of
time. In fact, the CONNECT messages could propagate to the
targets and their ACCEPT messages may potentially propagate
back to the origin before the negotiation is complete. If
this were permitted, the origin would not be aware of the
incomplete negotiation and could begin to send data packets.
Then the agent that is attempting to select a HID would have
to discard any data rather than sending it to the next-hops
since it might not have a valid HID to send with the data.
この交渉は不確定の長さの時間を続けるかもしれません。 事実上、CONNECTメッセージは目標に伝播されることができました、そして、交渉が完全になる前にそれらのACCEPTメッセージは潜在的に起源に伝播して戻られるかもしれません。 これが受入れられるなら、起源は、不完全な交渉を意識していなくて、データ・パケットを送り始めるかもしれないでしょうに。 そして、HIDを選択するのを試みているエージェントは、データと共に発信するためにそれが有効なHIDを持っていないかもしれないので次のホップにそれを送るよりむしろどんなデータも捨てなければならないでしょう。
CIP Working Group [Page 59] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[59ページ]RFC1190インターネット流れのプロトコル1990年10月
To prevent this situation, an ACCEPT should not be propagated
back to the previous-hop until the HID negotiation with the
next-hops has been completed.
この状況を防ぐために、次のホップとのHID交渉が終了するまで、前のホップにACCEPTを伝播して戻すべきではありません。
Although it is possible that the negotiation extends for an
arbitrary length of time, we consider this to be very
unlikely. Since the HID is only relevant across a single
hop, we can estimate the probability that a randomly selected
HID will conflict with the HID of an established stream.
Consider a stream in which the hop from an ST agent to ten
next-hop agents is through the multicast facility of a given
network. Assume also that each of the next-hop agents
participates in 1000 other streams, and that each has been
created with a different HID. A randomly selected 16-bit HID
will have a probability of greater than 85.9% of succeeding
on the first try, 98.1% of succeeding on the second, and
99.8% of succeeding on the third. We therefore suggest that
a 16-bit HID space is sufficiently large to support ST until
better multicast HID selection procedures, e.g., HID servers,
can be deployed.
交渉が任意の長さの時に広がるのが、可能ですが、私たちは、これが非常にありそうもないと考えます。 HIDが単一のホップの向こう側に関連しているだけであるので、私たちは手当たりしだいに選択されたHIDが確立した流れのHIDと衝突するという確率を見積もることができます。 STエージェントから10人の次のホップエージェントまでのホップが与えられたネットワークのマルチキャスト施設である流れを考えてください。 また、次のホップエージェントの各人が他の1000の流れに参加して、異なったHIDと共にそれぞれを作成してあると仮定してください。 手当たりしだいに選択された16ビットのHIDには、一度で成功する85.9%以上、2番目の上の98.1%の成功、および3日での99.8%の成功の確率があるでしょう。 したがって、私たちは、16ビットのHIDスペースが、より良いマルチキャストHID選択手順(例えば、HIDサーバ)を配備できるまでSTを支持できるくらい大きいと示唆します。
An obvious way to select the HID is for the ST agents to use
a random number generator as suggested above. An alternate
mechanism is for the intermediate agents to use the HID
contained in the incoming CONNECT message for all the
outgoing CONNECT messages, and generate a random number only
as a second choice. In this case, the origin ST agent would
HIDを選択する当たり前の方法はSTエージェントが上に示されるように乱数発生器を使用することです。 交互のメカニズムは、仲介物質がすべての送信するCONNECTメッセージに入って来るCONNECTメッセージに含まれたHIDを使用して、単に第二希望として乱数を発生させることです。 この場合、起源STエージェントはそうするでしょう。
Agent 3 Agent B
エージェントの3エージェントB
1. +-> CONNECT B -------------->+
<RVLId=0><SVLId=32> |
<Ref=315><HID=5990> V
2. (Check HID Table, 5990 busy, 6000-11 unused)
V
3. +<- HID-REJECT --------------+
| <RVLId=32><SVLId=45>
| <Ref=315><HID=5990>
V <FreeHIDs=5990:0000FFF0>
4. +-> HID-CHANGE ------------>+
<RVLId=45><SVLId=32> |
<Ref=320><HID=6000> V
5. (Check HID Table, 6000 (still) available)
V
6. +<- HID-APPROVE -------------+
<RVLId=32><SVLId=45>
<Ref=320><HID=6000>
1. +->はBを接続します。-------------->+<RVLId=0><SVLId=32>。| <審判=315><は= 5990>V2隠れました。 (6000-11に忙しい状態でHID Table、5990をチェックしてください、未使用、) V3。 +<廃棄物を隠しました。--------------+ | <RVLId=32><SVLId=45>。| <審判=315><は=5990>V<FreeHIDs=5990を隠しました: 0000FFF0>4。 +->、変化を隠しました。------------>+<RVLId=45><SVLId=32>。| <審判=320><は= 6000>V5隠れました。 (チェックHID Table、(まだ)利用可能な6000) V6。 + <、-、隠す、-承認してください。-------------6000+ SVLId=45><審判=320><が隠した<RVLId=32><=>。
7. (Both parties have now agreed to use HID 6000)
7. (双方は、現在、HID6000を使用するのに同意しました)
Figure 18. Typical HID Negotiation (No Multicasting)
図18。 典型的である、交渉を隠しました。(マルチキャスティングがありません)
CIP Working Group [Page 60] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[60ページ]RFC1190インターネット流れのプロトコル1990年10月
be responsible for generating the HID, and the same HID could
be propagated for the entire stream. This approach has the
marginal advantage that the HID could be created by a higher
layer protocol that might have global knowledge and could
select small, globally unique HIDs for all the streams. While
this is possible, we leave it for further study.
HIDを発生させるのに責任があってください。そうすれば、全体の流れのために同じHIDは伝播できました。 HIDはマージンの利点であるかもしれませんが、このアプローチはグローバルな知識を持っているかもしれなくて、すべての流れのために小さくて、グローバルにユニークなHIDsを選択できたより高い層のプロトコルによって作成されていた状態で残しました。これが可能である間、私たちはさらなる研究にそれを残します。
Agent 2 Agent C Agent D
エージェントの2エージェントのCエージェントD
1. +->+-> CONNECT ---------------------------------->+
| <RVLId=0><SVLId=26> |
| <Ref=250><HID=4824> |
V <Mcast=224.1.18.216,01:00:5E:01:12:d8> |
2. +-> CONNECT --------------------+ |
<RVLId=0><SVLId=25> | |
<Ref=252><HID=4824> | V
3. <Mcast=224.1.18.216, V (Check HID Table)
4. 01:00:5E:01:12:d8> (Check HID Table) (4824 ok)
(4824 busy) (4800-4809 ok)
(4800-4820 ok) |
V |
5. +<- HID-REJECT -----------------+ |
| <RVLId=25><SVLId=54> |
| <Ref=252><HID=4824> |
V <FreeHIDs=4824:FFFFF800> V
6. +<-+<- HID-APPROVE -------------------------------+
| <RVLId=26><SVLId=64>
| <Ref=250><HID=4824>
V <FreeHIDs=4824:FFC00080>
(find common HID 4800)
V
7. +->+-> HID-CHANGE ------------------------------->+
| <RVLId=64><SVLId=26> |
V <Ref=253><HID=4800> |
8. +-> HID-CHANGE ---------------->+ |
<RVLId=54><SVLId=25> | V
9. <Ref=254><HID=4800> V (Check HID Table)
10. (Check HID Table) (4800 ok)
(4800-4820 ok) (4800-4809 ok)
V |
11. +<- HID-APPROVE ----------------+ |
| <RVLId=25><SVLId=54> |
| <Ref=254><HID=4800> |
V <FreeHIDs=4800:7FFFF800> V
12. +<-+<- HID-APPROVE -------------------------------+
| <RVLId=26><SVLId=64>
| <Ref=253><HID=4800>
V <FreeHIDs=4800:7FC00080>
13. (all parties have now agreed to use HID 4800)
1. +>+>は接続します。---------------------------------->+| <RVLId=0><SVLId=26>。| | 250><が隠した<審判=は4824>と等しいです。| V<Mcast=224.1.18.216、01:00:5E: 01:12:d8>。| 2. +->は接続します。--------------------+ | <RVLId=0><SVLId=25>。| | 252><が隠した<審判=は4824>と等しいです。| V3。 <Mcast=224.1.18.216、V(チェックはテーブルを隠した)4。 01:00:5E: 01:12:d8>(HID Tableをチェックします)(4824年のOK)、(4824が忙しくする、)、(4800-4809 OKに)(4800-4820 OK)| V| 5. +<廃棄物を隠しました。-----------------+ | | <RVLId=25><SVLId=54>。| | 252><が隠した<審判=は4824>と等しいです。| V<FreeHIDs=4824: FFFFF800>V6。 + <-+<、-、隠す、-承認してください。-------------------------------+ | <RVLId=26><SVLId=64>。| <審判は250><HID=4824>V<FreeHIDs=4824と等しいです: FFC00080>(一般的なHIDが4800であることがわかる)V7。 +>+>、変化を隠しました。------------------------------->+| <RVLId=64><SVLId=26>。| 253><が隠したV<審判=は4800>と等しいです。| 8. +->、変化を隠しました。---------------->+| <RVLId=54><SVLId=25>。| V9。 <審判=254><は=4800>V(チェックはテーブルを隠しました)10を隠しました。 (チェックはテーブルを隠しました) (4800年のOK) (4800-4820 OK) (4800-4809 OK) V| 11. + <、-、隠す、-承認してください。----------------+ | | <RVLId=25><SVLId=54>。| | 254><が隠した<審判=は4800>と等しいです。| V<FreeHIDs=4800: 7FFFF800>V12。 + <-+<、-、隠す、-承認してください。-------------------------------+ | <RVLId=26><SVLId=64>。| <審判=253><は=4800>V<FreeHIDs=4800を隠しました: 7FC00080>13。 (パーティーが現在HID4800を使用するために同意させるすべて)
Figure 19. Multicast HID Negotiation
図19。 マルチキャストは交渉を隠しました。
CIP Working Group [Page 61] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[61ページ]RFC1190インターネット流れのプロトコル1990年10月
Agent 2 Agent C Agent D Agent 3
エージェントの2エージェントのCエージェントのDエージェント3
1. +----> CONNECT B ------------------------------------>+
<RVLId=0><SVLId=24> V
2. <Ref=260><HID=4800> (Check HID Table)
<Mcast=224.1.18.216, (4800 busy, 4801-4810 ok)
01:00:5E:01:12:d8> V
3. +<---- HID-REJECT <-----------------------------------+
| <RVLId=24><SVLId=33>
| <Ref=260><HID=4824>
V <FreeHIDs=4824:7FE00000>
4. (find common HID 4810)
V
5. +->+-> HID-CHANGE ----------------------------------->+
| <RVLId=33><SVLId=24> |
V <Ref=262><HID=4810> |
6. +-> HID-CHANGE-ADD ------------------->+ |
| <RVLId=64><SVLId=26> | V
7. V <Ref=263><HID=4810> | (Check HID Table)
8. +-> HID-CHANGE-ADD ---->+ | (4801-4815 ok)
<RVLId=54><SVLId=25>| V |
9. <Ref=265><HID=4810> V (Check HID Table) |
10. (Check HID Table) (4810 busy) |
(4801-4812 ok) (4801-4807 ok) |
V | |
11. +<- HID-APPROVE <-------+ | |
| <RVLId=25><SVLId=54> | |
| <Ref=265><HID=4810> | |
V <FreeHIDs=4810:7FD8000> V |
12. +<- HID-REJECT <-----------------------+ |
| <RVLId=26><SVLId=64> |
| <Ref=263><HID=4810> |
V <FreeHIDs=4810:7F000000> V
13. +<-+<- HID-APPROVE <----------------------------------+
| <RVLId=24><SVLId=33>
| <Ref=262><HID=4810>
V <FreeHIDs=4810:7FDF0000>
14. +->+-> HID-CHANGE-DELETE ---------------------------->+
| | <RVLId=33><SVLId=24> |
| V <Ref=266><HID=4810> |
15. | +-> HID-CHANGE-DELETE ->+ |
| <RVLId=54><SVLId=25>| |
| <Ref=268><HID=4810> V |
16. | +<- HID-APPROVE --------+ |
| <RVLId=25><SVLId=54> |
| <Ref=268><HID=0> V
17. | +<- HID-APPROVE -----------------------------------+
| <RVLId=24><SVLId=33>
V <Ref=266><HID=0>
18. (find common HID 4801)
1. +---->はBを接続します。------------------------------------>+<RVLId=0><SVLId=24>V2。 <審判は260><HID=4800>(HID Tableをチェックする)<Mcast=224.1.18.216、(4800年の忙しい4801-4810OK)と01:00:5E等しいです: 01:12:d8>V3。 + <。---- 廃棄物を隠している<。-----------------------------------+ | <RVLId=24><SVLId=33>。| <審判=260><は=4824>V<FreeHIDs=4824を隠しました: 7FE00000>4。 (掘り出し物一般的なHID4810) V5。 +>+>、変化を隠しました。----------------------------------->+| <RVLId=33><SVLId=24>。| 262><が隠したV<審判=は4810>と等しいです。| 6. +->、隠す、変化は加えます。------------------->+| | <RVLId=64><SVLId=26>。| V7。 263><が隠したV<審判=は4810>と等しいです。| (チェックはテーブルを隠しました) 8. +->、隠す、変化は加えます。---->+| (4801-4815 OK) <RVLId=54><SVLId=25>| V| 9. <審判=265><は=4810>Vを隠しました(チェックはテーブルを隠しました)。| 10. (チェックはテーブルを隠しました) (4810が忙しくする、) | (4801-4812 OK) (4801-4807 OK) | V| | 11. + <、-、隠す、-承認してください、<。-------+ | | | <RVLId=25><SVLId=54>。| | | 265><が隠した<審判=は4810>と等しいです。| | V<FreeHIDs=4810: 7FD8000>V| 12. + 廃棄物を隠している<<。-----------------------+ | | <RVLId=26><SVLId=64>。| | 263><が隠した<審判=は4810>と等しいです。| V<FreeHIDs=4810: 7F000000>V13。 + <-+<、-、隠す、-承認してください、<。----------------------------------+ | <RVLId=24><SVLId=33>。| <審判=262><は=4810>V<FreeHIDs=4810を隠しました: 7FDF0000>14。 +>+>、隠す、変化は削除します。---------------------------->+| | <RVLId=33><SVLId=24>。| | 266><が隠したV<審判=は4810>と等しいです。| 15. | +->、隠す、変化が削除する、-、>+| | <RVLId=54><SVLId=25>|、|、| <審判=268><は=4810>Vを隠しました。| 16. | + <、-、隠す、-承認してください。--------+ | | <RVLId=25><SVLId=54>。| | <審判=268><は=0>V17を隠しました。 | + <、-、隠す、-承認してください。-----------------------------------+ | <RVLId=24><SVLId=33>V<審判=266><は=0>18を隠しました。 (掘り出し物一般的なHID4801)
Figure 20. Multicast HID Re-Negotiation (part 1)
図20。 マルチキャストは再交渉を隠しました。(第1部)
CIP Working Group [Page 62] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[62ページ]RFC1190インターネット流れのプロトコル1990年10月
Agent 2 Agent C Agent D Agent 3
エージェントの2エージェントのCエージェントのDエージェント3
18. (find common HID 4801)
V
19. +->+-> HID-CHANGE ----------------------------------->+
| <RVLId=33><SVLId=24> |
V <Ref=270><HID=4801> |
20. +-> HID-CHANGE-ADD ------------------->+ |
| <RVLId=64><SVLId=26> | V
21. V <Ref=273><HID=4801> | (Check HID Table)
22. +-> HID-CHANGE-ADD ---->+ | (4801-4815 ok)
<RVLId=54><SVLId=25>| V |
23. <Ref=274><HID=4801> V (Check HID Table) |
24. (Check HID Table)(4801-4807 ok) |
(4801-4812 ok) | |
V | |
25. +<- HID-APPROVE <-------+ | |
| <RVLId=25><SVLId=54> | |
| <Ref=274><HID=4801> | |
V <FreeHIDs=4801:3FF80000> V |
26. +<- HID-APPROVE <----------------------+ |
| <RVLId=26><SVLId=64> |
| <Ref=273><HID=4801> |
V <FreeHIDs=4801:3F000000> V
27. +<-+<- HID-APPROVE <----------------------------------+
| <RVLId=24><SVLId=33>
| <Ref=270><HID=4801>
V <FreeHIDs=4801:3FFF0000>
28. (switch data stream to HID 4801, drop 4800)
V
29. +->+-> HID-CHANGE-DELETE ---------------->+
| <RVLId=64><SVLId=26> |
V <Ref=275><HID=4800> |
30. +-> HID-CHANGE-DELETE ->+ |
<RVLId=54><SVLId=25>| |
<Ref=277><HID=4800> V |
31. +<-+<- HID-APPROVE --------+ |
| <RVLId=25><SVLId=54> |
V <Ref=277><HID=0> V
32. +<-+<- HID-APPROVE -----------------------+
| <RVLId=26><SVLId=64>
V <Ref=275><HID=0>
(all parties have now agreed to use HID 4801)
18. (掘り出し物一般的なHID4801) V19。 +>+>、変化を隠しました。----------------------------------->+| <RVLId=33><SVLId=24>。| 270><が隠したV<審判=は4801>と等しいです。| 20. +->、隠す、変化は加えます。------------------->+| | <RVLId=64><SVLId=26>。| V21。 273><が隠したV<審判=は4801>と等しいです。| (チェックはテーブルを隠しました) 22. +->、隠す、変化は加えます。---->+| (4801-4815 OK) <RVLId=54><SVLId=25>| V| 23. <審判=274><は=4801>Vを隠しました(チェックはテーブルを隠しました)。| 24. (チェックはテーブルを隠しました)(4801-4807 OK) | (4801-4812 OK) | | V| | 25. + <、-、隠す、-承認してください、<。-------+ | | | <RVLId=25><SVLId=54>。| | | 274><が隠した<審判=は4801>と等しいです。| | V<FreeHIDs=4801: 3FF80000>V| 26. + <、-、隠す、-承認してください、<。----------------------+ | | <RVLId=26><SVLId=64>。| | 273><が隠した<審判=は4801>と等しいです。| V<FreeHIDs=4801: 3F000000>V27。 + <-+<、-、隠す、-承認してください、<。----------------------------------+ | <RVLId=24><SVLId=33>。| <審判=270><は=4801>V<FreeHIDs=4801を隠しました: 3FFF0000>28。 (HID4801にデータ・ストリームを切り換えてください、そして、4800を落としてください) V29。 +>+>、隠す、変化は削除します。---------------->+| <RVLId=64><SVLId=26>。| 275><が隠したV<審判=は4800>と等しいです。| 30. +->、隠す、変化が削除する、-、>+| <RVLId=54><SVLId=25>|、| <審判=277><は=4800>Vを隠しました。| 31. + <-+<、-、隠す、-承認してください。--------+ | | <RVLId=25><SVLId=54>。| V<審判=277><は=0>V32を隠しました。 + <-+<、-、隠す、-承認してください。-----------------------+ | <RVLId=26><SVLId=64>V<審判=275><は=0>を隠しました。(パーティーが現在HID4801を使用するために同意させるすべて)
Figure 20. Multicast HID Re-Negotiation (part 2)
図20。 マルチキャストは再交渉を隠しました。(第2部)
CIP Working Group [Page 63] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[63ページ]RFC1190インターネット流れのプロトコル1990年10月
3.7.4.1. Subset
3.7.4.1. 部分集合
The above mechanism can operate exactly as described even if
the ST agents do not all use the entire 16 bits of the HID.
A low capacity ST agent that cannot support a large number
of simultaneous streams may use only some of the bits in the
HID, say for example the low order byte. This may allow
this disadvantaged agent to use smaller internal data
structures at the expense of causing HID collisions to occur
more often. However, neither the disadvantaged agent's
previous-hop nor its next-hops need be aware of its
limitations. In the HID negotiation, the negotiators still
exchange a 16-bit quantity.
上のメカニズムはちょうどSTエージェントが皆、HIDの全体の16ビットを使用しないでも説明されるように動作できます。 多くの同時の流れを支持できない低い容量STエージェントはHIDで数ビットだけを使用するかもしれなくて、例えば下位バイトを言ってください。 これで、HID衝突が、よりしばしば起こることを引き起こすことを犠牲にしてこの不都合なエージェントは、より小さい内部のデータ構造を使用できるかもしれません。 しかしながら、不都合なエージェントの前のホップもその次のホップも制限を意識している必要はありません。 HID交渉では、交渉者はまだ16ビットの量を交換しています。
3.7.5. IP Encapsulation of ST
3.7.5. IP第カプセル化
ST packets may be encapsulated in IP to allow them to pass
through routers that don't support the ST Protocol. Of course,
ST resource management is precluded over such a path, and
packet overhead is increased by encapsulation, but if the
performance is reasonably predictable this may be better than
not communicating at all. IP encapsulation may also be
required either for enhanced security (see Section 3.7.8 (page
67)) or for user-space implementations of ST in hosts that
don't allow demultiplexing on the IP Version Number field (see
Section 4 (page 75)), but do allow access to raw IP packets.
STパケットは、STプロトコルをサポートしないルータを通り抜けるのを許容するためにIPでカプセルに入れられるかもしれません。 もちろん、ST資源管理がそのような経路に関して排除されて、カプセル化でパケットオーバーヘッドを上げますが、性能が合理的に予測できるなら、これは全く交信しないより良いかもしれません。 また、IPカプセル化が警備の強化(セクション3.7.8(67ページ)を見る)かIPバージョンNumberフィールドで逆多重化を許さないホストでのSTのユーザ宇宙実現に必要であるかもしれませんが(セクション4(75ページ)を見てください)、生のIPパケットへのアクセスを許してください。
IP-encapsulated ST packets begin with a normal IP header. Most
fields of the IP header should be filled in according to the
same rules that apply to any other IP packet. Three fields of
special interest are:
IPによって要約されたSTパケットは普通のIPヘッダーと共に始まります。 いかなる他のIPパケットにも適用されるのと同じ規則に従って、IPヘッダーのほとんどの分野が記入されるべきです。 特別に関心の3つの分野は以下の通りです。
o Protocol is 5 to indicate an ST packet is enclosed, as
opposed to TCP or UDP, for example. The assignment of
protocol 5 to ST is an arranged coincidence with the
assignment of IP Version 5 to ST [18].
o プロトコルはSTパケットがTCPかUDPと対照的に例えば、同封されるのを示す5です。 STへのプロトコル5の課題はST[18]へのIPバージョン5の課題がある整っている偶然の一致です。
o Destination Address is that of the next-hop ST agent.
This may or may not be the target of the ST stream.
There may be an intermediate ST agent to which the
packet should be routed to take advantage of service
guarantees on the path past that agent. Such an
intermediate agent would not be on a directly-connected
network (or else IP encapsulation wouldn't be needed),
so it would probably not be listed in the normal routing
table. Additional routing mechanisms, not defined here,
will be required to learn about such agents.
o 目的地Addressは次のホップSTエージェントのものです。 これはSTの流れの目標であるかもしれません。 パケットがそのエージェントの先で経路でサービス保証を利用するために発送されるべきである中間的STエージェントがいるかもしれません。 そのような仲介物質は直接接続されたネットワークの一員(IPカプセル化は必要でない)でないでしょう、したがって、それがたぶん正常な経路指定テーブルに記載されていないでしょう。 ここで定義されなかった追加ルーティングメカニズムはそのようなエージェントに関して学ばなければならないでしょう。
o Type-of-Service may be set to an appropriate value for
the service being requested (usually low delay, high
o タイプのサービスは要求されているサービスのための適切な値に設定されるかもしれません。(通常、安値が延着する、高さ
CIP Working Group [Page 64] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[64ページ]RFC1190インターネット流れのプロトコル1990年10月
throughput, normal reliability). This feature is not
implemented uniformly in the Internet, so its use can't be
precisely defined here.
スループット、正常な信頼性) この特徴がインターネットで一様に実行されないので、ここで正確に使用を定義できません。
Since there can be no guarantees made about performance across
a normal IP network, the ST agent that will encapsulate should
modify the Desired FlowSpec parameters when the stream is being
established to indicate that performance is not guaranteed. In
particular, Reliability should be set to the minimum value
(1/256), and suitably large values should be added to the
Accumulated Mean Delay and Accumulated Delay Variance to
reflect the possibility that packets may be delayed up to the
point of discard when there is network congestion. A suitably
large value is 255 seconds, the maximum packet lifetime as
defined by the IP Time-to-Live field.
正常なIPネットワークの向こう側に性能に関してされた保証が全くあるはずがないので、流れが性能が保証されないのを示すために確立されているとき、要約するSTエージェントはDesired FlowSpecパラメタを変更するべきです。 特に、Reliabilityは最小値(1/256)に用意ができるべきです、そして、適当に大きい値は、ネットワークの混雑があるとき、パケットが破棄のポイントまで遅れるかもしれない可能性を反映するためにAccumulated Mean DelayとAccumulated Delay Varianceに加えられるべきです。 適当に大きい値は255秒、IP生きるTime分野によって定義される最大のパケット生存期間です。
IP encapsulation adds little difficulty for the ST agent that
receives the packet. The IP header is simply removed, then the
ST header is processed as usual.
IPカプセル化はパケットを受けるSTエージェントのためにほとんど困難を加えません。 単にIPヘッダーを取り除いて、次に、いつものようにSTヘッダーを処理します。
The more difficult part is during setup, when the ST agent must
decide whether or not to encapsulate. If the next-hop ST agent
is on a remote network and the route to that network is through
a router that supports IP but not ST, then encapsulation is
required. As mentioned in Section 3.8.1 (page 69), routing
table entries must be expanded to indicate whether the router
supports ST.
STエージェントが、要約するかどうか決めなければならないとき、より難しい部分がセットアップの間、あります。 次のホップSTエージェントがリモートネットワークの一員であり、STではなく、IPを支持するルータを通してそのネットワークへのルートがあるなら、カプセル化が必要です。 セクション3.8.1(69ページ)で言及されるように、ルータがSTを支持するかどうかを示すために経路指定テーブルエントリーを広げなければなりません。
On forwarding, the (mostly constant) IP Header must be inserted
and the IP checksum appropriately updated.
推進のときに、(ほとんど一定)のIP Headerは挿入されていて適切にアップデートされたIPチェックサムであるに違いありません。
On a directly connected network, though, one might want to
encapsulate only when sending to a particular destination host
that does not allow demultiplexing on the IP Version Number
field. This requires the routing table to include host-route
as well as network-route entries. Host-route entries might
require static definition if the hosts do not participate in
the routing protocols. If packet size is not a critical
performance factor, one solution is always to encapsulate on
the directly connected network whenever some hosts require
encapsulation. Those that don't require the encapsulation
should be able to remove it upon reception.
もっとも、IPバージョンNumberフィールドで逆多重化を許さない特定のあて先ホストに発信するときだけ、直接接続されたネットワークでは、人は要約したがっているかもしれません。 これは、ネットワークルートエントリーと同様にホストルートを含むように経路指定テーブルを必要とします。 ホストがルーティング・プロトコルに参加しないなら、ホストルートエントリーは静的な定義を必要とするかもしれません。 1つの解決策は何人かのホストがカプセル化を必要とするときはいつも、パケットサイズがきわどい性能要素でないなら、直接接続されたネットワークでいつも要約することです。 カプセル化を必要としないものはレセプションでそれを取り除くはずであることができます。
3.7.5.1. IP Multicasting
3.7.5.1. IPマルチキャスティング
If an ST agent must use IP encapsulation to reach multiple
next-hops toward different targets, then either the packet
must be replicated for transmission to each next-hop, or IP
multicasting [6] may be used if it is implemented in the
next-hop ST agents and in the intervening IP routers.
STエージェントが複数の次のホップに異なった目標に向かって達するのにIPカプセル化を使用しなければならないならそれぞれの次のホップへの伝送のためパケットを模写しなければならない、さもなければ、それが次のホップSTエージェントと介入しているIPルータで実行されるなら、IPマルチキャスティング[6]は使用されるかもしれません。
CIP Working Group [Page 65] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[65ページ]RFC1190インターネット流れのプロトコル1990年10月
This is analogous to using network-level service to
multicast to several next-hop agents on a directly connected
network.
これは直接接続されたネットワークの数人の次のホップエージェントにマルチキャストに対するネットワークレベルサービスを利用するのに類似しています。
When the stream is established, the collection of next-hop
ST agents must be set up as an IP multicast group. It may
be necessary for the ST agent that wishes to send the IP
multicast to allocate a transient multicast group address
and then tell the next-hop agents to join the group. Use of
the MulticastAddress parameter (see Section 4.2.2.7 (page
86)) provides one way that the information may be
communicated, but other techniques are possible. The
multicast group address in inserted in the Destination
Address field of the IP encapsulation when data packets are
transmitted.
ストリームが確立されるとき、IPマルチキャストグループとして次のホップSTエージェントの収集をセットアップしなければなりません。 一時的なマルチキャストグループを割り当てるためにIPマルチキャストを送るという願望が、グループに加わるように次のホップエージェントに扱って、次に、言うのがSTエージェントに必要であるかもしれません。 MulticastAddressパラメタの使用、(.7(86ページ)が情報が伝えられるかもしれませんが、他のテクニックが可能である、ある方法に提供するセクション4.2.2を見てください。 IPカプセル化のDestination Address分野に挿入されるところのデータ・パケットが伝えられるとマルチキャストグループアドレス。
A block of transient IP multicast addresses, 224.1.0.0 -
224.1.255.255, has been allocated for this purpose. There
are 2^16 addresses in this block, allowing a direct mapping
with 16-bit HIDs, if appropriate. The mechanisms for
allocating these addresses are not defined here.
1ブロックの一時的なIPマルチキャストアドレス、224.1 .0 .0--224.1 .255 .255 このために、割り当てました。 適切であるなら16ビットのHIDsがあるダイレクトマッピングを許容して、2^16のアドレスがこのブロックにあります。 これらのアドレスを割り当てるためのメカニズムはここで定義されません。
In addition, two permanent IP multicast addresses have been
assigned to facilitate experimentation with exchange of
routing or other information among ST agents. Those
addresses are:
さらに、ルーティングか他の情報の交換がSTエージェントの中のひとりで実験を容易にするために2つの永久的なIPマルチキャストアドレスを割り当ててあります。 それらのアドレスは以下の通りです。
224.0.0.7 All ST routers
224.0.0.8 All ST hosts
224.0.0.7 .8All STが接待するすべてのSTルータ224.0.0
An ST router is an ST agent that can pass traffic between
attached networks; an ST host is an ST agent that is
connected to a single network or is not permitted to pass
traffic between attached networks. Note that the range of
these multicasts is normally just the attached local
network, limited by setting the IP time-to-live field to 1
(see [6]).
STルータは付属ネットワークの間にトラフィックを通過できるSTエージェントです。 STホストはただ一つのネットワークに接続されるか、または付属ネットワークの間にトラフィックを通過することは許可されていないSTエージェントです。 通常、これらのマルチキャストの範囲がただIP生きる時間分野を1に設定することによって制限された付属企業内情報通信網であることに注意してください。([6])を考えてください。
3.7.6. Retransmission
3.7.6. Retransmission
The ST Control Message Protocol is made reliable through use of
retransmission when an expected acknowledgment is not received
in a timely manner. The problem of when to send a
retransmission has been studied for protocols such as TCP [2]
[10] [11]. The problem should be simpler for ST since control
messages usually only have to travel a single hop and they do
not contain very much data. However, the algorithms developed
for TCP are sufficiently simple that their use is recommended
for ST as well; see [2]. An implementor might, for example,
choose to keep statistics separately for each
直ちに予想された承認を受けないとき、ST Control Messageプロトコルを「再-トランスミッション」の使用で信頼できるようにします。 いつ「再-トランスミッション」を送るかに関する問題はTCP[2][10][11]などのプロトコルのために研究されました。 通常、コントロールメッセージが単一のホップを旅行するだけでよくて、非常に多くのデータを含んでいないので、STには、問題は、より簡単であるべきです。 しかしながら、彼らの使用がまた、STのために推薦されるTCPが十分簡単であるので開発されたアルゴリズム。 [2]を見てください。 例えば、作成者は、別々にそれぞれ統計を取って置くのを選ぶかもしれません。
CIP Working Group [Page 66] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[66ページ]RFC1190インターネットストリームプロトコル1990年10月
neighboring ST agent, or combined into a single statistic for
an attached network.
STエージェントを近所付き合いさせるか、または付属ネットワークのためにただ一つの統計値に結合されます。
Estimating the packet round-trip time (RTT) is a key function
in reliable transport protocols such as TCP. Estimation must
be dynamic, since congestion and resource contention result in
varying delays. If RTT estimates are too low, packets will be
retransmitted too frequently, wasting network capacity. If RTT
estimates are too high, retransmissions will be delayed
reducing network throughput when transmission errors occur.
Article [11] identifies problems that arise when RTT estimates
are poor, outlines how RTT is used and how retransmission
timeouts (RTO) are estimated, and surveys several ways that RTT
and RTO estimates can be improved.
パケットの往復の時間が(RTT)であると見積もるのは、TCPなどの信頼できるトランスポート・プロトコルの主要な機能です。 異なることにおける混雑とリソース主張結果が延着するので、見積りはダイナミックであるに違いありません。 RTT見積りが低過ぎるなら、ネットワーク容量を浪費して、パケットはあまりに頻繁に再送されるでしょう。 伝送エラーが起こるとき、RTT見積りがまた、そうであるなら、高値、「再-トランスミッション」は遅れた減少しているネットワークスループットになるでしょう。 記事[11]は、RTT見積りが不十分であるときに起こる問題を特定して、再送タイムアウト(RTO)がRTTがどう使用されているか、そして、どう見積もられているかを概説して、RTTとRTO見積りを改良できるいくつかの方法を調査します。
Note the HELLO/ACK mechanism described in Section 3.7.1.2 (page
49) can give an estimate of the RTT and its variance. These
estimates are also important for use with the delay and delay
variance entries in the FlowSpec.
.2(49ページ)がRTTとその変化の見積りに与えることができるセクション3.7.1で説明されたHELLO/ACKメカニズムに注意してください。 また、使用に、遅れと遅れ変化のエントリーがFlowSpecにある状態で、これらの見積りも重要です。
3.7.7. Routing
3.7.7. ルート設定
ST requires access to routing information in order to select a
path from an origin to the destination(s). However, routing is
considered to be a separate issue and neither the routing
algorithm nor its implementation is specified here. ST should
operate equally well with any reasonable routing algorithm.
STは、発生源から目的地まで経路を選択するためにルーティング情報へのアクセスを必要とします。 しかしながら、ルーティングは別個問題であると考えられます、そして、ルーティング・アルゴリズムもその実装もここで指定されません。 STはどんな合理的なルーティング・アルゴリズムでも等しく井戸を操作するはずです。
While ST may be capable of using several types of information
that are not currently available, the minimal information
required is that provided by IP, namely the ability to find an
interface and next hop router for a specified IP destination
address and Type of Service. Methods to make more information
available and to use it are left for further study. For
initial ST implementations, any routing information that is
required but not automatically provided will be assumed to be
manually configured into the ST agents.
STは情報のいくつかの現在手があいていないタイプを使用できるかもしれませんが、必要である最小量の情報はIPによって提供されたそれ、すなわち、Serviceの指定された受信者IPアドレスとTypeに関してインタフェースと次のホップルータを見つける能力です。 詳しい情報を利用可能にして、それを使用するメソッドはさらなる研究に発たれます。 初期のST実装において、必要ですが、自動的に提供されない少しのルーティング情報によっても手動でSTエージェントに構成されると思われるでしょう。
3.7.8. Security
3.7.8. セキュリティ
The ST Protocol by itself does not provide security services.
It is more vulnerable to misdelivery and denial of service than
IP since the ST Header only carries a 16-bit HID for
identification purposes. Any information, such as source and
destination addresses, which a higher-layer protocol might use
to detect misdelivery are the responsibility of either the
application or higher-layer protocol.
それ自体でSTプロトコルはセキュリティー・サービスを提供しません。 それはST Header以来のIPが身元確認の目的で16ビットのHIDを運ぶだけであるよりサービスの配達ミスと否定に被害を受け易いです。 ソースや送付先アドレスなどのどんな情報もアプリケーションか上位層プロトコルの責任です。(上位層プロトコルは、配達ミスを検出するのにアドレスを使用するかもしれません)。
CIP Working Group [Page 67] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[67ページ]RFC1190インターネットストリームプロトコル1990年10月
ST is less prone to traffic analysis than IP since the only
identifying information contained in the ST Header is a hop-
by-hop identifier (HID). However, the use of a HID is also
what makes ST more vulnerable to denial of service since an ST
agent has no reliable way to detect when bogus traffic is
injected into, and thus consumes bandwidth from, a user's
stream. Detection can be enhanced through use of per-interface
forwarding tables and verification of local network source and
destination addresses.
STはST Headerに含まれた唯一の身元が分かる情報以来のIPがホップによるホップ識別子(HID)であるほどトラヒック分析に傾向がありません。 しかしながら、また、HIDの使用はSTエージェントにはユーザのストリームからにせのトラフィックがいつ注入されるかを検出して、その結果帯域幅を消費するどんな信頼できる方法もないのでSTをサービスの否定により被害を受け易くすることです。 1インタフェースあたりの推進テーブルの使用と企業内情報通信網ソースと送付先アドレスの検証で検出を機能アップできます。
We envision that applications that require security services
will use facilities, such as the Secure Digital Networking
System (SDNS) layer 3 Security Protocol (SP3/D) [19] [20]. In
such an environment, ST PDUs would first be encapsulated in an
IP Header, using IP Protocol 5 (ST) as described in Section
3.7.5 (page 64). These IP datagrams would then be secured
using SP3/D, which results in another IP Protocol 5 PDU that
can be passed between ST agents.
私たちはサービスが施設の、そして、セキュアデジタルNetworking System(SDNS)層の3Securityプロトコル(SP3/D)[19][20]としてそのような使用を望んでいるセキュリティを必要とするそのアプリケーションを思い描きます。 そのような環境で、ST PDUsは最初にIP Headerでカプセル化されるでしょう、セクション3.7.5(64ページ)で説明されるようにIPプロトコル5(ST)を使用して。 そして、これらのIPデータグラムは、SP3/D(STエージェントの間で渡すことができる別のIPプロトコル5PDUをもたらす)を使用することで固定されるでしょう。
This memo does not specify how an application invokes security
services.
このメモはアプリケーションがどうセキュリティー・サービスを呼び出すかを指定しません。
3.8. ST Service Interfaces
3.8. サービスは第連結します。
ST has several interfaces to other modules in a communication
system. ST provides its services to applications or transport-
level protocols through its "upper" interface (or SAP). ST in
turn uses the services provided by network layers, management
functions (e.g., address translation and routing), and IP. The
interfaces to these modules are described in this section in the
form of subroutine calls. Note that this does not mean that an
implementation must actually be implemented as subroutines, but is
instead intended to identify the information to be passed between
the modules.
STは通信系に他のモジュールにいくつかのインタフェースを持っています。 STは「上側」のインタフェース(または、SAP)を通してアプリケーションか輸送の平らなプロトコルに対するサービスを提供します。 STは順番にネットワーク層によって提供されたサービス、管理機能(例えば、アドレス変換とルーティング)、およびIPを使用します。 インタフェースはサブルーチン呼出しの形にこのセクションでこれらのモジュールに説明されます。 これが、実装が実際にサブルーチンとして実装しなければなりませんが、モジュールの間で通過されるために情報を特定することを代わりに意図することを意味しないことに注意してください。
In this style of outlining the module interfaces, the information
passed into a module is shown as arguments to the subroutine call.
Return information and/or success/failure indications are listed
after the arrow ("->") that follows the subroutine call. In
several cases, a list of values must either be passed to or
returned from a module interface. Examples include a set of
target addresses, or the mappings from a target list to a set of
next hop addresses that span the route to the originally listed
targets. When such a list is appropriate, the values repeated for
each list element are bracketed and an asterisk is added to
indicate that zero, one, or many list elements can be passed
across the interface (e.g., "<target>*" means zero, one, or more
targets).
モジュールインタフェースについて概説するこのスタイルでは、モジュールに通過された情報は議論としてサブルーチン呼出しに示されます。 リターン情報、そして/または、成功/失敗指摘はサブルーチン呼出しに従う矢("->")の後に記載されます。 いろいろな場合に、モジュールインタフェースから値のリストから移られなければならないか、または戻らなければなりません。 例は1セットのあて先アドレス、または目標リストから元々記載された目標にルートにかかる次のホップアドレスの1セットまでのマッピングを含んでいます。 そのようなリストが適切であるときに、各リスト要素のために繰り返された値は腕木を付けられます、そして、アスタリスクは、インタフェースの向こう側にゼロ、1、または多くのリスト要素を渡すことができるのを示すために加えられます(例えば、「<目標>*」はゼロを意味します、1個以上の目標)。
CIP Working Group [Page 68] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[68ページ]RFC1190インターネットストリームプロトコル1990年10月
3.8.1. Access to Routing Information
3.8.1. 経路情報へのアクセス
The design of routing functions that can support a variety of
resource management algorithms is difficult. In this section
we suggest a set of preliminary interfaces suitable for use in
initial experiments. We expect that these interfaces will
change as we gain more insight into how routing, resource
allocation, and decision making elements are best divided.
さまざまな資源管理がアルゴリズムであるとサポートすることができる経路選択機能のデザインは難しいです。 このセクションで、私たちは初期の実験における使用に適した予備のインタフェースのセットを勧めます。 私たちは、私たちがどうルーティング、資源配分、および意志決定要素を最も良い分割するかに関する、より多くの洞察を獲得するのに応じてこれらのインタフェースが変化すると予想します。
Routing functions are required to identify the set of potential
routes to each destination site. The routing functions should
make some effort to identify routes that are currently
available and that meet the resource requirements. However,
these properties need not be confirmed until the actual
resource allocation and connection setup propagation are
performed.
経路選択機能が、それぞれの目的地サイトに潜在的ルートのセットを特定するのに必要です。 経路選択機能は、現在、利用可能であり、リソース必要条件を満たすルートを特定するために何らかの取り組みを作るべきです。 しかしながら、実際の資源配分と接続設定伝播が実行されるまで、これらの特性は確認される必要はありません。
The minimum capability required of the interface to routing is
to identify the network interface and next hop toward a given
target. We expect that the traditional routing table will need
to be extended to include information that ST requires such as
whether or not a next hop supports ST, and, if so, whether or
not IP encapsulation (see Section 3.7.5 (page 64)) is required
to communicate with it. In particular, host entries will be
required for hosts that can only support ST through
encapsulation because the IP software either is not capable of
demultiplexing datagrams based on the IP Version Number field,
or the application interface only supports access to raw IP
datagrams. This interface is illustrated by the function:
インタフェースについてルーティングに必要である最小の能力は与えられた目標に向かってネットワーク・インターフェースと次のホップを特定することです。 私たちは、伝統的な経路指定テーブルが、次のホップがSTをサポートするかどうかと、そうだとすれば、IPカプセル化(セクション3.7.5(64ページ)を見る)がそれで交信するのに必要であるかどうかとしてSTがそのようなものを必要とするという情報を含むように広げられる必要であると予想します。 ホストエントリーがIPソフトウェアはIPバージョンNumber分野に基づく逆多重化データグラムができないのでカプセル化を通してSTをサポートすることができるだけであるホストに特に、必要でしょう、またはアプリケーション・インターフェースは生のIPデータグラムへのアクセスをサポートするだけです。このインタフェースは機能によって例証されます:
FindNextHop( destination, TOS )
-> result, < interface, next hop, ST-capable,
MustEncapsulate >*
FindNextHop(目的地、TOS)->結果、<インタフェース、次のホップ、STできるMustEncapsulate>*
However, the resource management functions can best tradeoff
among alternative routes when presented with a matrix of all
potential routes. The matrix entry corresponding to a
destination and a next hop would contain the estimated
characteristics of the corresponding pathway. Using this
representation, the resource management functions can quickly
determine the next hop sets that cover the entire destination
list, and compare the various parameters of the tradeoff
between the guarantees that can be promised by each set. An
interface that returns a compressed matrix, listing the
suitable routes by next hop and the destinations reachable
through each, is illustrated by the function:
しかしながら、リソース管理機能はすべての潜在的ルートのマトリクスを与えるとき代替手段の中の見返りが発送するベストをそうすることができます。 目的地と次のホップに対応するマトリクスエントリーは対応する小道のおよそ特性を含んでいるでしょう。 この表現を使用して、リソース管理機能は、すぐに全体の目的地リストをカバーする次のホップセットを決定して、各セットが約束できる保証の間の見返りの様々なパラメタを比較できます。 それぞれを通して届いている次のホップと目的地のそばに適当なルートを記載して、圧縮されたマトリクスを返すインタフェースは機能によって例証されます:
FindNextHops( < destination >*, TOS )
-> result, < destination, < interface, next hop,
ST-capable, MustEncapsulate >* >*
FindNextHops->結果、<の目的地、<インタフェース、次のホップ、STできるMustEncapsulate>*>*(<目的地>*、TOS)
CIP Working Group [Page 69] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[69ページ]RFC1190インターネットストリームプロトコル1990年10月
We hope that routing protocols will be available that propagate
additional metrics of bandwidth, delay, bit/burst error rate,
and whether a router has ST capability. However, propagating
this information in a timely fashion is still a key research
issue.
ルーティング・プロトコルが利用可能になることを願っています。帯域幅、遅れ、ビット/バースト誤りレート、ルータがST能力を持っているか否かに関係なく、それは追加測定基準を伝播します。 しかしながら、それでも、この情報を伝播するのは、直ちに主要な研究課題です。
3.8.2. Access to Network Layer Resource Reservation
3.8.2. ネットワーク層資源予約へのアクセス
The resources required to reach the next-hops associated with
the chosen routes must be allocated. These allocations will
generally be requested and released incrementally. As the
next-hop elements for the routes are chosen, the network
resources between the current node and the next-hops must be
allocated. Since the resources are not guaranteed to be
available -- a network or node further down the path might have
failed or needed resources might have been allocated since the
routing decisions where made -- some of these allocations may
have to be released, another route selected, and a new
allocation requested.
選ばれたルートに関連している次のホップに達するのに必要であるリソースを割り当てなければなりません。 一般に、これらの配分は、増加して要求されていて、リリースされるでしょう。 ルートへの次のホップ要素を選ぶとき、現在のノードと次のホップの間のネットワーク資源を割り当てなければなりません。 リソースが利用可能になるように保証されないので(ルーティング決定以来経路が失敗したかもしれないより遠い下であるか必要なリソースが作られているところに割り当てられているかもしれないネットワークかノード)、これらの配分のいくつかがリリースされなければならないかもしれません、と別のルートは選択して、新しい配分は要求しました。
There are four basic interface functions needed for the network
resource allocator. The first checks to see if the required
resources are available, returning the likelihood that an
ensuing resource allocation will succeed. A probability of 0%
indicates the resources are not available or cannot promise to
meet the required guarantees. Low probabilities indicate that
most of the resource has been allocated or that there is a lot
of contention for using the resource. This call does not
actually reserve the resources:
ネットワーク資源アロケータに必要である4つの基本インターフェース機能があります。 必要なリソースが利用可能であるかどうかを見る最初のチェック、それを見込みに返して、続く資源配分は成功するでしょう。 0%の確率は、リソースが、利用可能でないか、または必要な保証を満たすと約束できないのを示します。 低い確率は、リソースの大部分を割り当てたか、またはリソースを使用するための多くの主張があるのを示します。 この呼び出しは実際にリソースを予約しません:
ResourceProbe( requirements )
-> likelihood
ResourceProbe(要件)->見込み
Another call reserves the resources:
別の呼び出しはリソースを予約します:
ResourceReserve( requirements )
-> result, reservation_id
ResourceReserve(要件)->結果、予約_イド
The third call adjusts the resource guarantees:
3番目の呼び出しはリソース保証を調整します:
ResourceAdjust( reservation_id, new requirements )
-> result
ResourceAdjust(予約_イド、新しい要件)->結果
The final call allows the resources to be released:
最終案内は、リソースが発表されるのを許容します:
ResourceRelease( reservation_id )
-> result
ResourceRelease(予約_イド)->結果
CIP Working Group [Page 70] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[70ページ]RFC1190インターネットストリームプロトコル1990年10月
3.8.3. Network Layer Services Utilized
3.8.3. サービスが利用したネットワーク層
ST requires access to the usual network layer functions to send
and receive packets and to be informed of network status
information. In addition, it requires functions to enable and
disable reception of multicast packets. Such functions might
be defined as:
STは普通のネットワーク層機能へのアクセスがパケットを送って、受けて、ネットワーク状態情報において知識があるのを必要とします。 さらに、マルチキャストパケットのレセプションを可能にして、無効にするのが機能を必要とします。 そのような機能は以下と定義されるかもしれません。
JoinLocalGroup( network level group-address )
-> result, multicast_id
JoinLocalGroup(平らなグループアドレスをネットワークでつなぐ)->結果、マルチキャスト_イド
LeaveLocalGroup( network level group-address )
-> result
LeaveLocalGroup(平らなグループアドレスをネットワークでつなぐ)->結果
RecvNet( SAP )
-> result, src, dst, len, BufPTR )
RecvNet(SAP) ->結果、src、dst、len、BufPTR)
SendNet( src, dst, SAP, len, BufPTR )
-> result
SendNet(src、dst、SAP、len、BufPTR)->結果
GetNotification( SAP )
-> result, infop
GetNotification(SAP)->結果、infop
3.8.4. IP Services Utilized
3.8.4. 利用されたIPサービス
Since ST packets might be sent or received using IP
encapsulation, IP level routines to join and leave multicast
groups are required in addition to the usual services defined
in the IP specification (see the IP specification [2] [15] and
the IP multicast specification [6] for details).
IPカプセル化を使用することでSTパケットを送るか、または受け取るかもしれないので、マルチキャストグループに加わって、出るIPの平らなルーチンがIP仕様に基づき定義された普通のサービスに加えて必要です(IP仕様[2][15]と詳細のためのIPマルチキャスト仕様[6]を見てください)。
JoinHostGroup( IP level group-address, interface )
-> result, multicast_id
JoinHostGroup(IPの平らなグループアドレス、インタフェース)->結果、マルチキャスト_イド
LeaveHostGroup( IP level group-address, interface )
-> result
LeaveHostGroup(IPの平らなグループアドレス、インタフェース)->結果
GET_SRCADDR( remote IP addr, TOS )
-> local IP address
GET_SRCADDR(リモートIP addr、TOS)->ローカルアイピーアドレス
SEND( src, dst, prot, TOS, TTL, BufPTR, len, Id, DF,
opt )
-> result
SEND(src、dst、prot、TOS、TTL、BufPTR(len、Id、DF)は選ぶ)->結果
RECV( BufPTR, prot )
-> result, src, dst, SpecDest, TOS, len, opt
RECV(BufPTR、prot)->結果、src、dst、SpecDest、TOS(len)は選びます。
GET_MAXSIZES( local, remote, TOS )
-> MMS_R, MMS_S
GET_MAXSIZES(地方の、そして、リモートなTOS)->MMS_R、MMS_S
CIP Working Group [Page 71] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[71ページ]RFC1190インターネットストリームプロトコル1990年10月
ADVISE_DELIVPROB( problem, local, remote, TOS )
-> result
ADVISE_DELIVPROB(問題、地方の、そして、リモートなTOS)->結果
SEND_ICMP( src, dst, TOS, TTL, BufPTR, len, Id, DF, opt )
-> result
SEND_ICMP(src、dst、TOS、TTL、BufPTR(len、Id、DF)は選ぶ)->結果
RECV_ICMP( BufPTR )
-> result, src, dst, len, opt
RECV_ICMP(BufPTR)->結果、src、dst、lenは選ばれます。
3.8.5. ST Layer Services Provided
3.8.5. 層のサービスは第提供されました。
Interface to the ST layer services may be modeled using a set
of subroutine calls (but need not be implemented as such).
When the protocol is implemented as part of an operating
system, these subroutines may be used directly by a higher
level protocol processing layer.
ST層のサービスへのインタフェースは、1セットのサブルーチン呼出し(しかし、そういうものとして実装される必要はない)を使用することでモデル化されるかもしれません。 プロトコルがオペレーティングシステムの一部として実装されるとき、これらのサブルーチンは直接より高い平らなプロトコル処理層によって使用されるかもしれません。
These subroutines might also be provided through system service
calls to provide a raw interface for use by an application.
Often, this will require further adaptation to conform with the
idiom of the particular operating system. For example, 4.3 BSD
UNIX (TM) provides sockets, ioctls and signals for network
programming.
また、アプリケーションで生のインタフェースを使用に提供するというシステム業務通話でこれらのサブルーチンを提供するかもしれません。 しばしば、これは、適合が特定のオペレーティングシステムの熟語に従うのをさらに必要とするでしょう。 例えば、4.3BSD UNIX(TM)はネットワーク・プログラミングのためのソケット、ioctls、および信号を提供します。
open( connect/listen, SAPBytes, local SAP, local host,
account, authentication info, < foreign host,
SAPBytes, foreign SAP, options >*, flow spec,
precedence, group name, optional parameters )
-> result, id, stream name, < foreign host,
foreign SAPBytes, foreign SAP, result, flow spec,
rname, optional parameters >*
開いている(接続するか、または聴いてください、SAPBytes、地方のSAP、ローカル・ホスト、アカウント、認証インフォメーション、<異種宿主、SAPBytes、外国SAP、オプション>*、流れ仕様、先行、グループ名、任意のパラメタ)->結果、イド、ストリーム名、<異種宿主、外国SAPBytes(外国SAP)は結果になります、流れ仕様、rname、任意のパラメタ>*
Note that an open by a target in "listen mode" may cause ST to
create a state block for the stream to facilitate rendezvous.
ストリームがランデブーを容易にするようにSTが「モードを聴いてください」の目標による戸外で州のブロックを作成するかもしれないことに注意してください。
add( id, SAPBytes, local SAP, local host, < foreign host,
SAPBytes, foreign SAP, options >*, flow spec,
precedence, group name, optional parameters )
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result,
flow spec, rname, optional parameters >*
->結果を加えてください(イド、SAPBytes、地方のSAP、ローカル・ホスト、<異種宿主、SAPBytes、外国SAP、オプション>*、流れ仕様、先行、グループ名、任意のパラメタ)、<異種宿主、外国SAPBytes、外国SAP、結果、流れ仕様、rname、任意のパラメタ>*
send( id, buffer address, byte count, priority )
-> result, next send time, burst send time
->結果を送ってください、そして、(イド、バッファアドレス、バイト・カウント、優先権)時間が次に発信して、炸裂は時間を送ります。
recv( id, buffer address, max byte count )
-> result, byte count
recv(イド、バッファアドレスはバイト・カウントに最大限にする)->結果、バイト・カウント
recvsignal( id )
-> result, signal, info
recvsignal(イド)->結果、信号、インフォメーション
CIP Working Group [Page 72] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[72ページ]RFC1190インターネットストリームプロトコル1990年10月
receivecontrol( id )
-> result, id, stream name, < foreign host,
foreign SAPBytes, foreign SAP, result, flow spec,
rname, optional parameters >*
receivecontrol(イド)->結果、イド、ストリーム名、<異種宿主、外国SAPBytes(外国SAP)は結果になります、流れ仕様、rname、任意のパラメタ>*
sendcontrol( id, flow spec, precedence, options,
< foreign host, SAPBytes, foreign SAP, options >*)
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result, flow spec, rname,
optional parameters >*
sendcontrol(イド、流れ仕様、先行、オプション、<異種宿主外国SAP、オプション>*(SAPBytes))->結果、<異種宿主、外国SAPBytes(外国SAP)は結果になります、流れ仕様、rname、任意のパラメタ>*
change( id, flow spec, precedence, options,
< foreign host, SAPBytes, foreign SAP, options >*)
-> result, < foreign host, foreign SAPBytes,
foreign SAP, result, flow spec, rname,
optional parameters >*
->結果を変えてください(イド、流れ仕様、先行、オプション、<異種宿主外国SAP、オプション>*(SAPBytes))、<異種宿主、外国SAPBytes、外国SAP、結果、流れ仕様、rname、任意のパラメタ>*
close( id, < foreign host, SAPBytes, foreign SAP >*,
optional parameters )
-> result
近い(イド、<異種宿主、SAPBytes、外国SAP>*、任意のパラメタ)->結果
status( id/stream name/group name )
-> result, account, group name, protocol,
< stream name, < foreign host, SAPbytes,
foreign SAP, state, options, flow spec,
routing info, rname >*, precedence, options >*
状態(イド/ストリーム名前/グループ名)->結果、アカウント、グループ名は議定書を作ります、<ストリーム名、<異種宿主、SAPbytes、外国SAP、状態、オプション、流れ仕様、ルーティングインフォメーション、rname>*、先行、オプション>*
creategroup( members* )
-> result, group name
creategroup(メンバー*)->結果、グループ名
deletegroup( group name, members* )
-> result
deletegroup(グループ名、メンバー*)->結果
CIP Working Group [Page 73] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[73ページ]RFC1190インターネットストリームプロトコル1990年10月
[This page intentionally left blank.]
[このページは故意に空白を出ました。]
CIP Working Group [Page 74] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[74ページ]RFC1190インターネットストリームプロトコル1990年10月
4. ST Protocol Data Unit Descriptions
4. データ単位記述について第議定書の中で述べてください。
The ST PDUs sent between ST agents consist of an ST Header ncapsulating either a higher layer PDU or an ST Control Message. Since ST operates as an extension of IP, the packet arrives at the same network service access point that IP uses to receive IP datagrams, e.g., ST would use the same ethertype (0x800) as does IP. The two types of packets are distinguished by the IP Version Number field (the first four bits of the packet); IP currently uses a value of 4, while ST has been assigned the value 5 [18]. There is no requirement for compatibility between IP and ST packet headers beyond the first four bits.
STエージェントの間に送られたST PDUsはST Header ncapsulatingから成ります。PDUの、より高い層かST Control Messageのどちらか。 STがIPの拡大として作動するので、パケットはIPがIPデータグラムを受け取るのに使用するのと同じネットワークサービスアクセスポイントに到着します、例えば、STがIPのように同じethertype(0×800)を使用するでしょう。 IPバージョンNumber分野(パケットの最初の4ビット)によって2つのタイプのパケットは区別されます。 IPは現在、4の値を使用しますが、値5の[18]はSTに割り当てられました。 IPとSTパケットのヘッダーとの互換性のための要件は全く最初の4ビットを超えていません。
The ST Header also includes an ST Version Number, a total length field, a header checksum, and a HID, as shown in Figure 21. See Appendix 1 (page 147) for an explanation of the notation.
また、ST HeaderはSTバージョンNumber、全長分野、ヘッダーチェックサム、およびHIDを含んでいます、図21に示されるように。 記法の説明に関してAppendix1(147ページ)を見てください。
ST is the IP Version Number assigned to identify ST packets. The
value for ST is 5.
STはSTパケットを特定するために割り当てられたIPバージョンNumberです。 STのための値は5です。
Ver is the ST Version Number. This document defines ST Version 2.
VerはSTバージョンNumberです。 このドキュメントはSTバージョン2を定義します。
Pri is the priority of the packet. It is used in data packets to
indicate those packets to drop if a stream is exceeding its
allocation. Zero is the lowest priority and 7 the highest.
Priはパケットの優先権です。 ストリームが配分を超えているなら、それは、低下するためにそれらのパケットを示すのにデータ・パケットで使用されます。 ゼロは、最も高く最も低い優先度と7です。
T (bit 11) is used to indicate that a Timestamp is present
following the ST Header but before any next higher layer protocol
data. The Timestamp is not permitted on ST Control Messages
(which may use the OriginTimestamp option).
T(ビット11)は、ST Headerにもかかわらず、次のいずれの前により高い層のプロトコルデータに従って、Timestampが存在しているのを示すのに使用されます。 TimestampはST Control Messages(OriginTimestampオプションを使用するかもしれない)で受入れられません。
Bits 12 through 15 are spares and should be set to 0.
ビット12〜15は、予備であり、0に設定されるべきです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ST=5 | Ver=2 | Pri |T| Bits | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HID | HeaderChecksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 第=5| Ver=2| Pri|T| ビット| TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 隠れました。| HeaderChecksum| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- Timestamp -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +タイムスタンプ-+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21. ST Header
図21。 第ヘッダー
CIP Working Group [Page 75] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[75ページ]RFC1190インターネットストリームプロトコル1990年10月
TotalBytes is the length, in bytes, of the entire ST packet, it
includes the ST Header and optional Timestamp but does not include
any local network headers or trailers. In general, all length
fields in the ST Protocol are in units of bytes.
TotalBytesは長さです、バイトで全体のSTパケットでは、それがST Headerと任意のTimestampを含んでいますが、どんな企業内情報通信網ヘッダーやトレーラも含んでいません。 一般に、STプロトコルのすべての長さの分野がユニットのバイトであります。
HID is the 16-bit hop-by-hop stream identifier. It is an
abbreviation for the Name of the stream and is used both to reduce
the packet header length and, by the receiver of the data packet,
to make the forwarding function more efficient. Control Messages
have a HID value of zero. HIDs are negotiated by the next-hop and
previous-hop agents to make the abbreviation unique. It is used
here in the ST Header and in various Control Messages. HID values
1-3 are reserved for future use.
HIDはホップごとの16ビットのストリーム識別子です。 それは、ストリームのNameのための略語であり、ともにパケットヘッダ長を減少させるのに使用されます、そして、データ・パケットの受信機で、推進をするのは、より効率的な状態で機能します。 コントロールMessagesには、ゼロのHID値があります。 HIDsは、略語をユニークにするように次のホップと前のホップエージェントによって交渉されます。 それはここ、ST Headerと様々なControl Messagesで使用されます。 HID値1-3は今後の使用のために予約されます。
HeaderChecksum covers only the ST Header and Timestamp, if
present. The ST Protocol uses 16-bit checksums here in the ST
Header and in each Control Message. The standard Internet
checksum algorithm is used: "The checksum field is the 16-bit
one's complement of the one's complement sum of all 16-bit words
in the header. For purposes of computing the checksum, the value
of the checksum field is zero." See [1] [12] [15] for suggestions
for efficient checksum algorithms.
存在しているなら、HeaderChecksumはST HeaderとTimestampだけをカバーしています。 STプロトコルはここ、ST Headerと各Control Messageで16ビットのチェックサムを使用します。 標準のインターネットチェックサムアルゴリズムは使用されています: 「チェックサム分野はヘッダーでのすべての16ビットの単語の1の補数合計の16ビットの1の補数です。」 「チェックサムを計算する目的のために、チェックサム分野の値はゼロです。」 効率的なチェックサムアルゴリズムのための提案のための[1][12][15]を見てください。
Timestamp is an optional timestamp inserted into data packets by
the origin. It is only present when the T bit, described above,
is set (1). Its use is negotiated at connection setup time; see
Sections 4.2.3.5 (page 108) and 4.2.3.1 (page 100). The Timestamp
has the NTP format; see [13].
タイムスタンプは発生源によってデータ・パケットに挿入された任意のタイムスタンプです。 上で説明されたTビットがセット(1)であるときにだけ、それは存在しています。 使用は接続準備時間に交渉されます。 セクション4.2.3を見てください、.5、(108と)4.2ページ .3 .1 (100ページ。) Timestampには、NTP形式があります。 [13]を見てください。
4.1. Data Packets
4.1. データ・パケット
ST packets whose HID is not zero to three are user data packets.
Their interpretation is a matter for the higher layer protocols
and consequently is not specified here. The data packets are not
protected by an ST checksum and will be delivered to the higher
layer protocol even with errors.
HIDがゼロ〜3でないSTパケットはユーザデータ・パケットです。 彼らの解釈は、より高い層のプロトコルのための問題であり、その結果、ここで指定されません。 データ・パケットは、STチェックサムによって保護されないで、誤りがあっても、より高い層のプロトコルに提供されるでしょう。
ST agents will not pass data packets over a new hop whose setup is
not complete, i.e., a HID must have been negotiated and either an
ACCEPT or REFUSE has been received for all targets specified in
the CONNECT.
STエージェントはセットアップが完全です、すなわち、HIDを交渉したに違いなくて、CONNECTで指定されたすべての目標のためにACCEPTかREFUSEのどちらかを受け取ったということでない新しいホップの上にデータ・パケットを通過しないでしょう。
CIP Working Group [Page 76] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[76ページ]RFC1190インターネットストリームプロトコル1990年10月
4.2. ST Control Message Protocol Descriptions
4.2. メッセージプロトコル記述を第制御してください。
ST Control Messages are between a previous-hop agent and its
next-hop agent(s) using a HID of zero. The control protocol
follows a request-response model with all requests expecting
responses. Retransmission after timeout (see Section 3.7.6 (page
66)) is used to allow for lost or ignored messages. Control
messages do not extend across packet boundaries; if a control
message is too large for the MTU of a hop, its information
(usually a TargetList) is partitioned and a control message per
partition is sent. All control messages have the following
format:
前のホップエージェントとその次のホップエージェントの間には、ST Control Messagesが、ゼロのHIDを使用することであります。 制御プロトコルは、応答を予想しながら、すべての要求で要求応答モデルに従います。 タイムアウト(セクション3.7.6(66ページ)を見る)が考慮するのにおいて使用されていた後に、Retransmissionはメッセージを失ったか、または無視しました。 コントロールメッセージはパケット境界に達しません。 ホップのMTUには、コントロールメッセージが大き過ぎるなら、情報(通常TargetList)を仕切ります、そして、1パーティションあたり1つのコントロールメッセージを送ります。 すべてのコントロールメッセージには、以下の形式があります:
OpCode identifies the type of control message. Each is
described in detail in following sections.
OpCodeはコントロールメッセージのタイプを特定します。 それぞれが以下の章で詳細に説明されます。
Options is used to convey OpCode-specific variations for a
control message.
オプションは、コントロールメッセージのためにOpCode特有の変化を伝えるのに使用されます。
TotalBytes is the length of the control message, in bytes,
including all OpCode specific fields and optional parameters.
The value is always divisible by four.
TotalBytesはすべてのOpCodeの特定の分野と任意のパラメタを含むバイトで表現されるコントロールメッセージの長さです。 値はいつも4で分割可能です。
RVLId is used to convey the Virtual Link Identifier of the
receiver of the control message, when known, or zero in the
case of an initial CONNECT or diagnostic message. The RVLId is
intended to permit efficient dispatch to the portion of a
stream's state machine containing information about a specific
operation in progress over the link. RVLId values 1-3 are
reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).
RVLIdは、初期のCONNECTか診断メッセージの場合でコントロールメッセージ、知られているいつか、またはゼロの受信機のVirtual Link Identifierを運ぶのに使用されます。 RVLIdがリンクの上の進行中の特定の操作の情報を含むストリームの州のマシンの一部に効率的な発信を可能にすることを意図します。 RVLId値1-3は予約されています。 セクション3(17ページ)と3.7を見てください。.1 .2(49ページ)。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Options | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
: OpCode Specific Data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode| オプション| TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId| SVLId| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+ : OpCodeの特定のデータ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22. ST Control Message Format
図22。 メッセージ・フォーマットを第制御してください。
CIP Working Group [Page 77] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[77ページ]RFC1190インターネットストリームプロトコル1990年10月
SVLId is used to convey the Virtual Link Identifier of the
sender of the control message. Except for ERROR-IN-REQUEST and
diagnostic messages, it must never be zero. SVLId values 1-3
are reserved; see Sections 3 (page 17) and 3.7.1.2 (page 49).
SVLIdは、コントロールメッセージの送付者のVirtual Link Identifierを運ぶのに使用されます。 ERROR IN REQUESTと診断メッセージ以外の、それは決してゼロでないに違いありません。 SVLId値1-3は予約されています。 セクション3(17ページ)と3.7を見てください。.1 .2(49ページ)。
Reference is a transaction number. Each sender of a request
control message assigns a Reference number to the message that
is unique with respect to the stream. The Reference number is
used by the receiver to detect and discard duplicates. Each
acknowledgment carries the Reference number of the request
being acknowledged. Reference zero is never used, and
Reference numbers are assumed to be monotonically increasing
with wraparound so that the older-than and more-recent-than
relations are well defined.
参照はトランザクション番号です。 要求コントロールメッセージの各送付者はストリームに関してユニークなメッセージにReference番号を割り当てます。 写しをReference番号は受信機によって使用されて、検出して、捨てます。 承認されていて、各承認は要求のReference番号を運びます。 そして、参照ゼロが決して使用されないで、Reference番号が巻きつけて着るドレスでそうを単調に増強するのが、それであったなら想定される、旧、-、 より最近、関係はよく定義されます。
LnkReference contains the Reference field of the request
control message that caused this request control message to be
created. It is used in situations where a single request leads
to multiple "responses". Examples are CONNECT and CHANGE
messages that must be acknowledged hop-by-hop and will also
lead to an ACCEPT or REFUSE from each target in the TargetList.
LnkReferenceはこの作成されるべき要求コントロールメッセージを引き起こした要求コントロールメッセージのReference分野を含んでいます。 それはただ一つの要求が複数の「応答」に通じる状況で使用されます。 例がCONNECTであり、承認しなければならないCHANGEメッセージは、ホップで跳んで、また、TargetListの各目標からACCEPTかREFUSEに通じるでしょう。
SenderIPAddress is the 32-bit IP address of the network
interface that the ST agent used to send the control message.
This value changes each time the packet is forwarded by an ST
agent (hop-by-hop).
SenderIPAddressはSTエージェントがコントロールメッセージを送るのに使用したネットワーク・インターフェースの32ビットのIPアドレスです。 パケットがSTエージェントによって進められるたびに(ホップで、跳んでください)この値は変化します。
Checksum is the checksum of the control message. Because the
control messages are sent in packets that may be delivered with
bits in error, each control message must be checked before it
is acted upon; see Section 4 (page 76).
チェックサムはコントロールメッセージのチェックサムです。 ビットが間違っていた状態で提供されるかもしれないパケットでコントロールメッセージを送るので、それが作用される前に、それぞれのコントロールメッセージをチェックしなければなりません。 セクション4(76ページ)を見てください。
OpCode Specific Data contains any additional information that
is associated with the control message. It depends on the
specific control message and is explained further below. In
some response control messages, fields of zero are included to
allow the format to match that of the corresponding request
message. The OpCode Specific Data may also contain any of the
optional Parameters defined in Section 4.2.2 (page 80).
OpCode Specific Dataはコントロールメッセージに関連しているどんな追加情報も含んでいます。 それは、特定のコントロールメッセージによって、以下でさらに説明されます。 いくつかの応答制御メッセージでは、ゼロの分野は、形式が対応する要求メッセージのものに合っているのを許容するために含まれています。 また、OpCode Specific Dataはセクション4.2.2(80ページ)で定義された任意のParametersのいずれも含むかもしれません。
CIP Working Group [Page 78] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[78ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.1. ST Control Messages
4.2.1. メッセージを第制御してください。
The CONNECT and CHANGE messages are used to establish or modify
branches in the stream. They propagate in the direction from
the origin toward the targets. They are end-to-end messages
created by the origin. They propagate all the way to the
targets, and require ERROR-IN-REQUEST, ACK, HID-REJECT, HID-
APPROVE, ACCEPT, or REFUSE messages in response. The CONNECT
message is the stream setup message. The CHANGE message is
used to change the characteristics of an established stream.
The CONNECT message is also used to add one or more targets to
an existing stream and during recovery of a broken stream.
Both messages have a TargetList parameter and are processed
similarly.
CONNECTとCHANGEメッセージは、流れでブランチを設立するか、または変更するのに使用されます。 彼らは目標に向かった起源からの方向に伝播します。 それらは終わりから終わりへの起源によって作成されたメッセージです。 彼らは、いっぱいに目標に伝播して、応答でERROR IN REQUEST、ACK、HID-REJECT、HID- APPROVE、ACCEPT、またはREFUSEメッセージを必要とします。 CONNECTメッセージは流れのセットアップメッセージです。 CHANGEメッセージは、確立した流れの特性を変えるのに使用されます。 また、CONNECTメッセージは、既存の流れと中断した流れの回収の間、1個以上の目標を加えるのに使用されます。 両方のメッセージは、TargetListパラメタを持って、同様に処理されます。
The DISCONNECT message is used to tear down streams or parts of
streams. It propagates in the direction from the origin toward
the targets. It is either used as an end-to-end message
generated by the origin that is used to completely tear down a
stream, or is generated by an intermediate ST agent that
preempts a stream or detects the failure of its previous-hop
agent or network in the stream. In the latter case, it is used
to tear down the part of the stream from the failure to the
targets, thus the message propagates all the way to the
targets.
DISCONNECTメッセージは、流れか流れの一部分を取りこわすのに使用されます。それは目標に向かった起源からの方向に伝播されます。 それは、終わりから終わりへの流れを完全に取りこわすのに使用される起源で発生するメッセージとして使用されるか、または流れを先取りするか、または流れでその前のホップエージェントかネットワークの失敗を検出する中間的STエージェントによって発生します。 後者の場合では、それは失敗から目標までの流れの一部分を取りこわすのに使用されます、その結果、メッセージが目標までのいっぱいに伝播されます。
The REFUSE message is sent by a target to refuse to join or
remove itself from a stream; in these cases, it is an end-to-
end message. An intermediate ST agent issues a REFUSE if it
cannot find a route to a target, can only find a route to a
target through the previous-hop, preempts a stream, or detects
a failure in a next-hop ST agent or network. In all cases a
REFUSE propagates in the direction toward the origin.
目標でREFUSEメッセージを送って、流れからそれ自体を接合するか、または取り除くのを拒否します。 これらの場合では、それは終わりから終わりへのメッセージです。 次のホップSTエージェントかネットワークで目標にルートを見つけることができないか、前のホップを通して目標にルートを見つけることができるだけであるか、流れを先取りするか、または失敗を検出するなら、中間的STエージェントはREFUSEを発行します。 すべての場合では、REFUSEは起源に向かった方向に伝播します。
The ACCEPT message is an end-to-end message generated by a
target and is used to signify the successful completion of the
setup of a stream or part of a stream, or the change of the
FlowSpec. There are no other messages that are similar to it.
ACCEPTメッセージは、終わりから終わりへの目標で発生するメッセージであり、流れのセットアップの無事終了、流れの一部、またはFlowSpecの変化を意味するのに使用されます。 それと同様の他のどんなメッセージもありません。
The following sections contain descriptions of common fields
and parameters, followed by descriptions of the individual
control messages, both listed in alphabetical order. A brief
description of the use of the control message is given. The
packet format is shown graphically.
以下のセクションは共同耕地の記述を含みます、そして、パラメタはともにアルファベット順にリストアップされました、続いて、個々のコントロールメッセージの記述をリストアップします。 コントロールメッセージの使用の簡単な説明を与えます。 パケット・フォーマットはグラフィカルに示されます。
CIP Working Group [Page 79] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[79ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.2. Common SCMP Elements
4.2.2. 一般的なSCMP Elements
Several fields and parameters (referred to generically as
"elements") are common to two or more PDUs. They are described
in detail here instead of repeating their description several
times. In many cases, the presence of a parameter is optional.
To permit the parameters to be easily defined and parsed, each
is identified with a PCode byte that is followed by a PBytes
byte indicating the length of the parameter in bytes (including
the PCode, PByte, and any padding bytes). If the length of the
information is not a multiple of 4 bytes, the parameter is
padded with one to three zero (0) bytes. PBytes is thus always
a multiple of four. Parameters can be present in any order.
いくつかの分野とパラメタ(一般的に「要素」に言及される)は2PDUsに共通です。 何度か彼らの記述を繰り返すことの代わりにそれらはここで詳細に説明されます。 多くの場合、パラメタの存在は任意です。 パラメタが容易に定義されて、分析されることを許可するために、それぞれがバイトで表現されるパラメタの長さを示すPBytesバイトがあとに続くPCodeバイトと同一視されています(PCode、PByte、およびどんな詰め物バイトも含んでいて)。 情報の長さが4バイトの倍数でないなら、パラメタは1〜3ゼロ(0)バイトで水増しされます。 その結果、いつもPBytesは4の倍数です。 パラメタは順不同に存在している場合があります。
4.2.2.1. DetectorIPAddress
4.2.2.1. DetectorIPAddress
Several control messages contain the DetectorIPAddress
field. It is used to identify the agent that caused the
first instance of the message to be generated, i.e., before
it was propagated. It is copied from the received message
into the copy of the message that is to be propagated to a
previous-hop or next-hop. It use is primarily diagnostic.
いくつかのコントロールメッセージがDetectorIPAddress分野を含んでいます。 それは発生するべきメッセージの最初の例を引き起こしたエージェントを特定するのに使用されます、すなわち、それが伝播される前に。 それは受信されたメッセージから前のホップか次のホップに伝播されることになっているメッセージのコピーにコピーされます。 それ、使用は主として診断しています。
4.2.2.2. ErroredPDU
4.2.2.2. ErroredPDU
The ErroredPDU parameter (PCode = 1) is used for diagnostic
purposes to encapsulate a received ST PDU that contained an
error. It may be included in the ERROR-IN-REQUEST, ERROR-
IN-RESPONSE, or REFUSE messages. It use is primarily
diagnostic.
ErroredPDUパラメタ(PCode=1)は、誤りを含んだ容認されたST PDUを要約するのに診断目的で使用されます。 それはERROR IN REQUEST、ERROR IN-RESPONSE、またはREFUSEメッセージに含まれるかもしれません。 それ、使用は主として診断しています。
PDUBytes indicates how many bytes of the PDUInError are
actually present.
PDUBytesは、PDUInErrorのいくつのバイトが実際に存在しているかを示します。
ErrorOffset contains the number of bytes into the errored
PDU to the field containing the error. At least as much
of the PDU in error must be included to
ErrorOffsetは誤りを含む分野へのerrored PDUにバイト数を含んでいます。 少なくとも誤りにおける、PDUの同じくらい多くを含まなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 1 | PBytes | PDUBytes | ErrorOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PDUInError : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=1| PBytes| PDUBytes| ErrorOffset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PDUInError: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23. ErroredPDU
図23。 ErroredPDU
CIP Working Group [Page 80] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[80ページ]RFC1190インターネット流れのプロトコル1990年10月
include the field or parameter identified by ErrorOffset;
an ErrorOffset of zero would imply a problem with the IP
Version Number or ST Version Number fields.
ErrorOffsetによって特定された分野かパラメタを含めてください。 ゼロのErrorOffsetはIPバージョンNumberかSTバージョンNumber分野に関する問題を含意するでしょう。
PDUInError is the PDU in error, beginning with the ST
Header.
ST Headerと共に始まって、PDUInErrorは間違いPDUです。
4.2.2.3. FlowSpec & RFlowSpec
4.2.2.3. FlowSpec&RFlowSpec
The FlowSpec is used to convey stream service requirements
end-to-end. We expect that other versions of FlowSpec will
be needed in the future, which may or may not be subsets or
supersets of the version described here. PBytes will allow
new constraints to be added to the end without having to
simultaneously update all implementations in the field.
Implementations are expected to be able to process in a
graceful manner a Version 4 (or higher) structure that has
more elements than shown here.
FlowSpecは、流れのサービス要件の終わりから終わりを伝えるのに使用されます。 私たちは、FlowSpecの他のバージョンが未来に必要であると予想します。(ここで説明されたバージョンの部分集合か未来はスーパーセットであるかもしれません)。 PBytesは同時の終わりにそうする必要はなくてその分野でのすべての実現をアップデートするために加えられるという新しい規制を許すでしょう。 実現はここに示されるより多くの要素を持っている優しい物腰でバージョン4を処理できて(さらに高い)の構造であると予想されます。
The FlowSpec parameter (PCode = 2) is used in several
messages to convey the FlowSpec.
FlowSpecパラメタ(PCode=2)はFlowSpecを運ぶいくつかのメッセージで使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | PBytes | Version = 3 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DutyFactor | ErrorRate | Precedence | Reliability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tradeoffs | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnCost | LimitOnDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitOnPDUBytes | LimitOnPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinBytesXRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdMeanDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AccdDelayVariance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesPDUBytes | DesPDURate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode| PBytes| バージョン=3| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DutyFactor| ErrorRate| 先行| 信頼性| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 見返り| RecoveryTimeout| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LimitOnCost| LimitOnDelay| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LimitOnPDUBytes| LimitOnPDURate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinBytesXRate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AccdMeanDelay| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AccdDelayVariance| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DesPDUBytes| DesPDURate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24. FlowSpec & RFlowSpec
図24。 FlowSpec&RFlowSpec
CIP Working Group [Page 81] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[81ページ]RFC1190インターネット流れのプロトコル1990年10月
The RFlowSpec parameter (PCode = 12) is used in conjunction
with the FDx option to convey the FlowSpec that is to be
used in the reverse direction.
RFlowSpecパラメタ(PCode=12)は、反対の方向に使用されることになっているFlowSpecを運ぶのにFDxオプションに関連して使用されます。
Version identifies the version of the FlowSpec. Version
3 is defined here.
バージョンはFlowSpecのバージョンを特定します。 バージョン3はここで定義されます。
DutyFactor is the estimated proportion of the time that
the requested bandwidth will actually be in use. Zero is
taken to represent 256 and signify a duty factor of 1.
Other values are to be divided by 256 to yield the duty
factor.
DutyFactorは要求された帯域幅が実際に使用中になる現代のおよそ割合です。 256を表して、1に関するデューティファクタを意味するようにゼロを取ります。 他の値は256によって分割されて、デューティファクタをもたらすことです。
ErrorRate expresses the error rate as the negative
exponent of 10 in the error rate. One (1) represents a
bit error rate of 0.1 and 10 represents 0.0000000001.
ErrorRateは誤り率における、10の負の指数として誤り率を表します。 人(1)は0.1の誤り率を少し表します、そして、10は0.0000000001を表します。
Precedence is the precedence of the connection being
established. Zero represents the lowest precedence.
Note that non-zero values of this parameter should be
subject to authentication and authorization checks, which
are not specified here. In general, the distinction
between precedence and priority is that precedence
specifies streams that are permitted to take previously
committed resources from another stream, while priority
identifies those PDUs that a stream is most willing to
have dropped when the stream exceeds its guaranteed
limits.
先行は確立される接続の先行です。 ゼロは最も低い先行を表します。 このパラメタの非ゼロ値は認証と許可検査を受けることがあるべきであることに注意してください。(許可検査はここで指定されません)。 一般に、先行と優先権の区別は先行が別の流れから以前に遂行されたリソースを取ることが許可されている流れを指定するということです、流れが保証された限界を超えていると、優先権が流れが低下しても構わないと最も思っているそれらのPDUsを特定しますが。
Reliability is modified by each intervening ST agent as a
measure of the probability that a given offered data
packet will be forwarded and not dropped. Zero is taken
to represent 256 and signify a probability of 1. Other
values are to be divided by 256 to yield the probability.
信頼性は与えられた提供されたデータ・パケットが進められて、落とされないという確率の基準としてそれぞれの介入しているSTエージェントによって変更されます。 1の確率に256を表して、意味するようにゼロを取ります。 他の値は256によって分割されて、確率をもたらすことです。
Tradeoffs is incompletely defined at this time. Bits
currently specified are as follows:
見返りはこのとき、不完全に定義されます。 現在指定されているビットは以下の通りです:
The most significant bit in the field, bit 0 in the
Figure 24, when one (1) means that each ST agent must
"implement" all constraints in the FlowSpec even if
they are not shown in the figure, e.g., when the
FlowSpec has been extended. When zero (0), unknown
constraints may be ignored.
最も重要であるのはその分野で噛み付きました、図24のビット0、人(1)が、それらが図に示されないでもそれぞれのSTエージェントがFlowSpecでのすべての規制を「実行しなければならないこと」を意味すると、例えば、FlowSpecが広げられたとき。 (0)でないときに、未知の規制は無視されるかもしれません。
The second most significant bit in the field, bit 1,
when one (1) means that one or more constraints are
unknown and have been ignored. When zero (0), all
constraints are known and have been processed.
その分野における2番目の最上位ビット、ビット1、人(1)がいつそれを意味するか、そして、または、より多くの規制が、未知であり、無視されました。 (0)でないときに、すべての規制を、知られていて、処理してあります。
CIP Working Group [Page 82] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[82ページ]RFC1190インターネット流れのプロトコル1990年10月
The third most significant bit in the field, bit 2, is
used for RevChrg; see Section 3.6.5 (page 46).
その分野における3番目の最上位ビット(ビット2)はRevChrgに使用されます。 セクション3.6.5(46ページ)を見てください。
Other bits are currently unspecified, and should be
set to zero (0) by the origin ST agent and not changed
by other agents unless those agents know their
meaning.
それらのエージェントが彼らの意味を知らないなら、他のビットを現在、不特定であり、起源STエージェントで(0)のゼロを合わせるように設定して、他のエージェントは変えるべきではありません。
RecoveryTimeout specifies the nominal number of
milliseconds that the application is willing to wait for
a failed system component to be detected and any
corrective action to be taken.
検出されるべき失敗したシステムの部品とどんな修正措置も取られるのを待つことを望んでいた状態で、RecoveryTimeoutはアプリケーションがそうであるミリセカンドの名目上の数を指定します。
LimitOnCost specifies the maximum cost that the origin is
willing to expend. A value of zero indicates that the
application is not willing to incur any direct charges
for the resources used by the stream. The meaning of
non-zero values is left for further study.
LimitOnCostは起源が費やしても構わないと思っている最大の費用を指定します。 ゼロの値は、アプリケーションが運用資金のために流れでどんな直接料金も被ることを望んでいないのを示します。 非ゼロ値の意味はさらなる研究に発たれます。
LimitOnDelay specifies the maximum end-to-end delay, in
milliseconds, that can be tolerated by the origin.
LimitOnDelayは終わりから終わりへのミリセカンドの起源で許容できる最大の遅れを指定します。
LimitOnPDUBytes is the smallest packet size, in terms of
ST-user data bytes, that can be tolerated by the origin.
LimitOnPDUBytesはST-利用者データバイトに関する起源で許容できる中で最も小さいパケットサイズです。
LimitOnPDURate is the lowest packet rate that can be
tolerated by the origin, expressed as tenths of a packet
per second.
LimitOnPDURateは1秒あたり1つのパケットの10分の1として言い表された起源で許容できる中で最も低いパケットレートです。
MinBytesXRate is the minimum bandwidth that can be
tolerated by the origin, expressed as a product of bytes
and tenths of a packet per second.
MinBytesXRateはバイトの製品と1秒あたり1つのパケットの10分の1として言い表された起源で許容できる最小の帯域幅です。
AccdMeanDelay is modified by each intervening ST agent.
This provides a means of reporting the total expected
delay, in milliseconds, for a data packet. Note that it
is implicitly assumed that the requested mean delay is
zero and there is no limit on the mean delay, so there
are no parameters to specify these explicitly.
AccdMeanDelayはそれぞれの介入しているSTエージェントによって変更されます。 これは合計がデータ・パケットのためにミリセカンドの遅れを予想したと報告する手段を提供します。 明らかにこれらを指定するためにパラメタが全くないように要求された意地悪な遅れがゼロであり、限界が全く意地悪な遅れにないとそれとなく思われることに注意してください。
AccdDelayVariance is also modified by each intervening ST
agent as a measure, in milliseconds squared, of the
packet dispersion. This quantity can be used by the
target or origin in determining whether the resulting
stream has an adequate quality of service to support the
application. Note that it is implicitly assumed that the
requested delay variance is zero and there is no limit on
the delay variance, so there are no parameters to specify
these explicitly.
また、AccdDelayVarianceは測定としてパケット分散について二乗されたミリセカンドでそれぞれの介入しているSTエージェントによって変更されます。 アプリケーションを支持するために結果として起こる流れには適切なサービスの質があるかどうか決定する際に目標か起源でこの量を使用できます。 明らかにこれらを指定するためにパラメタが全くないように要求された遅れ変化がゼロであり、限界が全く遅れ変化にないとそれとなく思われることに注意してください。
CIP Working Group [Page 83] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[83ページ]RFC1190インターネット流れのプロトコル1990年10月
DesPDUBytes is the desired PDU size in bytes. This is
not necessarily the same as the minimum necessary PDU
size. This value may be made smaller by intervening ST
agents so long as it is not made smaller than
LimitOnPDUBytes. The *PDUBytes limits measure the size
of the PDUs of next-higher protocol layer, i.e., the user
information contained in a data packet. An ST agent must
account for both the ST Header (including possible IP
encapsulation) and any local network headers and trailers
when comparing a network's MTU with *PDUBytes. In an
ACCEPT message, the value of this field will be no larger
than the MTU of the path to the specified target.
DesPDUBytesはバイトで表現される必要なPDUサイズです。 これは必ず最小の必要なPDUサイズと同じであるというわけではありません。 それをLimitOnPDUBytesより小さくしない限り、STエージェントに介入することによって、この値をより小さくするかもしれません。 *PDUBytes限界は次の、より高いプロトコル層(すなわち、データ・パケットに含まれたユーザー情報)のPDUsのサイズを測定します。 *PDUBytesとネットワークのMTUを比べるとき、STエージェントはどんなST Header(可能なIPカプセル化を含んでいる)と企業内情報通信網ヘッダーとトレーラの両方も原因にならなければなりません。 ACCEPTメッセージでは、この分野の値は経路のMTUほど指定された目標により大きくならないでしょう。
DesPDURate is the requested PDU rate, expressed as tenths
of a packet per second. This value may be made smaller
by intervening ST agents so long as it is not made
smaller than LimitOnPDURate.
DesPDURateは1秒あたり1つのパケットの10分の1として表された要求されたPDUレートです。 それをLimitOnPDURateより小さくしない限り、STエージェントに介入することによって、この値をより小さくするかもしれません。
It is expected that the next parameter to be added to the
FlowSpec will be a Burst Descriptor. This parameter will
describe the burstiness of the offered traffic. For
example, this may include the simple average rate, peak
rate and variance values, or more complete descriptions
that characterize the distribution of expected burst
rates and their expected duration. The nature of the
algorithms that deal with the traffic's burstiness and
the information that needs to be described by this
parameter will be subjects of further experimentation.
It is expected that a new FlowSpec with Version = 4 will
be defined that looks like Version 3 but has a Burst
Descriptor parameter appended to the end.
FlowSpecに加えられるべき次のパラメタがBurst Descriptorになると予想されます。 このパラメタは提供された交通のburstinessについて説明するでしょう。 例えば、これは予想された炸裂率とそれらの予想された持続時間の分配を特徴付ける単純平均率かピークレートと変化の値か、より完全な記述を含むかもしれません。 トラフィックのburstinessに対処するアルゴリズムとこのパラメタによって説明される必要がある情報の本質はさらなる実験の対象になるでしょう。 バージョン3に似ていますが、Burst Descriptorパラメタを終わりまで追加させるバージョンがある新しいFlowSpec=4が定義されると予想されます。
4.2.2.4. FreeHIDs
4.2.2.4. FreeHIDs
The FreeHIDs parameter (PCode = 3) is used to communicate to
the previous-hop suggestions for a HID. It consists of
BaseHID and FreeHIDBitMask fields. Experiments will
determine how long the mask should be for practical use of
this parameter. The parameter (if implemented) should be
included in all HID-REJECTs, and in HID-APPROVEs that are
linked to a multicast CONNECT, e.g., one containing the
MulticastAddress parameter.
FreeHIDsパラメタ(PCode=3)は、HIDのために前のホップ提案に交信するのに使用されます。 それはBaseHIDとFreeHIDBitMask分野から成ります。 実験は、このパラメタの実用には、マスクがどれくらい長いはずであるかを決定するでしょう。 パラメタ(実行されるなら)はすべてのHID-REJECTs、およびマルチキャストCONNECT(例えば、MulticastAddressパラメタを含む1つ)にリンクされるHID-APPROVEsに含まれるべきです。
BaseHID was the suggested value in a HID-CHANGE or
CONNECT. BaseHID is chosen to be the suggested HID value
to insure that the masks from multiple FreeHIDs
parameters will overlap.
BaseHIDはHID-CHANGEかCONNECTの提案された値でした。 BaseHIDは、保障する複数のFreeHIDsパラメタからのマスクが重ね合わせる提案されたHID値になるように選ばれています。
FreeHIDBitMask identifies available HID values as
follows. Bit 0 in the FreeHIDBitMask corresponds to a
FreeHIDBitMaskは以下の利用可能なHID値を特定します。 FreeHIDBitMaskのビット0はaに対応しています。
CIP Working Group [Page 84] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[84ページ]RFC1190インターネット流れのプロトコル1990年10月
HID with a value equal to BaseHID with the 5 least
significant bits set to zero, bit 1 corresponds to that
value + 1, etc. This alignment of the mask on a 32-bit
boundary is used so that masks from several FreeHIDs
parameters might more easily be combined using a bit-wise
AND function to find a free HID.
ゼロに設定された5つの最下位ビットについてBaseHIDと等しい値があるHID、ビット1はその値+1つなどに対応しています。 32ビットの境界におけるマスクのこの整列は、自由なHIDを見つけるのに少し的にAND機能を使用することで、より容易にいくつかのFreeHIDsパラメタからのマスクを結合できるように使用されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 3 | 4+4*N | BaseHID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FreeHIDBitMask :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=3| 4+4*N| BaseHID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FreeHIDBitMask: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25. FreeHIDs
図25。 FreeHIDs
4.2.2.5. Group & RGroup
4.2.2.5. グループとRGroup
The Group parameter (PCode = 4) is an optional argument
used only for the creation of a stream. This parameter
contains a GroupName; the GroupName may be the same as the
Name of one of the group's streams. In addition, there
may be some number of <SubGroupId, Relation> tuples that
describe the meaning of the grouping and the relation
between the members of the group. The forms of grouping
are for further study.
Groupパラメタ(PCode=4)は流れの創造にだけ使用される任意の議論です。 このパラメタはGroupNameを含んでいます。 GroupNameはグループの流れの1つのNameと同じであるかもしれません。さらに、<SubGroupIdの何らかの数があるかもしれません、組分けの意味とグループのメンバーの関係について説明するRelation>tuples。 さらなる研究には組分けのフォームがあります。
The RGroup parameter (PCode = 13) is an optional argument
used only for the creation of a stream in the reverse
direction that is a member of a Group; see the FDx
option, Section 3.6.3 (page 45). This parameter has the
same format as the Group parameter.
RGroupパラメタ(PCode=13)はGroupのメンバーである反対の方向への流れの創造にだけ使用される任意の議論です。 FDxオプション、セクション3.6.3(45ページ)を見てください。 このパラメタには、Groupパラメタと同じ形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12+4*N | !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+
! GroupName !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubGroupId | Relation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode| 12+4*N| ! +++++++++++++++++--+!GroupName!+++++++++++++++++++++++++++++++++| SubGroupId| 関係| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SubGroupId| 関係| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26. Group & RGroup
図26。 グループとRGroup
CIP Working Group [Page 85] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[85ページ]RFC1190インターネット流れのプロトコル1990年10月
A GroupName has the same format as a Name; see Figure 29.
GroupNameには、Nameと同じ形式があります。 図29を見てください。
4.2.2.6. HID & RHID
4.2.2.6. 隠す、RHID
The HID parameter (PCode = 5) is used in the NOTIFY message
when the notification is related to a HID, and possibly in
the STATUS-RESPONSE message to convey additional HIDs that
are valid for a stream when there are more than one. It
consists of the PCode and PBytes bytes prepended to a HID;
HIDs were described in Section 4 (page 76).
通知がHIDに関連するとき、HIDパラメタ(PCode=5)はNOTIFYメッセージで使用されます、そして、ことによると伝えるSTATUS-RESPONSEメッセージでは、そこであるのに流れに、有効な追加HIDsは1歳以上です。 それはHIDにprependedされたPCodeとPBytesバイトから成ります。 HIDsはセクション4(76ページ)で説明されました。
The RHID parameter (PCode = 14) is used in conjunction with
the FDx option to convey the HID that is to be used in the
reverse direction. It consists of the PCode and PBytes
bytes prepended to a HID.
RHIDパラメタ(PCode=14)は、反対の方向に使用されることになっているHIDを運ぶのにFDxオプションに関連して使用されます。 それはHIDにprependedされたPCodeとPBytesバイトから成ります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4 | HID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode| 4 | 隠れました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27. HID & RHID
図27。 隠す、RHID
4.2.2.7. MulticastAddress
4.2.2.7. MulticastAddress
The MulticastAddress parameter (PCode = 6) is an optional
parameter that is used, when setting up a network level
multicast group, to communicate an IP and/or local network
multicast address to the next-hop agents that should become
members of the group.
MulticastAddressパラメタ(PCode=6)はグループのメンバーになるべきである次のホップエージェントにIP、そして/または、企業内情報通信網マルチキャストアドレスを伝えるためにネットワークレベルマルチキャストグループを設立するとき使用された任意のパラメタです。
LocalNetBytes is the length of the Local Net Multicast
Address.
LocalNetBytesはLocalネットMulticast Addressの長さです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 6 | PBytes | LocalNetBytes | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Local Net Multicast Address : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=6| PBytes| LocalNetBytes| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPマルチキャストアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ローカルのネットのマルチキャストアドレス: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28. MulticastAddress
図28。 MulticastAddress
CIP Working Group [Page 86] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[86ページ]RFC1190インターネット流れのプロトコル1990年10月
IP Multicast Address is described in [6]. This field is
zero (0) if no IP multicast address is known or is
applicable. The block of addresses 224.1.0.0 -
224.1.255.255 has been allocated for use by ST.
IP Multicast Addressは[6]で説明されます。 (0) どんなIPマルチキャストアドレスも知られていなくて、また適切でないなら、この分野はゼロです。 ブロック、アドレス224.1.0では、.0--224.1に、.255が割り当てられた.255はSTを使用します。
Local Net Multicast Address is the multicast address to
be used on the local network. It corresponds to the IP
Multicast Address when the latter is non-zero.
地方のネットMulticast Addressは企業内情報通信網で使用されるべきマルチキャストアドレスです。 後者が非ゼロであるときに、それはIP Multicast Addressに対応しています。
4.2.2.8. Name & RName
4.2.2.8. 名前とRName
Each stream is uniquely (i.e., globally) identified by a
Name. A Name is created by the origin host ST agent and is
composed of 1) a 16-bit number chosen to make the Name
unique within the agent, 2) the IP address of the origin ST
agent, and 3) a 32-bit timestamp. If the origin has
multiple IP addresses, then any that can be used to reach
target may be used in the Name. The intent is that the
<Unique ID, IP Address> tuple be unique for the lifetime of
the stream. It is suggested that to increase robustness a
Unique ID value not be reused for a period of time on the
order of 5 minutes.
すなわち、各流れが唯一そうである、(グローバルに)、Nameによって特定されます。 2歳のエージェントの中でユニークなName) 起源STエージェント、および3の)IPアドレスを32ビットのタイムスタンプにするように選ばれて、Nameは起源ホストSTエージェントによって作成されて、16ビットの数あたり1で)構成されます。 複数のIPアドレスが起源にあるなら、目標に達するのに使用できるいずれもNameで使用されるかもしれません。 意図は<Unique ID、IP Address>tupleが流れの生涯ユニークであるということです。 それが示される、それ、丈夫さa Unique ID価値を増加させるには、5分の注文ときにしばらく、再利用されないでください。
The Timestamp is included both to make the Name unique over
long intervals (e.g., forever) for purposes of network
management and accounting/billing, and to protect against
failure of an ST agent that causes knowledge of active
Unique IDs to be lost. The assumption is that all ST agents
have access to some "clock". If this is not the case, the
agent should have access to some form of non-volatile memory
in which it can store some number that at least gets
incremented per restart.
Timestampがともに長い間隔にわたってNameをユニークにするように含まれている、(例えば、いつまでも)、ネットワークマネージメントと会計/支払いの目的、STエージェントの失敗から守るために、それで、アクティブなUnique IDに関する知識を失います。 仮定はすべてのSTエージェントがいくつかの「時計」に近づく手段を持っているということです。 これがそうでないなら、エージェントはそれが再開単位で少なくとも増加される何らかの数を格納できる何らかのフォームに関する非揮発性メモリーに近づく手段を持つべきです。
The Name parameter (PCode = 7) is used in most control
messages to identify a stream.
Nameパラメタ(PCode=7)は流れを特定するほとんどのコントロールメッセージで使用されます。
The RName parameter (PCode = 15) is used in conjunction with
the FDx option to convey the Name of the reverse stream in
an ACCEPT message.
RNameパラメタ(PCode=15)は、ACCEPTメッセージにおける逆の流れのNameを運ぶのにFDxオプションに関連して使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 12 | Unique ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode| 12 | ユニークなID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29. Name & RName
図29。 名前とRName
CIP Working Group [Page 87] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[87ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.2.9. NextHopIPAddress
4.2.2.9. NextHopIPAddress
The NextHopIPAddress parameter (PCode = 8) is an optional
parameter of NOTIFY (RouteBack) or REFUSE (RouteInconsist or
RouteLoop) and contains the IP address of a suggested next-
hop ST agent.
NextHopIPAddressパラメタ(PCode=8)は、NOTIFY(RouteBack)かREFUSE(RouteInconsistかRouteLoop)の任意のパラメタであり、提案されたホップST次エージェントのIPアドレスを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 8 | 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=8| 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のホップIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30. NextHopIPAddress
図30。 NextHopIPAddress
4.2.2.10. Origin
4.2.2.10. 起源
The Origin parameter (PCode = 9) is used to identify the
origin of the stream, the next higher protocol, and the SAP
being used in conjunction with that protocol.
Originパラメタ(PCode=9)は、流れ、次の、より高いプロトコル、およびSAPの起源を特定するのにそのプロトコルに関連して使用されることで使用されます。
NextPcol is an 8-bit field used in demultiplexing
operations to identify the protocol to be used above ST.
The values of NextPcol are in the same number space as
the IP Header's Protocol field and are consequently
defined in the Assigned Numbers RFC [18].
NextPcolはSTの上で使用されるためにプロトコルを特定するのに逆多重化操作に使用される8ビットの分野です。NextPcolの値は、IP Headerのプロトコル分野と同じ数のスペースにあって、その結果、Assigned民数記RFC[18]で定義されます。
OriginSAPBytes specifies the length of the OriginSAP,
exclusive of any padding required to maintain 32-bit
alignment.
OriginSAPBytesは32ビットの整列を維持するのに必要である詰め物を除いてOriginSAPの長さを指定します。
OriginIPAddress is (one of) the IP address of the origin.
OriginIPAddressがそうである、(1つ、)、起源のIPアドレス。
OriginSAP identifies the origin's SAP associated with the
NextPcol protocol.
OriginSAPは起源のNextPcolプロトコルに関連しているSAPを特定します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 9 | PBytes | NextPcol |OriginSAPBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OriginSAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=9| PBytes| NextPcol|OriginSAPBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OriginIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : OriginSAP: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31. Origin
図31。 起源
CIP Working Group [Page 88] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[88ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.2.11. OriginTimestamp
4.2.2.11. OriginTimestamp
The OriginTimestamp parameter (PCode = 10) is used to
indicate the time at which the control message was sent.
OriginTimestampパラメタ(PCode=10)は、コントロールメッセージが送られた時を示すのに使用されます。
The units and format of the timestamp is that defined in the
NTP protocol specification [13]. Note that discontinuities
over leap seconds are expected.
タイムスタンプのユニットと形式はNTPプロトコル仕様[13]に基づきそんなに定義されています。 飛躍秒の上不連続が予想されることに注意してください。
Note that the time synchronization implied by the use of
such a parameter is the subject of systems management
functions not described in this memo, e.g., NTP.
そのようなパラメタの使用で含意された時間同期化がこのメモ(例えば、NTP)で説明されなかったシステム管理機能の対象であることに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 10 | 12 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Timestamp -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=10| 12 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +タイムスタンプ-+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32. OriginTimestamp
図32。 OriginTimestamp
4.2.2.12. ReasonCode
4.2.2.12. ReasonCode
Several errors may occur during protocol processing. All ST
error codes are taken from a single number space. The
currently defined values and their meaning is presented in
the list below. Note that new error codes may be defined
from time to time. All implementations are expected to
handle new codes in a graceful manner. If an unknown
ReasonCode is encountered, it should be assumed to be fatal.
いくつかの誤りがプロトコル処理の間、発生するかもしれません。 ただ一つの数のスペースからすべてのSTエラーコードを取ります。 現在定義された値とそれらの意味は以下のリストに提示されます。 新しいエラーコードが時々定義されるかもしれないことに注意してください。 すべての実装が優しい物腰で新法を扱うと予想されます。 未知のReasonCodeが遭遇するなら、致命的であると思われるべきです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33. ReasonCode
図33。 ReasonCode
CIP Working Group [Page 89] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[89ページ]RFC1190インターネットストリームプロトコル1990年10月
Name Value Meaning
---------------- ----- ---------------------------------------
名前値の意味---------------- ----- ---------------------------------------
AcceptTimeout 2 An Accept has not been
acknowledged.
AcceptTimeout2An Acceptは承認されていません。
AccessDenied 3 Access denied.
Accessが否定したAccessDenied3。
AckUnexpected 4 An unexpected ACK was received.
AckUnexpected4のAnの予期していなかったACKを受け取りました。
ApplAbort 5 The application aborted the stream
abnormally.
ApplAbort、5 アプリケーションは異常にストリームを中止しました。
ApplDisconnect 6 The application closed the stream
normally.
ApplDisconnect、6 通常、アプリケーションはストリームを閉じました。
AuthentFailed 7 The authentication function
failed.
認証機能が失敗したAuthentFailed7。
CantGetResrc 8 Unable to acquire (additional)
resources.
(追加する)のリソースを取得するCantGetResrc8Unable。
CantRelResrc 9 Unable to release excess
resources.
余分なリソースを発表するCantRelResrc9Unable。
CksumBadCtl 10 A received control PDU has a bad
message checksum.
CksumBadCtl10のA容認されたコントロールPDUには、悪いメッセージチェックサムがあります。
CksumBadST 11 A received PDU has a bad ST Header
checksum.
CksumBadST11のA容認されたPDUには、悪いST Headerチェックサムがあります。
DropExcdDly 12 A received PDU was dropped because
it could not be processed within
the delay specification.
DropExcdDly12のA容認されたPDUは、遅れ仕様の中でそれを処理できなかったので、下げられました。
DropExcdMTU 13 A received PDU was dropped because
its size exceeds the MTU.
サイズがMTUを超えているので、DropExcdMTU13のA容認されたPDUは下げられました。
DropFailAgt 14 A received PDU was dropped because
of a failed ST agent.
DropFailAgt14のA容認されたPDUは失敗したSTエージェントのために下げられました。
DropFailHst 15 A received PDU was dropped because
of a host failure.
DropFailHst15のA容認されたPDUはホスト障害のために下げられました。
DropFailIfc 16 A received PDU was dropped because
of a broken interface.
DropFailIfc16のA容認されたPDUは壊れているインタフェースのために下げられました。
DropFailNet 17 A received PDU was dropped because
of a network failure.
DropFailNet17のA容認されたPDUはネットワーク失敗のために下げられました。
CIP Working Group [Page 90] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[90ページ]RFC1190インターネットストリームプロトコル1990年10月
Name Value Meaning
---------------- ----- ---------------------------------------
名前値の意味---------------- ----- ---------------------------------------
DropLimits 18 A received PDU was dropped because
it exceeds the resource limits for
its stream.
ストリームのためにリソース限界を超えているので、DropLimits18のA容認されたPDUは下げられました。
DropNoResrc 19 A received PDU was dropped due to
no available resources (including
precedence).
DropNoResrc19のA容認されたPDUはどんな利用可能資源のためも下げられませんでした(先行を含んでいて)。
DropNoRoute 20 A received PDU was dropped because
of no available route.
DropNoRoute20のA容認されたPDUはどんな利用可能なルートのためにも下げられませんでした。
DropPriLow 21 A received PDU was dropped because
it has a priority too low to be
processed.
優先を処理できないくらい低くするので、DropPriLow21のA容認されたPDUは下げられました。
DuplicateIgn 22 A received control PDU is a
duplicate and is being
acknowledged.
DuplicateIgn22のA容認されたコントロールPDUは写しであり、承認していることにされます。
DuplicateTarget 23 A received control PDU contains a
duplicate target, or an attempt to
add an existing target.
DuplicateTarget23のA容認されたコントロールPDUは写し目標、または既存の目標を加える試みを含んでいます。
ErrorUnknown 1 An error not contained in this
list has been detected.
このリストに含まれなかったErrorUnknown1An誤りは検出されました。
failure N/A An abbreviation used in the text
for any of the more specific
errors: DropFailAgt, DropFailHst,
DropFailIfc, DropFailNet,
IntfcFailure, NetworkFailure,
STAgentFailure, FailureRecovery.
An略語が、より特定の誤りのいずれにもテキストで使用した失敗N/: DropFailAgt、DropFailHst、DropFailIfc、DropFailNet、IntfcFailure、NetworkFailure、STAgentFailure、FailureRecovery。
FailureRecovery 24 A notification that recovery is
being attempted.
回復が試みられているというFailureRecovery24A通知。
FlowVerBad 25 A received control PDU has a
FlowSpec Version Number that is
not supported.
FlowVerBad25のA容認されたコントロールPDUはサポートされないFlowSpecバージョンNumberを持っています。
GroupUnknown 26 A received control PDU contains an
unknown Group Name.
GroupUnknown26のA容認されたコントロールPDUは未知のGroup Nameを含んでいます。
HIDNegFails 28 HID negotiation failed.
HIDNegFails28HID交渉は失敗しました。
HIDUnknown 29 A received control PDU contains an
unknown HID.
HIDUnknown29のA容認されたコントロールPDUは未知のHIDを含んでいます。
CIP Working Group [Page 91] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[91ページ]RFC1190インターネットストリームプロトコル1990年10月
Name Value Meaning
---------------- ----- ---------------------------------------
名前値の意味---------------- ----- ---------------------------------------
InconsistHID 30 An inconsistency has been detected
with a stream Name and
corresponding HID.
InconsistHID30An矛盾はストリームNameと対応するHIDと共に検出されました。
InconsistGroup 31 An inconsistency has been detected
with the streams forming a group.
ストリームがグループを作っていて、InconsistGroup31An矛盾は検出されました。
IntfcFailure 32 A network interface failure has
been detected.
IntfcFailure32Aネットワーク・インターフェースの故障は検出されました。
InvalidHID 33 A received ST PDU contains an
invalid HID.
InvalidHID33のA容認されたST PDUは無効のHIDを含んでいます。
InvalidSender 34 A received control PDU has an
invalid SenderIPAddress field.
InvalidSender34のA容認されたコントロールPDUには、無効のSenderIPAddress分野があります。
InvalidTotByt 35 A received control PDU has an
invalid TotalBytes field.
InvalidTotByt35のA容認されたコントロールPDUには、無効のTotalBytes分野があります。
LnkRefUnknown 36 A received control PDU contains an
unknown LnkReference.
LnkRefUnknown36のA容認されたコントロールPDUは未知のLnkReferenceを含んでいます。
NameUnknown 37 A received control PDU contains an
unknown stream Name.
NameUnknown37のA容認されたコントロールPDUは未知のストリームNameを含んでいます。
NetworkFailure 38 A network failure has been
detected.
NetworkFailure38Aネットワークの故障は検出されました。
NoError 0 No error has occurred.
NoError0いいえ誤りは発生しました。
NoRouteToAgent 39 Cannot find a route to an ST
agent.
NoRouteToAgent39CannotはSTエージェントにとってルートを見つけます。
NoRouteToDest 40 Cannot find a route to the
destination.
NoRouteToDest40Cannotは目的地にルートを見つけます。
NoRouteToHost 41 Cannot find a route to a host.
NoRouteToHost41Cannotはホストにとってルートを見つけます。
NoRouteToNet 42 Cannot find a route to a network.
NoRouteToNet42Cannotはネットワークにおいてルートを見つけます。
OpCodeUnknown 43 A received control PDU has an
invalid OpCode field.
OpCodeUnknown43のA容認されたコントロールPDUには、無効のOpCode分野があります。
PCodeUnknown 44 A received control PDU has a
parameter with an invalid PCode.
PCodeUnknown44のA容認されたコントロールPDUには、無効のPCodeがあるパラメタがあります。
ParmValueBad 45 A received control PDU contains an
invalid parameter value.
ParmValueBad45のA容認されたコントロールPDUは無効のパラメタ値を含んでいます。
CIP Working Group [Page 92] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[92ページ]RFC1190インターネットストリームプロトコル1990年10月
Name Value Meaning
---------------- ----- ---------------------------------------
名前値の意味---------------- ----- ---------------------------------------
PcolIdUnknown 46 A received control PDU contains an
unknown next-higher layer protocol
identifier.
PcolIdUnknown46のA容認されたコントロールPDUは未知の次の、より高い層のプロトコル識別子を含んでいます。
ProtocolError 47 A protocol error was detected.
ProtocolError47Aプロトコル誤りは検出されました。
PTPError 48 Multiple targets were specified
for a stream created with the PTP
option.
PTPError48Multiple目標はPTPオプションで作成されたストリームに指定されました。
RefUnknown 49 A received control PDU contains an
unknown Reference.
RefUnknown49のA容認されたコントロールPDUは未知のReferenceを含んでいます。
RestartLocal 50 The local ST agent has recently
restarted.
地元のSTエージェントのRestartLocal50は最近、再開しました。
RemoteRestart 51 The remote ST agent has recently
restarted.
リモートSTエージェントのRemoteRestart51は最近、再開しました。
RetransTimeout 52 An acknowledgment to a control
message has not been received
after several retransmissions.
コントロールメッセージへのRetransTimeout52An承認は数個の「再-トランスミッション」の後に受けられていません。
RouteBack 53 The routing function indicates
that the route to the next-hop is
through the same interface as the
previous-hop and is not the
previous-hop.
前のホップではなく、経路選択機能が示す次のホップへのルートは前のホップと同じインタフェースを通してあって、あるRouteBack53。
RouteInconsist 54 A routing inconsistency has been
detected, e.g., a route loop.
RouteInconsist54Aルーティング矛盾は検出されて、例えば、ルートは輪です。
RouteLoop 55 A CONNECT was received that
specified an existing target.
既存の目標を指定したRouteLoop55A CONNECTを受け取りました。
SAPUnknown 56 A received control PDU contains an
unknown next-higher layer SAP
(port).
SAPUnknown56のA容認されたコントロールPDUはSAP(ポート)の未知の次の、より高い層を含んでいます。
STAgentFailure 57 An ST agent failure has been
detected.
STAgentFailure57An STエージェントの故障は検出されました。
StreamExists 58 A stream with the given Name or
HID already exists.
与えられたNameかHIDがあるStreamExists58Aストリームは既に存在しています。
StreamPreempted 59 The stream has been preempted by
one with a higher precedence.
StreamPreempted、59 ストリームは1時までに、より高い先行で先取りされました。
CIP Working Group [Page 93] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[93ページ]RFC1190インターネットストリームプロトコル1990年10月
Name Value Meaning
---------------- ----- ---------------------------------------
名前値の意味---------------- ----- ---------------------------------------
STVerBad 60 A received PDU is not ST Version
2.
STVerBad60のA容認されたPDUはSTバージョン2ではありません。
TooManyHIDs 61 Attempt to add more HIDs to a
stream than the implementation
supports.
実装がサポートするより多くのHIDsをストリームに加えるTooManyHIDs61Attempt。
TruncatedCtl 62 A received control PDU is shorter
than expected.
TruncatedCtl62のA容認されたコントロールPDUは予想より短いです。
TruncatedPDU 63 A received ST PDU is shorter than
the ST Header indicates.
TruncatedPDU63のA容認されたST PDUはST Headerが示すより短いです。
UserDataSize 64 The UserData parameter is too
large to permit a control message
to fit into a network's MTU.
UserDataパラメタが大き過ぎるUserDataSize64はネットワークのMTUに収まるコントロールメッセージを可能にします。
4.2.2.13. RecordRoute
4.2.2.13. RecordRoute
The RecordRoute parameter (PCode = 11) may be used to
request that the route between the origin and a target be
recorded and returned to the agent specified in the
DetectorIPAddress field.
RecordRouteパラメタ(PCode=11)は、発生源と目標の間のルートがDetectorIPAddress分野で指定されたエージェントに記録されて、返されるよう要求するのに使用されるかもしれません。
FreeOffset is the offset to the position where the next
next-hop IP address should be inserted. It is initialized
to four (4) and incremented by four each time an agent
inserts its IP address.
FreeOffsetは次の次のホップIPアドレスが挿入されるべきである位置へのオフセットです。 それは、4(4)に初期化されて、エージェントがIPアドレスを挿入するたびに4つ増加されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 11 | PBytes | 0 | FreeOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=11| PBytes| 0 | FreeOffset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のホップIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のホップIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34. RecordRoute
図34。 RecordRoute
CIP Working Group [Page 94] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[94ページ]RFC1190インターネットストリームプロトコル1990年10月
4.2.2.14. SrcRoute
4.2.2.14. SrcRoute
The SrcRoute parameter is used, in the Target structure
shown in Figure 36, to specify the IP addresses of the ST
agents through which the stream to the target should pass.
There are two forms of the option, distinguished by the
PCode.
SrcRouteパラメタは、目標への小川が通るはずであるSTエージェントのIPアドレスを指定するのに図36のTarget構造で使用されます。 PCodeによって区別されたオプションの2つのフォームがあります。
With loose source route (PCode = 18) each ST agent first
examines the first next-hop IP address in the option. If
the address is (one of) the address of the current ST agent,
that entry is removed, and the PBytes field reduced by four
(4). If the resulting PBytes field contains 4 (i.e., there
are no more next-hop IP addresses) the parameter is removed
from the Target. In either case, the Target's TargetBytes
field and the TargetList's PBytes field must be reduced
accordingly. The ST agent then routes toward the first
next-hop IP address in the option, if one exists, or toward
the target otherwise. Note that the target's IP address is
not included as the last entry in the list.
ゆるい送信元経路(PCode=18)で、それぞれのSTエージェントは最初に、オプションにおける最初の次のホップIPアドレスを調べます。 アドレスがそうである、(1つ、)、現在のSTエージェントのアドレス、そのエントリーを取り除いて、PBytes分野は4(4)で減少しました。 結果として起こるPBytes分野が4を含んでいるなら(すなわち、それ以上の次のホップIPアドレスが全くありません)、パラメタはTargetから取り除かれます。 どちらの場合ではも、TargetのTargetBytes分野とTargetListのPBytes分野はそれに従って、減少しなければなりません。 そうでなければ、最初の次のホップIPに向かった当時のルートが1であるならオプションで演説するSTエージェントは、存在しているか、または目標に向かってそうします。 目標のIPアドレスがリストにおける最後のエントリーとして含まれていないことに注意してください。
With a strict source route (PCode = 19) each ST agent first
examines the first next-hop IP address in the option. If
the address is not (one of) the address of the current ST
agent, a routing error has occurred and should be reported
with the appropriate reason code. Otherwise that entry is
removed, and the PBytes field reduced by four (4). If the
resulting PBytes field contains 4 (i.e., there are no more
next-hop IP addresses) the parameter is removed from the
Target. In either case, the Target's TargetBytes field and
the TargetList's PBytes field must be reduced accordingly.
The ST agent then routes toward the first next-hop IP
address in the option, if one exists, or toward the target
otherwise. Note that the target's IP address is not
included as the last entry in the list.
厳しい送信元経路(PCode=19)で、それぞれのSTエージェントは最初に、オプションにおける最初の次のホップIPアドレスを調べます。 アドレスがそうでない、(1つ、)、現在のSTエージェントのアドレス、ルーティング誤りは、起こって、適切な理由コードで報告されるべきです。 さもなければ、そのエントリーを取り除きました、そして、PBytes分野は4(4)で減少しました。 結果として起こるPBytes分野が4を含んでいるなら(すなわち、それ以上の次のホップIPアドレスが全くありません)、パラメタはTargetから取り除かれます。 どちらの場合ではも、TargetのTargetBytes分野とTargetListのPBytes分野はそれに従って、減少しなければなりません。 そうでなければ、オプションで最初の次のホップIPに向かった当時のルートが1であるなら演説するSTエージェントは、存在しているか、または目標に向かってそうします。 目標のIPアドレスがリストにおける最後のエントリーとして含まれていないことに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode | 4+4*N | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| next-hop IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode| 4+4*N| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のホップIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 次のホップIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35. SrcRoute
図35。 SrcRoute
CIP Working Group [Page 95] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[95ページ]RFC1190インターネット流れのプロトコル1990年10月
Since it is possible that a single hop between ST agents is
actually composed of multiple IP hops using IP
encapsulation, it might be necessary to also specify an IP
source routing option. Two additional PCodes are used in
this case. See [15] for a description of IP routing
options.
STエージェントの間の単一のホップが実際にIPカプセル化を使用する複数のIPホップで構成されるのが、可能であるので、また、IPソースルーティングオプションを指定するのが必要であるかもしれません。 2追加PCodesがこの場合使用されます。 IPルーティングオプションの記述のための[15]を見てください。
An IP Loose Source Route (PCode = 16) indicates that PDUs
for the next-hop ST agent should be encapsulated in IP and
that the IP datagram should contain an IP Loose Source Route
constructed from the list of IP router addresses contained
in this option.
IP Loose Source Route(PCode=16)は、次のホップSTエージェントのためのPDUsがIPで要約されるべきであり、IPデータグラムがこのオプションに含まれたIPルータアドレスのリストから組み立てられたIP Loose Source Routeを含むはずであるのを示します。
An IP Strict Source Route (PCode = 17) is similarly used
when the corresponding IP Strict Source Route option should
be constructed.
対応するIP Strict Source Routeオプションが構成されるべきであるとき、IP Strict Source Route(PCode=17)は同様に使用されます。
Consequently, the "routing parameter" may consist of a
sequence of one or more separate parameters with PCodes 16,
17, 18, or 19.
その結果、「ルーティングパラメタ」はPCodes16、17、18、または19と共に1つ以上の別々のパラメタの系列から成るかもしれません。
4.2.2.15. Target and TargetList
4.2.2.15. 目標とTargetList
Several control messages use a parameter called TargetList
(PCode = 20), which contains information about the targets
to which the message pertains. For each Target in the
TargetList, the information includes the IP addresses of the
target, the SAP applicable to the next higher layer
protocol, the length of the SAP (SAPBytes), and zero or more
optional SrcRoute parameters; see Section 4.2.2.14 (page
95). Consequently, a Target structure can be of variable
length. Each entry has the format shown in Figure 36.
いくつかのコントロールメッセージがTargetList(PCode=20)と呼ばれるパラメタを使用します。TargetListはメッセージが関係する目標の情報を含みます。 TargetListの各Targetに関しては、情報は目標のIPアドレスを含んで、次の、より高い層のプロトコルか、SAP(SAPBytes)の長さと、ゼロかその他に適切なSAPは任意のSrcRouteパラメタです。 セクション4.2を見てください。.2 .14(95ページ)。 その結果、Target構造は可変長のものであることができます。 各エントリーには、図36に示された書式があります。
The optional SrcRoute parameter is only meaningful in a
CONNECT messages; if present in other messages, they are
ignored. Note that the presence of SrcRoute parameter(s)
reduces the number of Targets that can be contained in a
TargetList since the maximum size of a TargetList is 256
bytes. Consequently an implementation should be prepared to
accept multiple TargetLists in a single message.
任意のSrcRouteパラメタは単にCONNECTメッセージで重要です。 他のメッセージに存在しているなら、それらは無視されます。 SrcRouteパラメタの存在がTargetListの最大サイズが256バイトであるのでTargetListに含むことができるTargetsの数を減少させることに注意してください。 その結果、実現はただ一つのメッセージで複数のTargetListsを受け入れるように準備されるべきです。
TargetIPAddress is the IP Address of the Target.
TargetIPAddressはTargetのIP Addressです。
TargetBytes is the length of the Target structure,
beginning with the TargetIPAddress and including any
SrcRoute Parameter(s).
TargetBytesはTargetIPAddressと共に始まって、どんなSrcRoute Parameter(s)も含むTarget構造の長さです。
SAPBytes is the length of the SAP, excluding any padding
required to maintain 32-bit alignment. I.e.,
32ビットの整列を維持するのに必要である詰め物を除いて、SAPBytesはSAPの長さです。 すなわち
CIP Working Group [Page 96] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[96ページ]RFC1190インターネット流れのプロトコル1990年10月
there would be no padding required for SAPs with lengths
of 2, 6, etc., bytes.
SAPsに2、6などの長さ、バイトで必要である水増しがないでしょう。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargetBytes | SAPBytes | :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+
: SAP : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetBytes| SAPBytes| : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+-+-+-+-+-+-+-+-+ : SAP: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : SrcRoute Parameter(s) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : SrcRouteパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36. Target
図36。 目標
We assume that the ST agents must know the maximum packet
size of the networks to which they are connected (the MTU),
and those maximum sizes will restrict the number of targets
that can be specified in control messages. We feel that
this is not a serious drawback. High bandwidth networks
such as the Ethernet or the Terrestrial Wideband network
support packet sizes large enough to allow well over one
hundred targets to be specified, and we feel that
conferences with a larger number of participants will not
occur for quite some time. Furthermore, we expect that
future higher bandwidth networks will allow even larger
packet sizes. It may be desirable to send ST voice data
packets in individual B-ISDN ATM cells, which are small, but
network services on ATM will provide "adaptation layers" to
implement network-level fragmentation that may be used to
carry larger ST control messages.
私たちは、STエージェントがそれらが関連しているネットワーク(MTU)の最大のパケットサイズを知らなければならないと思います、そして、それらの最大サイズはコントロールメッセージで指定できる目標の数を制限するでしょう。 私たちは、これが重大な欠点でないと感じます。 イーサネットかTerrestrial Widebandネットワークなどの高帯域ネットワークは100個の目標の上に指定されるのをよく許容できるくらい大きいパケットサイズを支持します、そして、私たちは、より多くの関係者との会議が長い間起こらないのを感じます。 その上、私たちは、将来の、より高い帯域幅ネットワークがさらに大きいパケットサイズを許容すると予想します。 小さい個々のB-ISDN ATMセルの中の声のデータ・パケットをSTに送るのが望ましいかもしれませんが、ATMにおけるネットワーク・サービスは、より大きいSTコントロールメッセージを伝えるのに使用されるかもしれないネットワークレベル断片化を実行するために「適合層」を提供するでしょう。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 20 | PBytes | TargetCount = N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target 1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Target N :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=20| PBytes| TargetCountはNと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 目標1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 目標N: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37. TargetList
図37。 TargetList
CIP Working Group [Page 97] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[97ページ]RFC1190インターネット流れのプロトコル1990年10月
If a message must pass across a network whose maximum packet
size is too small, the message must be broken up into
multiple messages, each of which carries part of the
TargetList. The function of the message can still be
performed even if the message is so partitioned. The effect
in this partitioning is to compromise the performance, but
still allows proper operation. For example, if a CONNECT
message were partitioned, the first CONNECT would establish
the stream, and the rest of the CONNECTs would be processed
as additions to the first. The routing decisions might
suffer, however, since they would be made on partial
information. Nevertheless, the stream would be created.
メッセージが最大のパケットサイズが小さ過ぎるネットワークの向こう側に終わらなければならないなら、複数のメッセージにメッセージを終えなければなりません。それはそれぞれTargetListの一部を運びます。 メッセージがそのように仕切られても、まだメッセージの機能を実行できます。 この仕切りにおける効果は、性能で妥協するためにありますが、まだ適切な操作を許しています。 例えば、CONNECTメッセージが仕切られるなら、最初のCONNECTは流れを確立するでしょうに、そして、CONNECTsの残りは1日への追加として処理されるでしょう。 それらは部分的な情報で作られているでしょう、しかしながら、したがって、ルーティング決定に苦しむかもしれません。 それにもかかわらず、流れは作成されるでしょう。
4.2.2.16. UserData
4.2.2.16. UserData
The UserData parameter (PCode = 21) is an optional parameter
that may be used by the next higher protocol or an
application to convey arbitrary information to its peers.
Note that since the size of control messages is limited by
the smallest MTU in the path to the target(s), the maximum
size of this parameter cannot be specified a priori. If the
parameter is too large for some network's MTU, a
UserDataSize error will occur. The parameter must be padded
to a multiple of 32 bits.
UserDataパラメタ(PCode=21)は任意の情報を同輩に伝えるのに次の、より高いプロトコルかアプリケーションで使用されるかもしれない任意のパラメタです。 コントロールメッセージのサイズが経路で最も小さいMTUによって目標に制限されるので先験的にこのパラメタの最大サイズを指定できないことに注意してください。 何らかのネットワークのMTUには、パラメタが大き過ぎるなら、UserDataSize誤りは発生するでしょう。 32ビットの倍数にパラメタを水増ししなければなりません。
UserBytes specifies the number of valid UserInformation
bytes.
UserBytesは有効なUserInformationバイトの数を指定します。
UserInformation is arbitrary data meaningful to the next
higher protocol layer or application.
UserInformationは次の、より高いプロトコル層かアプリケーションに重要な任意のデータです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCode = 21 | PBytes | UserBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserInformation : Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode=21| PBytes| UserBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserInformation: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38. UserData
図38。 UserData
CIP Working Group [Page 98] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[98ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.3. ST Control Message PDUs
4.2.3. メッセージPDUsを第制御してください。
Each control message is described in a following section. See
Appendix 1 (page 147) for an explanation of the notation.
それぞれのコントロールメッセージは以下の章で説明されます。 記法の説明に関してAppendix1(147ページ)を見てください。
CIP Working Group [Page 99] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[99ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.3.1. ACCEPT
4.2.3.1. 受け入れてください。
ACCEPT (OpCode = 1) is issued by a target as a positive
response to a CONNECT message. It implies that the target
is prepared to accept data from the origin along the stream
that was established by the CONNECT. The ACCEPT includes
the FlowSpec that contains the cumulative information that
was calculated by the intervening ST agents as the CONNECT
made its way from the origin to the target, as well as any
modifications made by the application at the target. The
ACCEPT is relayed by the ST agents from the target to the
origin along the path established by the CONNECT but in the
reverse direction. The ACCEPT must be acknowledged with an
ACK at each hop.
ACCEPT(OpCode=1)はCONNECTメッセージへの積極的な応答として目標によって発行されます。 それは、目標がCONNECTによって確立された流れに沿って起源からデータを受け入れるように準備されるのを含意します。 ACCEPTはCONNECTが起源から目標に進んでいたとき介入しているSTエージェントによって計算された累積している情報を含むFlowSpecを含んでいます、目標のアプリケーションでされたどんな変更と同様に。 ACCEPTは経路に沿って目標から起源までCONNECTにもかかわらず、反対の方向に確立していた状態でSTエージェントによってリレーされます。 各ホップのACKと共にACCEPTを承認しなければなりません。
The FlowSpec is not modified on this trip from the target
back to the origin. Since the cumulative FlowSpec
information can be different for different targets, no
attempt is made to combine the ACCEPTs from the various
targets. The TargetList included in each ACCEPT contains
the IP address of only the target that issued the ACCEPT.
FlowSpecはこの目標から起源までの旅行で変更されません。 異なった目標において、累積しているFlowSpec情報が異なる場合があるので、様々な目標からACCEPTsを結合するのを試みを全くしません。 各ACCEPTにTargetListを含んでいると、ACCEPTを発行した目標だけのIPアドレスは含んでいます。
Any SrcRoute parameters in the TargetList are ignored.
TargetListのどんなSrcRouteパラメタも無視されます。
Since an ACCEPT might be the first response from a next-hop
on a control link (due to network reordering), the SVLId
field may be the first source of the Virtual Link Identifier
to be used in the RVLId field of subsequent control messages
sent to that next-hop.
ACCEPTがコントロールリンク(ネットワーク再命令による)の上の次のホップからの最初の応答であるかもしれないので、SVLId分野はVirtual Link Identifierのその次のホップに送られたその後のコントロールメッセージのRVLId分野で使用されるべき最初の源であるかもしれません。
When the FDx option has been selected to setup a second
stream in the reverse direction, the ACCEPT will contain
both RFlowSpec and RName parameters. Each agent should
update the state tables for the reverse stream with this
information.
FDxオプションが2番目の流れを反対の方向にセットアップするのが選択されたとき、ACCEPTはRFlowSpecとRNameパラメタの両方を含むでしょう。 各エージェントはこの情報で逆の流れのためのステートテーブルをアップデートするべきです。
TSR (bits 14 and 15) specifies the target's response for
the use of data packet timestamps; see Section 4 (page
76). Its values and semantics are:
TSR(ビット14と15)はデータ・パケットタイムスタンプの使用のための目標の応答を指定します。 セクション4(76ページ)を見てください。 その値と意味論は以下の通りです。
00 Not implemented.
01 No timestamps are permitted.
10 Timestamps must always be present.
11 Timestamps may optionally be present.
00 実行されません。 01 タイムスタンプは全く受入れられません。 10のタイムスタンプがいつも存在していなければなりません。 11のタイムスタンプが任意に存在しているかもしれません。
Reference contains a number assigned by the agent sending
the ACCEPT for use in the acknowledging ACK.
参照は承認しているACKにおける使用のためにACCEPTを送るエージェントによって割り当てられた数を含んでいます。
LnkReference is the Reference number from the
corresponding CONNECT or CHANGE.
LnkReferenceは対応するCONNECTかCHANGEからのReference番号です。
CIP Working Group [Page 100] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[100ページ]RFC1190インターネット流れのプロトコル1990年10月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 1 | 0 |TSR| TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode=1| 0 |TSR| TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId| SVLId| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress| 命名..パラメタ FlowSpecパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetListパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRoute Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRouteパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RFlowSpec Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RFlowSpecパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! RName Parameter ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
パラメタ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserDataパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39. ACCEPT Control Message
図39。 コントロールメッセージを受け入れてください。
CIP Working Group [Page 101] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[101ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.3.2. ACK
4.2.3.2. ACK
ACK (OpCode = 2) is used to acknowledge a request. The
Reference in the header is the Reference number of the
control message being acknowledged.
ACK(OpCode=2)は、要求を承諾するのに使用されます。 承認されていて、ヘッダーのReferenceはコントロールメッセージのReference番号です。
Since a ACK might be the first response from a next-hop on a
control link, the SVLId field may be the first source of the
Virtual Link Identifier to be used in the RVLId field of
subsequent control messages sent to that next-hop.
ACKがコントロールリンクの上の次のホップからの最初の応答であるかもしれないので、SVLId分野はVirtual Link Identifierのその次のホップに送られたその後のコントロールメッセージのRVLId分野で使用されるべき最初の源であるかもしれません。
ReasonCode is usually NoError, but other possibilities
exist, e.g., DuplicateIgn.
ReasonCodeは通常NoErrorですが、他の可能性は例えば存在しています。DuplicateIgn。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 2 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode=2| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId| SVLId| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 名前..パラメタ
Figure 40. ACK Control Message
図40。 ACKコントロールメッセージ
CIP Working Group [Page 102] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[102ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.3.3. CHANGE-REQUEST
4.2.3.3. 変更要求
CHANGE-REQUEST (OpCode = 4) is used by an intermediate or
target agent to request that the origin change the FlowSpec
of an established stream. The CHANGE-REQUEST message is
propagated hop-by-hop to the origin, with an ACK at each
hop.
CHANGE-REQUEST(OpCode=4)は、起源が確立した流れのFlowSpecを変えるよう要求するのに中間介在物か目標エージェントによって使用されます。 CHANGE-REQUESTメッセージはホップごとに各ホップのACKと共に起源に伝播されます。
Any SrcRoute parameters in the targets of the TargetList are
ignored.
TargetListの目標のどんなSrcRouteパラメタも無視されます。
G (bit 8) is used to request a global, stream-wide
change; the TargetList parameter may be omitted when the
G bit is specified.
G(ビット8)はグローバルで、流れの全体の変化を要求するのに使用されます。 Gビットが指定されるとき、TargetListパラメタは省略されるかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 4 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode=4|G| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId| SVLId| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress| 命名..パラメタ FlowSpecパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetListパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserDataパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41. CHANGE-REQUEST Control Message
図41。 変更要求コントロールメッセージ
CIP Working Group [Page 103] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[103ページ]RFC1190インターネット流れのプロトコル1990年10月
4.2.3.4. CHANGE
4.2.3.4. 変化
CHANGE (OpCode = 3) is used to change the FlowSpec of an
established stream. Parameters are the same as for CONNECT
but the TargetList is not required. The CHANGE message is
processed similarly to the CONNECT message, except that it
travels along the path of an established stream.
CHANGE(OpCode=3)は、確立した流れのFlowSpecを変えるのに使用されます。 パラメタはCONNECTのように同じですが、TargetListは必要ではありません。 CHANGEメッセージは同様にCONNECTメッセージに処理されます、確立した流れの経路に沿って移動するのを除いて。
If the change to the FlowSpec is in a direction that makes
fewer demands of the involved networks, then the change has
a high probability of success along the path of the
established stream. Each ST agent receiving the CHANGE
message makes the necessary requested changes to the network
resource allocations, and if successful, propagates the
CHANGE message along the established paths. If the change
cannot be made then the ST agent must recover using
DISCONNECT and REFUSE messages as in the case of a network
failure. Note that a failure to change the resources
requested for a specific target(s) should not cause other
targets in the stream to be deleted. The CHANGE must be
ACKed.
より少なくかかわったネットワークに需要を満たす方向にFlowSpecへの変化があるなら、変化は確立した流れの経路に沿って成功の高い確率を持っています。 CHANGEメッセージを受け取るそれぞれのSTエージェントが、ネットワーク資源配分、うまくいくなら必要な要求された変更を行って、確立した経路に沿ってCHANGEメッセージを伝播します。 変更を行うことができないなら、STエージェントは、ネットワーク失敗に関するケースのようにDISCONNECTとREFUSEメッセージを使用することで回復しなければなりません。 特定の目標のために要求されたリソースを変えない場合流れの他の目標が削除されることを引き起こすべきでないことに注意してください。 CHANGEはACKedであるに違いありません。
If the CHANGE is a result of a CHANGE-REQUEST the
LnkReference field of the CHANGE will contain the value from
the Reference field of the CHANGE-REQUEST.
CHANGEがCHANGE-REQUESTの結果であるなら、CHANGEのLnkReference分野はCHANGE-REQUESTのReference分野からの値を含むでしょう。
It is recommended that the origin only have one outstanding
CHANGE per target; if the application requests more that
one to be outstanding at a time, it is the application's
responsibility to deal with any sequencing problems that may
arise.
起源に1目標あたり1傑出しているCHANGEしかないのは、お勧めです。 アプリケーションが、一度に傑出しているようそれにもう少し要求するなら、起こるかもしれないのは、どんな配列問題にも対処するアプリケーションの責任です。
Any SrcRoute parameters in the targets of the
TargetListParameter are ignored.
TargetListParameterの目標のどんなSrcRouteパラメタも無視されます。
G (bit 8) is used to request a global, stream-wide
change; the TargetList parameter may be omitted when the
G bit is specified.
G(ビット8)はグローバルで、流れの全体の変化を要求するのに使用されます。 Gビットが指定されるとき、TargetListパラメタは省略されるかもしれません。
CIP Working Group [Page 104] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[104ページ]RFC1190インターネット流れのプロトコル1990年10月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 3 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVLId | SVLId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Name Parameter !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode=3|G| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RVLId| SVLId| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress| 命名..パラメタ FlowSpecパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetListパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserDataパラメタ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 42. CHANGE Control Message
図42。 変化コントロールメッセージ
4.2.3.5. CONNECT
4.2.3.5. 接続してください。
CONNECT (OpCode = 5) requests the setup of a new stream or
an addition to or recovery of an existing stream. Only the
origin can issue the initial set of CONNECTs to setup a
stream, and the first CONNECT to each next-hop is used to
convey the initial suggestion for a HID. If the stream's
data packets will be sent to some set of next-hop ST agents
by multicast then the CONNECTs to that set must suggest the
same HID. Otherwise, the HIDs in the various CONNECTs can
be different.
CONNECT(OpCode=5)は既存の流れの新しい流れのセットアップ、添加または回収を要求します。 起源だけが流れをセットアップするためにCONNECTsの始発を発行できます、そして、それぞれの次のホップへの最初のCONNECTは、HIDのために初期の提案を伝えるのに使用されます。 マルチキャストで何らかのセットの次のホップSTエージェントに流れのデータ・パケットを送るなら、そのセットへのCONNECTsは同じHIDを勧めなければなりません。 さもなければ、様々なCONNECTsのHIDsは異なっている場合があります。
The CONNECT message must fit within the maximum allowable
packet size (MTU) for the intervening network. If a CONNECT
message is too large, it must be fragmented into multiple
CONNECT messages by partitioning the TargetList; see Section
4.2 (page 77). Any UserData parameter will be replicated in
each fragment for delivery to all targets.
CONNECTメッセージは最大の介入しているネットワークにおいて、許容できるパケットサイズ(MTU)の中で合わなければなりません。 CONNECTメッセージが大き過ぎるなら、TargetListを仕切ることによって、複数のCONNECTメッセージにそれを断片化しなければなりません。 セクション4.2(77ページ)を見てください。 どんなUserDataパラメタも配送のために各断片ですべての目標に模写されるでしょう。
CIP Working Group [Page 105] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[105ページ]RFC1190インターネット流れのプロトコル1990年10月
The next-hop can initially respond with any of the following
five responses:
次のホップは初めは、以下の5つの応答のどれかで応じることができます:
1 ERROR-IN-REQUEST, which implies that the CONNECT was
not valid and has been ignored,
1 ERROR IN REQUEST、どれがCONNECTが有効でなく、無視されたのを含意するか。
2 ACK, which implies that the CONNECT with the H bit not
set was valid and is being processed,
2 ACK、どれが、HビットがあるCONNECTがセットしなかったのを含意するか、有効であり、処理されています。
3 HID-APPROVE, which implies that the CONNECT with the
H bit set was valid, and the suggested HID can be
used or was deferred,
3 HID-APPROVE、どれが、HビットがあるCONNECTがセットしたのを含意するかが、有効であり、提案されたHIDは使用できたか、または延期されました。
4 HID-REJECT, which implies that the CONNECT with the H
bit set was valid but the suggested HID cannot be
used and another must be suggested in a subsequent
HID-CHANGE message, or
または4 HID-REJECT、どれが、HビットがあるCONNECTがセットしたのを含意するかが、有効でしたが、提案されたHIDを使用できないで、その後のHID-CHANGEメッセージに別のものを示さなければならない。
5 REFUSE, which implies that the CONNECT was valid but
the included list of targets in the REFUSE cannot be
processed for the stated reason.
5 述べられた理由でREFUSEにもかかわらず、どれが、CONNECTが有効であったのを含意するか、しかし、REFUSEの目標の含まれているリストを処理できません。
The next-hop will later relay back either an ACCEPT or
REFUSE from each target not already specified in the REFUSE
of case 5 above (note multiple targets may be included in a
single REFUSE message).
次のホップは後でケース5のREFUSEで既に(マルチターゲットがただ一つのREFUSEメッセージに含まれるかもしれないというメモ)を超えて指定されなかった各目標から後部のACCEPTかREFUSEのどちらかをリレーするでしょう。
An intermediate ST agent that receives a CONNECT selects the
next-hop ST agents, partitions the TargetList accordingly,
reserves network resources in the direction toward the
next-hop, updating the FlowSpec accordingly (see Section
4.2.2.3 (page 81)), selects a proposed HID for each next-
hop, and sends the resulting CONNECTs.
セクション4.2を見てください。a CONNECTを受け取る中間的STエージェントは、次のホップSTエージェントを選んで、それに従って、TargetListを仕切ります、次のホップに向かった方向への蓄えのネットワーク資源、それに従って、FlowSpecをアップデートして(.2 .3 (81ページ)) 次の各ホップのために提案されたHIDを選択して、結果として起こるCONNECTsを送ります。
If the intermediate ST agent that is processing a CONNECT
fails to find a route to a target, then it responds with a
REFUSE with the appropriate reason code. If the next-hop to
a target is by way of the network from which it received the
CONNECT, then it sends a NOTIFY with the appropriate reason
code (RouteBack). In either case, the TargetList specifies
the affected targets. The intermediate ST agent will only
route to and propagate a CONNECT to the targets for which it
does not issue either an ERROR-IN-REQUEST or a REFUSE.
CONNECTを処理している中間的STエージェントが目標にルートを見つけないなら、それはREFUSEと共に適切な理由コードで応じます。 目標への次のホップがそれがCONNECTを受けたネットワークを通してあるなら、それは適切な理由コード(RouteBack)があるNOTIFYを送ります。 どちらの場合ではも、TargetListは影響を受ける目標を指定します。 中間的STエージェントは、それがERROR IN REQUESTかREFUSEのどちらかを発行しない目標にルートだけを望んでいて、CONNECTを伝播します。
CIP Working Group [Page 106] RFC 1190 Internet Stream Protocol October 1990
CIPワーキンググループ[106ページ]RFC1190インターネット流れのプロトコル1990年10月
The processing of a received CONNECT message requires care
to avoid routing loops that could result from delays in
propagating routing information among ST agents. If a
received CONNECT contains a new Name, a new stream should be
created (unless the Virtual Link Identifier matches a known
link in which case an ERROR-IN-REQUEST should be sent). If
the Name is known, there are four cases:
受信されたCONNECTメッセージの処理は、STエージェントの中でルーティング情報を伝播する遅れから生じることができた輪を発送するのを避けるために注意を必要とします。 容認されたCONNECTが新しいNameを含んでいるなら、新しい流れは作成されるべきです(Virtual Link Identifierがその場合知られているリンクに合っていない場合、ERROR IN REQUESTを送るべきです)。 Nameが知られているなら、4つのケースがあります:
1 the Virtual Link Identifier matches and the Target
matches a current Target -- the duplicate target
should be ignored.
1 Targetは現在のTargetに合っています--Virtual Link Identifierは合って、写し目標は無視されるべきです。
2 the Virtual Link Identifier matches but the Target is
new -- the stream should be expanded to include the
new target.
2 Targetは新しいです--Virtual Link Identifierは合っていますが、流れは、新しい目標を含むように膨張するべきです。
3 the Virtual Link Identifier differs and the Target
matches a current Target -- an ERROR-IN-REQUEST
message should be sent specifying that the target is
involved in a routing loop. If a reroute, the old
path will eventually timeout and send a DISCONNECT;
a subsequent retransmission of the rerouted CONNECT
will then be processed under case 2 above.
3 Targetは現在のTargetに合っています--Virtual Link Identifierは異なって、ERROR IN REQUESTメッセージに目標がルーティング輪にかかわると指定させるべきです。 aであるならコースを変更してください、古い経路は、結局、タイムアウトを望んでいて、DISCONNECTを送ります。 そして、別ルートで送られたCONNECTのその後の「再-トランスミッション」は場合2の下で上に処理されるでしょう。
4 the Virtual Link Identifier differs but the Target is
new -- a new (instance of the) stream should be
created for the target that is deliberately part of
a loop using a SrcRoute parameter.
4 Virtual Link Identifierは異なりますが、Targetは新しいです--、a新しい、(例、)、流れは、故意に離れることである輪の目標のためにSrcRouteパラメタを使用することで作成されるべきです。
Note that the test for a known or matching Target includes
comparing any SrcRoute parameter that might be present.
知られているか合っているTargetのためのテストが、どんな存在するかもしれないSrcRouteパラメタも比較するのを含んでいることに注意してください。
Option bits are specified by either the origin's service
user or by an intermediate agent, depending on the specific
option. Bits not specified below are currently unspecified,
and should be set to zero (0) by the origin agent and not
changed by other agents unless those agents know their
meaning.
特定のオプションによって、オプションビットは起源のサービス利用者か仲介物質によって指定されます。 それらのエージェントが彼らの意味を知らないなら、以下で指定されなかったビットを、現在、不特定であり、起源エージェントで(0)のゼロを合わせるように設定して、他のエージェントは変えるべきではありません。
一覧
スポンサーリンク
