RFC1819 日本語訳
1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification -Version ST2+. L. Delgrossi, L. Berger, Eds.. August 1995. (Format: TXT=266875 bytes) (Obsoletes RFC1190, IEN 119) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group ST2 Working Group Request for Comments: 1819 L. Delgrossi and L. Berger, Editors Obsoletes: 1190, IEN 119 August 1995 Category: Experimental
コメントを求めるワーキンググループST2ワーキンググループ要求をネットワークでつないでください: 1819L.DelgrossiとL.バーガー、エディターズは以下を時代遅れにします。 1190 IEN119 1995年8月のカテゴリ: 実験的
Internet Stream Protocol Version 2 (ST2)
Protocol Specification - Version ST2+
インターネットストリームプロトコルバージョン2(ST2)プロトコル仕様--バージョンST2+
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG NOTE
IESG注意
This document is a revision of RFC1190. The charter of this effort was clarifying, simplifying and removing errors from RFC1190 to ensure interoperability of implementations.
このドキュメントはRFC1190の改正です。 この取り組みの特許は、実装の相互運用性を確実にするためにRFC1190から誤りをはっきりさせて、簡素化して、取り除いていました。
NOTE WELL: Neither the version of the protocol described in this document nor the previous version is an Internet Standard or under consideration for that status.
以下によく注意してください。 本書では説明されたプロトコルのバージョンも旧バージョンもインターネットStandardかその状態のために考慮でありません。
Since the publication of the original version of the protocol, there have been significant developments in the state of the art. Readers should note that standards and technology addressing alternative approaches to the resource reservation problem are currently under development within the IETF.
プロトコルのオリジナルバージョンの公表以来、重要な開発が到達技術水準にあります。 読者は、資源予約問題への代替的アプローチを扱う規格と技術が現在IETFの中で開発中であることに注意するべきです。
Abstract
要約
This memo contains a revised specification of the Internet STream Protocol Version 2 (ST2). ST2 is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet. It allows applications to build multi-destination simplex data streams with a desired quality of service. The revised version of ST2 specified in this memo is called ST2+.
このメモはインターネットSTreamプロトコルバージョン2(ST2)に関する訂正明細書を含んでいます。 ST2は終わりから終わりへのリアルタイムの保証をインターネットの上に提供することを意図する実験資源予約プロトコルです。 それで、アプリケーションは必要なサービスの質があるマルチの目的地シンプレクスデータ・ストリームを組み込むことができます。 このメモで指定されたST2の改訂版はST2+と呼ばれます。
This specification is a product of the STream Protocol Working Group of the Internet Engineering Task Force.
この仕様はインターネット・エンジニアリング・タスク・フォースのSTreamプロトコル作業部会の製品です。
Delgrossi & Berger, Editors Experimental [Page 1] RFC 1819 ST2+ Protocol Specification August 1995
[1ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
Table of Contents
目次
1 Introduction 6
1.1 What is ST2? 6
1.2 ST2 and IP 8
1.3 Protocol History 8
1.3.1 RFC1190 ST and ST2+ Major Differences 9
1.4 Supporting Modules for ST2 10
1.4.1 Data Transfer Protocol 11
1.4.2 Setup Protocol 11
1.4.3 Flow Specification 11
1.4.4 Routing Function 12
1.4.5 Local Resource Manager 12
1.5 ST2 Basic Concepts 15
1.5.1 Streams 16
1.5.2 Data Transmission 16
1.5.3 Flow Specification 17
1.6 Outline of This Document 19
1 序論6 1.1WhatはST2ですか? 6 1.2ST2とIP8 1.3プロトコル歴史8 1.3の.1RFC1190 STとST2+主要な違い、9、モジュールをサポートする1.4、ST2 10 1.4.1データ転送プロトコル11 1.4.2セットアッププロトコル11 1.4.3流れ仕様11 1.4.4経路選択機能12 1.4の.5の地方の資源管理プログラム12 1.5のST2基本概念15 1.5のために、1.5.2データ伝送16 1.5.3流れ仕様17 1.6が概説するこの.1のストリーム16が19を記録します。
2 ST2 User Service Description 19
2.1 Stream Operations and Primitive Functions 19
2.2 State Diagrams 21
2.3 State Transition Tables 25
2 2.1のST2ユーザサービス記述19ストリーム操作と2.2個の原始関数19州のダイヤグラム21の2.3個の状態遷移テーブル25
3 The ST2 Data Transfer Protocol 26
3.1 Data Transfer with ST 26
3.2 ST Protocol Functions 27
3.2.1 Stream Identification 27
3.2.2 Packet Discarding based on Data Priority 27
3、ST2 Data Transferプロトコル、26、3.1Data Transfer、.2Packet DiscardingがData Priority27に基礎づけたST26標準時3.2のプロトコルFunctions27 3.2.1Stream Identification27 3.2
4 SCMP Functional Description 28
4.1 Types of Streams 29
4.1.1 Stream Building 30
4.1.2 Knowledge of Receivers 30
4.2 Control PDUs 31
4.3 SCMP Reliability 32
4.4 Stream Options 33
4.4.1 No Recovery 33
4.4.2 Join Authorization Level 34
4.4.3 Record Route 34
4.4.4 User Data 35
4.5 Stream Setup 35
4.5.1 Information from the Application 35
4.5.2 Initial Setup at the Origin 35
4.5.2.1 Invoking the Routing Function 36
4.5.2.2 Reserving Resources 36
4.5.3 Sending CONNECT Messages 37
4.5.3.1 Empty Target List 37
4のSCMPの機能的な記述28 4.1のタイプのストリーム29 4.1.1ストリームビル、30、4.1、.2知識、受信機30 4.2コントロールPDUs31 4.3SCMPでは、信頼性32の4.4がオプション33 4.4.1いいえ回復を流す、33、4.4、.2、.4の利用者データ35 4.5が流すルート34 4.4がセットアップされるという承認レベル34 4.4.3記録を接合してください、35、4.5、.1情報、.2が頭文字をつけるアプリケーション35 4.5から、.2が発生源35 4.5でセットアップされている、.3発信が接続する経路選択機能36 4.5.2.2予約リソース36 4.5を呼び出す.1が37の4.5の.3の.1の空の目標リスト37を通信させます。
Delgrossi & Berger, Editors Experimental [Page 2] RFC 1819 ST2+ Protocol Specification August 1995
[2ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4.5.4 CONNECT Processing by an Intermediate ST agent 37
4.5.5 CONNECT Processing at the Targets 38
4.5.6 ACCEPT Processing by an Intermediate ST agent 38
4.5.7 ACCEPT Processing by the Origin 39
4.5.8 REFUSE Processing by the Intermediate ST agent 39
4.5.9 REFUSE Processing by the Origin 39
4.5.10 Other Functions during Stream Setup 40
4.6 Modifying an Existing Stream 40
4.6.1 The Origin Adding New Targets 41
4.6.2 The Origin Removing a Target 41
4.6.3 A Target Joining a Stream 42
4.6.3.1 Intermediate Agent (Router) as Origin 43
4.6.4 A Target Deleting Itself 43
4.6.5 Changing a Stream's FlowSpec 44
4.7 Stream Tear Down 45
4.5.4 Intermediate STエージェント37 4.5のCONNECT Processing、Targets38 4.5における.5CONNECT Processing、Intermediate STエージェント38 4.5の.6ACCEPT Processing、Origin39 4.5のものの.7ACCEPT Processing、Intermediate STエージェント39 4.5のものの.8REFUSE Processing、Originによる.9REFUSE Processing、39、4.5; 既存のストリームを変更するストリームセットアップ40 4.6の間の他の10の機能、40、4.6、.1、新しい目標を加える発生源、41、4.6、.2、目標を取り外す発生源、41、4.6、.3、発生源としてストリーム42 4.6.3.1仲介物質(ルータ)に加わる目標、43、4.6、.4、4.6に.5の変化しているaストリームのFlowSpec44 4.7に43自体を削除する目標は45の下側に裂け目を流します。
5 Exceptional Cases 45
5.1 Long ST Messages 45
5.1.1 Handling of Long Data Packets 45
5.1.2 Handling of Long Control Packets 46
5.2 Timeout Failures 47
5.2.1 Failure due to ACCEPT Acknowledgment Timeout 47
5.2.2 Failure due to CHANGE Acknowledgment Timeout 47
5.2.3 Failure due to CHANGE Response Timeout 48
5.2.4 Failure due to CONNECT Acknowledgment Timeout 48
5.2.5 Failure due to CONNECT Response Timeout 48
5.2.6 Failure due to DISCONNECT Acknowledgment Timeout 48
5.2.7 Failure due to JOIN Acknowledgment Timeout 48
5.2.8 Failure due to JOIN Response Timeout 49
5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout 49
5.2.10 Failure due to NOTIFY Acknowledgment Timeout 49
5.2.11 Failure due to REFUSE Acknowledgment Timeout 49
5.2.12 Failure due to STATUS Response Timeout 49
5.3 Setup Failures due to Routing Failures 50
5.3.1 Path Convergence 50
5.3.2 Other Cases 51
5.4 Problems due to Routing Inconsistency 52
5.5 Problems in Reserving Resources 53
5.5.1 Mismatched FlowSpecs 53
5.5.2 Unknown FlowSpec Version 53
5.5.3 LRM Unable to Process FlowSpec 53
5.5.4 Insufficient Resources 53
5.6 Problems Caused by CHANGE Messages 54
5.7 Unknown Targets in DISCONNECT and CHANGE 55
5例外的なCases45 5.1Long ST Messages45 5.1、Long Data Packets45 5.1の.1Handling、CHANGE Acknowledgment TimeoutへのACCEPT Acknowledgment Timeout47 5.2.2Failure支払われるべきものへのLong Control Packets46 5.2Timeout Failures47 5.2.1Failure支払われるべきものの.2Handling、47、5; JOIN Acknowledgment TimeoutへのDISCONNECT Acknowledgment Timeout48 5.2.7Failure支払われるべきものへのCONNECT Response Timeout48 5.2.6Failure支払われるべきものへのCONNECT Acknowledgment Timeout48 5.2.5Failure支払われるべきものへのCHANGE Response Timeout48 5.2.4Failure支払われるべきものによる2.3失敗、48、5; ルート設定Inconsistencyへの.2Other Cases51 5.4Problems当然のルート設定Failures50 5.3.1Path Convergence50 5.3によるSTATUS Response Timeout49 5.3Setup FailuresによるREFUSE Acknowledgment Timeout49 5.2.12失敗によるNOTIFY Acknowledgment Timeout49 5.2.11失敗によるJOIN-REJECT Acknowledgment Timeout49 5.2.10失敗へのJOIN Response Timeout49 5.2.9Failure支払われるべきものによる2.8失敗、52、5.5Problems、コネReserving Resources53 5.5.1Mismatched FlowSpecs53 5.5、.2Unknown FlowSpec Version53 5.5、Process FlowSpec53 5.5.4Insufficient Resourcesへの.3LRM Unable、53、5.6Problems Caused、CHANGE Messages、54、5.7Unknown Targets、DISCONNECTとCHANGE55
Delgrossi & Berger, Editors Experimental [Page 3] RFC 1819 ST2+ Protocol Specification August 1995
[3ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
6 Failure Detection and Recovery 55
6.1 Failure Detection 55
6.1.1 Network Failures 56
6.1.2 Detecting ST Agents Failures 56
6.2 Failure Recovery 58
6.2.1 Problems in Stream Recovery 60
6.3 Stream Preemption 62
第エージェント失敗56 6.2失敗回復を検出する6の失敗検出と回復55 6.1失敗検出55 6.1.1ネットワーク失敗56 6.1.2、58、6.2の.1問題、ストリーム回復60 6.3では、先取り62を流してください。
7 A Group of Streams 63
7.1 Basic Group Relationships 63
7.1.1 Bandwidth Sharing 63
7.1.2 Fate Sharing 64
7.1.3 Route Sharing 65
7.1.4 Subnet Resources Sharing 65
7.2 Relationships Orthogonality 65
ストリーム63 7.1基礎の7Aグループが関係63 7.1.1帯域幅共有63 7.1.2運命共有64 7.1.3ルート共有65 7.1.4のサブネットリソース共有65 7.2関係直交性から構成されている、65
8 Ancillary Functions 66
8.1 Stream ID Generation 66
8.2 Group Name Generator 66
8.3 Checksum Computation 67
8.4 Neighbor ST Agent Identification and
Information Collection 67
8.5 Round Trip Time Estimation 68
8.6 Network MTU Discovery 68
8.7 IP Encapsulation of ST 69
8.8 IP Multicasting 70
8つの補助的機能66 8.1ストリームID世代66 8.2グループ名ジェネレータ66 8.3チェックサム計算67 8.4の隣人エージェント第識別と情報収集67 8.5が旅行時間見積り68 8.6ネットワークMTU発見を一周させる、68、8.7IPカプセル化、69番目、8.8、IPマルチキャスティング70
9 The ST2+ Flow Specification 71
9.1 FlowSpec Version #0 - (Null FlowSpec) 72
9.2 FlowSpec Version #7 - ST2+ FlowSpec 72
9.2.1 QoS Classes 73
9.2.2 Precedence 74
9.2.3 Maximum Data Size 74
9.2.4 Message Rate 74
9.2.5 Delay and Delay Jitter 74
9.2.6 ST2+ FlowSpec Format 75
9 ST2+流れ仕様71 9.1FlowSpecバージョン#0--(ヌルFlowSpec)72 9.2FlowSpecバージョン#7--ST2+FlowSpec72 9.2.1QoSが73の.2の先行74 9.2の.3の最大のデータ9.2サイズ74 9.2.4メッセージレート74 9.2の.5遅れと遅れジター74 9.2.6ST2+FlowSpec形式75を分類します。
10 ST2 Protocol Data Units Specification 77
10.1 Data PDU 77
10.1.1 ST Data Packets 78
10.2 Control PDUs 78
10.3 Common SCMP Elements 80
10.3.1 FlowSpec 80
10.3.2 Group 81
10.3.3 MulticastAddress 82
10.3.4 Origin 82
10.3.5 RecordRoute 83
10.3.6 Target and TargetList 84
10 仕様77 10.1データPDU 77 10.1.1 STデータ・パケット78 10.2コントロールPDUs78 10.3の一般的なSCMP要素80 10.3.1FlowSpec80 10.3.2グループ81 10.3.3MulticastAddress82 10.3.4発生源82 10.3.5RecordRoute83 10.3.6が狙うST2プロトコルデータ単位とTargetList84
Delgrossi & Berger, Editors Experimental [Page 4] RFC 1819 ST2+ Protocol Specification August 1995
[4ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.3.7 UserData 85
10.3.8 Handling of Undefined Parameters 86
10.4 ST Control Message PDUs 86
10.4.1 ACCEPT 86
10.4.2 ACK 88
10.4.3 CHANGE 89
10.4.4 CONNECT 89
10.4.5 DISCONNECT 92
10.4.6 ERROR 93
10.4.7 HELLO 94
10.4.8 JOIN 95
10.4.9 JOIN-REJECT 96
10.4.10 NOTIFY 97
10.4.11 REFUSE 98
10.4.12 STATUS 100
10.4.13 STATUS-RESPONSE 100
10.5 Suggested Protocol Constants 101
10.5.1 SCMP Messages 102
10.5.2 SCMP Parameters 102
10.5.3 ReasonCode 102
10.5.4 Timeouts and Other Constants 104
10.6 Data Notations 105
11 References 106
12 Security Considerations 108
13 Acknowledgments and Authors' Addresses 108
10.3.7 未定義のパラメタ86標準時10.4のコントロールメッセージPDUsのUserData85 10.3.8取り扱い、86 10.4、.1、受諾、86 10.4.2ACK88 10.4.3変化89 10.4.4が89 10.4.5分離92 10.4.6誤り93 10.4.7を接続する、こんにちは、94 10.4に、.8が95 10.4に廃棄物を接合する状態で.9を接合する、96 10.4、.10、97 10.4.11廃物98 10.4.12状態に通知してください、100、10; 4.13 .4のタイムアウトと他の定数104 10.6のデータ記法105 11の参照箇所106 12のセキュリティ問題108 13人の承認と作者の状態応答100 10.5の提案されたプロトコル定数101 10.5.1のSCMPメッセージ102 10.5.2のSCMPパラメタ102 10.5.3ReasonCode102 10.5のアドレス108
Delgrossi & Berger, Editors Experimental [Page 5] RFC 1819 ST2+ Protocol Specification August 1995
[5ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
1. Introduction
1. 序論
1.1 What is ST2?
1.1 ST2は何ですか?
The Internet Stream Protocol, Version 2 (ST2) is an experimental connection-oriented internetworking protocol that operates at the same layer as connectionless IP. It has been developed to support the efficient delivery of data streams to single or multiple destinations in applications that require guaranteed quality of service. ST2 is part of the IP protocol family and serves as an adjunct to, not a replacement for, IP. The main application areas of the protocol are the real-time transport of multimedia data, e.g., digital audio and video packet streams, and distributed simulation/gaming, across internets.
インターネットStreamプロトコル、バージョン2(ST2)はコネクションレスなIPと同じ層で作動する実験接続指向のインターネットワーキングプロトコルです。 保証されたサービスの質を必要とするアプリケーションにおける単一であるか複数の目的地にデータ・ストリームの効率的な配送をサポートするためにそれを開発してあります。 ST2がそう、交換ではなくIPプロトコルファミリーに離れて、付属物としてサービスする、IP。 プロトコルの主要出願部は、マルチメディアデータのリアルタイムの輸送と、例えば、デジタル・オーディオとビデオパケットストリームと、分配されたシミュレーション/ゲーミングです、インターネットの向こう側に。
ST2 can be used to reserve bandwidth for real-time streams across network routes. This reservation, together with appropriate network access and packet scheduling mechanisms in all nodes running the protocol, guarantees a well-defined Quality of Service (QoS) to ST2 applications. It ensures that real-time packets are delivered within their deadlines, that is, at the time where they need to be presented. This facilitates a smooth delivery of data that is essential for time- critical applications, but can typically not be provided by best- effort IP communication.
リアルタイムのストリームのためにネットワークルートの向こう側に帯域幅を控えるのにST2を使用できます。 この予約はプロトコルを実行するすべてのノードの適切なネットワークアクセスとパケットスケジューリングメカニズムと共にService(QoS)の明確なQualityをST2アプリケーションに保証します。 それは、リアルタイムのパケットがすなわち、彼らの締め切り、時にそれらが提示される必要があるところに提供されるのを確実にします。 これを時間の重要なアプリケーションに、不可欠のデータの滑らかな配送を容易にしますが、最も良い取り組みIPコミュニケーションは通常提供できません。
DATA PATH CONTROL PATH
========= ============
Upper +------------------+ +---------+
Layer | Application data | | Control |
+------------------+ +---------+
| |
| V
| +-------------------+
SCMP | | SCMP | |
| +-------------------+
| |
V V
+-----------------------+ +------------------------+
ST | ST | | | ST | | |
+-----------------------+ +------------------------+
D-bit=1 D-bit=0
データ経路コントロール経路========= ============ 上側の+------------------+ +---------+ 層| アプリケーションデータ| | コントロール| +------------------+ +---------+ | | | V| +-------------------+ SCMP| | SCMP| | | +-------------------+ | | +に対するV-----------------------+ +------------------------第+| st| | | st| | | +-----------------------+ +------------------------+ 1D-ビットのDビット==0
Figure 1: ST2 Data and Control Path
図1: ST2データとコントロール経路
Just like IP, ST2 actually consists of two protocols: ST for the data transport and SCMP, the Stream Control Message Protocol, for all control functions. ST is simple and contains only a single PDU format that is designed for fast and efficient data forwarding in order to
まさしくIPのように、ST2は実際に2つのプロトコルから成ります: データ伝送のためのSTとSCMP、すべてのコントロールのためのStream Control Messageプロトコルは機能します。 STは簡単であり、速くて効率的なデータ推進のために設計されているただ一つのPDU形式だけを含んでいます。
Delgrossi & Berger, Editors Experimental [Page 6] RFC 1819 ST2+ Protocol Specification August 1995
[6ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
achieve low communication delays. SCMP, however, is more complex than IP's ICMP. As with ICMP and IP, SCMP packets are transferred within ST packets as shown in Figure 1.
低いコミュニケーション遅れを達成してください。 しかしながら、SCMPはIPのICMPより複雑です。 ICMPとIPのように、図1に示されるようにSTパケットの中でSCMPパケットを移します。
+--------------------+
| 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 | ... | RTP | 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| ... | RTP| 輸送| | +-----+ +-------+ +-----+ 層| /| / | \ / / | / /| |\ / | +------+--|--\-----+-/--|--- ... -+ / | | \ / | | | \ / | / | | \ / | | | \ +----|--- ... -+ | ----------- | \ / | | | \ / | | | V| | | V| | | +------+ | | | +------+ | +------+ | | | SCMP| | | | | ICMP| | | IGMP| | インターネット| +------+ | | | +------+ | +------+ | 層| | | | | | | | | +に対するV V V V V V V V-----------------+ +-----------------------------------+ | STreamプロトコル|、-、>| インターネットプロトコル| +-----------------+ +-----------------------------------+ | \ / | | \ / | | X| ------------ | / \ | | / \ | VV VV+----------------+ +----------------+ | (サブ、) ネットワーク|...| (サブ、) ネットワーク| (サブ、)ネットワーク| プロトコル| | プロトコル| 層+----------------+ +----------------+
Figure 2. Protocol Relationships
図2。 プロトコル関係
Delgrossi & Berger, Editors Experimental [Page 7] RFC 1819 ST2+ Protocol Specification August 1995
[7ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
1.2 ST2 and IP
1.2 ST2とIP
ST2 is designed to coexist with IP on each node. A typical distributed multimedia application would use both protocols: IP for the transfer of traditional data and control information, and ST2 for the transfer of real-time data. Whereas IP typically will be accessed from TCP or UDP, ST2 will be accessed via new end-to-end real-time protocols. The position of ST2 with respect to the other protocols of the Internet family is represented in Figure 2.
ST2は、各ノードの上にIPと共存するように設計されています。 典型的な分散型マルチメディアアプリケーションは両方のプロトコルを使用するでしょう: 伝統的なデータと制御情報の転送のためのIP、およびリアルタイムデータの転送のためのST2。 IPはTCPかUDPから通常アクセスされるでしょうが、終わりから終わりへの新しいリアルタイムのプロトコルでST2はアクセスされるでしょう。 インターネットファミリーの他のプロトコルに関するST2の位置は図2に表されます。
Both ST2 and IP apply the same addressing schemes to identify different hosts. ST2 and IP packets differ in the first four bits, which contain the internetwork protocol version number: number 5 is reserved for ST2 (IP itself has version number 4). As a network layer protocol, like IP, ST2 operates independently of its underlying subnets. Existing implementations use ARP for address resolution, and use the same Layer 2 SAPs as IP.
ST2とIPの両方が、異なったホストを特定するために体系を扱いながら、同じように適用されます。 ST2とIPパケットは最初の4ビットにおいて異なります:(ビットはインターネットワークプロトコルバージョン番号を含みます)。 No.5はST2のために予約されます(IP自身には、バージョンNo.4があります)。 ネットワーク層プロトコルとして、IPのように、ST2は基本的なサブネットの如何にかかわらず作動します。 既存の実装は、アドレス解決にARPを使用して、IPとして同じLayer2SAPsを使用します。
As a special function, ST2 messages can be encapsulated in IP packets. This is represented in Figure 2 as a link between ST2 and IP. This link allows ST2 messages to pass through routers which do not run ST2. Resource management is typically not available for these IP route segments. IP encapsulation is, therefore, suggested only for portions of the network which do not constitute a system bottleneck.
特別な機能として、IPパケットでST2メッセージをカプセル化することができます。 これはST2とIPとのリンクとして図2に表されます。 このリンクはST2を実行しないルータを通り抜けるメッセージをST2に許容します。 資源管理はこれらのIPルートセグメントに通常利用可能ではありません。 したがって、IPカプセル化はシステムボトルネックを構成しないネットワークの一部だけに示されます。
In Figure 2, the RTP protocol is shown as an example of transport layer on top of ST2. Others include the Packet Video Protocol (PVP) [Cole81], the Network Voice Protocol (NVP) [Cohe81], and others such as the Heidelberg Transport Protocol (HeiTP) [DHHS92].
図2では、RTPプロトコルはトランスポート層に関する例としてST2の上に示されます。 他のものはハイデルベルグTransportプロトコル(HeiTP)[DHHS92]などのPacket Videoプロトコル(PVP)[Cole81]、Network Voiceプロトコル(NVP)[Cohe81]、および他のものを入れます。
1.3 Protocol History
1.3 プロトコル歴史
The first version of ST was published in the late 1970's and was used throughout the 1980's for experimental transmission of voice, video, and distributed simulation. The experience gained in these applications led to the development of the revised protocol version ST2. The revision extends the original protocol to make it more complete and more applicable to emerging multimedia environments. The specification of this protocol version is contained in Internet RFC 1190 which was published in October 1990 [RFC1190].
STの最初のバージョンは、1970年代後半に発行されて、1980年代の間中声、ビデオ、および分配されたシミュレーションの実験的な送信に使用されました。 これらのアプリケーションで行われた経験は改訂されたプロトコルバージョンST2の開発につながりました。 改正は、それをマルチメディア環境として現れるのにより完全でより適切にするようにオリジナルのプロトコルを広げています。 このプロトコルバージョンの仕様は1990[RFC1190]年10月に発行されたインターネットRFC1190に含まれています。
With more and more developments of commercial distributed multimedia applications underway and with a growing dissatisfaction at the transmission quality for audio and video over IP in the MBONE, interest in ST2 has grown over the last years. Companies have products available incorporating the protocol. The BERKOM MMTS project of the German PTT [DeAl92] uses ST2 as its core protocol for
市販の分散型マルチメディアアプリケーションのますます多くの進行中であることの開発とMBONEのIPの上のオーディオとビデオのためのトランスミッション品質における増加している不満で、ST2への関心は最後の数年間増大しています。 会社は利用可能な製品にプロトコルを取り入れさせます。 PTTがコアプロトコルとしてのST2を使用する[DeAl92]ドイツ人のBERKOM MMTSプロジェクト
Delgrossi & Berger, Editors Experimental [Page 8] RFC 1819 ST2+ Protocol Specification August 1995
[8ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
the provision of multimedia teleservices such as conferencing and mailing. In addition, implementations of ST2 for Digital Equipment, IBM, NeXT, Macintosh, PC, Silicon Graphics, and Sun platforms are available.
会議や郵送などのマルチメディア遠隔サービスの支給。 さらに、デジタル・イクイップメント、IBM、NeXT、マッキントッシュ、PC、シリコングラフィックス、およびSunプラットホームへのST2の実装は利用可能です。
In 1993, the IETF started a new working group on ST2 as part of ongoing efforts to develop protocols that address resource reservation issues. The group's mission was to clean up the existing protocol specification to ensure better interoperability between the existing and emerging implementations. It was also the goal to produce an updated experimental protocol specification that reflected the experiences gained with the existing ST2 implementations and applications. Which led to the specification of the ST2+ protocol contained in this document.
1993年に、IETFは、資源予約が問題であると扱うプロトコルを開発するために進行中の取り組みの一部として新しいワーキンググループをST2に始めました。 グループの任務は、存在と実装として現れることの間の、より良い相互運用性を確実にするために既存のプロトコル仕様をきれいにすることになっていました。 また、既存のST2実装とアプリケーションで行われた経験を反映したのは、アップデートされた実験プロトコル仕様を作り出す目標でした。 本書では含まれたST2+プロトコルの仕様に通じました。
1.3.1 RFC1190 ST and ST2+ Major Differences
1.3.1 RFC1190 STとST2+主要な違い
The protocol changes from RFC1190 were motivated by protocol simplification and clarification, and codification of extensions in existing implementations. This section provides a list of major differences, and is probably of interest only to those who have knowledge of RFC1190. The major differences between the versions are:
RFC1190からのプロトコル変化はプロトコル簡素化、明確化、および既存の実装における、拡大の成文化で動機づけられました。 このセクションは、主要な違いのリストを提供して、たぶんRFC1190に関する知識を持っている人だけに興味があります。 バージョンの主要な違いは以下の通りです。
o Elimination of "Hop IDentifiers" or HIDs. HIDs added much complexity
to the protocol and was found to be a major impediment to
interoperability. HIDs have been replaced by globally unique
identifiers called "Stream IDentifiers" or SIDs.
o 「ホップ識別子」かHIDsの除去。 HIDsは多くの複雑さをプロトコルに追加して、相互運用性の主要な障害であることがわかりました。 HIDsを「ストリーム識別子」かSIDsと呼ばれるグローバルにユニークな識別子に取り替えました。
o Elimination of a number of stream options. A number of options were
found to not be used by any implementation, or were thought to add
more complexity than value. These options were removed. Removed
options include: point-to-point, full-duplex, reverse charge, and
source route.
o 多くのストリームオプションの除去。 多くのオプションが、どんな実装によっても使用されないのがわかったか、または値より多くの複雑さを加えると考えられました。 これらのオプションを取り除きました。 取り除かれたオプションは: ポイントツーポイント、全二重は充電、および送信元経路を逆にします。
o Elimination of the concept of "subset" implementations. RFC1190
permitted subset implementations, to allow for easy implementation
and experimentation. This led to interoperability problems. Agents
implementing the protocol specified in this document, MUST implement
the full protocol. A number of the protocol functions are best-
effort. It is expected that some implementations will make more
effort than others in satisfying particular protocol requests.
o 「部分集合」実装の概念の除去。 RFC1190は、簡単な実装と実験を考慮するために部分集合実装を可能にしました。 これは相互運用性問題プロトコルを実装するのが本書では指定して、完全なプロトコルであると実装しなければならないエージェントに通じました。 多くのプロトコル機能が最も良い取り組みです。 いくつかの実装が特定のプロトコル要求を満たす際に他のものより多くの取り組みを作ると予想されます。
o Clarification of the capability of targets to request to join a
steam. RFC1190 can be interpreted to support target requests, but
most implementors did not understand this and did not add support
for this capability. The lack of this capability was found to be a
significant limitation in the ability to scale the number of
participants in a single ST stream. This clarification is based on
o 蒸気を接合するよう要求する目標の能力の明確化。 目標要求をサポートするためにRFC1190を解釈できますが、ほとんどの作成者は、これを理解しないで、またこの能力のサポートを加えませんでした。 この能力の不足はただ一つのSTストリームにおける、関係者の数をスケーリングする能力における重要な制限であることがわかりました。 明確化に基づいているこれ
Delgrossi & Berger, Editors Experimental [Page 9] RFC 1819 ST2+ Protocol Specification August 1995
[9ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
work done by IBM Heidelberg.
IBMハイデルベルグによって行われた仕事。
o Separation of functions between ST and supporting modules. An effort
was made to improve the separation of functions provided by ST and
those provided by other modules. This is reflected in reorganization
of some text and some PDU formats. ST was also made FlowSpec
independent, although it does define a FlowSpec for testing and
interoperability purposes.
o STとモジュールをサポートすることの間の機能の分離。 取り組みはSTによって提供された機能と他のモジュールで提供されたものの分離を改良させられました。 これは何らかのテキストといくつかのPDU形式の再編成に反映されます。 テストと相互運用性目的のためにFlowSpecを定義しますが、また、STをFlowSpecから独立するようにしました。
o General reorganization and re-write of the specification. This
document has been organized with the goal of improved readability
and clarity. Some sections have been added, and an effort was made
to improve the introduction of concepts.
o 仕様の一般再編成と書き直し。 このドキュメントは改良された読み易さと明快の目標でまとめられました。 数人のセクションが言い足されました、そして、取り組みは概念の導入を改良させられました。
1.4 Supporting Modules for ST2
1.4 ST2のためにモジュールをサポートすること。
ST2 is one piece of a larger mosaic. This section presents the overall communication architecture and clarifies the role of ST2 with respect to its supporting modules.
ST2は、より大きいモザイクの1つの断片です。 このセクションは、総合的な通信アーキテクチャを提示して、モジュールをサポートすることに関してST2の役割をはっきりさせます。
ST2 proposes a two-step communication model. In the first step, the real-time channels for the subsequent data transfer are built. This is called stream setup. It includes selecting the routes to the destinations and reserving the correspondent resources. In the second step, the data is transmitted over the previously established streams. This is called data transfer. While stream setup does not have to be completed in real-time, data transfer has stringent real- time requirements. The architecture used to describe the ST2 communication model includes:
ST2はツーステップコミュニケーションモデルを提案します。 第一歩では、順次データ転送のためのリアルタイムのチャンネルは組立しています。 これはストリームセットアップと呼ばれます。 それは、ルートを目的地に選択して、通信員リソースを予約するのを含んでいます。 第2ステップでは、データは以前に確立したストリームの上に送られます。これはデータ転送と呼ばれます。 ストリームセットアップはリアルタイムでで終了する必要はありませんが、データ転送には、厳しい本当の時間要件があります。 ST2コミュニケーションモデルについて説明するのに使用されるアーキテクチャは:
o a data transfer protocol for the transmission of real-time data
over the established streams,
o 確立したストリームの上のリアルタイムデータの伝達のためのデータ転送プロトコル
o a setup protocol to establish real-time streams based on the flow
specification,
o リアルタイムのストリームを確立するセットアッププロトコルは流れ仕様を基礎づけました。
o a flow specification to express user real-time requirements,
o ユーザのリアルタイムの要件を言い表す流れ仕様
o a routing function to select routes in the Internet,
o インターネットでルートを選択する経路選択機能
o a local resource manager to appropriately handle resources involved
in the communication.
o 適切にコミュニケーションにかかわるリソースを扱うローカル資源マネージャ。
This document defines a data protocol (ST), a setup protocol (SCMP), and a flow specification (ST2+ FlowSpec). It does not define a routing function and a local resource manager. However, ST2 assumes their existence.
このドキュメントはデータプロトコル(ST)、セットアッププロトコル(SCMP)、および流れ仕様(ST2+FlowSpec)を定義します。 それは経路選択機能とローカル資源マネージャを定義しません。 しかしながら、ST2はそれらの存在を仮定します。
Delgrossi & Berger, Editors Experimental [Page 10] RFC 1819 ST2+ Protocol Specification August 1995
[10ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
Alternative architectures are possible, see [RFC1633] for an example alternative architecture that could be used when implementing ST2.
[RFC1633]は、ST2を実装するとき使用できた例の代替手段アーキテクチャに関して代替のアーキテクチャが可能であることを見ます。
1.4.1 Data Transfer Protocol
1.4.1 データ転送プロトコル
The data transfer protocol defines the format of the data packets belonging to the stream. Data packets are delivered to the targets along the stream paths previously established by the setup protocol. Data packets are delivered with the quality of service associated with the stream.
データ転送プロトコルはストリームに属すデータ・パケットの書式を定義します。 データ・パケットは経路が以前にセットアッププロトコルで確立したストリームに沿って目標に提供されます。 データ・パケットはストリームに関連しているサービスの質で提供されます。
Data packets contain a globally unique stream identifier that indicates which stream they belong to. The stream identifier is also known by the setup protocol, which uses it during stream establishment. The data transfer protocol for ST2, known simply as ST, is completely defined by this document.
データ・パケットはそれらがどのストリームに属すかを示すグローバルにユニークなストリーム識別子を含んでいます。 また、ストリーム識別子はセットアッププロトコルによって知られています。(それは、ストリーム設立の間、それを使用します)。 単にSTとして知られているST2のためのデータ転送プロトコルはこのドキュメントによって完全に定義されます。
1.4.2 Setup Protocol
1.4.2 セットアッププロトコル
The setup protocol is responsible for establishing, maintaining, and releasing real-time streams. It relies on the routing function to select the paths from the source to the destinations. At each host/router on these paths, it presents the flow specification associated with the stream to the local resource manager. This causes the resource managers to reserve appropriate resources for the stream. The setup protocol for ST2 is called Stream Control Message Protocol, or SCMP, and is completely defined by this document.
セットアッププロトコルはリアルタイムのストリームを確立して、維持して、リリースするのに原因となります。それは、ソースから目的地まで経路を選択するために経路選択機能を当てにします。 これらの経路の各ホスト/ルータでは、それはストリームに関連している流れ仕様をローカル資源マネージャに提示します。 これで、資源管理プログラムはストリームのための適切なリソースを予約します。 ST2のためのセットアッププロトコルは、Stream Control Messageプロトコル、またはSCMPと呼ばれて、このドキュメントによって完全に定義されます。
1.4.3 Flow Specification
1.4.3 流れ仕様
The flow specification is a data structure including the ST2 applications' QoS requirements. At each host/router, it is used by the local resource manager to appropriately handle resources so that such requirements are met. Distributing the flow specification to all resource managers along the communication paths is the task of the setup protocol. However, the contents of the flow specification are transparent to the setup protocol, which simply carries the flow specification. Any operations on the flow specification, including updating internal fields and comparing flow specifications are performed by the resource managers.
流れ仕様はST2アプリケーションのQoS要件を含むデータ構造です。 各ホスト/ルータでは、それが適切にリソースを扱うのにローカル資源マネージャによって使用されるので、そのような必要条件は満たされます。 通信路に沿ったすべての資源管理プログラムに流れ仕様を分配するのは、セットアッププロトコルに関するタスクです。 しかしながら、流れ仕様の内容はセットアッププロトコルに見え透いています。(単に、それは、流れ仕様を運びます)。 流れ仕様におけるどんな操作でありも、内部の分野をアップデートするのを含んで、流れ仕様を比較するのは資源管理プログラムによって実行されます。
This document defines a specific flow specification format that allows for interoperability among ST2 implementations. This flow specification is intended to support a flow with a single transmission rate for all destinations in the stream. Implementations may support more than one flow specification format and the means are provided to add new formats as they are defined in the future. However, the flow specification format has to be consistent
このドキュメントはST2実装の中で相互運用性を考慮する特定の流れ仕様書式を定義します。 この流れ仕様がただ一つの通信速度でストリームにおけるすべての目的地に流れをサポートすることを意図します。 実装は、1回以上の流れが仕様形式であるとサポートするかもしれません、そして、それらが将来定義されるとき新しい書式を加えるために手段を前提とします。 しかしながら、流れ仕様形式は一貫していなければなりません。
Delgrossi & Berger, Editors Experimental [Page 11] RFC 1819 ST2+ Protocol Specification August 1995
[11ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
throughout the stream, i.e., it is not possible to use different flow specification formats for different parts of the same stream.
ストリーム中では、すなわち、同じストリームの異なった部品に異なった流れ仕様形式を使用するのは可能ではありません。
1.4.4 Routing Function
1.4.4 経路選択機能
The routing function is an external unicast route generation capability. It provides the setup protocol with the path to reach each of the desired destinations. The routing function is called on a hop-by-hop basis and provides next-hop information. Once a route is selected by the routing function, it persists for the whole stream lifetime. The routing function may try to optimize based on the number of targets, the requested resources, or use of local network multicast or bandwidth capabilities. Alternatively, the routing function may even be based on simple connectivity information.
経路選択機能は外部のユニキャストルート世代能力です。 それは、それぞれの必要な目的地に達するようにセットアッププロトコルに経路を提供します。 経路選択機能は、ホップごとのベースで呼ばれて、次のホップ情報を提供します。 ルートが経路選択機能によっていったん選択されると、それは全体のストリームのために生涯を固持しています。 経路選択機能は目標、要求されたリソースの数、または企業内情報通信網マルチキャストか帯域幅能力の使用に基づいて最適化しようとするかもしれません。 あるいはまた、経路選択機能は簡単な接続性情報に基づきさえするかもしれません。
The setup protocol is not necessarily aware of the criteria used by the routing function to select routes. It works with any routing function algorithm. The algorithm adopted is a local matter at each host/router and different hosts/routers may use different algorithms. The interface between setup protocol and routing function is also a local matter and therefore it is not specified by this document.
セットアッププロトコルは必ず経路選択機能によって使用される、ルートを選択する評価基準を意識しているというわけではありません。 それはどんな経路選択機能アルゴリズムでも働いています。 採用されたアルゴリズムは各ホスト/ルータで地域にかかわる事柄です、そして、異なったホスト/ルータは異なったアルゴリズムを使用するかもしれません。また、セットアッププロトコルと経路選択機能とのインタフェースは地域にかかわる事柄です、そして、したがって、それはこのドキュメントによって指定されません。
This version of ST does not support source routing. It does support route recording. It does include provisions that allow identification of ST capable neighbors. Identification of remote ST hosts/routers is not specifically addressed.
STのこのバージョンはソースにルーティングをサポートしません。 それはルート録音をサポートします。 それはSTの有能な隣人の識別を許す条項を含んでいます。 リモートSTホスト/ルータの識別は明確に扱われません。
1.4.5 Local Resource Manager
1.4.5 ローカル資源マネージャ
At each host/router traversed by a stream, the Local Resource Manager (LRM) is responsible for handling local resources. The LRM knows which resources are on the system and what capacity they can provide. Resources include:
ストリームによって横断された各ホスト/ルータでは、Local Resourceマネージャ(LRM)はローカル資源を扱うのに責任があります。 LRMは、システムの上にどのリソースがあるか、そして、それらがどんな容量を提供できるかを知っています。 リソースは:
o CPUs on end systems and routers to execute the application and
protocol software,
o アプリケーションとプロトコル・ソフトウエアを作成するエンドシステムとルータのCPU
o main memory space for this software (as in all real-time systems,
code should be pinned in main memory, as swapping it out would have
detrimental effects on system performance),
o このソフトウェア(コードはすべてのリアルタイムのシステムのように主記憶装置の中にピンで止められるべきです、外でそれを交換すると有害な影響がシステム性能に持たれているだろうというとき)のための主記憶装置スペース
o buffer space to store the data, e.g., communication packets, passing
through the nodes,
o ノードを通り抜けて、データを保存するスペース、例えばコミュニケーションパケットをバッファリングしてください。
o network adapters, and
o そしてアダプターがネットワークになってください。
Delgrossi & Berger, Editors Experimental [Page 12] RFC 1819 ST2+ Protocol Specification August 1995
[12ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o transmission networks between the nodes. Networks may be as simple
as point-to-point links or as complex as switched networks such as
Frame Relay and ATM networks.
o ノードの間の送電網。 ネットワークは、ポイントツーポイントがリンクされるのと同じくらい簡単であるか、Frame RelayやATMネットワークなどの交換網とまたは同じくらい複雑であるかもしれません。
During stream setup and modification, the LRM is presented by the setup protocol with the flow specification associated to the stream. For each resource it handles, the LRM is expected to perform the following functions:
ストリームセットアップと変更の間、ストリームへの流れ仕様が関連しているセットアッププロトコルはLRMを寄贈します。 それが扱う各リソースに関しては、LRMが以下の機能を実行すると予想されます:
o Stream Admission Control: it checks whether, given the flow
specification, there are sufficient resources left to handle the new
data stream. If the available resources are insufficient, the new
data stream must be rejected.
o 入場コントロールを流してください: それは、流れ仕様を考えて、十分なリソースが新しいデータ・ストリームを扱う残っているかどうかチェックします。 利用可能資源が不十分であるなら、新しいデータ・ストリームを拒絶しなければなりません。
o QoS Computation: it calculates the best possible performance the
resource can provide for the new data stream under the current
traffic conditions, e.g., throughput and delay values are computed.
o QoS計算: それはリソースが現在の交通状況の下で新しいデータ・ストリームに提供できる可能な限り良い性能について計算します、例えば、スループットと遅れ値は計算されます。
o Resource Reservation: it reserves the resource capacities required
to meet the desired QoS.
o 資源予約: それは能力が必要なQoSに会うのを必要としたリソースを予約します。
During data transfer, the LRM is responsible for:
データ転送の間、LRMは以下に責任があります。
o QoS Enforcement: it enforces the QoS requirements by appropriate
scheduling of resource access. For example, data packets from an
application with a short guaranteed delay must be served prior to
data from an application with a less strict delay bound.
o QoS実施: それはリソースアクセサリーの適切なスケジューリングでQoS要件を実施します。 例えば、アプリケーションからのデータの前にそれほど厳しくない遅れバウンドで少し保証された遅れがあるアプリケーションからのデータ・パケットに役立たなければなりません。
The LRM may also provide the following additional functions:
また、LRMは以下の追加機能を提供するかもしれません:
o Data Regulation: to smooth a stream's data traffic, e.g., as with the
leaky bucket algorithm.
o データ規則: 例えば、水漏れするバケツアルゴリズムのようにストリームのデータ通信量を整えるために。
o Policing: to prevent applications exceed their negotiated QoS, e.g.,
to send data at a higher rate than indicated in the flow
specification.
o 取り締まります: アプリケーションを防ぐために、それらの交渉されたQoSを超えてください、例えば、流れ仕様で示されるより高いレートにおける送信データに。
o Stream Preemption: to free up resources for other streams with
higher priority or importance.
o 先取りを流してください: より高い優先度か重要性で他のストリームのためのリソースを開けるために。
The strategies adopted by the LRMs to handle resources are resource- dependent and may vary at every host/router. However, it is necessary that all LRMs have the same understanding of the flow specification. The interface between setup protocol and LRM is a local matter at every host and therefore it is not specified by this document. An example of LRM is the Heidelberg Resource Administration Technique (HeiRAT) [VoHN93].
リソースを扱うためにLRMsによって採用された戦略は、リソースに依存していて、あらゆるホスト/ルータにおいて異なるかもしれません。 しかしながら、すべてのLRMsには流れ仕様の同じ理解があるのが必要です。 セットアッププロトコルとLRMとのインタフェースはすべてのホストの地域にかかわる事柄です、そして、したがって、それはこのドキュメントによって指定されません。 LRMに関する例はハイデルベルグResource政権Technique(HeiRAT)[VoHN93]です。
Delgrossi & Berger, Editors Experimental [Page 13] RFC 1819 ST2+ Protocol Specification August 1995
[13ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
It is also assumed that the LRM provides functions to compare flow specifications, i.e., to decide whether a flow specification requires a greater, equal, or smaller amount of resource capacities to be reserved.
また、LRMがすなわち、流れ仕様が予約されるべきリソース能力の、より大きいか、等しいか、よりわずかな量を必要とするかどうか決めるために流れ仕様を比較するために機能を提供すると思われます。
Delgrossi & Berger, Editors Experimental [Page 14] RFC 1819 ST2+ Protocol Specification August 1995
[14ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
1.5 ST2 Basic Concepts
1.5 ST2基本概念
The following sections present at an introductory level some of the fundamental ST2 concepts including streams, data transfer, and flow specification.
以下のセクションは紹介しているレベルでストリーム、データ転送、および流れ仕様を含む基本的なST2概念のいくつかを提示します。
Hosts Connections... : ...and Streams
==================== : ==============
data Origin : Origin
packets +-----------+ : +----+
+----|Application| : | |
| |-----------| : +----+
+--->| ST Agent | : | |
+-----------+ : | |
| : | |
V : | |
+-------------+ : | |
| | : | |
+-------------| Network A | : +-------+ +--+
| | | : | |
| +-------------+ : | Target 2|
| | Target 2 : | & Router|
| Target 1 | and Router : | |
| +-----------+ | +-----------+ : V V
| |Application|<-+ | |Application|<-+ : +----+ +----+
| |-----------| | | |-----------| | : | | | |
+->| ST Agent |--+ +->| ST Agent |--+ : +----+ +----+
+-----------+ +-----------+ :Target 1 | |
| : | |
V : | |
+-------------+ : | |
| | : | |
+-------------| Network B | : +-----+ |
| | | : | |
| +-------------+ : | |
| Target 3 | Target 4 : | |
| +-----------+ | +-----------+ : V V
| |Application|<-+ | |Application|<-+ : +----+ +----+
| |-----------| | | |-----------| | : | | | |
+->| ST Agent |--+ +->| ST Agent |--+ : +----+ +----+
+-----------+ +-----------+ : Target 3 Target 4
:
コネクションズを接待します… : ...そして、ストリーム==================== : ============== データOrigin: 発生源パケット+-----------+ : +----+ +----|アプリケーション| : | | | |-----------| : +----+ +--->| 第エージェント| : | | +-----------+ : | | | : | | V: | | +-------------+ : | | | | : | | +-------------| ネットワークA| : +-------+ +--+ | | | : | | | +-------------+ : | 目標2| | | 目標2: | ルータ| | 目標1| ルータ: | | | +-----------+ | +-----------+ : V V| |アプリケーション| <、-+ | |アプリケーション| <、-+ : +----+ +----+ | |-----------| | | |-----------| | : | | | | +->| 第エージェント|--+ +->| 第エージェント|--+ : +----+ +----+ +-----------+ +-----------+ :Target1| | | : | | V: | | +-------------+ : | | | | : | | +-------------| ネットワークB| : +-----+ | | | | : | | | +-------------+ : | | | 目標3| 目標4: | | | +-----------+ | +-----------+ : V V| |アプリケーション| <、-+ | |アプリケーション| <、-+ : +----+ +----+ | |-----------| | | |-----------| | : | | | | +->| 第エージェント|--+ +->| 第エージェント|--+ : +----+ +----+ +-----------+ +-----------+ : 目標3目標4:
Figure 3: The Stream Concept
図3: ストリーム概念
Delgrossi & Berger, Editors Experimental [Page 15] RFC 1819 ST2+ Protocol Specification August 1995
[15ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
1.5.1 Streams
1.5.1 ストリーム
Streams form the core concepts of ST2. They are established between a sending origin and one or more receiving targets in the form of a routing tree. Streams are uni-directional from the origin to the targets. Nodes in the tree represent so-called ST agents, entities executing the ST2 protocol; links in the tree are called hops. Any node in the middle of the tree is called an intermediate agent, or router. An agent may have any combination of origin, target, or intermediate capabilities.
ストリームはST2のコア概念を形成します。 それらは、ルーティング木の形で目標を受けながら、送付発生源と1以上の間に設立されます。 ストリームはuni発生源から目標まで方向上です。 木のノードはいわゆるSTエージェント、ST2プロトコルを実行する実体を表します。 木のリンクはホップと呼ばれます。 木の中央のどんなノードも仲介物質、またはルータと呼ばれます。 エージェントには、発生源、目標、または中間的能力のどんな組み合わせもあるかもしれません。
Figure 3 illustrates a stream from an origin to four targets, where the ST agent on Target 2 also functions as an intermediate agent. Let us use this Target 2/Router node to explain some basic ST2 terminology: the direction of the stream from this node to Target 3 and 4 is called downstream, the direction towards the Origin node upstream. ST agents that are one hop away from a given node are called previous-hops in the upstream, and next-hops in the downstream direction.
図3は発生源から4個の目標までストリームを例証します。また、Target2の上のSTエージェントは仲介物質としてそこで機能します。 何らかの基本的なST2用語について説明するのにこのTarget2/ルータノードを使用しましょう: このノードからTarget3と4までのストリームの方向は川下に呼ばれます、Originノード上流に向かった方向。 遠くで与えられたノードからワンバウンドであることのSTエージェントは川下の方向に上流、および次のホップの前のホップと呼ばれます。
Streams are maintained using SCMP messages. Typical SCMP messages are CONNECT and ACCEPT to build a stream, DISCONNECT and REFUSE to close a stream, CHANGE to modify the quality of service associated with a stream, and JOIN to request to be added to a stream.
ストリームは、SCMPメッセージを使用することで維持されます。 典型的なSCMPメッセージは、ストリームを閉じるためにストリーム、DISCONNECT、およびREFUSEを造るCONNECTとACCEPTです、ストリームに加えられるよう要求するストリーム、およびJOINに関連しているサービスの質を変更するCHANGE。
Each ST agent maintains state information describing the streams flowing through it. It can actively gather and distribute such information. It can recognize failed neighbor ST agents through the use of periodic HELLO message exchanges. It can ask other ST agents about a particular stream via a STATUS message. These ST agents then send back a STATUS-RESPONSE message. NOTIFY messages can be used to inform other ST agents of significant events.
それぞれのSTエージェントはそれを通して流れるストリームについて説明する州の情報を保守します。 それは活発にそのような情報を集散できます。 それは周期的なHELLO交換処理の使用で失敗した隣人STエージェントを見分けることができます。 それは特定のストリームに関してSTATUSメッセージで他のSTエージェントに尋ねることができます。 そして、これらのSTエージェントはSTATUS-RESPONSEメッセージを返送します。 重大な行事について他のSTエージェントに知らせるのにNOTIFYメッセージを使用できます。
ST2 offers a wealth of functionalities for stream management. Streams can be grouped together to minimize allocated resources or to process them in the same way in case of failures. During audio conferences, for example, only a limited set of participants may talk at once. Using the group mechanism, resources for only a portion of the audio streams of the group need to be reserved. Using the same concept, an entire group of related audio and video streams can be dropped if one of them is preempted.
ST2はストリーム管理のために豊富な機能性を提供します。 割り当てられたリソースを最小にするか、または同様に、失敗の場合にそれらを処理するためにストリームを一緒に分類できます。 オーディオ会議の間、例えば、限られたセットの関係者だけがすぐに、話すかもしれません。 グループメカニズムを使用して、グループのオーディオストリームの一部だけのためのリソースは、予約される必要があります。 同じ概念を使用して、それらの1つが先取りされるなら、関連するオーディオとビデオストリームの全体のグループを下げることができます。
1.5.2 Data Transmission
1.5.2 データ伝送
Data transfer in ST2 is simplex in the downstream direction. Data transport through streams is very simple. ST2 puts only a small header in front of the user data. The header contains a protocol identification that distinguishes ST2 from IP packets, an ST2 version
ST2のデータ転送は川下の方向へのシンプレクスです。 ストリームを通したデータ伝送は非常に簡単です。 ST2は利用者データの正面に小さいヘッダーだけを置きます。 ヘッダーはIPパケット、ST2バージョンとST2を区別するプロトコル識別を含んでいます。
Delgrossi & Berger, Editors Experimental [Page 16] RFC 1819 ST2+ Protocol Specification August 1995
[16ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
number, a priority field (specifying a relative importance of streams in cases of conflict), a length counter, a stream identification, and a checksum. These elements form a 12-byte header.
数、優先権分野(闘争の場合における、ストリームの相対的な重要性を指定する)、長さのカウンタ、ストリーム識別、およびチェックサム。 これらの要素は12バイトのヘッダーを形成します。
Efficiency is also achieved by avoiding fragmentation and reassembly on all agents. Stream establishment yields a maximum message size for data packets on a stream. This maximum message size is communicated to the upper layers, so that they provide data packets of suitable size to ST2.
また、効率は、すべてのエージェントの上で断片化と再アセンブリを避けることによって、達成されます。 ストリーム設立はストリームでデータ・パケットのための最大のメッセージサイズをもたらします。 この最大のメッセージサイズは上側の層に伝えられます、適当なサイズのデータ・パケットをST2に供給するように。
Communication with multiple next-hops can be made even more efficient using MAC Layer multicast when it is available. If a subnet supports multicast, a single multicast packet is sufficient to reach all next-hops connected to this subnet. This leads to a significant reduction of the bandwidth requirements of a stream. If multicast is not provided, separate packets need to be sent to each next-hop.
それが利用可能であるときに、MAC Layerマルチキャストを使用することで複数の次のホップとのコミュニケーションをさらに効率的にすることができます。 サブネットがマルチキャストをサポートするなら、単一のマルチキャストパケットは、このサブネットに接続されたすべての次のホップに達するように十分です。 これはストリームに関する帯域幅要件のかなりの減少に通じます。 マルチキャストが提供されないなら、別々のパケットは、それぞれの次のホップに送られる必要があります。
As ST2 relies on reservation, it does not contain error correction mechanisms features for data exchange such as those found in TCP. It is assumed that real-time data, such as digital audio and video, require partially correct delivery only. In many cases, retransmitted packets would arrive too late to meet their real-time delivery requirements. Also, depending on the data encoding and the particular application, a small number of errors in stream data are acceptable. In any case, reliability can be provided by layers on top of ST2 when needed.
ST2が予約に依存するとき、それはデータ交換のためのTCPで見つけられたものなどのエラー修正メカニズム機能を含んでいません。 デジタル・オーディオやビデオなどのリアルタイムデータが部分的に正しい配送だけを必要とすると思われます。 多くの場合、再送されたパケットはそれらのリアルタイムの配送必要条件を満たすのにおいてあまりに遅く、到着するでしょう。 また、zデータの符号化と特定用途によって、ストリームデータにおける少ない数の誤りも許容できます。 どのような場合でも、必要であると、ST2の上で層のそばで信頼性を提供できます。
1.5.3 Flow Specification
1.5.3 流れ仕様
As part of establishing a connection, SCMP handles the negotiation of quality-of-service parameters for a stream. In ST2 terminology, these parameters form a flow specification (FlowSpec) which is associated with the stream. Different versions of FlowSpecs exist, see [RFC1190], [DHHS92] and [RFC1363], and can be distinguished by a version number. Typically, they contain parameters such as average and maximum throughput, end-to-end delay, and delay variance of a stream. SCMP itself only provides the mechanism for relaying the quality-of-service parameters.
取引関係を築く一部として、SCMPはストリームのためのサービスの質パラメタの交渉を扱います。 ST2用語では、これらのパラメタはストリームに関連している流れ仕様(FlowSpec)を結びます。 FlowSpecsの異なった見解は、存在していて、[RFC1190]、[DHHS92]、および[RFC1363]を見て、バージョン番号で区別できます。 通常、それらはストリームの平均して最大のスループットや、終わりから終わりへの遅れや、遅れ変化などのパラメタを含んでいます。 SCMP自身はサービスの質パラメタをリレーするのにメカニズムを提供するだけです。
Three kinds of entities participate in the quality-of-service negotiation: application entities on the origin and target sites as the service users, ST agents, and local resource managers (LRM). The origin application supplies the initial FlowSpec requesting a particular service quality. Each ST agent which obtains the FlowSpec as part of a connection establishment message, it presents the local resource manager with it. ST2 does not determine how resource managers make reservations and how resources are scheduled according to these reservations; ST2, however, assumes these mechanisms as its
3種類の実体はサービスの質交渉に参加します: 発生源に関するアプリケーション実体とサービス利用者、STエージェント、およびローカル資源マネージャ(LRM)としての目標サイト。 発生源アプリケーションは特定のサービス品質を要求する初期のFlowSpecを供給します。 コネクション確立メッセージの一部としてFlowSpecを入手するそれぞれのSTエージェント、それはローカル資源マネージャにそれを与えます。 ST2は、資源管理プログラムがどのように予約とこれらに従ってリソースがどう予定されているかを予約にするかを決定しません。 しかしながら、ST2がこれらのメカニズムを仮定する、それ
Delgrossi & Berger, Editors Experimental [Page 17] RFC 1819 ST2+ Protocol Specification August 1995
[17ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
basis.
基礎。
An example of the FlowSpec negotiation procedure is illustrated in Figure 4. Depending on the success of its local reservations, the LRM updates the FlowSpec fields and returns the FlowSpec to the ST agent, which passes it downstream as part of the connection message. Eventually, the FlowSpec is communicated to the application at the target which may base its accept/reject decision for establishing the connection on it and may finally also modify the FlowSpec. If a target accepts the connection, the (possibly modified) FlowSpec is propagated back to the origin which can then calculate an overall service quality for all targets. The application entity at the origin may later request a CHANGE to adjust reservations.
FlowSpec交渉手順に関する例は図4で例証されます。 地方の予約の成功によって、LRMはSTエージェントにFlowSpec分野をアップデートして、FlowSpecを返します。(そのエージェントは、接続メッセージの一部としてそれを川下に通過します)。 結局FlowSpecが基づくかもしれない目標のアプリケーションに伝えられる、それ、それで接続を確立して、最終的に確立できるように決定を受け入れるか、または拒絶してください、そして、また、FlowSpecを変更してください。 目標が接続を受け入れるなら、(ことによると変更されています)のFlowSpecは次にすべての目標のために総合的なサービス品質について計算できる発生源に伝播して戻されます。 発生源におけるアプリケーション実体は、後で予約を調整するようCHANGEに要求するかもしれません。
Origin Router Target 1
+------+ 1a +------+ 1b +------+
| |-------------->| |------------->| |
+------+ +------+ +------+
^ | ^ |
| | | 2 |
| | +------------------------------------------+
+ +
+-------------+ \ \ +-------------+ +-------------+
|Max Delay: 12| \ \ |Max Delay: 12| |Max Delay: 12|
|-------------| \ \ |-------------| |-------------|
|Min Delay: 2| \ \ |Min Delay: 5| |Min Delay: 9|
|-------------| \ \ |-------------| |-------------|
|Max Size:4096| + + |Max Size:2048| |Max Size:2048|
+-------------+ | | +-------------+ +-------------+
FlowSpec | | 1
| +---------------+
| |
| V
2 | +------+
+---------------| |
+------+
Target 2
+-------------+
|Max Delay: 12|
|-------------|
|Min Delay: 4|
|-------------|
|Max Size:4096|
+-------------+
発生源ルータ目標1+------+ 1a+------+ 1b+------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| +------+ +------+ +------+ ^ | ^ | | | | 2 | | | +------------------------------------------+ + + +-------------+ \ \ +-------------+ +-------------+ |マックスDelay: 12| \ \ |マックスDelay: 12| |マックスDelay: 12| |-------------| \ \ |-------------| |-------------| |分は延着します: 2| \ \ |分は延着します: 5| |分は延着します: 9| |-------------| \ \ |-------------| |-------------| |マックスSize: 4096| + + |マックスSize: 2048| |マックスSize: 2048| +-------------+ | | +-------------+ +-------------+ FlowSpec| | 1 | +---------------+ | | | V2| +------+ +---------------| | +------+ 目標2+-------------+ |マックスDelay: 12| |-------------| |分は延着します: 4| |-------------| |マックスSize: 4096| +-------------+
Figure 4: Quality-of-Service Negotiation with FlowSpecs
図4: FlowSpecsとのサービスの質交渉
Delgrossi & Berger, Editors Experimental [Page 18] RFC 1819 ST2+ Protocol Specification August 1995
[18ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
1.6 Outline of This Document
1.6 このドキュメントのアウトライン
This document contains the specification of the ST2+ version of the ST2 protocol. In the rest of the document, whenever the terms "ST" or "ST2" are used, they refer to the ST2+ version of ST2.
このドキュメントはST2プロトコルのST2+バージョンの仕様を含んでいます。 ドキュメントの残りでいつ、用語“ST"か「ST2"が使用されている、彼らはST2のST2+バージョンを示す」。
The document is organized as follows:
ドキュメントは以下の通りまとめられます:
o Section 2 describes the ST2 user service from an application point
of view.
o セクション2はアプリケーション観点からST2ユーザサービスについて説明します。
o Section 3 illustrates the ST2 data transfer protocol, ST.
o ST、セクション3はST2データ転送プロトコルを例証します。
o Section 4 through Section 8 specify the ST2 setup protocol, SCMP.
o SCMP、セクション8を通したセクション4はST2セットアッププロトコルを指定します。
o the ST2 flow specification is presented in Section 9.
o ST2流れ仕様はセクション9に提示されます。
o the formats of protocol elements and PDUs are defined in Section 10.
o プロトコル要素とPDUsの書式はセクション10で定義されます。
2. ST2 User Service Description
2. ST2ユーザサービス記述
This section describes the ST user service from the high-level point of view of an application. It defines the ST stream operations and primitive functions. It specifies which operations on streams can be invoked by the applications built on top of ST and when the ST primitive functions can be legally executed. Note that the presented ST primitives do not specify an API. They are used here with the only purpose of illustrating the service model for ST.
このセクションはアプリケーションのハイレベルの観点からSTユーザサービスについて説明します。 それはSTストリーム操作と原始関数を定義します。 それはSTの上で組立てられたアプリケーションでストリームにおけるどの操作を呼び出すことができるか、そして、いつST原始関数を法的に実行できるかを指定します。 提示されたST基関数がAPIを指定しないことに注意してください。 それらはSTのためにサービスモデルを例証する唯一の目的と共にここで使用されます。
2.1 Stream Operations and Primitive Functions
2.1 ストリーム操作と原始関数
An ST application at the origin may create, expand, reduce, change, send data to, and delete a stream. When a stream is expanded, new targets are added to the stream; when a stream is reduced, some of the current targets are dropped from it. When a stream is changed, the associated quality of service is modified.
発生源におけるSTアプリケーションが作成して、広げて、減らして、変えて、データを送るかもしれない、ストリームを削除してください。 ストリームが広げられるとき、新しい目標はストリームに加えられます。 ストリームが減少するとき、いくつかの現在の目標がそれから下げられます。 ストリームを変えるとき、関連サービスの質は変更しています。
An ST application at the target may join, receive data from, and leave a stream. This translates into the following stream operations:
目標のアプリケーションが接合して、データを受け取って、ストリームを残すかもしれないST。 これは以下のストリーム操作に翻訳されます:
o OPEN: create new stream [origin], CLOSE: delete stream [origin],
o 以下を開いてください。 CLOSE、新しいストリーム[発生源]を作成してください: ストリーム[発生源]を削除してください。
o ADD: expand stream, i.e., add new targets to it [origin],
o 追加: ストリームを広げてください、そして、すなわち、それ[発生源]に新しい目標を加えてください。
o DROP: reduce stream, i.e., drop targets from it [origin],
o 以下を落としてください。 ストリームを減少させてください、そして、すなわち、それ[発生源]から目標を下げてください。
o JOIN: join a stream [target], LEAVE: leave a stream [target],
o 接合します: LEAVE、ストリーム[目標]を接合してください: ストリーム[目標]を残してください。
Delgrossi & Berger, Editors Experimental [Page 19] RFC 1819 ST2+ Protocol Specification August 1995
[19ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o DATA: send data through stream [origin],
o データ: ストリーム[発生源]を通してデータを送ってください。
o CHG: change a stream's QoS [origin],
o CHG: ストリームのQoS[発生源]を変えてください。
Each stream operation may require the execution of several primitive functions to be completed. For instance, to open a new stream, a request is first issued by the sender and an indication is generated at one or more receivers; then, the receivers may each accept or refuse the request and the correspondent indications are generated at the sender. A single receiver case is shown in Figure 5 below.
それぞれのストリーム操作は、いくつかの原始関数の実行が終了するのを必要とするかもしれません。 例えば、新しいストリームを開くために、要求は最初に送付者が出されます、そして、指示は1台以上の受信機で生成されます。 次に、受信機は、それぞれ要求を受け入れるか、または拒否するかもしれません、そして、通信員指摘は送付者で生成されます。 ただ一つの受信機ケースは以下の図5で見せられます。
Sender Network Receiver
| | |
OPEN.req | | |
|-----------------> | |
| |-----------------> |
| | | OPEN.ind
| | | OPEN.accept
| |<----------------- |
|<----------------- | |
OPEN.accept-ind | | |
| | |
送付者ネットワーク受信機| | | OPEN.req| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| OPEN.ind| | | OPEN.accept| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| OPEN.accept-ind| | | | | |
Figure 5: Primitives for the OPEN Stream Operation
図5: 開いている流れの操作のための基関数
Delgrossi & Berger, Editors Experimental [Page 20] RFC 1819 ST2+ Protocol Specification August 1995
[20ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
Table 1 defines the ST service primitive functions associated to each stream operation. The column labelled "O/T" indicates whether the primitive is executed at the origin or at the target.
テーブル1は原始関数がそれぞれの流れの操作に関連づけたSTサービスを定義します。 「O/T」とラベルされたコラムは、原始が起源において、または、目標で実行されるかどうかを示します。
+===================================================+
|Primitive | Descriptive |O/T|
|===================================================|
|OPEN.req | open a stream | O |
|OPEN.ind | connection request indication | T |
|OPEN.accept | accept stream | T |
|OPEN.refuse | refuse stream | T |
|OPEN.accept-ind| connection accept indication | O |
|OPEN.refuse-ind| connection refuse indication | O |
|ADD.req | add targets to stream | O |
|ADD.ind | add request indication | T |
|ADD.accept | accept stream | T |
|ADD.refuse | refuse stream | T |
|ADD.accept-ind | add accept indication | O |
|ADD.refuse-ind | add refuse indication | O |
|JOIN.req | join a stream | T |
|JOIN.ind | join request indication | O |
|JOIN.reject | reject a join | O |
|JOIN.reject-ind| join reject indication | T |
|DATA.req | send data | O |
|DATA.ind | receive data indication | T |
|CHG.req | change stream QoS | O |
|CHG.ind | change request indication | T |
|CHG.accept | accept change | T |
|CHG.refuse | refuse change | T |
|CHG.accept-ind | change accept indication | O |
|CHG.refuse-ind | change refuse indication | O |
|DROP.req | drop targets | O |
|DROP.ind | disconnect indication | T |
|LEAVE.req | leave stream | T |
|LEAVE.ind | leave stream indication | O |
|CLOSE.req | close stream | O |
|CLOSE.ind | close stream indication | T |
+---------------------------------------------------+
+===================================================+ |原始| 描写的である|O/T| |===================================================| |OPEN.req| 流れを開いてください。| O| |OPEN.ind| 接続要求指示| T| |OPEN.accept| 流れを受け入れてください。| T| |OPEN.refuse| 廃物の流れ| T| |OPEN.accept-ind| 接続は指示を受け入れます。| O| |OPEN.refuse-ind| 接続廃物指示| O| |ADD.req| 流す目標を加えてください。| O| |ADD.ind| 要求指示を加えてください。| T| |ADD.accept| 流れを受け入れてください。| T| |ADD.refuse| 廃物の流れ| T| |ADD.accept-ind| 指示を受け入れるように言い足してください。| O| |ADD.refuse-ind| 廃物指示を加えてください。| O| |JOIN.req| 流れに参加してください。| T| |JOIN.ind| 要求指示に参加してください。| O| |JOIN.reject| aが接合する廃棄物| O| |JOIN.reject-ind| 廃棄物指示に参加してください。| T| |DATA.req| 送信データ| O| |DATA.ind| 受信データ指示| T| |CHG.req| 変化流れのQoS| O| |CHG.ind| 変更要求指示| T| |CHG.accept| 変化を受け入れてください。| T| |CHG.refuse| 変化を拒否してください。| T| |CHG.accept-ind| 変化は指示を受け入れます。| O| |CHG.refuse-ind| 変化廃物指示| O| |DROP.req| 目標を落としてください。| O| |DROP.ind| 指示を外してください。| T| |LEAVE.req| 流れを残してください。| T| |LEAVE.ind| 流れの指示を残してください。| O| |CLOSE.req| 近くでは、流れてください。| O| |CLOSE.ind| 流れの指示を終えてください。| T| +---------------------------------------------------+
Table 1: ST Primitives
テーブル1: 第基関数
2.2 State Diagrams
2.2 州のダイヤグラム
It is not sufficient to define the set of ST stream operations. It is also necessary to specify when the operations can be legally executed. For this reason, a set of states is now introduced and the transitions from one state to the others are specified. States are defined with respect to a single stream. The previously defined
ST流れの操作のセットを定義するのは十分ではありません。 また、いつ操作を法的に実行できるかを指定するのも必要です。 この理由で、現在1セットの州を導入します、そして、1つの州から他のものまでの変遷を指定します。 州はただ一つの流れに関して定義されます。 以前に、定義されています。
Delgrossi & Berger, Editors Experimental [Page 21] RFC 1819 ST2+ Protocol Specification August 1995
[21ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
stream operations can be legally executed only from an appropriate state.
単に適切な状態から流れの操作を法的に実行できます。
An ST agent may, with respect to an ST stream, be in one of the following states:
STの流れに関して、STエージェントは以下の州の1つにいるかもしれません:
o IDLE: the stream has not been created yet.
o 怠けます: 流れはまだ作成されていません。
o PENDING: the stream is in the process of being established.
o 未定: 設立されることの途中に流れがあります。
o ACTIVE: the stream is established and active.
o アクティブ: 流れは、確立していて活発です。
o ADDING: the stream is established. A stream expansion is underway.
o 加えます: 流れは確立されます。 流れの拡大は進行中です。
o CHGING: the stream is established. A stream change is underway.
o CHGING: 流れは確立されます。 流れの変化は進行中です。
Previous experience with ST has lead to limits on stream operations that can be executed simultaneously. These restrictions are:
STの以前の経験は同時に実行できる流れの操作における限界にリードを持っています。 これらの制限は以下の通りです。
1. A single ADD or CHG operation can be processed at one time. If
an ADD or CHG is already underway, further requests are queued
by the ST agent and handled only after the previous operation
has been completed. This also applies to two subsequent
requests of the same kind, e.g., two ADD or two CHG operations.
The second operation is not executed until the first one has
been completed.
1. ひところ、独身のADDかCHG操作を処理できます。 ADDかCHGが既に進行中であるなら、古い手術痕が終了した後にだけ、さらなる要求は、STエージェントによって列に並ばせられて、扱われます。 また、これは同じ種類、例えば、2の2つのその後の要求にADDか2つのCHG操作を適用します。 最初のものが完成するまで、2番目の操作は実行されません。
2. Deleting a stream, leaving a stream, or dropping targets from a
stream is possible only after stream establishment has been
completed. A stream is considered to be established when all
the next-hops of the origin have either accepted or refused the
stream. Note that stream refuse is automatically forced after
timeout if no reply comes from a next-hop.
2. 流れの設立が終了した後にだけ流れを削除するか、流れを残すか、または流れから目標を落とすのが可能です。 起源のすべての次のホップが流れを受け入れるか、または拒否したとき、流れが確立していると考えられます。 回答が全く次のホップから来ないなら流れの廃物がタイムアウトの後に自動的に強制されることに注意してください。
3. An ST agent forwards data only along already established paths
to the targets, see also Section 3.1. A path is considered to
be established when the next-hop on the path has explicitly
accepted the stream. This implies that the target and all other
intermediate ST agents are ready to handle the incoming data
packets. In no cases an ST agent will forward data to a
next-hop ST agent that has not explicitly accepted the stream.
To be sure that all targets receive the data, an application
should send the data only after all paths have been
established, i.e., the stream is established.
3. セクション3.1も、STエージェントが既に確立した経路だけに沿ってデータを目標に転送するのを見ます。 経路の次のホップが明らかに流れを受け入れたとき、経路が確立していると考えられます。 目標と他のすべての中間的STエージェントがこれは受信データパケットを扱うつもりである準備ができています。 どんな場合でも、STエージェントは明らかに流れを受け入れていない次のホップSTエージェントにデータを転送しないでしょう。 すべての目標がデータを受信して、すなわち、すべての経路が確立された後にだけアプリケーションがデータを送るべきであるのを確信しているように、流れは確立されます。
Delgrossi & Berger, Editors Experimental [Page 22] RFC 1819 ST2+ Protocol Specification August 1995
[22ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4. It is allowed to send data from the CHGING and ADDING states.
While sending data from the CHGING state, the quality of
service to the targets affected by the change should be assumed
to be the more restrictive quality of service. When sending
data from the ADDING state, the targets that receive the data
include at least all the targets that were already part of the
stream at the time the ADD operation was invoked.
4. それはCHGINGとADDING州からデータを送ることができます。 CHGING状態からデータを送る間、変化で影響を受ける目標へのサービスの質は、より制限しているサービスの質であると思われるべきです。 ADDING状態からデータを送るとき、データを受信する目標は少なくともADD操作が呼び出されたとき既に流れの一部であったすべての目標を含んでいます。
The rules introduced above require ST agents to queue incoming requests when the current state does not allow to process them immediately. In order to preserve the semantics, ST agents have to maintain the order of the requests, i.e., implement FIFO queuing. Exceptionally, the CLOSE request at the origin and the LEAVE request at the target may be immediately processed: in these cases, the queue is deleted and it is possible that requests in the queue are not processed.
すぐに現状でそれらを処理しないとき、上で導入された規則は、STエージェントが入って来る要求を列に並ばせるのを必要とします。 意味論を保存するために、STエージェントはすなわち、要求、道具先入れ先出し法の列を作りの注文を維持しなければなりません。 例外的に、起源におけるCLOSE要求と目標でのLEAVE要求はすぐに、処理されるかもしれません: これらの場合では、待ち行列は削除されます、そして、待ち行列における要求が処理されないのは、可能です。
The following state diagrams define the ST service. Separate diagrams are presented for the origin and the targets.
以下の州のダイヤグラムはSTサービスを定義します。 別々のダイヤグラムは起源と目標のために提示されます。
The symbol (a/r)* indicates that all targets in the target list have explicitly accepted or refused the stream, or refuse has been forced after timeout. If the target list is empty, i.e., it contains no targets, the (a/r)* condition is immediately satisfied, so the empty stream is created and state ESTBL is entered.
シンボル(/r)*は、目標リストのすべての目標が明らかに流れを受け入れるか、拒否した、または廃物がタイムアウトの後に強制されたのを示します。 目標リストが空であるなら、目標を全く含んでいません、そして、(/r)*状態はすぐに満たされています、そして、したがって、空の流れは作成されます、そして、州のESTBLは入られます。
The separate OPEN and ADD primitives at the target are for conceptual purposes only. The target is actually unable to distinguish between an OPEN and an ADD. This is reflected in Figure 7 and Table 3 through the notation OPEN/ADD.
目標の別々のオープンとADD基関数は概念的な目的だけのためのものです。 目標は実際にオープンとADDを見分けることができません。 これは記法オープン/ADDで図7とTable3に反映されます。
Delgrossi & Berger, Editors Experimental [Page 23] RFC 1819 ST2+ Protocol Specification August 1995
[23ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
+------------+
| |<-------------------+
+---------->| IDLE |-------------+ |
| | | OPEN.req | |
| +------------+ | |
CLOSE.req | CLOSE.req ^ ^ CLOSE.req V | CLOSE.req
| | | +---------+ |
| | | | PENDING |-|-+ JOIN.reject
| | -------------| |<|-+
| JOIN.reject | +---------+ |
| DROP.req +----------+ | |
| +-----| | | |
| | | ESTDL | OPEN.(a/r)* | |
| +---->| |<------------+ |
| +----------+ |
| | ^ | ^ |
| | | | | |
+----------+ CHG.req| | | | Add.(a/r)* +----------+
| |<-------+ | | +-------------- | |
| CHGING | | | | ADDING |
| |-----------+ +----------------->| |
+----------+ CHG.(a/r)* JOIN.ind +----------+
| ^ ADD.req | ^
| | | |
+---+ +---+
DROP.req DROP.req
JOIN.reject JOIN.reject
+------------+ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +---------->| 怠けてください。|-------------+ | | | | OPEN.req| | | +------------+ | | CLOSE.req| CLOSE.req^ ^CLOSE.req V| CLOSE.req| | | +---------+ | | | | | 未定|-|-+ JOIN.reject| | -------------| | <|、-+ | JOIN.reject| +---------+ | | DROP.req+----------+ | | | +-----| | | | | | | ESTDL| 戸外(/r)*| | | +---->| | <、-、-、-、-、-、-、-、-、-、-、--+ | | +----------+ | | | ^ | ^ | | | | | | | +----------+ CHG.req| | | | . (/r)*+を加えてください。----------+ | | <、-、-、-、-、-、--+ | | +-------------- | | | CHGING| | | | 加えます。| | |-----------+ +----------------->|、| +----------+ CHG(/r)*JOIN.ind+----------+ | ^ADD.req| ^ | | | | +---+ +---+ DROP.req DROP.req JOIN.reject JOIN.reject
Figure 6: ST Service at the Origin
図6: 起源における第サービス
+--------+
| |-----------------------+
| IDLE | |
| |<---+ | OPEN/ADD.ind
+--------+ | CLOSE.ind | JOIN.req
^ | OPEN/ADD.refuse |
| | JOIN.refect-ind |
CLOSE.ind | | V
DROP.ind | | +---------+
LEAVE.req | +-------------| |
| | PENDING |
+-------+ | |
| | +---------+
| ESTBL | OPEN/ADD.accept |
| |<-----------------------+
+-------+
+--------+ | |-----------------------+ | 怠けてください。| | | | <、-、--+ | 戸外/ADD.ind+--------+ | CLOSE.ind| JOIN.req^| 戸外/ADD.refuse| | | JOIN.refect-ind| CLOSE.ind| | V DROP.ind| | +---------+ LEAVE.req| +-------------| | | | 未定| +-------+ | | | | +---------+ | ESTBL| 戸外/ADD.accept| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +-------+
Figure 7: ST Service at the Target
図7: 目標での第サービス
Delgrossi & Berger, Editors Experimental [Page 24] RFC 1819 ST2+ Protocol Specification August 1995
[24ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
2.3 State Transition Tables
2.3 状態遷移テーブル
Table 2 and Table 3 define which primitives can be processed from which states and the possible state transitions.
テーブル2とTable3は、どの州からどの基関数を処理できるかを定義します、そして、可能な状態は移行します。
+======================================================================+
|Primitive |IDLE| PENDING | ESTBL | CHGING | ADDING |
|======================================================================|
|OPEN.req | ok | - | - | - | - |
|OPEN.accept-ind| - |if(a,r)*->ESTBL| - | - | - |
|OPEN.refuse-ind| - |if(a,r)*->ESTBL| - | - | - |
|ADD.req | - | queued |->ADDING| queued | queued |
|ADD.accept-ind | - | - | - | - |if(a,r)* |
| | - | - | - | - |->ESTBL |
|ADD.refuse-ind | - | - | - | - |if(a,r)* |
| | - | - | - | - |->ESTBL |
|JOIN.ind | - | queued |->ADDING| queued |queued |
|JOIN.reject | - | OK | ok | ok | ok |
|DATA.req | - | - | ok | ok | ok |
|CHG.req | - | queued |->CHGING| queued |queued |
|CHG.accept-ind | - | - | - |if(a,r)* | - |
| | - | - | - |->ESTBL | - |
|CHG.refuse.ind | - | - | - |if(a,r)* | - |
| | - | - | - |->ESTBL | - |
|DROP.req | - | - | ok | ok | ok |
|LEAVE.ind | - | OK | ok | ok | ok |
|CLOSE.req | - | OK | ok | ok | ok |
+----------------------------------------------------------------------+
Table 2: Primitives and States at the Origin
+======================================================================+ |原始|怠けてください。| 未定| ESTBL| CHGING| 加えます。| |======================================================================| |OPEN.req| OK| - | - | - | - | |OPEN.accept-ind| - |(a、r)*->ESTBLです。| - | - | - | |OPEN.refuse-ind| - |(a、r)*->ESTBLです。| - | - | - | |ADD.req| - | 列を作ります。|->付加| 列を作ります。| 列を作ります。| |ADD.accept-ind| - | - | - | - |(a、r)*です。| | | - | - | - | - |->ESTBL| |ADD.refuse-ind| - | - | - | - |(a、r)*です。| | | - | - | - | - |->ESTBL| |JOIN.ind| - | 列を作ります。|->付加| 列を作ります。|列を作ります。| |JOIN.reject| - | OK| OK| OK| OK| |DATA.req| - | - | OK| OK| OK| |CHG.req| - | 列を作ります。|->CHGING| 列を作ります。|列を作ります。| |CHG.accept-ind| - | - | - |(a、r)*です。| - | | | - | - | - |->ESTBL| - | |CHG.refuse.ind| - | - | - |(a、r)*です。| - | | | - | - | - |->ESTBL| - | |DROP.req| - | - | OK| OK| OK| |LEAVE.ind| - | OK| OK| OK| OK| |CLOSE.req| - | OK| OK| OK| OK| +----------------------------------------------------------------------+ テーブル2: 起源における基関数と州
+======================================================+
| Primitive | IDLE | PENDING | ESTBL |
|======================================================|
| OPEN/ADD.ind | ->PENDING | - | - |
| OPEN/ADD.accept | - | ->ESTBL | - |
| OPEN/ADD.refuse | - | ->IDLE | - |
| JOIN.req | ->PENDING | - | - |
| JOIN.reject-ind |- | ->IDLE | - |
| DATA.ind | - | - | ok |
| CHG.ind | - | - | ok |
| CHG.accept | - | - | ok |
| DROP.ind | - | ok | ok |
| LEAVE.req | - | ok | ok |
| CLOSE.ind | - | ok | ok |
| CHG.ind | - | - | ok |
+------------------------------------------------------+
Table 3: Primitives and States at the Target
+======================================================+ | 原始| 怠けてください。| 未定| ESTBL| |======================================================| | 戸外/ADD.ind| -未定の>。| - | - | | 戸外/ADD.accept| - | ->ESTBL| - | | 戸外/ADD.refuse| - | ->活動していません。| - | | JOIN.req| -未定の>。| - | - | | JOIN.reject-ind|- | ->活動していません。| - | | DATA.ind| - | - | OK| | CHG.ind| - | - | OK| | CHG.accept| - | - | OK| | DROP.ind| - | OK| OK| | LEAVE.req| - | OK| OK| | CLOSE.ind| - | OK| OK| | CHG.ind| - | - | OK| +------------------------------------------------------+ テーブル3: 目標の基関数と州
Delgrossi & Berger, Editors Experimental [Page 25] RFC 1819 ST2+ Protocol Specification August 1995
[25ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
3. The ST2 Data Transfer Protocol
3. ST2データ転送プロトコル
This section presents the ST2 data transfer protocol, ST. First, data transfer is described in Section 3.1, then, the data transfer protocol functions are illustrated in Section 3.2.
このセクションは最初に、ST2データ転送プロトコル(ST)を提示して、データ転送はセクション3.1で説明されて、次に、データ転送プロトコル機能はセクション3.2で例証されます。
3.1 Data Transfer with ST
3.1第データ転送
Data transmission with ST is unreliable. An application is not guaranteed that the data reaches its destinations and ST makes no attempts to recover from packet loss, e.g., due to the underlying network. However, if the data reaches its destination, it should do so according to the quality of service associated with the stream.
STがあるデータ伝送は頼り無いです。 アプリケーションはデータの範囲の目的地とSTがパケット損失から回復する試みを全くしないのが保証されません、例えば、基本的なネットワークのため。 しかしながら、データが目的地に到着するなら、流れに関連しているサービスの質に従って、それはそうするべきです。
Additionally, ST may deliver data corrupted in transmission. Many types of real-time data, such as digital audio and video, require partially correct delivery only. In many cases, retransmitted packets would arrive too late to meet their real-time delivery requirements. On the other hand, depending on the data encoding and the particular application, a small number of errors in stream data are acceptable. In any case, reliability can be provided by layers on top of ST2 if needed.
さらに、STはトランスミッションで崩壊するデータを送るかもしれません。 多くのタイプに関するデジタル・オーディオやビデオなどのリアルタイムデータは部分的に正しい配送だけを必要とします。 多くの場合、再送されたパケットはそれらのリアルタイムの配送必要条件を満たすのにおいてあまりに遅く、到着するでしょう。 他方では、zデータの符号化と特定用途によって、流れのデータにおける少ない数の誤りが許容できます。 どのような場合でも、必要であるなら、ST2の上で層のそばで信頼性を提供できます。
Also, no data fragmentation is supported during the data transfer phase. The application is expected to segment its data PDUs according to the minimum MTU over all paths in the stream. The application receives information on the MTUs relative to the paths to the targets as part of the ACCEPT message, see Section 8.6. The minimum MTU over all paths can be calculated from the MTUs relative to the single paths. ST agents silently discard too long data packets, see also Section 5.1.1.
また、データ断片化は全くデータ転送段階の間、支持されません。 すべての経路にわたる最小のMTUに応じてアプリケーションが流れでデータPDUsを区分すると予想されます。 アプリケーションはACCEPTメッセージの一部として目標への経路に比例してMTUsの情報を受け取ります、とセクション8.6は見ます。 ただ一つの経路に比例してMTUsからすべての経路にわたる最小のMTUについて計算できます。 STエージェントは、静かに長過ぎるデータ・パケットを捨てて、また、セクション5.1.1を見ます。
An ST agent forwards the data only along already established paths to targets. A path is considered to be established once the next-hop ST agent on the path sends an ACCEPT message, see Section 2.2. This implies that the target and all other intermediate ST agents on the path to the target are ready to handle the incoming data packets. In no cases will an ST agent forward data to a next-hop ST agent that has not explicitly accepted the stream.
STエージェントは既に確立した経路だけに沿ってデータを目標に転送します。 経路の次のホップSTエージェントがいったんACCEPTメッセージを送ると経路が設立されると考えられます、とセクション2.2は見ます。 目標と目標への経路の他のすべての中間的STエージェントがこれは受信データパケットを扱うつもりである準備ができています。 少しの場合でも、STエージェントは明らかに流れを受け入れていない次のホップSTエージェントにデータを転送しないでしょう。
To be reasonably sure that all targets receive the data with the desired quality of service, an application should send the data only after the whole stream has been established. Depending on the local API, an application may not be prevented from sending data before the completion of stream setup, but it should be aware that the data could be lost or not reach all intended targets. This behavior may actually be desirable to applications, such as those application that have multiple targets which can each process data as soon as it is
すべての目標が必要なサービスの質でデータを受信するのを合理的に確信しているように、全体の流れが確立された後にだけアプリケーションはデータを送るべきです。 地方のAPIによって、アプリケーションが流れのセットアップの完成の前にデータを送るかもしれなくてもよいのですが、それは、データを失うことができたのを意識しているか、またはすべての標的に達するべきであるというわけではありません。 この振舞いは実際にそれがそうであるとすぐに、それぞれデータを処理できるマルチターゲットを持っているそれらのアプリケーションなどの応用に望ましいかもしれません。
Delgrossi & Berger, Editors Experimental [Page 26] RFC 1819 ST2+ Protocol Specification August 1995
[26ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
available (e.g., a lecture or distributed gaming).
利用可能です(例えば、講演か分配されたゲーミング)。
It is desirable for implementations to take advantage of networks that support multicast. If a network does not support multicast, or for the case where the next-hops are on different networks, multiple copies of the data packet must be sent.
実現がマルチキャストを支持するネットワークを利用するのは、望ましいです。 ネットワークがマルチキャストを支持してはいけないか、または次のホップが異なったネットワークにあるケースにおいてデータ・パケットの複本を送らなければならないなら。
3.2 ST Protocol Functions
標準時3.2のプロトコル機能
The ST protocol provides two functions:
STプロトコルは2つの機能を提供します:
o stream identification
o 流れの識別
o data priority
o データ優先権
3.2.1 Stream Identification
3.2.1 流れの識別
ST data packets are encapsulated by an ST header containing the Stream IDentifier (SID). This SID is selected at the origin so that it is globally unique over the Internet. The SID must be known by the setup protocol as well. At stream establishment time, the setup protocol builds, at each agent traversed by the stream, an entry into its local database containing stream information. The SID can be used as a reference into this database, to obtain quickly the necessary replication and forwarding information.
STデータ・パケットはStream IDentifier(SID)を含むSTヘッダーによってカプセルに入れられます。 このSIDが起源で選択されるので、それはインターネットの上でグローバルにユニークです。 また、セットアッププロトコルはSIDを知っていなければなりません。 流れの設立時間、流れで横断された各エージェント、地方のデータベース含有へのエントリーのセットアッププロトコル体格では、情報を流してください。 SIDはすぐに必要な模写を得るのに参照としてこのデータベースに使用されて、情報を転送できます。
Stream IDentifiers are intended to be used to make the packet forwarding task most efficient. The time-critical operation is an intermediate ST agent receiving a packet from the previous-hop ST agent and forwarding it to the next-hop ST agents.
パケット推進タスクを最も効率的にするのに流れのIDentifiersが使用されることを意図します。 時間批判的な操作は前のホップSTエージェントからパケットを受けて、次のホップSTエージェントにそれを送る中間的STエージェントです。
The format of data PDUs including the SID is defined in Section 10.1. Stream IDentifier generation is discussed in Section 8.1.
SIDを含むデータPDUsの書式はセクション10.1で定義されます。 セクション8.1で流れのIDentifier世代について議論します。
3.2.2 Packet Discarding based on Data Priority
3.2.2 Data Priorityに基づくパケットDiscarding
ST provides a well defined quality of service to its applications. However, there may be cases where the network is temporarily congested and the ST agents have to discard certain packets to minimize the overall impact to other streams. The ST protocol provides a mechanism to discard data packets based on the Priority field in the data PDU, see Section 10.1. The application assigns each data packet with a discard-priority level, carried into the Priority field. ST agents will attempt to discard lower priority packets first during periods of network congestion. Applications may choose to send data at multiple priority levels so that less important data may be discarded first.
STはよく定義されたサービスの質をアプリケーションに提供します。 しかしながら、ケースがネットワークが一時充血するところにあるかもしれません、そして、STエージェントは総合的な衝撃を他の流れに最小にするためにあるパケットを捨てなければなりません。STプロトコルはデータPDUのPriority分野に基づくデータ・パケットを捨てるためにメカニズムを提供します、とセクション10.1は見ます。 アプリケーションは優先順位を捨てていて、Priority分野まで運ばれたaで各データ・パケットを割り当てます。 STエージェントは、最初に、ネットワークの混雑の期間、低優先度パケットを捨てるのを試みるでしょう。 アプリケーションは、最初にそれほど重要でないデータを捨てることができるように複数の優先順位でデータを送るのを選ぶかもしれません。
Delgrossi & Berger, Editors Experimental [Page 27] RFC 1819 ST2+ Protocol Specification August 1995
[27ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4. SCMP Functional Description
4. SCMPの機能的な記述
ST agents create and manage streams using the ST Control Message Protocol (SCMP). Conceptually, SCMP resides immediately above ST (as does ICMP above IP). SCMP follows a request-response model. SCMP messages are made reliable through the use of retransmission after timeout.
STエージェントは、ST Control Messageプロトコル(SCMP)を使用することで流れを作成して、管理します。 概念的に、SCMPはST(IPの上のICMPのような)のすぐ上に住んでいます。 SCMPは要求応答モデルに従います。 SCMPメッセージをタイムアウトの後に「再-トランスミッション」の使用で信頼できるようにします。
This section contains a functional description of stream management with SCMP. To help clarify the SCMP exchanges used to setup and maintain ST streams, we include an example of a simple network topology, represented in Figure 8. Using the SCMP messages described in this section it will be possible for an ST application to:
このセクションはSCMPとの流れの管理の機能的な記述を含みます。 STの流れをセットアップして、維持するのに使用されるSCMP交換をはっきりさせるのを助けるために、私たちは図8に表された簡単なネットワーク形態に関する例を入れます。 このセクションで説明されたSCMPメッセージを使用して、それは以下のことのためにSTアプリケーションは可能になるでしょう。
o Create a stream from A to the peers at B, C and D,
o B、C、およびDでAから同輩までの流れを作成してください。
o Add a peer at E,
o Eで同輩を加えてください。
o Drop peers B and C, and
o そして同輩BとCが低下してください。
o Let F join the stream
o Fを流れに参加させてください。
o Delete the stream.
o 流れを削除してください。
Delgrossi & Berger, Editors Experimental [Page 28] RFC 1819 ST2+ Protocol Specification August 1995
[28ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
+---------+ +---+
| |----| B |
+---------+ +----------+ | | +---+
| |------| Router 1 |---| Subnet2 |
| | +----------+ | |
| | | |
| | +---------+
| | |
| Subnet1 | |
| | +----------+
| | | Router 3 |
+---+ | | +----------+
| A |---| | +----------+ |
+---+ | |----| Router 2 | |
| | +----------+ |
+---------+ | |
| |
| +----------+ +---+
+----------| |----| C |
| | +---+
+---------+ | Subnet3 |
+---+ | | +---+ | | +---+
| F |---| Subnet4 |---| E |--| |----| D |
+---+ | | +---+ +----------+ +---+
+---------+
+---------+ +---+ | |----| B| +---------+ +----------+ | | +---+ | |------| ルータ1|---| Subnet2| | | +----------+ | | | | | | | | +---------+ | | | | Subnet1| | | | +----------+ | | | ルータ3| +---+ | | +----------+ | A|---| | +----------+ | +---+ | |----| ルータ2| | | | +----------+ | +---------+ | | | | | +----------+ +---+ +----------| |----| C| | | +---+ +---------+ | Subnet3| +---+ | | +---+ | | +---+ | F|---| Subnet4|---| E|--| |----| D| +---+ | | +---+ +----------+ +---+ +---------+
Figure 8: Sample Topology for an ST Stream
エイト環: 最初の流れのためのサンプルトポロジー
We first describe the possible types of stream in Section 4.1; Section 4.2 introduces SCMP control message types; SCMP reliability is discussed in Section 4.3; stream options are covered in Section 4.4; stream setup is presented in Section 4.5; Section 4.6 illustrates stream modification including stream expansion, reduction, changes of the quality of service associated to a stream. Finally, stream deletion is handled in Section 4.7.
私たちは最初に、セクション4.1で可能なタイプの流れについて説明します。 セクション4.2はSCMPコントロールメッセージタイプを導入します。 セクション4.3でSCMPの信頼性について議論します。 流れのオプションはセクション4.4でカバーされています。 流れのセットアップはセクション4.5に提示されます。 セクション4.6は流れの拡大、サービスの質の変化が流れに関連づけた減少を含む流れの変更を例証します。 最終的に、流れの削除はセクション4.7で扱われます。
4.1 Types of Streams
流れの4.1のタイプ
SCMP allows for the setup and management of different types of streams. Streams differ in the way they are built and the information maintained on connected targets.
SCMPは異なったタイプの流れのセットアップと管理を考慮します。流れはそれらが組立していて、オンに保守された情報が目標を接続した方法で異なります。
Delgrossi & Berger, Editors Experimental [Page 29] RFC 1819 ST2+ Protocol Specification August 1995
[29ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4.1.1 Stream Building
4.1.1 流れのビル
Streams may be built in a sender-oriented fashion, receiver-oriented fashion, or with a mixed approach:
流れは送付者指向のファッショナブルで、受信機指向のファッション、または複雑なアプローチで組み込まれるかもしれません:
o in the sender-oriented fashion, the application at the origin
provides the ST agent with the list of receivers for the stream. New
targets, if any, are also added from the origin.
o 送付者指向のファッションで、起源におけるアプリケーションは流れのために受信機のリストをSTエージェントに提供します。 また、もしあれば新しい目標は起源から加えられます。
o in the receiver-oriented approach, the application at the origin
creates an empty stream that contains no targets. Each target then
joins the stream autonomously.
o 受信機指向のアプローチでは、起源におけるアプリケーションは目標を全く含まない空の流れを作成します。 そして、各目標は自主的に流れに参加します。
o in the mixed approach, the application at the origin creates a
stream that contains some targets and other targets join the stream
autonomously.
o 複雑なアプローチでは、起源におけるアプリケーションはいくつかの目標を含む流れを作成します、そして、他の目標は自主的に流れに参加します。
ST2 provides stream options to support sender-oriented and mixed approach steams. Receiver-oriented streams can be emulated through the use of mixed streams. The fashion by which targets may be added to a particular stream is controlled via join authorization levels. Join authorization levels are described in Section 4.4.2.
ST2は、送付者指向の、そして、混ぜられたアプローチ蒸気を支持するために流れのオプションを提供します。複雑な流れの使用で受信機指向の流れは見習うことができます。を通して目標が特定の流れに加えられるかもしれないファッションが制御されている、認可レベルを接合してください。 認可レベルを接合してください。セクション4.4.2では、説明されます。
4.1.2 Knowledge of Receivers
4.1.2 受信機に関する知識
When streams are built in the sender-oriented fashion, all ST agents will have full information on all targets down stream of a particular agent. In this case, target information is relayed down stream from agent-to-agent during stream set-up.
流れが送付者指向のファッションで組み込まれるとき、すべてのSTエージェントが特定代理人の流れの下側にすべての目標に関する完全情報を持つでしょう。 この場合、目標情報は流れのセットアップの間、代理人対代理人から流れの下側にリレーされます。
When targets add themselves to mixed approach streams, upstream ST agents may or may not be informed. Propagation of information on targets that "join" a stream is also controlled via join authorization levels. As previously mentioned, join authorization levels are described in Section 4.4.2.
目標が複雑な接近流に自分たちを加えるとき、上流のSTエージェントは知識があるかもしれません。 を通してまた、流れを「接合する」目標における情報の伝播が制御される、認可レベルを接合してください。 以前に接合するように言及するとき、認可レベルはセクション4.4.2で説明されます。
This leads to two types of streams:
これは2つのタイプの流れに通じます:
o full target information is propagated in a full-state stream. For
such streams, all agents are aware of all downstream targets
connected to the stream. This results in target information being
maintained at the origin and at intermediate agents. Operations on
single targets are always possible, i.e., change a certain target,
or, drop that target from the stream. It is also always possible for
any ST agent to attempt recovery of all downstream targets.
o 完全な目標情報は完全な州の流れで伝播されます。 そのような流れにおいて、すべてのエージェントが流れに接続されたすべての下流標的を意識しています。 これは起源において仲介物質で保守される目標情報をもたらします。 ただ一つの目標における操作がいつも可能であるか、すなわち、ある目標を変えるか、または流れからその目標を落としてください。 また、どんなSTエージェントもすべての下流標的の回復を試みるのも、いつも可能です。
Delgrossi & Berger, Editors Experimental [Page 30] RFC 1819 ST2+ Protocol Specification August 1995
[30ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o in light-weight streams, it is possible that the origin and other
upstream agents have no knowledge about some targets. This results
in less maintained state and easier stream management, but it limits
operations on specific targets. Special actions may be required to
support change and drop operations on unknown targets, see Section
5.7. Also, stream recovery may not be possible. Of course, generic
functions such as deleting the whole stream, are still possible. It
is expected that applications that will have a large number of
targets will use light-weight streams in order to limit state in
agents and the number of targets per control message.
o 軽量の流れでは、起源と他の上流のエージェントにはいくつかの目標に関する知識が全くないのは、可能です。 これはそれほど維持されなかった州と、より簡単な流れの管理をもたらしますが、それは特定の目標の上で操作を制限します。 セクション5.7は、特別な動きが未知の目標で変化を支持して、操作を落とすのに必要であるかもしれないことを見ます。 また、流れの回復も可能でないかもしれません。 もちろん全体の流れを削除などなどの一般的な機能はまだ可能です。 多くの目標を持っているアプリケーションがコントロールメッセージあたりの目標のエージェントと数が状態を制限するのに軽量の流れを使用すると予想されます。
Full-state streams serve well applications as video conferencing or distributed gaming, where it is important to have knowledge on the connected receivers, e.g., to limit who participates. Light-weight streams may be exploited by applications such as remote lecturing or playback applications of radio and TV broadcast where the receivers do not need to be known by the sender. Section 4.4.2 defines join authorization levels, which support two types of full-state streams and one type of light-weight stream.
完全な州の流れはビデオ会議か分配されたゲーミングとしての井戸アプリケーションに役立ちます。接続受信機の上で心得があるのが重要である、例えば、だれを制限するかはそこで参加します。 軽量の流れは送付者によって受信機が知られている必要はないラジオとテレビ放送のリモート講義か再生応用などの応用で開発されるかもしれません。 .2が定義するセクション4.4は認可レベルに合流します。(レベルは2つのタイプの完全な州の流れと1つのタイプの軽量の流れを支持します)。
4.2 Control PDUs
4.2 コントロールPDUs
SCMP defines the following PDUs (the main purpose of each PDU is also indicated):
SCMPは以下のPDUsを定義します(また、それぞれのPDUの主な目的は示されます):
1. ACCEPT to accept a new stream
2. ACK to acknowledge an incoming message
3. CHANGE to change the quality of service associated with
a stream
4. CONNECT to establish a new stream or add new targets to
an existing stream
5. DISCONNECT to remove some or all of the stream's targets
6. ERROR to indicate an error contained in an incoming
message
7. HELLO to detect failures of neighbor ST agents
8. JOIN to request stream joining from a target
9. JOIN-REJECT to reject a stream joining request from a target
10. NOTIFY to inform an ST agent of a significant event
11. REFUSE to refuse the establishment of a new stream
12. STATUS to query an ST agent on a specific stream
13. STATUS-RESPONSE to reply queries on a specific stream
1. 新しい流れ2を受け入れるACCEPT。 入力メッセージ3を承認するACK。 サービスの質を変えるCHANGEは流れ4と交際しました。 新しい流れを確立するか、または新しい目標を存在に加えるCONNECTは5を流します。 流れの目標6のいくつかかすべてを取り除くDISCONNECT。 入力メッセージ7に含まれた誤りを示すERROR。 隣人STエージェント8の失敗を検出するHELLO。 要求へのJOINは、目標9から接合しながら、流れます。 目標10からの流れの接合要求を拒絶するJOIN-REJECT。 重大な行事11についてSTエージェントに知らせるNOTIFY。 新しい流れ12の設立を拒否するREFUSE。 特定の流れ13のときにSTエージェントについて質問するSTATUS。 特定の流れの回答質問へのSTATUS-RESPONSE
SCMP follows a request-response model with all requests expecting responses. Retransmission after timeout 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 is partitioned and a control message per partition is sent, as described in Section 5.1.2.
SCMPは、応答を予想しながら、すべての要求で要求応答モデルに従います。 タイムアウトが考慮するのにおいて使用されていた後に、Retransmissionはメッセージを失ったか、または無視しました。 コントロールメッセージはパケット境界に達しません。 ホップのMTUには、コントロールメッセージが大き過ぎるなら、情報を仕切ります、そして、1パーティションあたり1つのコントロールメッセージを送ります、セクション5.1.2で説明されるように。
Delgrossi & Berger, Editors Experimental [Page 31] RFC 1819 ST2+ Protocol Specification August 1995
[31ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
CONNECT and CHANGE request messages are answered with ACCEPT messages which indicate success, and with REFUSE messages which indicate failure. JOIN messages are answered with either a CONNECT message indicating success, or with a JOIN-REJECT message indicating failure. Targets may be removed from a stream by either the origin or the target via the DISCONNECT and REFUSE messages.
CONNECTとCHANGE要求メッセージは成功を示すACCEPTメッセージ、および失敗を示すREFUSEメッセージで答えられます。 CONNECTメッセージが成功を示しているか、またはJOIN-REJECTメッセージが失敗を示していて、JOINメッセージは答えられます。 目標は起源か目標のどちらかによって流れからDISCONNECTとREFUSEメッセージで取り外されるかもしれません。
The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY and REFUSE messages must always be explicitly acknowledged:
いつも明らかにACCEPT、CHANGE、CONNECT、DISCONNECT、JOIN、JOIN-REJECT、NOTIFY、およびREFUSEメッセージを承認しなければなりません:
o with an ACK message, if the message was received correctly and it
was possible to parse and correctly extract and interpret its
header, fields and parameters,
o ACKメッセージ、正しくメッセージを受け取って、正しくヘッダーを分析して、抽出して、解釈するのが可能であったか、そして、分野、およびパラメタで
o with an ERROR message, if a syntax error was detected in the header,
fields, or parameters included in the message. The errored PDU may
be optionally returned as part of the ERROR message. An ERROR
message indicates a syntax error only. If any other errors are
detected, it is necessary to first acknowledge with ACK and then
take appropriate actions. For instance, suppose a CHANGE message
contains an unknown SID: first, an ACK message has to be sent, then
a REFUSE message with ReasonCode (SIDUnknown) follows.
o メッセージに含まれていたERRORメッセージ、構文エラーがヘッダーに検出されたか、そして、分野、またはパラメタで。 ERRORメッセージの一部として任意にerrored PDUを返すかもしれません。 ERRORメッセージは構文エラーだけを示します。 他の誤りが検出されるなら、適切な行動が最初にACKと共に承諾して、次に、取るのが必要です。 例えば、CHANGEメッセージが未知のSIDを含むと仮定してください: まず最初に、ACKメッセージを送らなければならなくて、次に、ReasonCode(SIDUnknown)があるREFUSEメッセージは従います。
If no ACK or ERROR message are received before the correspondent timer expires, a timeout failure occurs. The way an ST agent should handle timeout failures is described in Section 5.2.
通信員タイマが期限が切れる前にACKかどんなERRORメッセージも受信されていないなら、タイムアウト失敗は起こります。 STエージェントがタイムアウト失敗を扱うべき方法はセクション5.2に述べられます。
ACK, ERROR, and STATUS-RESPONSE messages are never acknowledged.
ACK、ERROR、およびSTATUS-RESPONSEメッセージは決して承認されません。
HELLO messages are a special case. If they contain a syntax error, an ERROR message should be generated in response. Otherwise, no acknowledgment or response should be generated. Use of HELLO messages is discussed in Section 6.1.2.
HELLOメッセージは特別なケースです。 構文エラーを含んでいるなら、ERRORメッセージは応答で発生するべきです。 さもなければ、どんな承認も応答も発生するべきではありません。 セクション6.1.2でHELLOメッセージの使用について議論します。
STATUS messages containing a syntax error should be answered with an ERROR message. Otherwise, a STATUS-RESPONSE message should be sent back in response. Use of STATUS and STATUS-RESPONSE are discussed in Section 8.4.
構文エラーを含むSTATUSメッセージはERRORメッセージで答えられるべきです。 さもなければ、STATUS-RESPONSEメッセージは応答で返送されるべきです。 セクション8.4でSTATUSとSTATUS-RESPONSEの使用について議論します。
4.3 SCMP Reliability
4.3 SCMPの信頼性
SCMP is made reliable through the use of retransmission when a response is not received in a timely manner. The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and REFUSE messages all must be answered with an ACK message, see Section 4.2. In general, when sending a SCMP message which requires an ACK response, the sending ST agent needs to set the Toxxxx timer (where xxxx is the SCMP message type, e.g., ToConnect). If it does not receive an ACK
直ちに応答を受けないとき、SCMPを「再-トランスミッション」の使用で信頼できるようにします。 ACCEPT(ACKメッセージですべてに答えなければならないCHANGE、CONNECT、DISCONNECT、JOIN、JOIN-REJECT、NOTIFY、およびREFUSEメッセージ)はセクション4.2を見ます。 ACK応答を必要とするSCMPメッセージを送るとき、一般に、送付STエージェントは、Toxxxxタイマ(xxxxがSCMPメッセージタイプ、例えばToConnectであるところ)を設定する必要があります。 それがACKを受けないなら
Delgrossi & Berger, Editors Experimental [Page 32] RFC 1819 ST2+ Protocol Specification August 1995
[32ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
before the Toxxxx timer expires, the ST agent should retransmit the SCMP message. If no ACK has been received within Nxxxx retransmissions, then a SCMP timeout condition occurs and the ST agent enters its SCMP timeout recovery state. The actions performed by the ST agent as the result of the SCMP timeout condition differ for different SCMP messages and are described in Section 5.2.
Toxxxxタイマが期限が切れる前に、STエージェントはSCMPメッセージを再送するべきです。 Nxxxx retransmissionsの中にACKを全く受け取っていないなら、SCMPタイムアウト状態は現れます、そして、STエージェントはSCMPタイムアウト回復状態に入れます。 SCMPタイムアウト状態の結果としてSTエージェントによって実行された動作は、異なったSCMPメッセージのために異なって、セクション5.2で説明されます。
For some SCMP messages (CONNECT, CHANGE, JOIN, and STATUS) the sending ST agent also expects a response back (ACCEPT/REFUSE, CONNECT/JOIN- REJECT) after ACK has been received. For these cases, the ST agent needs to set the ToxxxxResp timer after it receives the ACK. (As before, xxxx is the initiating SCMP message type, e.g., ToConnectResp). If it does not receive the appropriate response back when ToxxxxResp expires, the ST agent updates its state and performs appropriate recovery action as described in Section 5.2. Suggested constants are given in Section 10.5.4.
また、いくつかのSCMPメッセージ(CONNECT、CHANGE、JOIN、およびSTATUS)に関しては、逆(ACCEPT/REFUSE、CONNECT/JOIN- REJECT)ACKを受け取った後に送付STエージェントは応答を予想します。 これらのケースのために、STエージェントは、ACKを受けた後にToxxxxRespタイマを設定する必要があります。 (従来と同様、xxxxは開始しているSCMPメッセージタイプ、例えば、ToConnectRespです。) ToxxxxRespが期限が切れる場合適切な応答後部を受けないなら、STエージェントは、セクション5.2で説明されるように状態をアップデートして、適切な回復処置を実行します。 セクション10.5.4で提案された定数を与えます。
The timeout and retransmission algorithm is implementation dependent and it is outside the scope of this document. Most existing algorithms are based on an estimation of the Round Trip Time (RTT) between two agents. Therefore, SCMP contains a mechanism, see Section 8.5, to estimate this RTT. Note that the timeout related variable names described above are for reference purposes only, implementors may choose to combine certain variables.
タイムアウトと再送信アルゴリズムは実現に依存しています、そして、このドキュメントの範囲の外にそれはあります。 ほとんどの既存のアルゴリズムが2人のエージェントの間のRound Trip Time(RTT)に関する見積りに基づいています。 したがって、SCMPはメカニズムを含んでいて、セクション8.5を見て、このRTTを見積もってください。 上で説明されたタイムアウト関連変数名が参照目的だけのためのものであるというメモ、作成者はある変数を結合するのを選ぶかもしれません。
4.4 Stream Options
4.4 流れのオプション
An application may select among some stream options. The desired options are indicated to the ST agent at the origin when a new stream is created. Options apply to single streams and are valid during the whole stream's lifetime. The options chosen by the application at the origin are included into the initial CONNECT message, see Section 4.5.3. When a CONNECT message reaches a target, the application at the target is notified of the stream options that have been selected, see Section 4.5.5.
アプリケーションは何らかの流れの中でオプションを選択するかもしれません。 新しい流れが作成されるとき、希望のオプションは起源でSTエージェントに示されます。 オプションは、ただ一つの流れに適用して、全体の流れの生涯有効です。 セクション4.5.3は、起源におけるアプリケーションで選ばれたオプションが初期のCONNECTメッセージに含められているのを見ます。 CONNECTメッセージが目標に達するとき、目標のアプリケーションは選択された流れのオプションについて通知されます、とセクション4.5.5が見ます。
4.4.1 No Recovery
4.4.1 回復がありません。
When a stream failure is detected, an ST agent would normally attempt stream recovery, as described in Section 6.2. The NoRecovery option is used to indicate that ST agents should not attempt recovery for the stream. The protocol behavior in the case that the NoRecovery option has been selected is illustrated in Section 6.2. The NoRecovery option is specified by setting the S-bit in the CONNECT message, see Section 10.4.4. The S-bit can be set only by the origin and it is never modified by intermediate and target ST agents.
流れの失敗が検出されるとき、通常、STエージェントはセクション6.2で説明されるように流れの回復を試みるでしょう。 NoRecoveryオプションは、STエージェントが流れのために回復を試みるべきでないのを示すのに使用されます。 NoRecoveryオプションが選択されて、プロトコルの振舞いはセクション6.2で例証されます。 セクション10.4.4は、NoRecoveryオプションがS-ビットをCONNECTメッセージにはめ込むことによって指定されるのを見ます。 起源だけでS-ビットを設定できます、そして、それは中間介在物と目標STエージェントによって決して変更されません。
Delgrossi & Berger, Editors Experimental [Page 33] RFC 1819 ST2+ Protocol Specification August 1995
[33ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4.4.2 Join Authorization Level
4.4.2 認可レベルを接合してください。
When a new stream is created, it is necessary to define the join authorization level associated with the stream. This level determines the protocol behavior in case of stream joining, see Section 4.1 and Section 4.6.3. The join authorization level for a stream is defined by the J-bit and N-bit in the CONNECT message header, see Section 10.4.4. One of the following authorization levels has to be selected:
新しい流れが作成されるとき、それが定義するのに必要である、流れに関連している認可レベルを接合してください。 セクション4.1とセクション4.6.3は、このレベルが流れの接合の場合にプロトコルの振舞いを決定するのを見ます。 流れがJ-ビットとN-ビットによってCONNECTメッセージヘッダーで定義されるので、認可レベルを接合してください、とセクション10.4は.4に見ます。 以下の認可レベルの1つは選択されなければなりません:
o Level 0 - Refuse Join (JN = 00): No targets are allowed to join this
stream.
o レベル0--廃物は(JN=00)を接合します: どんな目標もこの流れに参加できません。
o Level 1 - OK, Notify Origin (JN = 01): Targets are allowed to join
the stream. The origin is notified that the target has joined.
o レベル1--OK、起源(JN=01)に通知してください: 目標は流れに参加できます。 起源は目標が接合したことに通知されます。
o Level 2 - OK (JN = 10): Targets are allowed to join the stream. No
notification is sent to the stream origin.
o レベル2--(JN=10)を承認してください: 目標は流れに参加できます。 通知を全く流れの起源に送りません。
Some applications may choose to maintain tight control on their streams and will not permit any connections without the origin's permission. For such streams, target applications may request to be added by sending an out-of-band, i.e., via regular IP, request to the origin. The origin, if it so chooses, can then add the target following the process described in Section 4.6.1.
いくつかのアプリケーションは、彼らの流れのときに厳格な管理を維持するのを選ぶかもしれなくて、起源の許可なしで少しの接続も許可しないでしょう。 そのような流れ、アプリケーションがすなわち、通常のIPを通してバンドのアウトを送ることによって加えられるよう要求するかもしれない目標、起源への要求のために。 そして、セクション4.6.1で説明された過程に従って、そう選ぶなら、起源は目標を加えることができます。
The selected authorization level impacts stream handling and the state that is maintained for the stream, as described in Section 4.1.
選択された認可レベルは流れのために維持される流れの取り扱いと状態に影響を与えます、セクション4.1で説明されるように。
4.4.3 Record Route
4.4.3 ルートを記録してください。
The RecordRoute option can be used to request the route between the origin and a target be recorded and delivered to the application. This option may be used while connecting, accepting, changing, or refusing a stream. The results of a RecordRoute option requested by the origin, i.e., as part of the CONNECT or CHANGE messages, are delivered to the target. The results of a RecordRoute option requested by the target, i.e., as part of the ACCEPT or REFUSE messages, are delivered to the origin.
記録されていて、アプリケーションに届けられた起源と目標の間のルートを要求するのにRecordRouteオプションを使用できます。 このオプションは流れを接続するか、受け入れるか、変えるか、または拒否している間、使用されるかもしれません。 すなわち、起源、CONNECTの一部として要求されたRecordRouteオプションかCHANGEメッセージの結果を目標に渡します。 すなわち、目標、ACCEPTの一部として要求されたRecordRouteオプションかREFUSEメッセージの結果を起源に送ります。
The RecordRoute option is specified by adding the RecordRoute parameter to the mentioned SCMP messages. The format of the RecordRoute parameter is shown in Section 10.3.5. When adding this parameter, the ST agent at the origin must determine the number of entries that may be recorded as explained in Section 10.3.5.
RecordRouteオプションは、言及されたSCMPメッセージにRecordRouteパラメタを追加することによって、指定されます。 RecordRouteパラメタの書式はセクション10.3.5で示されます。 このパラメタを加えるとき、起源におけるSTエージェントはセクション10.3.5で説明されるように記録されるかもしれないエントリーの数を測定しなければなりません。
Delgrossi & Berger, Editors Experimental [Page 34] RFC 1819 ST2+ Protocol Specification August 1995
[34ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4.4.4 User Data
4.4.4 利用者データ
The UserData option can be used by applications to transport application specific data along with some SCMP control messages. This option can be included with ACCEPT, CHANGE, CONNECT, DISCONNECT, and REFUSE messages. The format of the UserData parameter is shown in Section 10.3.7. This option may be included by the origin, or the target, by adding the UserData parameter to the mentioned SCMP messages. This option may only be included once per SCMP message.
いくつかのSCMPコントロールメッセージに伴うアプリケーションの特定のデータを輸送するのにアプリケーションでUserDataオプションを使用できます。 ACCEPT、CHANGE、CONNECT、DISCONNECT、およびREFUSEメッセージでこのオプションを含むことができます。 UserDataパラメタの書式はセクション10.3.7で示されます。 このオプションは起源、または目標によって含まれるかもしれません、言及されたSCMPメッセージにUserDataパラメタを追加することによって。 このオプションはSCMPメッセージあたりの一度、含まれているだけであるかもしれません。
4.5 Stream Setup
4.5 流れのセットアップ
This section presents a description of stream setup. For simplicity, we assume that everything succeeds, e.g., any required resources are available, messages are properly delivered, and the routing is correct. Possible failures in the setup phase are handled in Section 5.2.
このセクションは流れのセットアップの記述を提示します。 簡単さのために、私たちはすべてが成功して、例えば、どんな必要なリソースも利用可能であり、適切にメッセージを送って、ルーティングが正しいと思います。 セットアップフェーズにおける可能な失敗はセクション5.2で扱われます。
4.5.1 Information from the Application
4.5.1 アプリケーションからの情報
Before stream setup can be started, the application has to collect the necessary information to determine the characteristics for the connection. This includes identifying the participants and selecting the QoS parameters of the data flow. Information passed to the ST agent by the application includes:
流れのセットアップを始めることができる前に、アプリケーションは、接続のために特性を決定するために必要事項を集めなければなりません。 これは、関係者を特定して、データフローのQoSパラメタを選択するのを含んでいます。 アプリケーションでSTエージェントに渡された情報は:
o the list of the stream's targets (Section 10.3.6). The list may be
empty (Section 4.5.3.1),
o 流れの目標(セクション10.3.6)のリスト。 リストが空であるかもしれない、(セクション4.5 .3 .1)
o the flow specification containing the desired quality of service for
the stream (Section 9),
o 流れ(セクション9)のための必要なサービスの質を含む流れ仕様
o information on the groups in which the stream is a member, if any
(Section 7),
o もしあれば(セクション7)流れがメンバーであるグループの情報
o information on the options selected for the stream (Section 4.4).
o オプションの情報は流れのために(セクション4.4)を選択しました。
4.5.2 Initial Setup at the Origin
4.5.2 起源における初期のセットアップ
The ST agent at the origin then performs the following operations:
次に、起源におけるSTエージェントは以下の操作を実行します:
o allocates a stream ID (SID) for the stream (Section 8.1),
o 流れ(セクション8.1)のために、ID(SID)を流れに割り当てます。
o invokes the routing function to determine the set of next-hops for
the stream (Section 4.5.2.1),
o 流れのために次のホップのセットを決定するために経路選択機能を呼び出す、(セクション4.5 .2 .1)
o invokes the Local Resource Manager (LRM) to reserve resources
(Section 4.5.2.2),
o リソースを予約するために、Local Resourceマネージャ(LRM)を呼び出す、(セクション4.5 .2 .2)
Delgrossi & Berger, Editors Experimental [Page 35] RFC 1819 ST2+ Protocol Specification August 1995
[35ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o creates local database entries to store information on the new
stream,
o 新しい流れの情報を格納するために地方のデータベースエントリーを作成します。
o propagates the stream creation request to the next-hops determined
by the routing function (Section 4.5.3).
o 経路選択機能(セクション4.5.3)で断固とした次のホップに流れの創造要求を伝播します。
4.5.2.1 Invoking the Routing Function
4.5.2.1 経路選択機能を呼び出すこと。
An ST agent that is setting up a stream invokes the routing function to find the next-hop to reach each of the targets specified by the target list provided by the application. This is similar to the routing decision in IP. However, in this case the route is to a multitude of targets with QoS requirements rather than to a single destination.
流れをセットアップしているSTエージェントは、アプリケーションで提供された目標リストによって指定されたそれぞれの目標に達するように次のホップを見つけるために経路選択機能を呼び出します。 これはIPでのルーティング決定と同様です。 しかしながら、この場合、単一の目的地にというよりむしろQoS要件がある目標の多数にはルートがあります。
The result of the routing function is a set of next-hop ST agents. The set of next-hops selected by the routing function 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. Alternatively, the routing algorithm may use a simple route lookup for each target.
経路選択機能の結果は1セットの次のホップSTエージェントです。 経路選択機能によって選択された次のホップのセットは必ず同じ目的地への多くの独立しているIPデータグラムを考えて、IPが選択する次のホップのセットと同じであるというわけではありません。 ルーティング・アルゴリズムは、パケットが取るホップの数以外のパラメタを最適化するのを試みるかもしれません、遅れ、地方のネットワーク回線容量消費、または総インターネット帯域幅消費などのように。 あるいはまた、ルーティング・アルゴリズムは各目標に簡単なルートルックアップを使用するかもしれません。
Once a next-hop is selected by the routing function, it persists for the whole stream lifetime, unless a network failure occurs.
次のホップが経路選択機能によっていったん選択されると、全体が生涯を流すので、固執しています、ネットワーク失敗が起こらない場合。
4.5.2.2 Reserving Resources
4.5.2.2 リソースを予約すること。
The ST agent invokes the Local Resource Manager (LRM) to perform the appropriate reservations. The ST agent presents the LRM with information including:
STエージェントは、適切な予約を実行するために、Local Resourceマネージャ(LRM)を呼び出します。 与えて、:STエージェントは情報をLRMに与えます。
o the flow specification with the desired quality of service for the
stream (Section 9),
o 流れ(セクション9)のための必要なサービスの質がある流れ仕様
o the version number associated with the flow specification
(Section 9).
o バージョン番号は(セクション9)を流れ仕様に関連づけました。
o information on the groups the stream is member in, if any
(Section 7),
o 流れが中のメンバーであるというもしあれば(セクション7)グループの情報
The flow specification contains information needed by the LRM to allocate resources. The LRM updates the flow specification contents information before returning it to the ST agent. Section 9.2.3 defines the fields of the flow specification to be updated by the LRM.
流れ仕様はリソースを割り当てるためにLRMによって必要とされた情報を含んでいます。 STエージェントにそれを返す前に、LRMは流れ仕様コンテンツ情報をアップデートします。 セクション9.2 .3 LRMによってアップデートされるように、流れ仕様の分野を定義します。
Delgrossi & Berger, Editors Experimental [Page 36] RFC 1819 ST2+ Protocol Specification August 1995
[36ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
The membership of a stream in a group may affect the amount of resources that have to be allocated by the LRM, see Section 7.
グループにおける流れの会員資格はLRMによって割り当てられなければならないリソースの量に影響するかもしれません、とセクション7は見ます。
4.5.3 Sending CONNECT Messages
4.5.3 発信して、メッセージを接続してください。
The ST agent sends a CONNECT message to each of the next-hop ST agents identified by the routing function. Each CONNECT message contains the SID, the selected stream options, the FlowSpec, and a TargetList. The format of the CONNECT message is defined by Section 10.4.4. In general, the FlowSpec and TargetList depend on both the next-hop and the intervening network. Each TargetList is a subset of the original TargetList, identifying the targets that are to be reached through the next-hop to which the CONNECT message is being sent.
STエージェントは経路選択機能によって特定された次のホップSTエージェントの各人にCONNECTメッセージを送ります。 それぞれのCONNECTメッセージはSID、選択された流れのオプション、FlowSpec、およびTargetListを含んでいます。 CONNECTメッセージの書式はセクション10.4.4によって定義されます。 一般に、FlowSpecとTargetListは次のホップと介入しているネットワークの両方に頼っています。 各TargetListはオリジナルのTargetListの部分集合です、次のホップを通ってCONNECTメッセージが送られる達することになっている目標を特定して。
The TargetList may be empty, see Section 4.5.3.1; if the TargetList causes a too long CONNECT message to be generated, the CONNECT message is partitioned as explained in Section 5.1.2. 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.
セクション4.5.3が、TargetListが空であるかもしれないことを見る、.1。 TargetListが発生するべき長過ぎるCONNECTメッセージを引き起こすなら、CONNECTメッセージはセクション5.1.2で説明されるように仕切られます。 複数の次のホップにネットワークを通して達するつもりであると、サポートが平らなマルチキャストをネットワークでつないで、それにもかかわらず、以来に異なったCONNECTメッセージをそれぞれの次のホップに送らなければならないのにおいて、それぞれ異なったTargetListがあるでしょう。
4.5.3.1 Empty Target List
4.5.3.1 空の目標リスト
An application at the origin may request the local ST agent to create an empty stream. It does so by passing an empty TargetList to the local ST agent during the initial stream setup. When the local ST agent receives a request to create an empty stream, it allocates the stream ID (SID), updates its local database entries to store information on the new stream and notifies the application that stream setup is complete. The local ST agent does not generate any CONNECT message for streams with an empty TargetList. Targets may be later added by the origin, see Section 4.6.1, or they may autonomously join the stream, see Section 4.6.3.
起源におけるアプリケーションは、空の流れを作成するよう地元のSTエージェントに要求するかもしれません。 それは、初期の流れのセットアップの間、地元のSTエージェントに空のTargetListを渡すことによって、そうします。 地元のSTエージェントが空の流れを作成するという要求を受け取るとき、それは、ID(SID)を流れに割り当てて、新しい流れの情報を格納するために地方のデータベースエントリーをアップデートして、流れのセットアップが完全であるようにアプリケーションに通知します。 地元のSTエージェントは空のTargetListとの流れへのどんなCONNECTメッセージも発生させません。 目標は後で起源によって加えられるかもしれません、とセクション4.6.1が見るか、またはそれらが自主的に流れに参加するかもしれません、とセクション4.6.3が見ます。
4.5.4 CONNECT Processing by an Intermediate ST agent
4.5.4 Intermediate STエージェントによるCONNECT Processing
An ST agent receiving a CONNECT message, assuming no errors, responds to the previous-hop with an ACK. The ACK message must identify the CONNECT message to which it corresponds by including the reference number indicated by the Reference field of the CONNECT message. The intermediate ST agent calls the routing function, invokes the LRM to reserve resources, and then propagates the CONNECT messages to its next-hops, as described in the previous sections.
誤りを全く仮定しないで、CONNECTメッセージを受け取るSTエージェントはACKと共に前のホップに応じます。 ACKメッセージはそれがCONNECTメッセージのReference分野によって示された参照番号を含んでいることによって相当するCONNECTメッセージを特定しなければなりません。 中間的STエージェントは、経路選択機能を呼んで、リソースを予約するためにLRMを呼び出して、次に、CONNECTメッセージを次のホップに伝播します、前項で説明されるように。
Delgrossi & Berger, Editors Experimental [Page 37] RFC 1819 ST2+ Protocol Specification August 1995
[37ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4.5.5 CONNECT Processing at the Targets
4.5.5 処理を目標に関連づけてください。
An ST agent that is the target of a CONNECT message, assuming no errors, responds to the previous-hop with an ACK. The ST agent invokes the LRM to reserve local resources and then queries the specified application process whether or not it is willing to accept the connection.
誤りを全く仮定しないで、CONNECTメッセージの目標であるSTエージェントはACKと共に前のホップに応じます。 STエージェントは、ローカル資源を予約するためにLRMを呼び出して、それが、接続を受け入れても構わないと思っているか否かに関係なく、次に、指定されたアプリケーション・プロセスを質問します。
The application is presented with parameters from the CONNECT message including the SID, the selected stream options, Origin, FlowSpec, TargetList, and Group, if any, to be used as a basis for its decision. The application is identified by a combination of the NextPcol field, from the Origin parameter, and the service access point, or SAP, field included in the correspondent (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 the SID, that can be mapped into this information and be used for their delivery.
決定の基礎として使用されるためにパラメタをSID、選択された流れのオプション、Origin、FlowSpec、TargetListを含むCONNECTメッセージとGroupからアプリケーションにもしあれば与えます。 アプリケーションはNextPcol分野の組み合わせで特定されます、Originパラメタと、サービスアクセスポイントか、SAPから、TargetListの通信員(通常単一の残り)目標に分野を含んでいて。 SAP分野のコンテンツはホストST層の上のプロトコル層のそばで使用のためのポートか他のローカルの識別子を指定するかもしれません。 次に受信データパケットがSIDを運んで、それをこの情報に写像して、彼らの配送に使用できます。
Finally, based on the application's decision, the ST agent sends to the previous-hop from which the CONNECT message was received either an ACCEPT or REFUSE message. Since the ACCEPT (or REFUSE) message has to be acknowledged by the previous-hop, it is assigned a new Reference number that will be returned in the ACK. The CONNECT message to which ACCEPT (or REFUSE) is a reply is identified by placing the CONNECT's Reference number in the LnkReference field of ACCEPT (or REFUSE). The ACCEPT message contains the FlowSpec as accepted by the application at the target.
最終的に、アプリケーションの決定に基づいて、STエージェントはCONNECTメッセージが受け取って、ACCEPTかREFUSEのどちらかが通信するということであった前のホップに発信します。 ACCEPT(または、REFUSE)メッセージが前のホップによって承認されなければならないので、ACKで返される新しいReference番号はそれに割り当てられます。 ACCEPT(または、REFUSE)が回答であるCONNECTメッセージは、ACCEPT(または、REFUSE)のLnkReference分野にCONNECTのReference番号を置くことによって、特定されます。 ACCEPTメッセージは目標のアプリケーションで受け入れるようにFlowSpecを含んでいます。
4.5.6 ACCEPT Processing by an Intermediate ST agent
4.5.6 Intermediate STエージェントによるACCEPT Processing
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 message, with ReasonCode (LnkRefUnknown). Otherwise, it responds to the next-hop ST agent with an ACK, and propagates the individual ACCEPT message to the previous-hop along the same path traced by the CONNECT but in the reverse direction toward the origin.
中間的STエージェントがACCEPTを受け取るとき、それは、最初に、メッセージが以前のCONNECTへの応答であることを確かめます。 そうでなければ、それはERRORメッセージ、ReasonCode(LnkRefUnknown)の次のホップSTエージェントに応じます。 さもなければ、それは、ACKの次のホップSTエージェントに応じて、CONNECTによってたどられた同じ経路にもかかわらず、起源に向かった反対の方向で個々の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 when the CONNECT was originally processed. Therefore, the ST agent presents the LRM with the FlowSpec included in the ACCEPT message. It is expected that each LRM adjusts local reservations releasing any excess resources. The
FlowSpecは、起源と中間的STエージェントがCONNECTがインターネットを横断したとき蓄積された情報へのアクセスを得ることができるように、ACCEPTメッセージに含まれています。 ACCEPTメッセージのFlowSpecで指定されるリソースがCONNECTが元々処理されたとき予約されたリソースと異なるかもしれないことに注意してください。 したがって、STエージェントはACCEPTメッセージに含まれていたFlowSpecをLRMに与えます。 各LRMがどんな余分なリソースも発表する地方の予約を調整すると予想されます。 The
Delgrossi & Berger, Editors Experimental [Page 38] RFC 1819 ST2+ Protocol Specification August 1995
[38ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
LRM may choose not to adjust local reservations when that adjustment may result in the loss of needed resources. It may also choose to wait to adjust allocated resources until all targets in transition have been accepted or refused.
LRMは、その調整が必要なリソースの損失をもたらすかもしれないなら地方の予約を調整しないのを選ぶかもしれません。 また、それは、変遷におけるすべての目標を受け入れるか、または拒否するまで割り当てられたリソースを調整するのを待つのを選ぶかもしれません。
In the case where the intermediate ST agent is acting as the origin with respect to this target, see Section 4.6.3.1, the ACCEPT message is not propagated upstream.
中間的STエージェントが起源としてこの目標に関して務めている場合では、セクション4.6を見てください。.3 .1 ACCEPTメッセージは上流へ伝播されません。
4.5.7 ACCEPT Processing by the Origin
4.5.7 起源で処理を受け入れてください。
The origin will eventually receive an ACCEPT (or REFUSE) message from each of the targets. As each ACCEPT is received, the application is 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.
起源は結局、それぞれの目標からACCEPT(または、REFUSE)メッセージを受け取るでしょう。 それぞれのACCEPTが受け取られているとき、アプリケーションは経路に沿って首尾よくそれに割り当てられた目標とリソースについて通知されます、ACCEPTメッセージに含まれたFlowSpecで指定されるように。 そして、アプリケーションは、各目標への流れの一部を採用するか、または終えるのに情報を使用するかもしれません。
When an ACCEPT is received by the origin, the path to the target is considered to be established and the ST agent is allowed to forward the data along this path as explained in Section 2 and in Section 3.1.
起源でACCEPTを受け取るとき、設立されると目標への経路を考えます、そして、STエージェントはセクション2とセクション3.1で説明されるようにこの経路に沿ってデータを転送できます。
4.5.8 REFUSE Processing by the Intermediate ST agent
4.5.8 Intermediate STエージェントによるREFUSE Processing
If an application at a target does not wish to participate in the stream, it sends a REFUSE message back to the origin with ReasonCode (ApplDisconnect). An intermediate ST agent that receives a REFUSE message with ReasonCode (ApplDisconnect) acknowledges it by sending an ACK to the next-hop, invokes the LRM to adjusts reservations as appropriate, deletes the target entry from the internal database, and propagates the REFUSE message back to the previous-hop ST agent.
目標のアプリケーションが流れに参加したくないなら、それはReasonCode(ApplDisconnect)と共にREFUSEメッセージを起源に送り返します。 ReasonCodeがある(ApplDisconnect)が次のホップにACKを送りながらそれを承認して、LRMを呼び出すREFUSEメッセージを受け取る中間的STエージェントは、適宜予約を調整して、内部のデータベースから目標エントリーを削除して、前のホップSTエージェントにREFUSEメッセージを伝播して戻します。
In the case where the intermediate ST agent is acting as the origin with respect to this target, see Section 4.6.3.1, the REFUSE message is only propagated upstream when there are no more downstream agents participating in the stream. In this case, the agent indicates that the agent is to be removed from the stream propagating the REFUSE message with the G-bit set (1).
中間的STエージェントが起源としてこの目標に関して務めている場合では、セクション4.6を見てください。.3 .1 流れに参加するエージェントがさらにない川下にいるときだけ、REFUSEメッセージは上流へ伝播されます。 この場合、エージェントは、エージェントがG-ビットセット(1)でREFUSEメッセージを伝播する流れから免職されることになっているのを示します。
4.5.9 REFUSE Processing by the Origin
4.5.9 起源で処理を拒否してください。
When the REFUSE message reaches the origin, the ST agent at the origin sends an ACK and notifies the application that the target 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, or keep the stream active to allow addition
REFUSEメッセージが起源に達すると、起源におけるSTエージェントは、ACKを送って、目標がもう流れの一部とまた、流れでは残っている目標が全くないかどうかということであるようにアプリケーションに通知します。 残っている目標が全くなければ、アプリケーションは、流れを終えることを願っているか、または添加を許すためにアクティブに流れを保つかもしれません。
Delgrossi & Berger, Editors Experimental [Page 39] RFC 1819 ST2+ Protocol Specification August 1995
[39ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
of targets or stream joining as described in Section 4.6.3.
セクション4.6.3で説明される目標か流れの接合について。
4.5.10 Other Functions during Stream Setup
4.5.10 流れのセットアップの間の他の機能
Some other functions have to be accomplished by an ST agent as CONNECT messages travel downstream and ACCEPT (or REFUSE) messages travel upstream during the stream setup phase. They were not mentioned in the previous sections to keep the discussion as simple as possible. These functions include:
CONNECTメッセージが川下に移動するので、ある他の機能はSTエージェントによって達成されなければなりません、そして、ACCEPT(または、REFUSE)メッセージは流れのセットアップ段階の間、上流へ移動します。 前項でそれらは、できるだけ簡単に議論を保つために言及されませんでした。 これらの機能は:
o computing the smallest Maximum Transmission Unit size over the path
to the targets, as part of the MTU discovery mechanism presented in
Section 8.6. This is done by updating the MaxMsgSize field of the
CONNECT message, see Section 10.4.4. This value is carried back to
origin in the MaxMsgSize field of the ACCEPT message, see Section
10.4.1.
o セクション8.6に提示されたMTU発見メカニズムの一部として経路に関して最も小さいMaximum Transmission Unitサイズを目標に計算します。 セクション10.4.4は、CONNECTメッセージのMaxMsgSize分野をアップデートすることによってこれをするのを見ます。 セクション10.4.1は、この値がACCEPTメッセージのMaxMsgSize分野の起源に戻されているのを見ます。
o counting the number of IP clouds to be traversed to reach the
targets, if any. IP clouds are traversed when the IP encapsulation
mechanism is used. This mechanism described in Section 8.7.
Encapsulating agents update the IPHops field of the CONNECT message,
see Section 10.4.4. The resulting value is carried back to origin in
the IPHops field of the ACCEPT message, see Section 10.4.1.
o もしあれば目標に達するように横断されるためにIP雲の数を数えます。 IPカプセル化メカニズムが使用されているとき、IP雲は横断されます。 セクション8.7で説明されたこのメカニズム。 セクション10.4.4は、要約のエージェントがCONNECTメッセージのIPHops分野をアップデートするのを見ます。 セクション10.4.1は、結果として起こる値がACCEPTメッセージのIPHops分野の起源に戻されているのを見ます。
o updating the RecoveryTimeout value for the stream based on what can
the agent can support. This is part of the stream recovery
mechanism, in Section 6.2. This is done by updating the
RecoveryTimeout field of the CONNECT message, see Section 10.4.4.
This value is carried back to origin in the RecoveryTimeout field of
the ACCEPT message, see Section 10.4.1.
o 何に基づく流れがそうすることができるのでRecoveryTimeout値をアップデートして、エージェントは支持できます。 これはセクション6.2の流れの回収機構の一部です。 セクション10.4.4は、CONNECTメッセージのRecoveryTimeout分野をアップデートすることによってこれをするのを見ます。 セクション10.4.1は、この値がACCEPTメッセージのRecoveryTimeout分野の起源に戻されているのを見ます。
4.6 Modifying an Existing Stream
4.6 既存の流れを変更すること。
Some applications may wish to modify a stream after it has been created. Possible changes include expanding a stream, reducing it, and changing its FlowSpec. The origin may add or remove targets as described in Section 4.6.1 and Section 4.6.2. Targets may request to join the stream as described in Section 4.6.3 or, they may decide to leave a stream as described in Section 4.6.4. Section 4.6.5 explains how to change a stream's FlowSpec.
それを作成してある後にいくつかのアプリケーションが流れを変更したがっているかもしれません。 それを減少させて、FlowSpecを変えて、可能な変化は、流れを膨張させるのを含んでいます。 起源は、セクション4.6.1とセクション4.6.2で説明されるように目標を加えるか、または取り外すかもしれません。 目標が、セクション4.6.3で説明されるように流れに参加するよう要求するかもしれませんか、またはそれらは、セクション4.6.4で説明されるように流れを残すと決めるかもしれません。 セクション4.6 .5 流れのFlowSpecを変える方法を説明します。
As defined by Section 2, an ST agent can handle only one stream modification at a time. If a stream modification operation is already underway, further requests are queued and handled when the previous operation has been completed. This also applies to two subsequent requests of the same kind, e.g., two subsequent changes to the FlowSpec.
セクション2によって定義されるように、STエージェントは一度に、1つの流れだけの変更を扱うことができます。 流れの変更操作が既に進行中であるなら、古い手術痕が終了したとき、さらなる要求は、列に並ばせられて、扱われます。 また、これは同じ種類の2つのその後の要求、例えば、FlowSpecへの2回のその後の変化に適用されます。
Delgrossi & Berger, Editors Experimental [Page 40] RFC 1819 ST2+ Protocol Specification August 1995
[40ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
4.6.1 The Origin Adding New Targets
4.6.1 新しい目標を加える起源
It is possible for an application at the origin to add new targets to an existing stream any time after the stream has been established. Before new targets are added, the application has to collect the necessary information on the new targets. Such information is passed to the ST agent at the origin.
起源におけるアプリケーションが流れが確立された後にいつでも既存の流れに新しい目標を加えるのは、可能です。 新しい目標が加えられる前に、アプリケーションは必要事項を新しい目標に集めなければなりません。 そのような情報は起源でSTエージェントに渡されます。
The ST agent at the origin issues a CONNECT message that contains the SID, the FlowSpec, and the TargetList specifying the new targets. This is similar to sending a CONNECT message during stream establishment, with the following exceptions: the origin checks that a) the SID is valid, b) the targets are not already members of the stream, c) that the LRM evaluates the FlowSpec of the new target to be the same as the FlowSpec of the existing stream, i.e., it requires an equal or smaller amount of resources to be allocated. If the FlowSpec of the new target does not match the FlowSpec of the existing stream, an error is generated with ReasonCode (FlowSpecMismatch). Functions to compare flow specifications are provided by the LRM, see Section 1.4.5.
起源におけるSTエージェントは新しい目標を指定するSID、FlowSpec、およびTargetListを含むCONNECTメッセージを発行します。 これは流れの設立の間、以下の例外でCONNECTメッセージを送るのと同様です: 既に流れのメンバーではなく、a) SIDが有効である、b) 目標がそうである起源チェック、c) LRMがすなわち、既存の流れのFlowSpec、それと同じになるように新しい目標のFlowSpecを評価するのが等しいか、よりわずかな量のリソースが割り当てられるのを必要とします。 新しい目標のFlowSpecが既存の流れのFlowSpecに合っていないなら、誤りはReasonCode(FlowSpecMismatch)と共に発生します。 セクション1.4.5は、流れ仕様を比較する機能がLRMによって提供されるのを見ます。
An intermediate ST agent that is already a participant in the stream looks at the SID and StreamCreationTime, and verifies that 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, it responds with a REFUSE message with ReasonCode (TargetExists) that contains a TargetList of those targets that were duplicates. To indicate that the stream exists, and includes the listed targets, the ST agent sets to one (1) the E-bit of the REFUSE message, see Section 10.4.11. The agent then proceeds processing each new target in the TargetList.
既に流れの関係者である中間的STエージェントは、SIDとStreamCreationTimeを見て、流れが同じであることを確かめます。 そして、それは、TargetListの交差点と確立した流れの目標に人影がないかどうかチェックします。 これがそうでないなら、それは写しであったそれらの目標のTargetListを含むReasonCode(TargetExists)と共にREFUSEメッセージで応じます。 流れが存在していて、記載された目標を含んでいるのを示すために、STエージェントはREFUSEメッセージのE-ビットを1つ(1)に設定します、とセクション10.4.11が見ます。 そして、エージェントは、それぞれの新しい目標を処理しながら、TargetListで続きます。
For each new target in the TargetList, processing is much the same as for the original CONNECT. The CONNECT is acknowledged, propagated, and network resources are reserved. Intermediate or target ST agents that are not already participants in the stream behave as in the case of stream setup (see Section 4.5.4 and Section 4.5.5).
TargetListのそれぞれの新しい目標において、処理はオリジナルのCONNECTのように似たり寄ったりです。 CONNECTは承認されて、伝播されています、そして、ネットワーク資源は予約されています。 既に流れの関係者でない中間介在物か目標STエージェントは流れのセットアップに関するケースのように振る舞います(セクション4.5.4とセクション4.5.5を見てください)。
4.6.2 The Origin Removing a Target
4.6.2 目標を取り外す起源
It is possible for an application at the origin to remove existing targets of a stream any time after the targets have accepted the stream. The application at the origin specifies the set of targets that are to be removed and informs the local ST agent. Based on this information, the ST agent sends DISCONNECT messages with the ReasonCode (ApplDisconnect) to the next-hops relative to the targets.
起源におけるアプリケーションが目標が流れを受け入れた後にいつでも流れの既存の目標を取り外すのは、可能です。 起源におけるアプリケーションは、取り外されることになっている目標のセットを指定して、地元のSTエージェントに知らせます。 この情報に基づいて、STエージェントは目標に比例して次のホップへのReasonCode(ApplDisconnect)があるメッセージをDISCONNECTに送ります。
Delgrossi & Berger, Editors Experimental [Page 41] RFC 1819 ST2+ Protocol Specification August 1995
[41ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
An ST agent that receives a DISCONNECT message must acknowledge it by sending an ACK to the previous-hop. The ST agent updates its state and notifies the LRM of the target deletion so that the LRM can modify reservations as appropriate. When the DISCONNECT message reaches the target, the ST agent also notifies the application that the target is no longer part of the stream. When there are no remaining targets that can be reached through a particular next-hop, the ST agent informs the LRM and it deletes the next-hop from its next-hops set.
DISCONNECTメッセージを受け取るSTエージェントは、前のホップにACKを送ることによって、それを承認しなければなりません。 STエージェントは、LRMが適宜予約を変更できるように、目標削除について状態をアップデートして、LRMに通知します。 また、DISCONNECTメッセージが目標に達すると、STエージェントは、目標がもう流れの一部でないようにアプリケーションに通知します。 残っている目標が全くないとき、それに特定の次のホップを通して達することができます、そして、STエージェントはLRMに知らせます、そして、それは次のホップセットから次のホップを削除します。
SCMP also provides a flooding mechanism to delete targets that joined the stream without notifying the origin. The special case of target deletion via flooding is described in Section 5.7.
また、SCMPは、起源に通知しないで流れに参加した目標を削除するために氾濫メカニズムを提供します。 氾濫を通した目標削除の特別なケースはセクション5.7で説明されます。
4.6.3 A Target Joining a Stream
4.6.3 流れに参加する目標
An application may request to join an existing stream. It has to collect information on the stream including the stream ID (SID) and the IP address of the stream's origin. This can be done out-of-band, e.g., via regular IP. The information is then passed to the local ST agent. The ST agent generates a JOIN message containing the application's request to join the stream and sends it toward the stream origin.
アプリケーションは、存在を接合するために、流れるよう要求するかもしれません。 それは流れのID(SID)と流れの起源のIPアドレスを含む流れの情報を集めなければなりません。 例えば、バンドの外通常のIPを通してこれができます。 そして、情報は地元のSTエージェントに渡されます。 STエージェントは、流れに参加するというアプリケーションの要求を含むJOINメッセージを発生させて、流れの起源に向かってそれを送ります。
An ST agent receiving a JOIN message, assuming no errors, responds with an ACK. The ACK message must identify the JOIN message to which it corresponds by including the Reference number indicated by the Reference field of the JOIN message. If the ST agent is not traversed by the stream that has to be joined, it propagates the JOIN message toward the stream's origin. Once a JOIN message has been acknowledged, ST agents do not retain any state information related to the JOIN message.
誤りを全く仮定しないで、JOINメッセージを受け取るSTエージェントはACKと共に応じます。 ACKメッセージはそれがJOINメッセージのReference分野によって示されたReference番号を含んでいることによって相当するJOINメッセージを特定しなければなりません。 STエージェントが参加されなければならない流れで横断されないなら、それは流れの起源に向かってJOINメッセージを伝播します。 JOINメッセージがいったん承認されると、STエージェントはJOINメッセージに関連する少しの州の情報も保有しません。
Eventually, an ST agent traversed by the stream or the stream's origin itself is reached. This agent must respond to a received JOIN first with an ACK to the ST agent from which the message was received, then, it issues either a CONNECT or a JOIN-REJECT message and sends it toward the target. The response to the join request is based on the join authorization level associated with the stream, see Section 4.4.2:
結局、流れか流れの起源自体によって横断されたSTエージェントは連絡されています。 このエージェントが最初にメッセージが受け取られたSTエージェントへのACKと共に容認されたJOINに応じなければならなくて、次に、それは、CONNECTかJOIN-REJECTメッセージのどちらかを発行して、目標に向かってそれを送ります。 応答、接合、要求が基づいている、流れに関連している認可レベルを接合してください、そして、セクション4.4.2を見てください:
o If the stream has authorization level #0 (refuse join):
The ST agent sends a JOIN-REJECT message toward the target with
ReasonCode (JoinAuthFailure).
o 流れに認可があるなら、#0、を平らにしてください(廃物は接合します): STエージェントはReasonCode(JoinAuthFailure)がある目標に向かってJOIN-REJECTメッセージを送ります。
o If the stream has authorization level #1 (ok, notify origin):
The ST agent sends a CONNECT message toward the target with a
TargetList including the target that requested to join the stream.
o 流れに認可があるなら、#1、を平らにしてください(OK、起源に通知してください): STエージェントはTargetListがそれが流れに参加するよう要求した目標を含んでいる目標に向かってCONNECTメッセージを送ります。
Delgrossi & Berger, Editors Experimental [Page 42] RFC 1819 ST2+ Protocol Specification August 1995
[42ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
This eventually results in adding the target to the stream. When
the ST agent receives the ACCEPT message indicating that the new
target has been added, it does not propagate the ACCEPT message
backwards (Section 4.5.6). Instead, it issues a NOTIFY message
with ReasonCode (TargetJoined) so that upstream agents, including
the origin, may add the new target to maintained state
information. The NOTIFY message includes all target specific
information.
これは結局、流れに目標を加えるのに結果として生じます。 STエージェントが新しい目標が加えられるのを示すACCEPTメッセージを受け取るとき、それは後方にACCEPTメッセージ(セクション4.5.6)を伝播しません。 代わりに、それは、起源を含む上流のエージェントが維持された州の情報に新しい目標を追加できるように、ReasonCode(TargetJoined)と共にNOTIFYメッセージを発行します。 NOTIFYメッセージはすべての目標特殊情報を含んでいます。
o If the stream has authorization level #2 (ok):
The ST agent sends a CONNECT message toward the target with a
TargetList including the target that requested to join the stream.
This eventually results in adding the target to the stream. When
the ST agent receives the ACCEPT message indicating that the new
target has been added, it does not propagate the ACCEPT message
backwards (Section 4.5.6), nor does it notify the origin. A NOTIFY
message is generated with ReasonCode (TargetJoined) if the target
specific information needs to be propagated back to the origin. An
example of such information is change in MTU, see Section 8.6.
o 流れに認可があるなら、#2(OK)を平らにしてください: STエージェントはTargetListがそれが流れに参加するよう要求した目標を含んでいる目標に向かってCONNECTメッセージを送ります。 これは結局、流れに目標を加えるのに結果として生じます。 いつSTエージェントは新しい目標が加えられるのを示すACCEPTメッセージを受け取って、後方にACCEPTメッセージ(セクション4.5.6)を伝播しないで、またそれは起源に通知しないか。 NOTIFYメッセージは起源に伝播して戻られるべき目標特殊情報の必要性であるならReasonCode(TargetJoined)と共に発生します。 セクション8.6は、そのような情報に関する例がMTUで変化であると考えます。
4.6.3.1 Intermediate Agent (Router) as Origin
4.6.3.1 起源としての仲介物質(ルータ)
When a stream has join authorization level #2, see Section 4.4.2, it is possible that the stream origin is unaware of some targets participating in the stream. In this case, the ST intermediate agent that first sent a CONNECT message to this target has to act as the stream origin for the given target. This includes:
いくつかの目標が流れに参加するのに流れの起源が気づかないのは、流れがそうしたときには認可レベル#2に参加してください、とセクション4.4.2が見るのが可能です。 この場合、この目標へのCONNECTメッセージが最初に発信したST仲介物質は与えられた目標のための流れの起源として務めなければなりません。 これは:
o if the whole stream is deleted, the intermediate agent must
disconnect the target.
o 全体の流れが削除されるなら、仲介物質は目標を外さなければなりません。
o if the stream FlowSpec is changed, the intermediate agent must
change the FlowSpec for the target as appropriate.
o 流れのFlowSpecを変えるなら、仲介物質は目標のために適宜FlowSpecを変えなければなりません。
o proper handling of ACCEPT and REFUSE messages, without propagation
to upstream ST agents.
o ACCEPTの適切な取り扱いと上流のSTエージェントへの伝播のないREFUSEメッセージ。
o generation of NOTIFY messages when needed. (As described above.)
o NOTIFYメッセージの世代必要であると。 (上で説明されるように。)
The intermediate agent behaves normally for all other targets added to the stream as a consequence of a CONNECT message issued by the origin.
通常、仲介物質はCONNECTメッセージの結果が起源で発行したように流れに加えられた他のすべての目標のために振る舞います。
4.6.4 A Target Deleting Itself
4.6.4 それ自体を削除する目標
The application at the target may inform the local ST agent that it wants to be removed from the stream. The ST agent then forms a REFUSE message with the target itself as the only entry in the TargetList
目標のアプリケーションは、それを流れから取り除かれたいことを地元のSTエージェントに知らせるかもしれません。 そしてSTエージェントはTargetListにおける唯一のエントリーとして目標自体でREFUSEメッセージを形成します。
Delgrossi & Berger, Editors Experimental [Page 43] RFC 1819 ST2+ Protocol Specification August 1995
[43ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
and with ReasonCode (ApplDisconnect). The REFUSE message 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.
そして、ReasonCode(ApplDisconnect)と共に。 前のホップを通した起源はREFUSEメッセージに送り返されます。 流れにはマルチターゲットがあって、1個の目標がこのREFUSEメカニズムを使用することで流れを残すなら、他の目標への流れは影響を受けません。 流れは存続します。
An ST agent that receives a REFUSE message acknowledges it by sending an ACK to the next-hop. The target is deleted and the LRM is notified so that it adjusts reservations as appropriate. The REFUSE message is also propagated back to the previous-hop ST agent except in the case where the agent is acting as the origin. In this case a NOTIFY may be propagated instead, see Section 4.6.3.
REFUSEメッセージを受け取るSTエージェントは、次のホップにACKを送ることによって、それを承認します。 目標が削除されて、LRMが通知されるので、それは適宜予約を調整します。 また、エージェントが起源として務めているケースの中を除いて、REFUSEメッセージは前のホップSTエージェントに伝播して戻されます。 セクション4.6.3は、この場合NOTIFYが代わりに伝播されるかもしれないのを見ます。
When the REFUSE reaches the origin, the origin sends an ACK and notifies the application that the target is no longer part of the stream.
REFUSEが起源に達すると、起源は、ACKを送って、目標がもう流れの一部でないようにアプリケーションに通知します。
4.6.5 Changing a Stream's FlowSpec
4.6.5 流れのFlowSpecを変えること。
The application at the origin may wish to change the FlowSpec of an established stream. Changing the FlowSpec is a critical operation and it may even lead in some cases to the deletion of the affected targets. Possible problems with FlowSpec changes are discussed in Section 5.6.
起源におけるアプリケーションは確立した流れのFlowSpecを変えたがっているかもしれません。 FlowSpecを変えるのは、重大な作動です、そして、いくつかの場合、それは影響を受ける目標の削除に通じさえするかもしれません。 セクション5.6でFlowSpec変化に伴う起こりうる問題について議論します。
To change the stream's FlowSpec, the application informs the ST agent at the origin of the new FlowSpec and of the list of targets relative to the change. The ST agent at the origin then issues one CHANGE message per next-hop including the new FlowSpec and sends it to the relevant next-hop ST agents. If the G-bit field of the CHANGE message is set (1), the change affects all targets in the stream.
流れのFlowSpecを変えるために、変化に比例してアプリケーションは新しいFlowSpecと目標のリストの起源でSTエージェントに知らせます。 起源におけるSTエージェントは、次に、新しいFlowSpecを含んでいて、次のホップあたり1つのCHANGEメッセージを発行して、関連次のホップSTエージェントにそれを送ります。 CHANGEメッセージのG-ビット分野がセット(1)であるなら、変化は流れですべての目標に影響します。
The CHANGE message contains a bit called I-bit, see Section 10.4.3. By default, the I-bit is set to zero (0) to indicate that the LRM is expected to try and perform the requested FlowSpec change without risking to tear down the stream. Applications that desire a higher probability of success and are willing to take the risk of breaking the stream can indicate this by setting the I-bit to one (1). Applications that require the requested modification in order to continue operating are expected to set this bit.
セクション10.4.3は、CHANGEメッセージが少し呼ばれたI-ビットを含むのを見ます。 デフォルトで、I-ビットがLRMが流れを取りこわすために危険を冒すのなしで要求されたFlowSpec変化を実行してみると予想されるのを示すために(0)のゼロに合うように設定されます。 成功の、より高い確率を望んでいて、流れを壊すという危険を冒しても構わないと思っているアプリケーションは、I-ビットを1つ(1)に設定することによって、これを示すことができます。 作動し続けるために要求された変更を必要とするアプリケーションがこのビットを設定すると予想されます。
An intermediate ST agent that receives a CHANGE message first sends an ACK to the previous-hop and then provides the FlowSpec to the LRM. If the LRM can perform the change, the ST agent propagates the CHANGE messages along the established paths.
最初にCHANGEメッセージを受け取る中間的STエージェントは、前のホップにACKを送って、次に、FlowSpecをLRMに供給します。 LRMが変化を実行できるなら、STエージェントは確立した経路に沿ってCHANGEメッセージを伝播します。
Delgrossi & Berger, Editors Experimental [Page 44] RFC 1819 ST2+ Protocol Specification August 1995
[44ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
If the whole process succeeds, the CHANGE messages will eventually reach the targets. Targets respond with an ACCEPT (or REFUSE) message that is propagated back to the origin. In processing the ACCEPT message on the way back to the origin, excess resources may be released by the LRM as described in Section 4.5.6. The REFUSE message must have the ReasonCode (ApplRefused).
全体の過程が成功すると、CHANGEメッセージは結局、目標に達するでしょう。 目標は起源に伝播して戻されるACCEPT(または、REFUSE)メッセージで応じます。 起源への途中にACCEPTメッセージを処理する際に、余分なリソースはセクション4.5.6で説明されるようにLRMによって発表されるかもしれません。 REFUSEメッセージには、ReasonCode(ApplRefused)がなければなりません。
SCMP also provides a flooding mechanism to change targets that joined the stream without notifying the origin. The special case of target change via flooding is described in Section 5.7.
また、SCMPは、起源に通知しないで流れに参加した目標を変えるために氾濫メカニズムを提供します。 氾濫を通した目標変化の特別なケースはセクション5.7で説明されます。
4.7 Stream Tear Down
4.7 流れの裂け目の下
A stream is usually terminated by the origin when it has no further data to send. A stream is also torn down if the application should terminate abnormally or if certain network failures are encountered. Processing in this case is identical to the previous descriptions except that the ReasonCode (ApplAbort, NetworkFailure, etc.) is different.
それに送るデータがこれ以上ないと、通常、流れは起源によって終えられます。 また、アプリケーションが異常に終わるべきであるか、またはあるネットワーク失敗に遭遇するなら、小川を取りこわします。 ReasonCode(ApplAbort、NetworkFailureなど)が異なっているのを除いて、この場合、処理は前の記述と同じです。
When all targets have left a stream, the origin notifies the application of that fact, and the application is then responsible for terminating the stream. Note, however, that the application may decide to add targets to the stream instead of terminating it, or may just leave the stream open with no targets in order to permit stream joins.
すべての目標が流れを残したとき、起源はその事実の適用に通知します、そして、次に、アプリケーションは流れを終えるのに原因となります。 注意、しかしながら、アプリケーションがそれを終えることの代わりに流れに目標を加えると決めるか、または流れを可能にするためにただ流れを目標なしで開いた状態でおくかもしれないのが接合します。
5. Exceptional Cases
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 exceed a network MTU, are lost, the requested resources are not available, the routing fails or is inconsistent.
前の記述はすべてが働いていた簡単なケースをカバーしました。 私たちは、現在、いろいろなことが成功しないと何が起こるかと議論します。 含まれているのは、メッセージがネットワークMTUを超えて、無くなる、要求されたリソースが利用可能でない、ルーティングが失敗するか、または矛盾している状況です。
5.1 Long ST Messages
5.1 長い第メッセージ
It is possible that an ST agent, or an application, will need to send a message that exceeds a network's Maximum Transmission Unit (MTU). This case must be handled but not via generic fragmentation, since ST2 does not support generic fragmentation of either data or control messages.
STエージェント、またはアプリケーションが、ネットワークのMaximum Transmission Unit(MTU)を超えているメッセージを送る必要があるのは、可能です。 本件を、扱われますが、一般的な断片化で扱ってはいけません、ST2がデータかコントロールメッセージのどちらかの一般的な断片化を支持しないので。
5.1.1 Handling of Long Data Packets
5.1.1 長いデータ・パケットの取り扱い
ST agents discard data packets that exceed the MTU of the next-hop network. No error message is generated. Applications should avoid sending data packets larger than the minimum MTU supported by a given
STエージェントは次のホップネットワークのMTUを超えているデータ・パケットを捨てます。 エラーメッセージは全く発生しません。 アプリケーションは、最小のMTUが当然のことを支持したより大きいデータ・パケットを送るのを避けるべきです。
Delgrossi & Berger, Editors Experimental [Page 45] RFC 1819 ST2+ Protocol Specification August 1995
[45ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
stream. The application, both at the origin and targets, can learn the stream minimum MTU through the MTU discovery mechanism described in Section 8.6.
流れてください。 起源と目標では、アプリケーションはセクション8.6で説明されたMTU発見メカニズムを通して流れの最小のMTUを学ぶことができます。
5.1.2 Handling of Long Control Packets
5.1.2 長いコントロールパケットの取り扱い
Each ST agent knows the MTU of the networks to which it is connected, and those MTUs restrict the size of the SCMP message it can send. An SCMP message size can exceed the MTU of a given network for a number of reasons:
それぞれのSTエージェントはそれが関連しているネットワークについてMTUを知っています、そして、それらのMTUsはそれが送ることができるSCMPメッセージのサイズを制限します。 SCMPメッセージサイズは様々な意味で与えられたネットワークのMTUを超えることができます:
o the TargetList parameter (Section 10.3.6) may be too long;
o TargetListパラメタ(セクション10.3.6)は長過ぎるかもしれません。
o the RecordRoute parameter (Section 10.3.5) may be too long.
o RecordRouteパラメタ(セクション10.3.5)は長過ぎるかもしれません。
o the UserData parameter (Section 10.3.7) may be too long;
o UserDataパラメタ(セクション10.3.7)は長過ぎるかもしれません。
o the PDUInError field of the ERROR message (Section 10.4.6) may be
too long;
o ERRORメッセージ(セクション10.4.6)のPDUInError分野は長過ぎるかもしれません。
An ST agent receiving or generating a too long SCMP message should:
長過ぎるSCMPメッセージを受け取るか、または発生させているSTエージェントはそうするべきです:
o break the message into multiple messages, each carrying part of the
TargetList. Any RecordRoute and UserData parameters are replicated
in each message for delivery to all targets. Applications that
support a large number of targets may avoid using long TargetList
parameters, and are expected to do so, by exploiting the stream
joining functions, see Section 4.6.3. One exception to this rule
exists. In the case of a long TargetList parameter to be included in
a STATUS-RESPONSE message, the TargetList parameter is just
truncated to the point where the list can fit in a single message,
see Section 8.4.
o それぞれTargetListの一部を運んで、メッセージを複数のメッセージに細かく分けてください。 どんなRecordRouteとUserDataパラメタも配送への各メッセージですべての目標に模写されます。 多くの目標を支えるアプリケーションは、長いTargetListパラメタを使用するのを避けるかもしれなくて、そうすると予想されます、流れの接合機能を利用することによって、とセクション4.6.3は見ます。 この規則への1つの例外が存在しています。 STATUS-RESPONSEメッセージに含まれるべき長いTargetListパラメタの場合では、TargetListパラメタはただリストがただ一つのメッセージをうまくはめ込むことができるポイントに先端を切られます、とセクション8.4は見ます。
o for down stream agents: if the TargetList parameter contains a
single Target element and the message size is still too long, the ST
agent should issue a REFUSE message with ReasonCode
(RecordRouteSize) if the size of the RecordRoute parameter causes
the SCMP message size to exceed the network MTU, or with ReasonCode
(UserDataSize) if the size of the UserData parameter causes the SCMP
message size to exceed the network MTU. If both RecordRoute and
UserData parameters are present the ReasonCode (UserDataSize) should
be sent. For messages generated at the target: the target ST agent
must check for SCMP messages that may exceed the MTU on the complete
target-to-origin path, and inform the application that a too long
SCMP messages has been generated. The format for the error reporting
is a local implementation issue. The error codes are the same as
previously stated.
o 下に、エージェントを流してください: TargetListパラメタがただ一つのTarget要素を含んでいて、メッセージサイズがまだ長過ぎると、SCMPメッセージサイズがRecordRouteパラメタのサイズでネットワークMTUを超えているなら、STエージェントがReasonCode(RecordRouteSize)と共にREFUSEメッセージを発行するべきですか、またはReasonCodeと共に、(UserDataSize)はSCMPメッセージサイズにUserDataパラメタのサイズであるならネットワークMTUを超えさせます。 RecordRouteとUserDataパラメタの両方が存在しているなら、ReasonCode(UserDataSize)を送るべきです。 目標で発生するメッセージのために: 目標STエージェントは目標から起源への完全な経路のMTUを超えて、発生していた状態で長過ぎるSCMPメッセージがあった利用を知らせるかもしれないSCMPメッセージがないかどうか、チェックしなければなりません。 誤り報告のための形式はローカルの導入問題です。 エラーコードは前述のように同じです。
Delgrossi & Berger, Editors Experimental [Page 46] RFC 1819 ST2+ Protocol Specification August 1995
[46ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
ST agents generating too long ERROR messages, simply truncate the PDUInError field to the point where the message is smaller than the network MTU.
STエージェントが長過ぎるERRORメッセージを発生させて、メッセージがネットワークMTUより小さい肝心のPDUInError分野に単に、先端を切らせてください。
5.2 Timeout Failures
5.2 タイムアウト失敗
As described in Section 4.3, SCMP message delivery is made reliable through the use of acknowledgments, timeouts, and retransmission. The ACCEPT, CHANGE, CONNECT, DISCONNECT, JOIN, JOIN-REJECT, NOTIFY, and REFUSE messages must always be acknowledged, see Section 4.2. In addition, for some SCMP messages (CHANGE, CONNECT, JOIN) the sending ST agent also expects a response back (ACCEPT/REFUSE, CONNECT/JOIN- REJECT) after an ACK has been received. Also, the STATUS message must be answered with a STATUS-RESPONSE message.
セクション4.3で説明されるように、SCMPメッセージ配送を承認、タイムアウト、および「再-トランスミッション」の使用で信頼できるようにします。 セクション4.2は、いつもACCEPT、CHANGE、CONNECT、DISCONNECT、JOIN、JOIN-REJECT、NOTIFY、およびREFUSEメッセージを承認しなければならないのを見ます。 また、さらに、いくつかのSCMPメッセージ(CHANGE、CONNECT、JOIN)に関して、逆(ACCEPT/REFUSE、CONNECT/JOIN- REJECT)ACKを受け取った後に送付STエージェントは応答を予想します。 また、STATUS-RESPONSEメッセージでSTATUSメッセージに答えなければなりません。
The following sections describe the handling of each of the possible failure cases due to timeout situations while waiting for an acknowledgment or a response. The timeout related variables, and their names, used in the next sections are for reference purposes only. They may be implementation specific. Different implementations are not required to share variable names, or even the mechanism by which the timeout and retransmission behavior is implemented.
以下のセクションは承認か応答を待っている間、タイムアウト状況によるそれぞれの可能な失敗事件の取り扱いについて説明します。 タイムアウトは変数、およびそれらの名前を関係づけて、使用されて、目的しか参照のために次のセクションでは、ありません。 それらは実現特有であるかもしれません。 異なった実現は、変数名、またはタイムアウトと「再-トランスミッション」の振舞いが実行されるメカニズムさえ共有するのに必要ではありません。
5.2.1 Failure due to ACCEPT Acknowledgment Timeout
5.2.1 ACCEPT Acknowledgment Timeoutによる失敗
An ST agent that sends an ACCEPT message upstream expects an ACK from the previous-hop ST agent. If no ACK is received before the ToAccept timeout expires, the ST agent should retry and send the ACCEPT message again. After NAccept unsuccessful retries, the ST agent sends a REFUSE message toward the origin, and a DISCONNECT message toward the targets. Both REFUSE and DISCONNECT must identify the affected targets and specify the ReasonCode (RetransTimeout).
ACCEPTメッセージ上流を送るSTエージェントは前のホップSTエージェントからACKを予想します。 ToAcceptタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びACCEPTメッセージを再試行して、送るべきです。 NAcceptの失敗の再試行の後に、STエージェントは起源に向かったREFUSEメッセージ、および目標に向かったDISCONNECTメッセージを送ります。 REFUSEとDISCONNECTの両方が、影響を受ける目標を特定して、ReasonCode(RetransTimeout)を指定しなければなりません。
5.2.2 Failure due to CHANGE Acknowledgment Timeout
5.2.2 CHANGE Acknowledgment Timeoutによる失敗
An ST agent that sends a CHANGE message downstream expects an ACK from the next-hop ST agent. If no ACK is received before the ToChange timeout expires, the ST agent should retry and send the CHANGE message again. After NChange unsuccessful retries, the ST agent aborts the change attempt by sending a REFUSE message toward the origin, and a DISCONNECT message toward the targets. Both REFUSE and DISCONNECT must identify the affected targets and specify the ReasonCode (RetransTimeout).
CHANGEメッセージを川下に送るSTエージェントは次のホップSTエージェントからACKを予想します。 ToChangeタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びCHANGEメッセージを再試行して、送るべきです。 NChangeの失敗の再試行の後に、STエージェントは、REFUSEメッセージを起源に向かって発信させて、DISCONNECTメッセージを目標に向かって発信させることによって、変化試みを中止します。 REFUSEとDISCONNECTの両方が、影響を受ける目標を特定して、ReasonCode(RetransTimeout)を指定しなければなりません。
Delgrossi & Berger, Editors Experimental [Page 47] RFC 1819 ST2+ Protocol Specification August 1995
[47ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
5.2.3 Failure due to CHANGE Response Timeout
5.2.3 CHANGE Response Timeoutによる失敗
Only the origin ST agent implements this timeout. After correctly receiving the ACK to a CHANGE message, an ST agent expects to receive an ACCEPT, or REFUSE message in response. If one of these messages is not received before the ToChangeResp timer expires, the ST agent at the origin aborts the change attempt, and behaves as if a REFUSE message with the E-bit set and with ReasonCode (ResponseTimeout) is received.
起源STエージェントだけがこのタイムアウトを実行します。 正しくCHANGEメッセージにACKを受けた後に、STエージェントは、応答でACCEPT、またはREFUSEメッセージを受け取ると予想します。 ToChangeRespタイマが期限が切れる前にこれらのメッセージの1つが受け取られていないなら、起源におけるSTエージェントは、変化試みを中止して、まるでE-ビットセットとReasonCode(ResponseTimeout)があるREFUSEメッセージが受信されているかのように振る舞います。
5.2.4 Failure due to CONNECT Acknowledgment Timeout
5.2.4 CONNECT Acknowledgment Timeoutによる失敗
An ST agent that sends a CONNECT message downstream expects an ACK from the next-hop ST agent. If no ACK is received before the ToConnect timeout expires, the ST agent should retry and send the CONNECT message again. After NConnect unsuccessful retries, the ST agent sends a REFUSE message toward the origin, and a DISCONNECT message toward the targets. Both REFUSE and DISCONNECT must identify the affected targets and specify the ReasonCode (RetransTimeout).
CONNECTメッセージを川下に送るSTエージェントは次のホップSTエージェントからACKを予想します。 ToConnectタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びCONNECTメッセージを再試行して、送るべきです。 NConnectの失敗の再試行の後に、STエージェントは起源に向かったREFUSEメッセージ、および目標に向かったDISCONNECTメッセージを送ります。 REFUSEとDISCONNECTの両方が、影響を受ける目標を特定して、ReasonCode(RetransTimeout)を指定しなければなりません。
5.2.5 Failure due to CONNECT Response Timeout
5.2.5 CONNECT Response Timeoutによる失敗
Only the origin ST agent implements this timeout. After correctly receiving the ACK to a CONNECT message, an ST agent expects to receive an ACCEPT or REFUSE message in response. If one of these messages is not received before the ToConnectResp timer expires, the origin ST agent aborts the connection setup attempt, acts as if a REFUSE message is received, and it sends a DISCONNECT message toward the targets. Both REFUSE and DISCONNECT must identify the affected targets and specify the ReasonCode (ResponseTimeout).
起源STエージェントだけがこのタイムアウトを実行します。 正しくCONNECTメッセージにACKを受けた後に、STエージェントは、応答におけるACCEPTかREFUSEメッセージを受け取ると予想します。 これらのメッセージの1つが以前受け取られないなら、ToConnectRespタイマは期限が切れます、そして、起源STエージェントは、接続設定試みを中止して、まるでREFUSEメッセージが受信されているかのように行動します、そして、それはDISCONNECTメッセージを目標に向かって送ります。 REFUSEとDISCONNECTの両方が、影響を受ける目標を特定して、ReasonCode(ResponseTimeout)を指定しなければなりません。
5.2.6 Failure due to DISCONNECT Acknowledgment Timeout
5.2.6 DISCONNECT Acknowledgment Timeoutによる失敗
An ST agent that sends a DISCONNECT message downstream expects an ACK from the next-hop ST agent. If no ACK is received before the ToDisconnect timeout expires, the ST agent should retry and send the DISCONNECT message again. After NDisconnect unsuccessful retries, the ST agent simply gives up and it assumes the next-hop ST agent is not part in the stream any more.
DISCONNECTメッセージを川下に送るSTエージェントは次のホップSTエージェントからACKを予想します。 ToDisconnectタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びDISCONNECTメッセージを再試行して、送るべきです。 NDisconnectの失敗の再試行の後に、STエージェントは単にあきらめます、そして、それは次のホップSTエージェントがもう流れの部分でないと仮定します。
5.2.7 Failure due to JOIN Acknowledgment Timeout
5.2.7 JOIN Acknowledgment Timeoutによる失敗
An ST agent that sends a JOIN message toward the origin expects an ACK from a neighbor ST agent. If no ACK is received before the ToJoin timeout expires, the ST agent should retry and send the JOIN message again. After NJoin unsuccessful retries, the ST agent sends a JOIN- REJECT message back in the direction of the target with ReasonCode (RetransTimeout).
JOINメッセージを起源に向かって送るSTエージェントは隣人STエージェントからACKを予想します。 ToJoinタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びJOINメッセージを再試行して、送るべきです。 NJoinの失敗の再試行の後に、STエージェントはReasonCode(RetransTimeout)がある目標の向きにJOIN- REJECTメッセージを返送します。
Delgrossi & Berger, Editors Experimental [Page 48] RFC 1819 ST2+ Protocol Specification August 1995
[48ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
5.2.8 Failure due to JOIN Response Timeout
5.2.8 JOIN Response Timeoutによる失敗
Only the target agent implements this timeout. After correctly receiving the ACK to a JOIN message, the ST agent at the target expects to receive a CONNECT or JOIN-REJECT message in response. If one of these message is not received before the ToJoinResp timer expires, the ST agent aborts the stream join attempt and returns an error corresponding with ReasonCode (RetransTimeout) to the application.
目標エージェントだけがこのタイムアウトを実行します。 正しくJOINメッセージにACKを受けた後に、目標のSTエージェントは、応答におけるCONNECTかJOIN-REJECTメッセージを受け取ると予想します。 ToJoinRespタイマが期限が切れる前にこれらのメッセージの1つが受け取られていないなら、流れが参加するSTエージェントアボートは、ReasonCode(RetransTimeout)と共にアプリケーションに対応する誤りを試みて、返します。
Note that, after correctly receiving the ACK to a JOIN message, intermediate ST agents do not maintain any state on the stream joining attempt. As a consequence, they do not set the ToJoinResp timer and do not wait for a CONNECT or JOIN-REJECT message. This is described in Section 4.6.3.
正しくJOINメッセージにACKを受けた後に中間的STエージェントが流れの接合試みの少しの状態も維持しないことに注意してください。 結果として、彼らは、ToJoinRespタイマを設定しないで、またCONNECTかJOIN-REJECTメッセージを待ちません。 これはセクション4.6.3で説明されます。
5.2.9 Failure due to JOIN-REJECT Acknowledgment Timeout
5.2.9 JOIN-REJECT Acknowledgment Timeoutによる失敗
An ST agent that sends a JOIN-REJECT message toward the target expects an ACK from a neighbor ST agent. If no ACK is received before the ToJoinReject timeout expires, the ST agent should retry and send the JOIN-REJECT message again. After NJoinReject unsuccessful retries, the ST agent simply gives up.
JOIN-REJECTメッセージを目標に向かって送るSTエージェントは隣人STエージェントからACKを予想します。 ToJoinRejectタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びJOIN-REJECTメッセージを再試行して、送るべきです。 NJoinRejectの失敗の再試行の後に、STエージェントは単にあきらめます。
5.2.10 Failure due to NOTIFY Acknowledgment Timeout
5.2.10 NOTIFY Acknowledgment Timeoutによる失敗
An ST agent that sends a NOTIFY message to a neighbor ST agent expects an ACK from that neighbor ST agent. If no ACK is received before the ToNotify timeout expires, the ST agent should retry and send the NOTIFY message again. After NNotify unsuccessful retries, the ST agent simply gives up and behaves as if the ACK message was received.
隣人STエージェントにNOTIFYメッセージを送るSTエージェントはその隣人STエージェントからACKを予想します。 ToNotifyタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びNOTIFYメッセージを再試行して、送るべきです。 NNotifyの失敗の再試行の後に、STエージェントは、単にあきらめて、まるでACKメッセージを受け取るかのように振る舞います。
5.2.11 Failure due to REFUSE Acknowledgment Timeout
5.2.11 REFUSE Acknowledgment Timeoutによる失敗
An ST agent that sends a REFUSE message upstream expects an ACK from the previous-hop ST agent. If no ACK is received before the ToRefuse timeout expires, the ST agent should retry and send the REFUSE message again. After NRefuse unsuccessful retries, the ST agent gives up and it assumes it is not part in the stream any more.
REFUSEメッセージ上流を送るSTエージェントは前のホップSTエージェントからACKを予想します。 ToRefuseタイムアウトが期限が切れる前にどんなACKも受け取られていないなら、STエージェントは、再びREFUSEメッセージを再試行して、送るべきです。 NRefuseの失敗の再試行の後に、STエージェントはあきらめます、そして、それはもう流れの部分でないと仮定します。
5.2.12 Failure due to STATUS Response Timeout
5.2.12 STATUS Response Timeoutによる失敗
After sending a STATUS message to a neighbor ST agent, an ST agent expects to receive a STATUS-RESPONSE message in response. If this message is not received before the ToStatusResp timer expires, the ST agent sends the STATUS message again. After NStatus unsuccessful retries, the ST agent gives up and assumes that the neighbor ST agent
隣人STエージェントにSTATUSメッセージを送った後に、STエージェントは、応答におけるSTATUS-RESPONSEメッセージを受け取ると予想します。 ToStatusRespタイマが期限が切れる前にこのメッセージが受信されていないなら、STエージェントは再びSTATUSメッセージを送ります。 NStatusの失敗の再試行の後に、STエージェントは、それが隣人STエージェントであるとあきらめて、仮定します。
Delgrossi & Berger, Editors Experimental [Page 49] RFC 1819 ST2+ Protocol Specification August 1995
[49ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
is not active.
アクティブでない。
5.3 Setup Failures due to Routing Failures
5.3 ルート設定FailuresによるセットアップFailures
It is possible for an ST agent to receive a CONNECT message that contains a known SID, but from an ST agent other than the previous- hop ST agent of the stream with that SID. This may be:
それは、知られているSIDを含むCONNECTメッセージを受け取るSTエージェントにとって可能ですが、そのSIDとの流れの前のホップSTエージェント以外のSTエージェントから可能です。 これは以下の通りです。
1. that two branches of the tree forming the stream have joined
back together,
1. 流れを形成する木の2つの枝が結合し返しました。
2. the result of an attempted recovery of a partially failed
stream, or
または2. 部分的に失敗した流れの試みられた回収の結果。
3. a routing loop.
3. ルーティング輪。
The TargetList contained in the CONNECT is used to distinguish the different cases by comparing each newly received target with those of the previously existing stream:
CONNECTに含まれたTargetListは以前に既存の流れのものとそれぞれの新たに受け取られた目標を比べることによって異なったケースを区別するのに使用されます:
o if the IP address of the target(s) differ, it is case #1;
o 目標のIPアドレスであるなら、異なってください、そして、それはケース#1です。
o if the target matches a target in the existing stream, it may be
case #2 or #3.
o 目標が既存の流れで目標に合っているなら、それは、ケース#2か#3、かもしれない。
Case #1 is handled in Section 5.3.1, while the other cases are handled in Section 5.3.2.
ケース#1はセクション5.3.1で扱われますが、他のケースはセクション5.3.2で扱われます。
5.3.1 Path Convergence
5.3.1 経路集合
It is possible for an ST agent to receive a CONNECT message that contains a known SID, but from an ST agent other than the previous- hop ST agent of the stream with that SID. This might be the result of two branches of the tree forming the stream have joined back together. Detection of this case and other possible sources was discussed in Section 5.2.
それは、知られているSIDを含むCONNECTメッセージを受け取るSTエージェントにとって可能ですが、そのSIDとの流れの前のホップSTエージェント以外のSTエージェントから可能です。 これは流れが結合し返させた木の形成の2つのブランチの結果であるかもしれません。 セクション5.2で本件と他の可能なソースの検出について議論しました。
SCMP does not allow for streams which have converged paths, i.e., streams are always tree-shaped and not graph-like. At the point of convergence, the ST agent which detects the condition generates a REFUSE message with ReasonCode (PathConvergence). Also, as a help to the upstream ST agent, the detecting agent places the IP address of one of the stream's connected targets in the ValidTargetIPAddress field of the REFUSE message. This IP address will be used by upstream ST agents to avoid splitting the stream.
すなわち、流れは、SCMPが経路を一点に集めた流れを考慮しないで、またいつも木の形をしていてグラフのようではありません。 集合のポイントでは、状態を検出するSTエージェントはReasonCode(PathConvergence)と共にREFUSEメッセージを発生させます。 また、上流のSTエージェントへの助けとして、検出しているエージェントは流れの接続目標の1つのIPアドレスをREFUSEメッセージのValidTargetIPAddress分野に置きます。 このIPアドレスは、流れを分けるのを避けるのに上流のSTエージェントによって使用されるでしょう。
An upstream ST agent that receives the REFUSE with ReasonCode (PathConvergence) will check to see if the listed IP address is one
ReasonCode(PathConvergence)と共にREFUSEを受け取る上流のSTエージェントは、記載されたIPアドレスが1であるかどうか確認するためにチェックするでしょう。
Delgrossi & Berger, Editors Experimental [Page 50] RFC 1819 ST2+ Protocol Specification August 1995
[50ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
of the known stream targets. If it is not, the REFUSE is propagated to the previous-hop agent. If the listed IP address is known by the upstream ST agent, this ST agent is the ST agent that caused the split in the stream. (This agent may even be the origin.) This agent then avoids splitting the stream by using the next-hop of that known target as the next-hop for the refused targets. It sends a CONNECT with the affected targets to the existing valid next-hop.
知られている流れの目標について。 それがそうでないなら、REFUSEは前のホップエージェントに伝播されます。 記載されたIPアドレスが上流のSTエージェントによって知られているなら、このSTエージェントは流れで分裂を引き起こしたSTエージェントです。 (このエージェントは起源でさえあるかもしれません。) そして、このエージェントは、拒否された目標に次のホップとしてその知られている目標の次のホップを使用することによって流れを分けるのを避けます。 それは既存の有効な次のホップに影響を受ける目標があるCONNECTを送ります。
The above process will proceed, hop by hop, until the ValidTargetIPAddress matches the IP address of a known target. The only case where this process will fail is when the known target is deleted prior to the REFUSE propagating to the origin. In this case the origin can just reissue the CONNECT and start the whole process over again.
上の過程を続かせて、ValidTargetIPAddressが知られている目標のIPアドレスに合うまで、ホップで跳んでください。 この過程が失敗する唯一のケースが起源への知られている目標がREFUSE伝播の前に削除される時です。 この場合、起源は、ただCONNECTを再発行して、再び全体の過程をやり直すことができます。
5.3.2 Other Cases
5.3.2 他のケース
The remaining cases including a partially failed stream and a routing loop, are not easily distinguishable. In attempting recovery of a failed stream, an ST agent may issue new CONNECT messages to the affected targets. Such a CONNECT may reach an ST agent downstream of the failure before that ST agent has received a DISCONNECT from the neighborhood of the failure. Until that ST agent receives the DISCONNECT, it cannot distinguish between a failure recovery and an erroneous routing loop. That ST agent must therefore respond to the CONNECT with a REFUSE message with the affected targets specified in the TargetList and an appropriate ReasonCode (StreamExists).
部分的に失敗した流れとルーティング輪を含む残っているケースは容易に区別可能ではありません。 失敗した流れの回収を試みる際に、STエージェントは新しいCONNECTメッセージを影響を受ける目標に発行するかもしれません。 そのSTエージェントが失敗の近所からDISCONNECTを受け取る前にそのようなCONNECTは失敗のSTエージェント川下に達するかもしれません。 そのSTエージェントがDISCONNECTを受け取るまで、それは失敗回復と誤ったルーティング輪を見分けることができません。 したがって、影響を受ける目標がTargetListと適切なReasonCode(StreamExists)で指定されている状態で、そのSTエージェントはREFUSEメッセージでCONNECTに応じなければなりません。
The ST agent immediately preceding that point, i.e., the latest ST 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 ST 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, see Section 5.2.4. 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 ReasonCode (RouteLoop).
そのポイント、すなわち、最新のSTエージェントのすぐにCONNECTメッセージを送るために上位であるSTエージェントはREFUSEメッセージを受け取るでしょう。 それは排他的な記載された目標への交通に予約されたどんなリソースも発表しなければなりません。 このSTエージェントが流れの回復を試みるものでなかったなら、それは失敗回復と誤ったルーティング輪を見分けることができません。 セクション5.2.4は、それがToConnectタイムアウトの後にCONNECTを繰り返すべきであるのを見ます。 NConnect retransmissionsの後にREFUSEメッセージを受け取り続けているなら、それは影響を受ける目標を指定するTargetListにもかかわらず、異なったReasonCode(RouteLoop)と共に起源に向かったREFUSEメッセージを伝播するべきです。
The REFUSE message with this ReasonCode (RouteLoop) is propagated by each ST agent without retransmitting any CONNECT messages. At each ST 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 ST agent or the origin itself. In the case of a stream recovery, the ST agent attempting the
どんなCONNECTメッセージも再送しないで、このReasonCode(RouteLoop)があるREFUSEメッセージはそれぞれのSTエージェントによって伝播されます。 それぞれのSTエージェントでは、それは記載された目標がリリースされるために排他的に予約されたどんなリソースも引き起こします。 REFUSEは誤ったルーティング輪の場合で起源に伝播されるでしょう。 流れの回復の場合では、それは中間的STエージェントか起源自体であるかもしれない回復を試みているSTエージェントに伝播されるでしょう。 流れの回復、STエージェントの試みに関するケース
Delgrossi & Berger, Editors Experimental [Page 51] RFC 1819 ST2+ Protocol Specification August 1995
[51ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
recovery may issue new CONNECT messages to the same or to different next-hops.
回復は同じくらい、または、異なった次のホップに新しいCONNECTメッセージを発行するかもしれません。
If an ST agent receives both a REFUSE message and a DISCONNECT message with a target in common then it can, for the each target in common, release the relevant resources and propagate neither the REFUSE nor the DISCONNECT.
目標がコモンにある状態でSTエージェントが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 informed so that it may take whatever action it seems necessary.
起源がそのようなREFUSEメッセージを受け取るなら、それは、すべての影響を受ける目標に新しいCONNECTを送るのを試みるべきです。 インターネットにおけるルーティング誤りが一時的であると思われて、新しいCONNECTsは結局許容できるルートを目標に見つけるでしょう、1つが存在しているなら。 NRetryRouteが試みた後にさらなるルートが全く存在していないなら、アプリケーションは、必要な状態で思えるどんな行動も取ることができるように、知識があるべきです。
5.4 Problems due to Routing Inconsistency
5.4 ルート設定Inconsistencyによる問題
When an intermediate ST agent receives a CONNECT, it invokes the routing algorithm to select the next-hop ST 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 ST agent an informative NOTIFY message with the appropriate ReasonCode (RouteBack), pertinent TargetList, and in the NextHopIPAddress element the address of the next-hop ST agent returned by its routing algorithm.
中間的STエージェントがCONNECTを受け取るとき、それは、TargetListに基づく次のホップSTエージェントとそれが関連しているネットワークを選択するためにルーティング・アルゴリズムを呼び出します。 目標のどれかへの結果として起こる次のホップがそれがCONNECT(しかし、前のホップ自体でない)を受けたのと同じネットワークのむこうにあるなら、ルーティング問題があるかもしれません。 しかしながら、ホップがローカルのアルゴリズムと異なって最適化しているかもしれない前のルーティング・アルゴリズムは同じ状況でそうするでしょう。 地元のSTエージェントが2つのケースを区別できないので、セットアップを可能にしますが、適切なReasonCode(RouteBack)と共に前のホップSTエージェントに有益なNOTIFYメッセージを送り返すべきです、適切なTargetList、そして、NextHopIPAddress要素では、ルーティング・アルゴリズムで次のホップSTエージェントのアドレスは戻りました。
The ST agent that receives such a NOTIFY should ACK it. If the ST agent is using an algorithm that would produce such behavior, no further action is taken; if not, the ST agent should send a DISCONNECT to the next-hop ST agent to correct the problem.
そのようなNOTIFYを受け取るSTエージェントがそうするべきである、ACK、それ。 STエージェントがそのような振舞いを起こすアルゴリズムを使用しているなら、さらなる行動を全く取りません。 そうでなければ、STエージェントは、問題を修正するために次のホップSTエージェントに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 the previous-hop ST agent containing an appropriate ReasonCode (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 ST 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.
あるいはまた、事実上、経路選択機能によって返された次のホップが前のホップであるなら、ルーティング矛盾は検出されました。 この場合、REFUSEは適切なReasonCode(RouteInconsist)、適切なTargetList、およびNextHopIPAddress要素の前のホップのアドレスを含む前のホップSTエージェントに送り返されます。 前のホップがREFUSEを受けるとき、それは影響を受ける目標のために次のホップを再計算するでしょう。 ルーティングデータベースの違いが2人のSTエージェントにあれば、彼らは再びCONNECTとREFUSEメッセージを交換するかもしれません。 インターネットにおけるそのようなルーティング誤りが一時的であると思われるので、状況は結局、安定するべきです。
Delgrossi & Berger, Editors Experimental [Page 52] RFC 1819 ST2+ Protocol Specification August 1995
[52ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
5.5 Problems in Reserving Resources
5.5 リソースを予約することにおける問題
As mentioned in Section 1.4.5, resource reservation is handled by the LRM. The LRM may not be able to satisfy a particular request during stream setup or modification for a number of reasons, including a mismatched FlowSpec, an unknown FlowSpec version, an error in processing a FlowSpec, and an inability to allocate the requested resource. This section discusses these cases and specifies the ReasonCodes that should be used when these error cases are encountered.
セクション1.4.5で言及されるように、資源予約はLRMによって扱われます。 LRMは流れのセットアップか変更の間、様々な意味で特定の要求を満たすことができないかもしれません、ミスマッチしているFlowSpec、未知のFlowSpecバージョン、FlowSpecを処理することにおける誤り、および要求されたリソースを割り当てることができないことを含んでいて。 このセクションは、これらのケースについて論じて、これらの誤り事件が遭遇するとき使用されるべきであるReasonCodesを指定します。
5.5.1 Mismatched FlowSpecs
5.5.1 ミスマッチしているFlowSpecs
In some cases the LRM may require a requested FlowSpec to match an existing FlowSpec, e.g., when adding new targets to an existing stream, see Section 4.6.1. In case of FlowSpec mismatch the LRM notifies the processing ST agent which should respond with ReasonCode (FlowSpecMismatch).
例えば、既存の流れに新しい目標を加えるとき、いくつかの場合、LRMは、要求されたFlowSpecが既存のFlowSpecに合っているのを必要とするかもしれません、とセクション4.6.1が見ます。 FlowSpecミスマッチの場合には、LRMはReasonCode(FlowSpecMismatch)と共に応じるべきである処理STエージェントに通知します。
5.5.2 Unknown FlowSpec Version
5.5.2 未知のFlowSpecバージョン
When the LRM is invoked, it is passed information including the version of the FlowSpec, see Section 4.5.2.2. If this version is not known by the LRM, the LRM notifies the ST agent. The ST agent should respond with a REFUSE message with ReasonCode (FlowVerUnknown).
セクション4.5.2は、LRMが呼び出されるとき、FlowSpecのバージョンを含む情報がそれに通過されるのを.2に見ます。 このバージョンがLRMによって知られていないなら、LRMはSTエージェントに通知します。 STエージェントはReasonCode(FlowVerUnknown)と共にREFUSEメッセージで応じるべきです。
5.5.3 LRM Unable to Process FlowSpec
5.5.3 FlowSpecを処理できないLRM
The LRM may encounter an LRM or FlowSpec specific error while attempting to satisfy a request. An example of such an error is given in Section 9.2.1. These errors are implementation specific and will not be enumerated with ST ReasonCodes. They are covered by a single, generic ReasonCode. When an LRM encounters such an error, it should notify the ST agent which should respond with the generic ReasonCode (FlowSpecError).
要望に応じるのを試みている間、LRMはLRMかFlowSpecの特定の誤りに遭遇するかもしれません。 そのような誤りに関する例はセクション9.2.1で出されます。 これらの誤りは、実現特有であり、ST ReasonCodesと共に列挙されないでしょう。 それらは単一の、そして、一般的なReasonCodeで覆われています。 LRMがそのような誤りに遭遇するのでSTエージェントに通知するべきであるとき(一般的なReasonCode(FlowSpecError)と共に応じるべきです)。
5.5.4 Insufficient Resources
5.5.4 不十分なリソース
If the LRM cannot make the necessary reservations because sufficient resources are not available, an ST agent may:
LRMが十分なリソースが利用可能でないので必要な予約をすることができないなら、STエージェントはします:
o try alternative paths to the targets: the ST agent calls the routing
function to find a different path to the targets. If an alternative
path is found, stream connection setup continues in the usual way,
as described in Section 4.5.
o 目標に迂回経路を試みてください: STエージェントは、異なった経路を目標に見つけるために経路選択機能を呼びます。 迂回経路が見つけられるなら、流れの接続設定はセクション4.5で説明されるように不断のとおり続きます。
Delgrossi & Berger, Editors Experimental [Page 53] RFC 1819 ST2+ Protocol Specification August 1995
[53ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o refuse to establish the stream along this path: the origin ST agent
informs the application of the stream setup failure; intermediate
and target ST agents issue a REFUSE message (as described in Section
4.5.8) with ReasonCode (CantGetResrc).
o この経路に沿って流れを確立するのを拒否してください: 起源STエージェントは流れのセットアップ失敗のアプリケーションを知らせます。 中間介在物と目標STエージェントはReasonCode(CantGetResrc)と共にREFUSEメッセージ(セクション4.5.8で説明されるように)を発行します。
It depends on the local implementations whether an ST agent tries alternative paths or refuses to establish the stream. In any case, if enough resources cannot be found over different paths, the ST agent has to explicitly refuse to establish the stream.
地方の実現のときにSTエージェントが、迂回経路を試みるか、または流れを確立するのを拒否することにかかわらず場合によりけりです。 どのような場合でも、異なった経路に関して十分なリソースを見つけることができないなら、STエージェントは、流れを確立するのを明らかに拒否しなければなりません。
5.6 Problems Caused by CHANGE Messages
5.6 変化メッセージによって引き起こされた問題
A CHANGE might fail for several reasons, including:
CHANGEはいくつかの理由、包含のために失敗するかもしれません:
o insufficient resources: the request may be for a larger amount of
network resources when those resources are not available, ReasonCode
(CantGetResrc);
o 不十分なリソース: ReasonCode(CantGetResrc)、それらのリソースが利用可能でないときに、要求は多く以上の量のネットワーク資源のためのものであるかもしれません。
o a target application not agreeing to the change, ReasonCode
(ApplRefused);
o 変化、ReasonCode(ApplRefused)に同意しない目標アプリケーション。
The affected stream can be left in one of two states as a result of change failures: a) the stream can revert back to the state it was in prior to the CHANGE message being processed, or b) the stream may be torn down.
変化失敗の結果、2つの州の1つに影響を受ける小川を残すことができます: 流れが処理されるCHANGEメッセージ、またはbの前に、それがあった状態に振り向けて戻すことができるa)) 小川を取りこわすかもしれません。
The expected common case of failure will be when the requested change cannot be satisfied, but the pre-change resources remain allocated and available for use by the stream. In this case, the ST agent at the point where the failure occurred must inform upstream ST agents of the failure. (In the case where this ST agent is the target, there may not actually be a failure, the application may merely have not agreed to the change). The ST agent informs upstream ST agents by sending a REFUSE message with ReasonCode (CantGetResrc or ApplRefused). To indicate that the pre-change FlowSpec is still available and that the stream still exists, the ST agent sets the E- bit of the REFUSE message to one (1), see Section 10.4.11. Upstream ST agents receiving the REFUSE message inform the LRM so that it can attempt to revert back to the pre-change FlowSpec. It is permissible, but not desirable, for excess resources to remain allocated.
失敗の予想されたよくある例は要求された変化が満足することができない時になるでしょうが、プレ変化リソースは流れで使用に割り当てて利用可能なままで残っています。 この場合、失敗が起こったポイントのSTエージェントは失敗について上流のSTエージェントに知らせなければなりません。 (このSTエージェントが目標である場合には、失敗が実際にないかもしれなくて、またアプリケーションは単に変化に同意していないかもしれません。) STエージェントは、ReasonCode(CantGetResrcかApplRefused)と共に上流のSTエージェントにREFUSEメッセージを送ることによって、知らせます。 プレ変化FlowSpecがまだ利用可能であり、流れがまだ存在しているのを示すために、STエージェントはREFUSEメッセージのEビットを1つ(1)に設定します、とセクション10.4.11が見ます。 REFUSEメッセージを受け取る上流のSTエージェントは、プレ変化FlowSpecに戻って戻るのを試みることができるようにLRMに知らせます。 許されますが、割り当てたままで残っているのは、余分なリソースには、望ましくはありません。
For the case when the attempt to change the stream results in the loss of previously reserved resources, the stream is torn down. This can happen, for instance, when the I-bit is set (Section 4.6.5) and the LRM releases pre-change stream resources before the new ones are reserved, and neither new nor former resources are available. In this case, the ST agent where the failure occurs must inform other ST agents of the break in the affected portion of the stream. This is
流れを変える試みが以前に予約されたリソースの損失をもたらすときのケースにおいて、小川を取りこわします。 例えば、I-ビットが設定されて(セクション4.6.5)、新しい方が予約されている前にLRMがプレ変化流れのリソースを発表すると、これは起こることができます、そして、新しくなくてまた前でないリソースは利用可能です。 この場合、STエージェントは流れの影響を受ける部分で失敗が起こるところで中断について他のSTエージェントに知らせなければなりません。 これはそうです。
Delgrossi & Berger, Editors Experimental [Page 54] RFC 1819 ST2+ Protocol Specification August 1995
[54ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
done by the ST agent by sending a REFUSE message upstream and a DISCONNECT message downstream, both with the ReasonCode (CantGetResrc). To indicate that pre-change stream resources have been lost, the E-bit of the REFUSE message is set to zero (0).
ReasonCode(CantGetResrc)と共に両方の、REFUSEメッセージ上流とDISCONNECTメッセージを川下に送ることによって、STエージェントによって行われます。 プレ変化流れのリソースが失われたのを示すために、REFUSEメッセージのE-ビットが(0)のゼロに合うように設定されます。
Note that a failure to change the resources requested for specific targets should not cause other targets in the stream to be deleted.
特定の目標のために要求されたリソースを変えない場合流れの他の目標が削除されることを引き起こすべきでないことに注意してください。
5.7 Unknown Targets in DISCONNECT and CHANGE
5.7 分離と変化における未知の目標
The handling of unknown targets listed in a DISCONNECT or CHANGE message is dependent on a stream's join authorization level, see Section 4.4.2. For streams with join authorization levels #0 and #1, see Section 4.4.2, all targets must be known. In this case, when processing a CHANGE message, the agent should generate a REFUSE message with ReasonCode (TargetUnknown). When processing a DISCONNECT message, it is possible that the DISCONNECT is a duplicate of an old request so the agent should respond as if it has successfully disconnected the target. That is, it should respond with an ACK message.
DISCONNECTかCHANGEメッセージに記載された未知の目標の取り扱いは流れのものでの扶養家族が認可レベルに加わります、とセクション4.4.2が見るということです。 あふれる、認可レベル#0、と#1を接合してください、そして、セクション4.4.2、すべての目標を知っていなければならないのを確実にしてください。 この場合CHANGEメッセージを処理するとき、エージェントはReasonCode(TargetUnknown)と共にREFUSEメッセージを発生させるべきです。 DISCONNECTメッセージを処理するとき、DISCONNECTが古い要求の写しであることが可能であるので、まるで首尾よく目標を外したかのようにエージェントは応じるべきです。 すなわち、それはACKメッセージで応じるべきです。
For streams with join authorization level #2, it is possible that the origin is not aware of some targets that participate in the stream. The origin may delete or change these targets via the following flooding mechanism.
あふれる、認可レベル#2に参加してください、そして、起源が流れに参加するいくつかの目標を意識していないのは、可能です。 起源は、以下の氾濫メカニズムでこれらの目標を削除するか、または変えるかもしれません。
If no next-hop ST agent can be associated with a target, the CHANGE/ DISCONNECT message including the target is replicated to all known next-hop ST agents. This has the effect of propagating the CHANGE/ DISCONNECT message to all downstream ST agents. Eventually, the ST agent that acts as the origin for the target (Section 4.6.3.1) is reached and the target is deleted.
次のホップSTエージェントを全く目標に関連づけることができないなら、目標を含むCHANGE/ DISCONNECTメッセージはすべての知られている次のホップSTエージェントに模写されます。 これには、すべての川下のSTエージェントにCHANGE/ DISCONNECTメッセージを伝播するという効果があります。 結局目標のための起源として務めるSTエージェント、(セクション4.6 .3 .1に)達していて、目標は削除されます。
Target deletion/change via flooding is not expected to be the normal case. It is included to present the applications with uniform capabilities for all stream types. Flooding only applies to streams with join authorization level #2.
氾濫を通した目標削除/変化は正常なケースでないと予想されます。 すべてのストリーム型のために一定の能力をアプリケーションに与えるのは含まれています。 氾濫が流れに適用するだけである、認可レベル#2に参加してください。
6. Failure Detection and Recovery
6. 失敗検出と回復
6.1 Failure Detection
6.1 失敗検出
The SCMP failure detection mechanism is based on two assumptions:
SCMP失敗検出メカニズムは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エージェントは、それらの流れに関するどんな問題もなかったと仮定できます。
Delgrossi & Berger, Editors Experimental [Page 55] RFC 1819 ST2+ Protocol Specification August 1995
[55ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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, the recovery procedures described in Section 6.2 are initiated by the ST agents.
ここで定義された丈夫さプロトコルの目的はSTエージェントが、隣人を通した流れが隣人か介入しているネットワークの失敗によって壊されたと決心することです。 このプロトコルは起こることができる失敗の圧倒的多数を検出するべきです。 失敗がいったん検出されると、セクション6.2で説明されたリカバリ手順はSTエージェントによって着手されます。
6.1.1 Network Failures
6.1.1 ネットワーク失敗
An ST agent can detect network failures by two mechanisms:
STエージェントは2つのメカニズムでネットワーク失敗を検出できます:
o the network can report a failure, or
o またはネットワークが失敗を報告できる。
o the ST agent can discover a failure by itself.
o STエージェント自身は失敗を発見できます。
They differ in the amount of information that an 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. 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エージェントが回復決定をするようにそれに利用可能にする情報量において異なります。 例えば、ネットワークは、予約された帯域幅が失われたと報告できて損失の理由であるかもしれなく、また、隣接しているSTエージェントの残りへのその接続性が完全であると報告するかもしれません。 他方では、STエージェントは、いつかの期間にまだその隣人からの交通を受けていないので隣接しているSTエージェントとのコミュニケーションがやんだと発見するかもしれません。 STエージェントが失敗を検出するなら、隣人が利用可能なままで残っているか、ネットワークが元の状態のままになりますが、または隣人が失敗している間、ネットワークで失敗があったかを決定できないかもしれません。
6.1.2 Detecting ST Agents Failures
6.1.2 エージェント第失敗を検出すること。
Each ST agent periodically sends each neighbor with which it shares one or more streams a HELLO message. This message exchange is between ST agents, not entities representing streams or applications. 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 ST agents that share active streams can participate in this exchange and it is an error to send a HELLO message to a neighbor ST agent with no streams in common, e.g., to check whether it is active. STATUS messages can be used to poll the status of neighbor ST agents, see Section 8.4.
それぞれのSTエージェントは定期的にそれが1つ以上の流れを共有する各隣人にHELLOメッセージを送ります。 流れかアプリケーションを表す実体ではなく、STエージェントの間には、この交換処理はあります。 すなわち、STエージェントはそれらの間を流れる流れの数にかかわらずただ一つのHELLOメッセージを隣人に送るだけでよいです。 すべてのSTエージェント(中間的と同様に、接待します)がこの交換に参加しなければなりません。 しかしながら、活発な流れを共有するSTエージェントだけがこの交換に参加できます、そして、それは一般的で流れなしで隣人STエージェントにHELLOメッセージを送って、例えばそれがアクティブであるかどうかチェックする誤りです。 セクション8.4は、隣人STエージェントの状態に投票するのにSTATUSメッセージを使用できるのを見ます。
For the purpose of HELLO message exchange, stream existence is bounded by ACCEPT and DISCONNECT/REFUSE processing and is defined for both the upstream and downstream case. A stream to a previous-hop is
HELLO交換処理の目的において、流れの存在は、ACCEPTとDISCONNECT/REFUSE処理で境界があって、上流と川下がケースに入れる両方のために定義されます。 前のホップへの流れはそうです。
Delgrossi & Berger, Editors Experimental [Page 56] RFC 1819 ST2+ Protocol Specification August 1995
[56ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
defined to start once an ACCEPT message has been forwarded upstream. A stream to a next-hop is defined to start once the received ACCEPT message has been acknowledged. A stream is defined to terminate once an acknowledgment is sent for a received DISCONNECT or REFUSE message, and an acknowledgment for a sent DISCONNECT or REFUSE message has been received.
いったん上流へACCEPTメッセージを転送したあとに始まるように、定義されます。 次のホップへの流れは、受信されたACCEPTメッセージがいったん承認されたあとに始まるように定義されます。 容認されたDISCONNECTかREFUSEメッセージのためにいったん承認を送ると、終わるために流れを定義します、そして、送られたDISCONNECTかREFUSEメッセージのための承認を受けました。
The HELLO message has two fields:
HELLOメッセージには、2つの分野があります:
o a HelloTimer field that is in units of milliseconds modulo the
maximum for the field size, and
o そしてa HelloTimerがそれをさばく、ユニットのミリセカンド法には最大が分野サイズのためにある。
o a Restarted-bit specifying that the ST agent has been restarted
recently.
o STエージェントが最近再出発されたと指定するRestarted-ビット。
The HelloTimer must appear to be incremented every millisecond whether a HELLO message is sent or not. 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 in all HELLO messages sent in the following HelloTimerHoldDown seconds.
HelloTimerは、HELLOメッセージを送るか否かに関係なく、ミリセカンド毎に増加されるように見えなければなりません。 最大値に達した後に、HelloTimerはゼロに巻きつけます。 STエージェントがST州の情報を失いながらそれをもたらすかもしれない大惨事を受けるときはいつも、それは、ゼロにHelloTimerをリセットしなければならなくて、以下のHelloTimerHoldDown秒に送られたすべてのHELLOメッセージにRestarted-ビットをはめ込まなければなりません。
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 state. If it shares streams with that neighbor, it must initiate stream recovery activity, see Section 6.2. If it does not share streams with that neighbor, it should not attempt to create one until that bit is no longer set. If an ST agent receives a CONNECT message from a neighbor whose Restarted-bit is still set, the agent must respond with an ERROR message with the appropriate ReasonCode (RestartRemote). If an agent receives a CONNECT message while the agent's own Restarted- bit is set, the agent must respond with an ERROR message with the appropriate ReasonCode (RestartLocal).
STエージェントがRestartedの噛み付いているセットを含むHELLOメッセージを受け取るなら、それは、送付STエージェントが状態を失ったと仮定しなければなりません。 セクション6.2は、その隣人と流れを共有するなら、それが流れの回復活動を開始しなければならないのを見ます。 その隣人と流れを共有しないなら、それは、そのビットがもう設定されないまで1つを作成するのを試みるべきではありません。 STエージェントがRestarted-ビットがまだ設定されている隣人からCONNECTメッセージを受け取るなら、エージェントは適切なReasonCode(RestartRemote)と共にERRORメッセージで応じなければなりません。 エージェントの自身のRestartedビットが設定されますが、エージェントがCONNECTメッセージを受け取るなら、エージェントは適切なReasonCode(RestartLocal)と共にERRORメッセージで応じなければなりません。
Each ST stream has an associated RecoveryTimeout value. This value is assigned by the origin and carried in the CONNECT message, see Section 4.5.10. Each agent checks to see if it can support the requested value. If it can not, it updates the value to the smallest timeout interval it can support. The RecoveryTimeout used by a particular stream is obtained from the ACCEPT message, see Section 4.5.10, and is the smallest value seen across all ACCEPT messages from participating targets.
それぞれのSTの流れには、関連RecoveryTimeout値があります。 セクション4.5.10は、この値が起源によって割り当てられて、CONNECTメッセージで運ばれるのを見ます。 各エージェントは、それが要求された値を支持できるかどうか確認するためにチェックします。 そうすることができないなら、それは支持できる中で最も小さいタイムアウト間隔まで値をアップデートします。 ACCEPTメッセージから特定の流れで使用されるRecoveryTimeoutを入手します、とセクション4.5.10は見ます、そして、すべてのACCEPTメッセージの向こう側に参加するのから見られる中で最も小さい値は目標ですか?
An ST agent must send HELLO messages to its neighbor with a period shorter than the smallest RecoveryTimeout of all the active streams that pass between the two ST agents, regardless of direction. This period must be smaller by a factor, called HelloLossFactor, which is
期間が2人のSTエージェントの間を通るすべての活発な流れの最も小さいRecoveryTimeoutより短い状態でSTエージェントは隣人へのメッセージをHELLOに送らなければなりません、指示にかかわらず。 この期間はHelloLossFactorと呼ばれる要素で、より小さいに違いありません。
Delgrossi & Berger, Editors Experimental [Page 57] RFC 1819 ST2+ Protocol Specification August 1995
[57ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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人のSTエージェントのコミュニケーションがまだ実行可能である間に確かに失うことができた連続したHELLOメッセージの最大数と少なくとも同じくらい大きいです。
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に送るかもしれません。
An ST agent must expect to receive at least one new HELLO message from each neighbor at least as frequently as the smallest RecoveryTimeout of any active stream in common with that neighbor. The agent can detect duplicate or delayed HELLO messages by comparing the HelloTimer field of the most recent valid HELLO message from that neighbor with the HelloTimer field of an incoming HELLO message. Valid incoming HELLO messages will have a HelloTimer field that is greater than the field contained in the previously received valid HELLO message by the time elapsed since the previous message was received. Actual evaluation of the elapsed time interval should take into account the maximum likely delay variance from that neighbor.
STエージェントは、その隣人と共用して各隣人から少なくとも1つの新しいHELLOメッセージをどんな活発な流れの最も小さいRecoveryTimeoutと少なくとも同じくらい頻繁にも受け取ると予想しなければなりません。 エージェントは、その隣人からの最新の有効なHELLOメッセージのHelloTimer分野を入って来るHELLOメッセージのHelloTimer分野にたとえることによって、写しか遅れたHELLOメッセージを検出できます。 有効な入って来るHELLOメッセージには、前のメッセージ以来経過している時までに以前に受信された有効なHELLOメッセージに含まれた野原を受け取ったより大きいHelloTimer分野があるでしょう。 経過時間間隔の実際の評価はその隣人から最大のありそうな遅れ変化を考慮に入れるべきです。
If the ST agent does not receive a valid HELLO message within the RecoveryTimeout period 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, as described below in Section 6.2.
STエージェントが流れのRecoveryTimeout一区切り中に有効なHELLOメッセージを受け取らないなら、隣接しているSTエージェントか2つの間の通信リンクが失敗して、流れの回復活動を開始しなければならないと仮定しなければなりません、セクション6.2で以下で説明されるように。
6.2 Failure Recovery
6.2 失敗回復
If an intermediate ST agent fails or a network or part of a network fails, the previous-hop ST agent and the various next-hop ST agents will discover the fact by the failure detection mechanism described in Section 6.1.
中間的STエージェントが失敗するか、またはネットワークのネットワークか一部が行き詰まると、前のホップSTエージェントと様々な次のホップSTエージェントはセクション6.1で説明された失敗検出メカニズムで事実を発見するでしょう。
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 typically 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 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の流れの回収は比較的複雑で時間がかかった努力です。 したがって、それは、情報が広く分配されるのが必要であり、比較的長いタイマを必要とするかもしれません。 他方では、ネットワークが通常均一系であるので、ネットワークでの失敗回復は比較的速くて、より簡単な操作であるかもしれません。 したがって、失敗を検出するSTエージェントは、STの流れの回収を試みる前にネットワーク失敗を修正するのを試みるべきです。 ネットワーク回収機構で単独で失敗の前に2人のSTエージェントの間に存在した流れを再建できないなら、ST流れの回収機構を呼び出さなければなりません。
Delgrossi & Berger, Editors Experimental [Page 58] RFC 1819 ST2+ Protocol Specification August 1995
[58ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
If stream recovery is necessary, the different ST agents will need to perform different functions, depending on their relation to the failure:
流れの回復が必要であるなら、異なったSTエージェントは、異なった機能を実行する必要があるでしょう、失敗との彼らの関係によって:
o An ST agent that is a next-hop from a failure 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 for each active stream from that neighbor it should
first send a REFUSE message upstream with the appropriate ReasonCode
(STAgentFailure). This is done to the neighbor to speed up the
failure recovery in case the hop is unidirectional, i.e., the
neighbor can hear the ST agent but the ST agent cannot hear the
neighbor. The ST agent detecting the failure must then, for each
active stream from that neighbor, send DISCONNECT messages with the
same ReasonCode toward the targets. All downstream ST agents process
this DISCONNECT message just like the DISCONNECT that tears down the
stream. If recovery is successful, targets will receive new CONNECT
messages.
o 失敗からの次のホップであるSTエージェントは、最初に、失敗があったことを確かめるべきです。 それは、上流の隣人について質問するSTATUSメッセージを使用することでこれができます。 その隣人とコミュニケートできないなら、その隣人からのそれぞれの活発な流れのために、それは最初に、適切なReasonCode(STAgentFailure)と共にREFUSEメッセージを上流へ送るべきです。 ホップが単方向であるといけないので失敗回復を早くするために隣人にこれをしますが、すなわち、隣人はSTエージェントの声を聞くことができますが、STエージェントは隣人の声を聞くことができません。 そして、その隣人からのそれぞれの活発な流れのために、失敗を検出するSTエージェントは目標に向かった同じReasonCodeがあるメッセージをDISCONNECTに送らなければなりません。 すべての川下のSTエージェントがまさしく流れを取りこわすDISCONNECTのようにこのDISCONNECTメッセージを処理します。 回復がうまくいくと、目標は新しいCONNECTメッセージを受け取るでしょう。
o 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 try and reconstruct
(explained below) the affected streams, for those streams that do
not have the NoRecovery option selected. If it cannot communicate
with the next-hop, then the ST agent detecting the failure sends a
DISCONNECT message, for each affected stream, with the appropriate
ReasonCode (STAgentFailure) 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.
o 失敗したコンポーネントの前の前のホップ1番目であるSTエージェントは、STATUSメッセージを使用することで川下の隣人について質問するのによる失敗があったことを確かめます。 隣人が状態を失いましたが、手があくなら、STエージェントは影響を受ける流れを再建してみるかもしれません(以下で、説明されます)、NoRecoveryオプションを選択しないそれらの流れのために。 次のホップで交信できないなら、失敗を検出するSTエージェントはDISCONNECTメッセージを送ります、それぞれの影響を受ける流れのために、影響を受ける目標に向かった適切なReasonCode(STAgentFailure)と共に。 失敗回復は、コミュニケーションが単方向であるかもしれなく、首尾よくこのメッセージを送るといけないかもしれないので、そう加速します。
Based on the NoRecovery option, the ST agent that is the previous-hop before the failed component takes the following actions:
NoRecoveryオプション、STエージェントに基づいて、失敗したコンポーネントの前の前のホップは以下の行動を取ります:
o If the NoRecovery option is selected, then the ST agent sends, per
affected stream, a REFUSE message with the appropriate ReasonCode
(STAgentFailure) to the previous-hop. The TargetList in these
messages contains all the targets that were reached through the
broken branch. As discussed in Section 5.1.2, 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. The application at the origin can attempt recovery of
the stream by sending a new CONNECT to the affected targets. For
established streams, the new CONNECT will be treated by intermediate
ST agents as an addition of new targets into the established stream.
o NoRecoveryオプションが選択されるなら、STエージェントは発信します、影響を受ける流れ単位で、前のホップへの適切なReasonCode(STAgentFailure)があるREFUSEメッセージ。 これらのメッセージのTargetListは折れている支店を通って達したすべての目標を含んでいます。 セクション5.1.2で議論するように、介入しているネットワークのMTUには、PDUが長過ぎるなら、複数のREFUSEメッセージが必要であるかもしれません。 REFUSEメッセージは起源までのいっぱいに伝播されます。 起源におけるアプリケーションは、新しいCONNECTを影響を受ける目標に送ることによって、流れの回収を試みることができます。 確立した流れにおいて、新しいCONNECTは新しい目標の添加として中間的STエージェントによって確立した流れの中に扱われるでしょう。
Delgrossi & Berger, Editors Experimental [Page 59] RFC 1819 ST2+ Protocol Specification August 1995
[59ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o If the NoRecovery option is not selected, the ST agent can attempt
recovery of the affected streams. It does so one a stream by stream
basis 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
ReasonCode (CantRecover) 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.
o NoRecoveryオプションが選択されないなら、STエージェントは影響を受ける流れの回収を試みることができます。それは、流れの基礎で新しいCONNECTメッセージを影響を受ける目標に発行することによって、そう1つに流れをします。 STエージェントがいくつかの目標に新しいルートを見つけることができないか、または前のホップを通していくつかの目標への唯一のルートがあるなら、それは適切なReasonCode(CantRecover)がTargetListの影響を受ける目標を指定している前のホップに1つ以上のREFUSEメッセージを送ります。 そして、前のホップは、それらの目標にCONNECTを発行することによって、流れの回収を試みることができます。 適切なルートを見つけることができないと、それはREFUSEメッセージを起源に向かって伝播するでしょう。
Regardless of which ST 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 are 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.
どのSTエージェントが破損している流れの回収を試みるかにかかわらず、それは1つ以上のCONNECTメッセージを影響を受ける目標に発行するでしょう。 これらのCONNECTメッセージは新しい目標の追加として中間的STエージェントによって確立した流れの中に扱われます。 新しいCONNECTメッセージのFlowSpecsはものが最新のCONNECTかCHANGEに流れが操作上であったときに、STエージェントが影響を受ける目標に向かって発信したというメッセージを含んだのと同じです。
Upon receiving an ACCEPT during the a stream recovery, the agent reconstructing the stream must ensure that the FlowSpec and other stream attributes (e.g., MaxMsgSize and RecoveryTimeout) of the re- established stream are equal to, or are less restrictive, than the pre-failure stream. If they are more restrictive, the recovery attempt must be aborted. If they are equal, or are less restrictive, then the recovery attempt is successful. When the attempt is a success, failure recovery related ACCEPTs are not forwarded upstream by the recovering agent.
a流れの回復、流れを再建すると確実にされなければならないエージェントの間、ACCEPTを受ける場合、そのFlowSpecと他は、再確立した流れの(例えば、MaxMsgSizeとRecoveryTimeout)が等しい属性を流すか、またはそれほど制限していません、プレ失敗の流れより。 それらが、より制限しているなら、回復試みを中止しなければなりません。 それらが等しいか、またはそれほど制限していないなら、回復試みはうまくいっています。 試みが成功であるときに、失敗回復関連するACCEPTsは回復しているエージェントによって上流へ進められません。
Any ST agent that decides that enough recovery attempts have been made, or that recovery attempts have no chance of succeeding, may indicate that no further attempts at recovery should be made. This is done by setting the N-bit in the REFUSE message, see Section 10.4.11. This bit must be set by agents, including the target, that know that there is no chance of recovery succeeding. An ST agent that receives a REFUSE message with the N-bit set (1) will not attempt recovery, regardless of the NoRecovery option, and it will set the N-bit when propagating the REFUSE message upstream.
十分な回復試みをしたか、または回復試みには成功するという機会が全くないと決めるどんなSTエージェントも、回復へのさらなる試みを全くするべきでないのを示すかもしれません。 セクション10.4.11は、N-ビットをREFUSEメッセージにはめ込むことによってこれをするのを見ます。 回復が成功するという見込みが全くないのを知っている目標を含むエージェントはこのビットを設定しなければなりません。 N-ビットセット(1)でREFUSEメッセージを受け取るSTエージェントは回復を試みないでしょう、NoRecoveryオプションにかかわらず、そして、REFUSEメッセージ上流を伝播するとき、それがN-ビットを設定するでしょう。
6.2.1 Problems in Stream Recovery
6.2.1 流れの回復における問題
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 ERROR messages for the new CONNECTs that are caused by internet routing errors. The ST agent attempting the
中断した流れの再構成はスムーズに続かないかもしれません。 失敗の情報がインターネット中で伝播されている間、何らかの遅れがあるかもしれないので、ルーティング誤りは失敗の後にしばらく発生するかもしれません。 その結果、回復を試みるSTエージェントはインターネットルーティング誤りで引き起こされる新しいCONNECTsのためにエラー・メッセージを受信するかもしれません。 STエージェントの試み
Delgrossi & Berger, Editors Experimental [Page 60] RFC 1819 ST2+ Protocol Specification August 1995
[60ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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.
回復は流れを再建するのに成功する前に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 ST 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 message with the appropriate ReasonCode (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. Therefore, the ST agent that receives the ERROR message with ReasonCode (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 ReasonCode (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を受け取るSTエージェントは流れが失敗を受けて、ルーティング失敗から生じると新しいCONNECTを解釈するのをまだ意識していません。 それは適切なReasonCode(StreamExists)と共にERRORメッセージで応じるでしょう。 すぐに、失敗に先行して、すぐに失敗の後をつけるSTエージェントがおよそそうであるタイムアウト以来、同じように、DISCONNECTメッセージはすぐ、中断した流れの残りを非常に取りこわしそうでしょう。 したがって、ToConnectタイムアウトが期限が切れた後にReasonCode(StreamExists)と共にERRORメッセージを受け取るSTエージェントはCONNECTメッセージを再送するべきです。 これが再び失敗すると、要求はNConnect回のために再試行されるでしょう。 まだ失敗している場合にだけ、STエージェントは適切なReasonCode(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 ST agent receives a second CONNECT message for a target that recently resulted in a REFUSE, that ST 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エージェントはいつかの期間の間、この情報を保守するべきです。 STエージェントが最近REFUSEをもたらした目標への2番目のCONNECTメッセージを受け取るなら、CONNECTを伝播するのを試みるよりそのSTエージェントはすぐに、REFUSEと共にむしろ応じるかもしれません。 これには、CONNECTメッセージの伝播で最初に選択されるルートで届いていない目標に形成される木を剪定するという効果があります。 木は一度だけどんな与えられたSTエージェントも通り抜けるでしょう、そして、流れのセットアップフェーズは、より速く完成するでしょう。
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. FlowSpec comparison is done by the LRM. If the selections of the parameters are different, then the ST
CONNECTメッセージに達するなら、目標、目標はできるだけ効率的に使用するべきです。流れが流れの回収の間、失敗する前にそれが節約した状態を使用してください。 そして、それは起源に向かってACCEPTメッセージを発行するでしょう。 ACCEPTメッセージはまして、破損している流れ、起源の回復を試みているSTエージェントによって傍受されるでしょう。 ACCEPTに含まれたFlowSpecが失敗の前に有効であったようにパラメタの同じ品揃えを指定すると、回復を試みているSTエージェントはACCEPTを伝播しないでしょう。 LRMはFlowSpec比較を完了しています。 パラメタの品揃えは異なっていて、その時はSTです。
Delgrossi & Berger, Editors Experimental [Page 61] RFC 1819 ST2+ Protocol Specification August 1995
[61ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
agent that is attempting recovery will send the origin a NOTIFY message with the appropriate ReasonCode (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.
回復を試みているエージェントが新しいパラメタ値を指定するFlowSpecを含む適切なReasonCode(FailureRecovery)があるNOTIFYメッセージを起源に送るでしょう。 そして、起源は新たに回復している下位木を使用するCHANGEメッセージでデータ生成の特性と流れのパラメタを変えなければならないかもしれません。
6.3 Stream Preemption
6.3 流れの先取り
As mentioned in Section 1.4.5, it is possible that the LRM decides to break a stream intentionally. This is called stream preemption. Streams are expected to be preempted in order to free resources for a new stream which has a higher priority.
セクション1.4.5で言及されるように、LRMが、故意に流れを壊すと決めるのは、可能です。 これは流れの先取りと呼ばれます。 より高い優先度を持っている新しい流れのためのリソースを解放するために流れが先取りされると予想されます。
If the LRM decides that it is necessary to preempt one or more of the stream traversing it, the decision on which streams have to be preempted has to be made. There are two ways for an application to influence such decision:
LRMが、それを横断する流れの1つ以上を先取りするのが必要であると決めるなら、流れが先取りされなければならない決定をしなければなりません。 アプリケーションがそのような決定に影響を及ぼす2つの方法があります:
1. based on FlowSpec information. For instance, with the ST2+
FlowSpec, streams can be assigned a precedence value from 0
(least important) to 256 (most important). This value is
carried in the FlowSpec when the stream is setup, see Section
9.2, so that the LRM is informed about it.
1. FlowSpec情報に基づきます。 例えば、ST2+FlowSpecと共に、流れは先行値を0(最も重要でない)から256(最も重要な)に割り当てることができます。 流れがセットアップであるときに、この値はFlowSpecで運ばれます、とセクション9.2は見ます、LRMがそれに関して知識があるように。
2. with the group mechanism. An application may specify that a set
of streams are related to each other and that they are all
candidate for preemption if one of them gets preempted. It can
be done by using the fate-sharing relationship defined in
Section 7.1.2. This helps the LRM making a good choice when
more than one stream have to be preempted, because it leads to
breaking a single application as opposed to as many
applications as the number of preempted streams.
2.、グループメカニズムで。 アプリケーションは1セットの流れが互いに関連して、それらの1つが先取りされるなら彼らが皆先取りの候補であると指定するかもしれません。 セクション7.1.2で定義された運命を共有する関係を使用することによって、それができます。 これは、1つ以上の流れが先取りされなければならないとき、LRMがうまく選び当てるのを助けます、先取りされた流れの数と同じくらい多くのアプリケーションと対照的にただ一つのアプリケーションを破るのに通じるので。
If the LRM preempts a stream, it must notify the local ST agent. The following actions are performed by the ST agent:
LRMが流れを先取りするなら、それは地元のSTエージェントに通知しなければなりません。 以下の動作はSTエージェントによって実行されます:
o The ST agent at the host where the stream was preempted sends
DISCONNECT messages with the appropriate ReasonCode
(StreamPreempted) toward the affected targets. It sends a REFUSE
message with the appropriate ReasonCode (StreamPreempted) to the
previous-hop.
o 流れが先取りされたホストのSTエージェントは影響を受ける目標に向かった適切なReasonCode(StreamPreempted)があるメッセージをDISCONNECTに送ります。 それは適切なReasonCode(StreamPreempted)があるREFUSEメッセージを前のホップに送ります。
o A previous-hop ST agent of the preempted stream acts as in case of
failure recovery, see Section 6.2.
o セクション6.2は、先取りされた流れの前のホップSTエージェントが失敗回復の場合に行動するのを見ます。
o A next-hop ST agent of the preempted stream acts as in case of
failure recovery, see Section 6.2.
o セクション6.2は、先取りされた流れの次のホップSTエージェントが失敗回復の場合に行動するのを見ます。
Delgrossi & Berger, Editors Experimental [Page 62] RFC 1819 ST2+ Protocol Specification August 1995
[62ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
Note that, as opposite to failure recovery, there is no need to verify that the failure actually occurred, because this is explicitly indicated by the ReasonCode (StreamPreempted).
失敗回復に反対です、失敗が実際に起こったことを確かめる必要は全くないことに注意してください、これがReasonCode(StreamPreempted)によって明らかに示されるので。
7. A Group of Streams
7. 流れのグループ
There may be 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.
関連する流れを関連づける必要があるかもしれません。グループメカニズムは単にSTエージェントが関連させていることになっている異なった流れを特定できる協会のテクニックです。
A group consists of a set of streams and a relationship. The set of streams may be empty. The relationship applies to all group members. Each group is identified by a group name. The group name must be globally unique.
グループは1セットの流れと関係から成ります。 流れのセットは空であるかもしれません。 関係はすべてのグループのメンバーに適用されます。 各グループはグループ名によって特定されます。 グループ名はグローバルにユニークでなければなりません。
Streams belong to the same group if they have the same GroupName in the GroupName field of the Group parameter, see Section 10.3.2. The relationship is defined by the Relationship field. Group membership must be specified at stream creation time and persists for the whole stream lifetime. A single stream may belong to multiple groups.
GroupパラメタのGroupName分野に同じGroupNameを持っているなら、流れは同じグループのものです、とセクション10.3.2が見ます。 関係はRelationship分野によって定義されます。 会員資格がそうしなければならないグループは、流れの創造時間に指定されて、全体の流れのために生涯を固持します。 ただ一つの流れは複数のグループのもの、かもしれません。
The ST agent that creates a new group is called group initiator. Any ST agent can be a group initiator. The initiator allocates the GroupName and the Relationship among group members. The initiator may or may not be the origin of a stream belonging to the group. GroupName generation is described in Section 8.2.
新しいグループを創設するSTエージェントはグループの創始者と呼ばれます。 どんなSTエージェントもグループの創始者であるかもしれません。 創始者はGroupNameとRelationshipをグループのメンバーに割り当てます。 創始者は、起源であるか、グループのもの流れの起源でないかもしれません。 GroupName世代はセクション8.2で説明されます。
7.1 Basic Group Relationships
7.1 基本的なグループ関係
This version of ST defines four basic group relationships. An ST2+ implementation must support all four basic relationships. Adherence to specified relationships are usually best effort. The basic relationships are described in detail below in Section 7.1.1 - Section 7.1.4.
STのこのバージョンは4つの基本的なグループ関係を定義します。 ST2+実現はすべての4つの基本的な関係を支持しなければなりません。 通常、指定された関係への固守はベストエフォート型です。 基本的な関係は以下でセクション7.1.1で詳細に説明されます--セクション7.1.4。
7.1.1 Bandwidth Sharing
7.1.1 帯域幅共有
Streams associated with the same group share the same network bandwidth. The intent is to support applications such as audio conferences where, of all participants, only some are allowed to speak at one time. In such a scenario, global bandwidth utilization can be lowered by allocating only those resources that can be used at once, e.g., it is sufficient to reserve bandwidth for a small set of audio streams.
同じグループに関連している流れは同じネットワーク回線容量を共有します。 意図はすべての関係者では、或るものだけがひところ話すことができるオーディオ会議などの応用を支持することです。 そのようなシナリオでは、すぐに使用できるそれらのリソースだけを割り当てることによって、グローバルな帯域幅利用を下ろすことができます、例えば、小さいセットのオーディオストリームのために帯域幅を控えるのは十分です。
The basic concept of a shared bandwidth group is that the LRM will allocate up to some specified multiplier of the most demanding stream that it knows about in the group. The LRM will allocate resources
共有された帯域幅グループに関する基本概念はLRMがそれがグループで知っている過酷な流れを大部分の何らかの指定された乗数まで割り当てるということです。 LRMはリソースを割り当てるでしょう。
Delgrossi & Berger, Editors Experimental [Page 63] RFC 1819 ST2+ Protocol Specification August 1995
[63ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
incrementally, as stream setup requests are received, until the total group requirements are satisfied. Subsequent setup requests will share the group's resources and will not need any additional resources allocated. The procedure will result in standard allocation where only one stream in a group traverses an agent, and shared allocations where multiple streams traverse an agent.
流れのセットアップとして、総グループ要件が満たされるまで、要求は増加して、受信されています。 その後のセットアップ要求は、グループのリソースを共有して、どんな追加リソースも割り当てる必要はないでしょう。 グループにおける1つの流れだけが複数の流れがエージェントを横断するところにエージェント、および共有された配分を横断するところで手順は標準の配分をもたらすでしょう。
To illustrate, let's call the multiplier mentioned above "N", and the most demanding stream that an agent knows about in a group Bmax. For an application that intends to allow three participants to speak at the same time, N has a value of three and each LRM will allocate for the group an amount of bandwidth up to 3*Bmax even when there are many more steams in the group. The LRM will reserve resources incrementally, per stream request, until N*Bmax resources are allocated. Each agent may be traversed by a different set and number of streams all belonging to the same group.
例証するために、「N」の上で言及された乗数、およびエージェントがグループBmaxで知っている最も過酷な流れを呼びましょう。 Nには、3人の関係者が同時に話すのを許容するつもりであるアプリケーションのために、3の値があります、そして、グループにずっと多くの蒸気ありさえするときさえ、各LRMはグループのために帯域幅の量を3*Bmaxまで割り当てるでしょう。 LRMは流れの要求単位でリソースが増加してN*Bmaxリソースを割り当てるまで控え目でしょう。 各エージェントは同じグループのもの異なったセットと数の流れですべて、横断されるかもしれません。
An ST agent receiving a stream request presents the LRM with all necessary group information, see Section 4.5.2.2. If maximum bandwidth, N*Bmax, for the group has already been allocated and a new stream with a bandwidth demand less than Bmax is being established, the LRM won't allocate any further bandwidth.
セクション4.5.2は、流れの要求を受け取るSTエージェントがすべての必要なグループ情報をLRMに与えるのを.2に見ます。 最大の帯域幅、既にグループのためのN*Bmaxを割り当てて、帯域幅要求がBmaxより少ない新しい流れを確立していると、LRMは少しの一層の帯域幅も割り当てないでしょう。
If there is less than N*Bmax resources allocated, the LRM will expand the resources allocated to the group by the amount requested in the new FlowSpec, up to N*Bmax resources. The LRM will update the FlowSpec based on what resources are available to the stream, but not the total resources allocated for the group.
*Bmaxリソースが割り当てたNがあると、LRMは新しいFlowSpecで要求された量によってグループに割り当てられたリソースを広げるでしょう、N*Bmaxリソースまで。 LRMはグループのために割り当てられた総リソースではなく、どんなリソースが流れに利用可能であるかに基づくFlowSpecをアップデートするでしょう。
It should be noted that ST agents and LRMs become aware of a group's requirements only when the streams belonging to the group are created. In case of the bandwidth sharing relationship, an application should attempt to establish the most demanding streams first to minimize stream setup efforts. If on the contrary the less demanding streams are built first, it will be always necessary to allocate additional bandwidth in consecutive steps as the most demanding streams are built. It is also up to the applications to coordinate their different FlowSpecs and decide upon an appropriate value for N.
グループのもの流れが作成されるときだけ、STエージェントとLRMsがグループの要件を意識するようになることに注意されるべきです。 関係を共有する帯域幅の場合には、アプリケーションは、最初に、流れのセットアップの努力を最小にするために最も過酷な流れを確立するのを試みるべきです。 それほど過酷でない流れが最初にこれに反して、組み込まれると、最も過酷な流れが組立しているように連続したステップにおける追加帯域幅を割り当てるのがいつも必要でしょう。 それらの異なったFlowSpecsを調整して、Nのために適切な値について決めるのはアプリケーションまでも達しています。
7.1.2 Fate Sharing
7.1.2 運命共有
Streams belonging to this group share the same fate. If a stream is deleted, the other members of the group are also deleted. This is intended to support stream preemption by indicating which streams are mutually related. If preemption of multiple streams is necessary, this information can be used by the LRM to delete a set of related streams, e.g., with impact on a single application, instead of making
このグループのもの流れが同じ運命を共有します。 また、流れが削除されるなら、グループの他のメンバーは削除されます。 どの流れが互いに関係づけられるかを示すことによってこれが流れの先取りを支持することを意図します。 複数の流れの先取りが必要であるなら、LRMは1セットの関連する流れを削除するのにこの情報を使用できます、例えば、ただ一つのアプリケーションへの影響で、作成の代わりに
Delgrossi & Berger, Editors Experimental [Page 64] RFC 1819 ST2+ Protocol Specification August 1995
[64ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
a random choice with the possible effect of interrupting several different applications. This attribute does not apply to normal stream shut down, i.e., ReasonCode (ApplDisconnect). On normal disconnect, other streams belonging to such groups remain active.
いくつかの異なったアプリケーションを中断するという可能な効果に伴う無作為の選択。 この属性はすなわち、通常の流れの閉鎖、ReasonCode(ApplDisconnect)に適用されません。 通常の分離では、そのようなグループのもの他の流れがアクティブなままです。
This relationship provides a hint on which streams should be preempted. Still, the LRM responsible for the preemption is not forced to behave accordingly, and other streams could be preempted first based on different criteria.
この関係は流れが先取りされるべきであるヒントを提供します。 それでも、先取りに責任があるLRMはやむを得ずそれに従って、振る舞いません、そして、最初に、異なった評価基準に基づいて他の流れは先取りできました。
7.1.3 Route Sharing
7.1.3 ルート共有
Streams belonging to this group share the same paths as much as is possible. This can be desirable for several reasons, e.g., to exploit the same allocated resources or in the attempt to maintain the transmission order. An ST agent attempts to select the same path although the way this is implemented depends heavily on the routing algorithm which is used.
このグループのもの流れが同じ経路をできるだけたくさん共有します。 これは例えば、いくつかの理由、同じくらいがリソースを割り当てた功績またはトランスミッション命令を維持する試みで望ましい場合があります。 STエージェントは、これが実行される方法が大いに使用されたルーティング・アルゴリズムによりますが、同じ経路を選択するのを試みます。
If the routing algorithm is sophisticated enough, an ST agent can suggest that a stream is routed over an already established path. Otherwise, it can ask the routing algorithm for a set of legal routes to the destination and check whether the desired path is included in those feasible.
ルーティング・アルゴリズムが十分高度であるなら、STエージェントは、小川が既に確立した経路の上に発送されることを提案できます。 さもなければ、それは、1セットの目的地への法的なルートにルーティング・アルゴリズムを尋ねて、必要な経路が可能なそれらに含まれているかどうかチェックできます。
Route sharing is a hint to the routing algorithm used by ST. Failing to route a stream through a shared path should not prevent the creation of a new stream or result in the deletion of an existing stream.
ルート共有はSTによって使用されたルーティング・アルゴリズムへのヒントです。共有された経路を通して流れを発送しないと、既存の流れの削除における、新しい流れか結果の創造は防がれるべきではありません。
7.1.4 Subnet Resources Sharing
7.1.4 サブネットリソース共有
This relationship provides a hint to the data link layer functions. Streams belonging to this group may share the same MAC layer resources. As an example, the same MAC layer multicast address may be used for all the streams in a given group. This mechanism allows for a better utilization of MAC layer multicast addresses and it is especially useful when used with network adapters that offer a very small number of MAC layer multicast addresses.
この関係はデータ・リンク層機能にヒントを提供します。 このグループのもの流れは同じMAC層のリソースを共有するかもしれません。 例として、同じMAC層のマルチキャストアドレスは与えられたグループにおけるすべての流れに使用されるかもしれません。 このメカニズムはMAC層のマルチキャストの、より良い利用のためにアドレスを許容します、そして、非常に少ない数のMAC層のマルチキャストアドレスを提供するネットワークアダプターと共に使用されると、それは特に役に立ちます。
7.2 Relationships Orthogonality
7.2 関係直交性
The four basic relationships, as they have been defined, are orthogonal. This means, any combinations of the basic relationships are allowed. For instance, let's consider an application that requires full-duplex service for a stream with multiple targets. Also, let's suppose that only N targets are allowed to send data back to the origin at the same time. In this scenario, all the reverse
それらが定義されたとき、4つの基本的な関係が直交しています。 この手段であり、基本的な関係のどんな組み合わせも許されています。 例えば、マルチターゲットによる流れのための全二重サービスを必要とするアプリケーションを考えましょう。 また、N目標だけが同時にデータを起源に送り返すことができると思いましょう。 このシナリオ、すべての逆で
Delgrossi & Berger, Editors Experimental [Page 65] RFC 1819 ST2+ Protocol Specification August 1995
[65ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
streams could belong to the same group. They could be sharing both the paths and the bandwidth attributes. The Path&Bandwidth sharing relationship is obtained from the basic set of relationships. This example is important because it shows how full-duplex service can be efficiently obtained in ST.
流れは同じグループのもの、かもしれません。 彼らは経路と帯域幅属性の両方を共有しているかもしれません。 基本的な関係から関係を共有するPath&Bandwidthを入手します。 STでどう効率的に全二重サービスを得ることができるかを示しているので、この例は重要です。
8. Ancillary Functions
8. 補助的機能
Certain functions are required by ST host and intermediate agent implementations. Such functions are described in this section.
ある機能がSTホストと仲介物質実現で必要です。 そのような機能はこのセクションで説明されます。
8.1 Stream ID Generation
8.1流れのID世代
The stream ID, or SID, is composed of 16-bit unique identifier and the stream origin's 32-bit IP address. Stream IDs must be globally unique. The specific definition and format of the 16 -bit field is left to the implementor. This field is expected to have only local significance.
流れのID、またはSIDが16ビットのユニークな識別子と流れの起源の32ビットのIPアドレスで構成されます。 流れのIDはグローバルにユニークでなければなりません。 16ビット分野の特定の定義と形式は作成者に任せます。 この分野にはローカルの意味しかないと予想されます。
An ST implementation has to provide a stream ID generator facility, so that an application or higher layer protocol can obtain a unique IDs from the ST layer. This is a mechanism for the application to request the allocation of stream ID that is independent of the request to create a stream. The Stream ID is used by the application or higher layer protocol when creating the streams.
ST実現は流れのIDジェネレータ施設を提供しなければなりません、アプリケーションか、より高い層のプロトコルがST層から固有のIDを得ることができるように。 これはアプリケーションが流れを作成するよう要求から独立している流れのIDの配分に要求するメカニズムです。 流れを作成するとき、Stream IDはアプリケーションか、より高い層のプロトコルによって使用されます。
For instance, the following two functions could be made available:
例えば、以下の2つの機能を利用可能にするかもしれません:
o AllocateStreamID() -> result, StreamID
o AllocateStreamID()->結果、StreamID
o ReleaseStreamID(StreamID) -> result
o ReleaseStreamID(StreamID)->結果
An implementation may also provide a StreamID deletion function.
また、実現はStreamID削除機能を提供するかもしれません。
8.2 Group Name Generator
8.2 グループ名ジェネレータ
GroupName generation is similar to Stream ID generation. The GroupName includes a 16-bit unique identifier, a 32-bit creation timestamp, and a 32-bit IP address. Group names are globally unique. A GroupName includes the creator's IP address, so this reduces a global uniqueness problem to a simple local problem. The specific definitions and formats of the 16-bit field and the 32-bit creation timestamp are left to the implementor. These fields must be locally unique, and only have local significance.
GroupName世代はStream ID世代と同様です。 GroupNameは16ビットのユニークな識別子、32ビットの創造タイムスタンプ、および32ビットのIPアドレスを含んでいます。 グループ名はグローバルにユニークです。 GroupNameが創造者のIPアドレスを含めるので、これはグローバルなユニークさの問題を簡単なローカルの問題に減少させます。 16ビットの分野と32ビットの創造タイムスタンプの特定の定義と形式は作成者に任せます。 これらの分野は、局所的にユニークであり、ローカルの意味を持つだけでよいです。
An ST implementation has to provide a group name generator facility, so that an application or higher layer protocol can obtain a unique GroupName from the ST layer. This is a mechanism for the application
ST実現はグループ名ジェネレータ施設を提供しなければなりません、アプリケーションか、より高い層のプロトコルがST層からユニークなGroupNameを入手できるように。 これはアプリケーションのためのメカニズムです。
Delgrossi & Berger, Editors Experimental [Page 66] RFC 1819 ST2+ Protocol Specification August 1995
[66ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
to request the allocation of a GroupName that is independent of the request to create a stream. The GroupName is used by the application or higher layer protocol when creating the streams that are to be part of the group.
GroupNameの配分を要求するために、それは流れを作成するという要求から独立しています。 グループの一部であることになっている流れを作成するとき、GroupNameはアプリケーションか、より高い層のプロトコルによって使用されます。
For instance, the following two functions could be made available:
例えば、以下の2つの機能を利用可能にするかもしれません:
o AllocateGroupName() -> result, GroupName
o AllocateGroupName()->結果、GroupName
o ReleaseGroupName(GroupName) -> result
o ReleaseGroupName(GroupName)->結果
An implementation may also provide a GroupName deletion function.
また、実現はGroupName削除機能を提供するかもしれません。
8.3 Checksum Computation
8.3 チェックサム計算
The standard Internet checksum algorithm is used for ST: "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 (0)." See [RFC1071], [RFC1141], and [RFC791] for suggestions for efficient checksum algorithms.
標準のインターネットチェックサムアルゴリズムはSTに使用されます: 「チェックサム分野はヘッダーでのすべての16ビットの単語の1の補数合計の16ビットの1の補数です。」 「チェックサムを計算する目的のために、チェックサム分野の値は(0)ではありません。」 効率的なチェックサムアルゴリズムのための提案に関して[RFC1071]、[RFC1141]、および[RFC791]を見てください。
8.4 Neighbor ST Agent Identification and Information Collection
8.4 隣人エージェント第識別と情報収集
The STATUS message can be used to collect information about neighbor ST agents, streams the neighbor supports, and specific targets of streams the neighbor supports. An agent receiving a STATUS message provides the requested information via a STATUS-RESPONSE message.
隣人が支持する流れの隣人STエージェント、隣人が支える流れ、および特定の目標の情報を集めるのにSTATUSメッセージを使用できます。 STATUSメッセージを受け取るエージェントはSTATUS-RESPONSEメッセージで求められた情報を提供します。
The STATUS message can be used to collect different information from a neighbor. It can be used to:
隣人と異なった情報を集めるのにSTATUSメッセージを使用できます。 以下のことにそれを使用できます。
o identify ST capable neighbors. If an ST agent wishes to check if
a neighbor is ST capable, it should generate a STATUS message with
an SID which has all its fields set to zero. An agent receiving a
STATUS message with such SID should answer with a STATUS-RESPONSE
containing the same SID, and no other stream information. The
receiving ST agent must answer as soon as possible to aid in Round
Trip Time estimation, see Section 8.5;
o STの有能な隣人を特定してください。 STエージェントが、隣人ができるSTであるかどうかチェックしたいなら、それはすべての分野をゼロに設定させるSIDと共にSTATUSメッセージを発生させるべきです。 同じSIDを含んでいますが、STATUS-RESPONSEが他のどんな流れの情報も含んでいない状態で、そのようなSIDと共にSTATUSメッセージを受け取るエージェントが答えるべきです。 セクション8.5は、受信STエージェントができるだけ早くRound Trip Time見積りにおける援助に対応しなければならないのを見ます。
o obtain information on a particular stream. If an ST agent wishes to
check a neighbor's general information related to a specific
stream, it should generate a STATUS message containing the stream's
SID. An ST agent receiving such a message, will first check to see
if the stream is known. If not known, the receiving ST agent sends a
STATUS-RESPONSE containing the same SID, and no other stream
information. If the stream is known, the receiving ST agent sends a
STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group
o 特定の流れの情報を得てください。 STエージェントが特定の流れに関連する隣人の一般情報をチェックしたいなら、それは流れのSIDを含むSTATUSメッセージを発生させるべきです。 STエージェントがそのようなメッセージを受け取ると、最初に、流れが知られているかどうか確認するためにチェックするでしょう。 知られないなら、受信STエージェントは同じSIDを含んでいますが、他のどんな流れの情報も含まないSTATUS-RESPONSEを送ります。 流れが知られているなら、受信STエージェントは流れのSIDを含むSTATUS-RESPONSEを送って、IPHops(FlowSpec)は分類します。
Delgrossi & Berger, Editors Experimental [Page 67] RFC 1819 ST2+ Protocol Specification August 1995
[67ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
membership (if any), and as many targets as can be included in a
single message as limited by MTU, see Section 5.1.2. Note that all
targets may not be included in a response to a request for general
stream information. If information on a specific target in a stream
is desired, the mechanism described next should be used.
(もしあれば)の会員資格、およびあることができるのと同じくらい多くの目標がMTUによる制限されるとしてのただ一つのメッセージに含まれていて、セクション5.1.2を見てください。 すべての目標が一般的な流れの情報に関する要求への応答に含まれるかもしれないというわけではないことに注意してください。 流れの特定の目標の情報が望まれているなら、次に説明されたメカニズムは使用されるべきです。
o obtain information on particular targets in a stream. If an ST agent
wishes to check a neighbor's information related to one or more
specific targets of a specific stream, it should generate a STATUS
message containing the stream's SID and a TargetList parameter
listing the relevant targets. An ST agent receiving such a message,
will first check to see if the stream and target are known. If the
stream is not known, the agent follows the process described above.
If both the stream and targets are known, the agent responds with
STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group
membership (if any), and the requested targets that are known. If
the stream is known but the target is not, the agent responds with a
STATUS-RESPONSE containing the stream's SID, IPHops, FlowSpec, group
membership (if any), but no targets.
o 絶え間なく特定の目標の情報を得てください。 STエージェントが特定の流れの1個以上の特定の目標に関連する隣人の情報をチェックしたいなら、それは流れのSIDを含むSTATUSメッセージと関連目標を記載するTargetListパラメタを発生させるべきです。 STエージェントがそのようなメッセージを受け取ると、最初に、流れと目標が知られているかどうか確認するためにチェックするでしょう。 流れが知られていないなら、エージェントは上で説明された過程に従います。 流れと目標の両方が知られているなら、STATUS-RESPONSEが流れのSID、IPHops、FlowSpec、(もしあれば)のグループ会員資格、および知られている要求された目標を含んでいて、エージェントは応じます。 流れが知られていますが、目標が知られているというわけではないなら、(もしあれば)のグループ会員資格を含んでいますが、STATUS-RESPONSEが流れのSID、IPHops、FlowSpec、どんな目標も含んでいなく、エージェントが応じます。
The specific formats for STATUS and STATUS-RESPONSE messages are defined in Section 10.4.12 and Section 10.4.13.
STATUSとSTATUS-RESPONSEメッセージのための特定の書式はセクション10.4.12とセクション10.4.13で定義されます。
8.5 Round Trip Time Estimation
8.5 周遊旅行時間見積り
SCMP is made reliable through use of retransmission when an expected acknowledgment is not received in a timely manner. Timeout and retransmission algorithms are implementation dependent and are outside the scope of this document. However, it must be reasonable enough not to cause excessive retransmission of SCMP messages while maintaining the robustness of the protocol. Algorithms on this subject are described in [WoHD95], [Jaco88], [KaPa87].
直ちに予想された承認を受けないとき、SCMPを「再-トランスミッション」の使用で信頼できるようにします。 タイムアウトと再送信アルゴリズムは、実現に依存していて、このドキュメントの範囲の外にあります。 しかしながら、それはプロトコルの丈夫さを維持している間、SCMPメッセージの過度の「再-トランスミッション」を引き起こさないほど妥当でなければなりません。 この話題の上のアルゴリズムは[WoHD95]、[Jaco88][KaPa87]で説明されます。
Most existing algorithms are based on an estimation of the Round Trip Time (RTT) between two hosts. With SCMP, if an ST agent wishes to have an estimate of the RTT to and from a neighbor, it should generate a STATUS message with an SID which has all its fields set to zero. An ST agent receiving a STATUS message with such SID should answer as rapidly as possible with a STATUS-RESPONSE message containing the same SID, and no other stream information. The time interval between the send and receive operations can be used as an estimate of the RTT to and from the neighbor.
ほとんどの既存のアルゴリズムが2人のホストの間のRound Trip Time(RTT)に関する見積りに基づいています。 SCMPで、STエージェントに隣人と隣人からのRTTの見積りがありたいなら、それはすべての分野をゼロに設定させるSIDと共にSTATUSメッセージを発生させるべきです。 同じSIDを含んでいますが、早急にSTATUS-RESPONSEメッセージが他のどんな流れの情報も含んでいない状態で、そのようなSIDと共にSTATUSメッセージを受け取るSTエージェントが答えるべきです。 操作を送って、受けてください。間の時間間隔、RTTの見積りとして隣人と隣人から使用できます。
8.6 Network MTU Discovery
8.6 ネットワークMTU発見
At connection setup, the application at the origin asks the local ST agent to create streams with certain QoS requirements. The local ST agent fills out its network MTU value in the MaxMsgSize parameter in
接続設定では、発生源におけるアプリケーションは、あるQoS要件でストリームを作成するように地元のSTエージェントに頼みます。 地元のSTエージェントは中にMaxMsgSizeパラメタのネットワークMTU価値に書き込みます。
Delgrossi & Berger, Editors Experimental [Page 68] RFC 1819 ST2+ Protocol Specification August 1995
[68ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
the CONNECT message and forwards it to the next-hop ST agents. Each ST agent in the path checks to see if it's network MTU is smaller than the one specified in the CONNECT message and, if it is, the ST agent updates the MaxMsgSize in the CONNECT message to it's network MTU. If the target application decides to accept the stream, the ST agent at the target copies the MTU value in the CONNECT message to the MaxMsgSize field in the ACCEPT message and sends it back to the application at the origin. The MaxMsgSize field in the ACCEPT message is the minimum MTU of the intervening networks to that target. If the application has multiple targets then the minimum MTU of the stream is the smallest MaxMsgSize received from all the ACCEPT messages. It is the responsibility of the application to segment its PDUs according to the minimum MaxMsgSize of the stream since no data fragmentation is supported during the data transfer phase. If a particular target's MaxMsgSize is unacceptable to an application, it may disconnect the target from the stream and assume that the target cannot be supported. When evaluating a particular target's MaxMsgSize, the application or the application interface will need to take into account the size of the ST data header.
CONNECTは次のホップSTエージェントに通信して、それを送ります。 見る経路チェックにおけるそれぞれのSTエージェントはそれがネットワークMTUであるならものがCONNECTメッセージで指定したより小さいです、そして、それがそうなら、STエージェントはCONNECTメッセージでそれのネットワークMTUにMaxMsgSizeをアップデートします。 目標アプリケーションが、ストリームを受け入れると決めるなら、目標のSTエージェントは、ACCEPTメッセージのMaxMsgSize分野にCONNECTメッセージのMTU値をコピーして、発生源でそれをアプリケーションに送り返します。 ACCEPTメッセージのMaxMsgSize分野はその目標への介入しているネットワークの最小のMTUです。 アプリケーションにマルチターゲットがあるなら、ストリームの最小のMTUはすべてのACCEPTメッセージから受け取られる中で最も小さいMaxMsgSizeです。 それはデータ断片化がないの以来のストリームの最小のMaxMsgSizeに従ったPDUsがデータ転送段階の間にサポートされるセグメントへのアプリケーションの責任です。 特定の目標のMaxMsgSizeがアプリケーションに容認できないなら、それは、ストリームから目標から切断して、目標を支えることができないと仮定するかもしれません。 特定の目標のMaxMsgSizeを評価するとき、アプリケーションかアプリケーション・インターフェースが、STデータヘッダーのサイズを考慮に入れる必要があるでしょう。
8.7 IP Encapsulation of ST
8.7IP第カプセル化
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.
STパケットは、STプロトコルをサポートしないルータを通り抜けるのを許容するためにIPでカプセルに入れられるかもしれません。 もちろん、ST資源管理がそのような経路に関して排除されて、パケットオーバーヘッドがカプセル化によって増強されますが、性能が合理的に予測できるなら、これは全く交信しないより良いかもしれません。
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, see [RFC1700], to indicate an ST packet is enclosed,
as opposed to TCP or UDP, for example.
o プロトコルが5である、[RFC1700]を見てください、そして、STパケットを示すのはTCPかUDPと対照的に例えば、同封されます。
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, see [RFC1700]. This feature is not implemented
uniformly in the Internet, so its use can't be precisely defined
here.
o [RFC1700]は、サービスのタイプが要求されているサービスのための適切な値に用意ができるかもしれないのを見ます。 この特徴がインターネットで一様に実装されないので、ここで正確に使用を定義できません。
Delgrossi & Berger, Editors Experimental [Page 69] RFC 1819 ST2+ Protocol Specification August 1995
[69ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
IP encapsulation adds little difficulty for the ST agent that receives the packet. However, when IP encapsulation is performed it must be done in both directions. To process the encapsulated IP message, the ST agents simply remove the IP header and proceed with ST header as usual.
IPカプセル化はパケットを受けるSTエージェントのためにほとんど困難を加えません。 しかしながら、IPカプセル化を実行するとき、両方の方向にそれをしなければなりません。 STエージェントは、カプセル化されたIPメッセージを処理するために、単に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. The routing function provides ST agents with the route and capability information needed to support encapsulation.
STエージェントが、要約するかどうか決めなければならないとき、より難しい部分がセットアップの間、あります。 次のホップSTエージェントがリモートネットワークの一員であり、STではなく、IPをサポートするルータを通してそのネットワークへのルートがあるなら、カプセル化が必要です。 経路選択機能はカプセル化をサポートするのに必要であるルートと能力情報をSTエージェントに提供します。
On forwarding, the (mostly constant) IP Header must be inserted and the IP checksum appropriately updated.
推進のときに、(ほとんど一定)のIP Headerは挿入されていて適切にアップデートされたIPチェックサムであるに違いありません。
Applications are informed about the number of IP hops traversed on the path to each target. The IPHops field of the CONNECT message, see Section 10.4.4, carries the number of traversed IP hops to the target application. The field is incremented by each ST agent when IP encapsulation will be used to reach the next-hop ST agent. The number of IP hops traversed is returned to the origin in the IPHops field of the ACCEPT message, Section 10.4.1.
アプリケーションは経路で各目標に横断されたIPホップの数に関して知識があります。 セクション10.4.4は、CONNECTメッセージのIPHops分野が横断されたIPホップの数を目標アプリケーションまで運ぶのを見ます。 IPカプセル化が次のホップSTエージェントに届くのに使用されるとき、分野はそれぞれのSTエージェントによって増加されます。 ホップが横断したIPの数はACCEPTメッセージ、セクション10.4.1のIPHops分野の発生源に返されます。
When using IP Encapsulation, the MaxMsgSize field will not reflect the MTU of the IP encapsulated segments. This means that IP fragmentation and reassembly may be needed in the IP cloud to support a message of MaxMsgSize. IP fragmentation can only occur when the MTU of the IP cloud, less IP header length, is the smallest MTU in a stream's network path.
IP Encapsulationを使用するとき、MaxMsgSize分野はセグメントであるとカプセル化されたIPのMTUを反映しないでしょう。 これは、IP雲でIP断片化と再アセンブリがMaxMsgSizeに関するメッセージをサポートするのが必要であるかもしれないことを意味します。 IP雲のMTU(より少ないIPヘッダ長)がストリームのネットワーク経路で最も小さいMTUであるときにだけ、IP断片化は起こることができます。
8.8 IP Multicasting
8.8 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 may be used if it is implemented in the next-hop ST agents and in the intervening IP routers.
STエージェントが複数の次のホップに異なった目標に向かって達するのにIPカプセル化を使用しなければならないならそれぞれの次のホップへの伝送のためパケットを模写しなければならない、さもなければ、それが次のホップSTエージェントと介入しているIPルータで実装されるなら、IPマルチキャスティングは使用されるかもしれません。
When the stream is established, the collection of next-hop ST agents must be set up as an IP multicast group. The ST agent must allocate an appropriate IP multicast address (see Section 10.3.3) and fill that address in the IPMulticastAddress field of the CONNECT message. The IP multicast address in the CONNECT message is used to inform the next-hop ST agents that they should join the multicast group to receive subsequent PDUs. Obviously, the CONNECT message itself must be sent using unicast. The next-hop ST agents must be able to receive on the specified multicast address in order to accept the connection.
ストリームが確立されるとき、IPマルチキャストグループとして次のホップSTエージェントの収集をセットアップしなければなりません。 STエージェントは、適切なIPマルチキャストアドレス(セクション10.3.3を見る)を割り当てて、CONNECTメッセージのIPMulticastAddress分野にそのアドレスをいっぱいにしなければなりません。 CONNECTメッセージのIPマルチキャストアドレスは、彼らがその後のPDUsを受け取るためにマルチキャストグループに加わるべきであることを次のホップSTエージェントに知らせるのに使用されます。 明らかに、CONNECTメッセージ自体にユニキャストを使用させなければなりません。 次のホップSTエージェントは、接続を受け入れるために指定されたマルチキャストアドレスで受信できなければなりません。
Delgrossi & Berger, Editors Experimental [Page 70] RFC 1819 ST2+ Protocol Specification August 1995
[70ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
If the next-hop ST agent can not receive on the specified multicast address, it sends a REFUSE message with ReasonCode (BadMcastAddress). Upon receiving the REFUSE, the upstream agent can choose to retry with a different multicast address. Alternatively, it can choose to lose the efficiency of multicast and use unicast delivery.
次のホップSTエージェントが指定されたマルチキャストアドレスで受信できないなら、それはReasonCode(BadMcastAddress)があるREFUSEメッセージを送ります。 REFUSEを受けると、上流のエージェントは、異なったマルチキャストアドレスで再試行するのを選ぶことができます。 あるいはまた、それは、マルチキャストの効率を失って、ユニキャスト配送を使用するのを選ぶことができます。
The following permanent IP multicast addresses have been assigned to ST:
以下の永久的なIPマルチキャストアドレスをSTに割り当ててあります:
224.0.0.7 All ST routers (intermediate agents)
224.0.0.8 All ST hosts (agents)
224.0.0.7 すべてのSTルータ(仲介物質)224.0.0.8人のAll STホスト(エージェント)
In addition, a block of transient IP multicast addresses, 224.1.0.0 - 224.1.255.255, has been allocated for ST multicast groups. For instance, the following two functions could be made available:
追加、1ブロックの一時的なIPマルチキャストアドレスに割り当てる、224.1 .0 .0--224.1 .255 .255 STマルチキャストグループのために、割り当てました。 例えば、以下の2つの機能を利用可能にするかもしれません:
o AllocateMcastAddr() -> result, McastAddr
o AllocateMcastAddr()->結果、McastAddr
o ListenMcastAddr(McastAddr) -> result
o ListenMcastAddr(McastAddr)->結果
o ReleaseMcastAddr(McastAddr) -> result
o ReleaseMcastAddr(McastAddr)->結果
9. The ST2+ Flow Specification
9. ST2+流れ仕様
This section defines the ST2+ flow specification. The flow specification contains the user application requirements in terms of quality of service. Its contents are LRM dependent and are transparent to the ST2 setup protocol. ST2 carries the flow specification as part of the FlowSpec parameter, which is described in Section 10.3.1. The required ST2+ flow specification is included in the protocol only to support interoperability. ST2+ also defines a "null" flow specification to be used only to support testing.
このセクションはST2+流れ仕様を定義します。 流れ仕様はサービスの質に関してユーザアプリケーション要件を含んでいます。 内容は、LRM扶養家族であり、ST2セットアッププロトコルに見え透いています。 ST2はFlowSpecパラメタの一部として流れ仕様を運びます。(パラメタはセクション10.3.1で説明されます)。 必要なST2+流れ仕様はプロトコルに含まれていますが、相互運用性をサポートします。 また、ST2+は、使用されますが、テストをサポートするために「ヌル」の流れ仕様を定義します。
ST2 is not dependent on a particular flow specification format and it is expected that other versions of the flow specification will be needed in the future. Different flow specification formats are distinguished by the value of the Version field of the FlowSpec parameter, see Section 10.3.1. A single stream is always associated with a single flow specification format, i.e., the Version field is consistent throughout the whole stream. The following Version field values are defined:
ST2は特定の流れ仕様形式に依存していません、そして、流れ仕様の他のバージョンが将来必要であると予想されます。 セクション10.3.1は、異なった流れ仕様形式がFlowSpecパラメタのバージョン分野の値によって区別されるのを見ます。 ただ一つのストリームがいつもただ一つの流れ仕様形式に関連している、すなわち、バージョン分野は全体のストリーム中で一貫しています。 以下のバージョン分野値は定義されます:
Delgrossi & Berger, Editors Experimental [Page 71] RFC 1819 ST2+ Protocol Specification August 1995
[71ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
0 - Null FlowSpec /* must be supported */ 1 - ST Version 1 2 - ST Version 1.5 3 - RFC 1190 FlowSpec 4 - HeiTS FlowSpec 5 - BerKom FlowSpec 6 - RFC 1363 FlowSpec 7 - ST2+ FlowSpec /* must be supported */
FlowSpec/*がサポートしている*/1(STバージョン1 2)がSTバージョンであったならそうしなければならない0--ヌル、1.5、3、--*/であるとRFC1190FlowSpec4--HeiTS FlowSpec5--BerKom FlowSpec6--RFC1363FlowSpec7--ST2+FlowSpec/*をサポートしなければならない
FlowSpecs version #0 and #7 must be supported by ST2+ implementations. Version numbers in the range 1-6 indicate flow specifications are currently used in existing ST2 implementations. Values in the 128-255 range are reserved for private and experimental use.
ST2+実装でFlowSpecsバージョン#0と#7、をサポートしなければなりません。 範囲1-6のバージョン番号は、流れ仕様が現在既存のST2実装に使用されるのを示します。 128-255範囲の値は個人的で実験的な使用のために予約されます。
In general, a flow specification may support sophisticated flow descriptions. For example, a flow specification could represent sub- flows of a particular stream. This could then be used to by a cooperating application and LRM to forward designated packets to specific targets based on the different sub-flows. The reserved bits in the ST2 Data PDU, see Section 10.1, may be used with such a flow specification to designate packets associated with different sub- flows. The ST2+ FlowSpec is not so sophisticated, and is intended for use with applications that generate traffic at a single rate for uniform delivery to all targets.
一般に、流れ仕様は、洗練された流れが記述であるとサポートするかもしれません。 例えば、流れ仕様は特定のストリームのサブ流れを表すかもしれません。 そしてときのaで協力するのに使用されて、フォワードへのアプリケーションとLRMが異なったサブ流れに基づく特定の目標にパケットを指定したというこれによることであるかもしれません。 セクション10.1は、ST2 Data PDUの予約されたビットが異なったサブ流れに関連しているパケットを指定するのにそのような流れ仕様で使用されるかもしれないのを見ます。 ST2+FlowSpecはそれほど洗練されていなくて、使用のために一定の配送のための単一賃率ですべての目標にトラフィックを生成するアプリケーションで意図します。
9.1 FlowSpec Version #0 - (Null FlowSpec)
9.1FlowSpecバージョン#0、-(ヌルFlowSpec)
The flow specification identified by a #0 value of the Version field is called the Null FlowSpec. This flow specification causes no resources to be allocated. It is ignored by the LRMs. Its contents are never updated. Stream setup takes place in the usual way leading to successful stream establishment, but no resources are actually reserved.
バージョン分野の#0値によって特定された流れ仕様はNull FlowSpecと呼ばれます。 この流れ仕様で、リソースを全く割り当てません。 LRMsはそれを無視します。内容を決してアップデートしません。 ストリームセットアップは不断のとおりうまくいっているストリーム設立に通じながら、行われますが、リソースは全く実際に予約されません。
The purpose of the Null FlowSpec is that of facilitating interoperability tests by allowing streams to be built without actually allocating the correspondent amount of resources. The Null FlowSpec may also be used for testing and debugging purposes.
Null FlowSpecの目的は容易にすることでは、ストリームが実際にリソースの通信員量を割り当てないで築き上げられるのを許容することによって相互運用性にテストされるということです。 また、Null FlowSpecは、目的をテストして、デバッグするのに使用されるかもしれません。
The Null FlowSpec comprises the 4-byte FlowSpec parameter only, see Section 10.3.1. The third byte (Version field) must be set to 0.
セクション10.3.1は、Null FlowSpecが4バイトのFlowSpecパラメタだけを包括するのを見ます。 3番目のバイト(バージョン分野)を0に設定しなければなりません。
9.2 FlowSpec Version #7 - ST2+ FlowSpec
9.2FlowSpecバージョン#7--ST2+FlowSpec
The flow specification identified by a #7 value of the Version field is the ST2+ FlowSpec, to be used by all ST2+ implementations. It allows the user applications to express their real-time requirements
バージョン分野の#7値によって特定された流れ仕様は、すべてのST2+実装によって使用されるためにはST2+FlowSpecです。 それで、ユーザアプリケーションはそれらのリアルタイムの要件を言い表すことができます。
Delgrossi & Berger, Editors Experimental [Page 72] RFC 1819 ST2+ Protocol Specification August 1995
[72ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
in the form of a QoS class, precedence, and three basic QoS parameters:
QoSのクラスのフォーム、先行、および3つの基本のQoSパラメタで:
o message size,
o メッセージサイズ
o message rate,
o メッセージレート
o end-to-end delay.
o 終わりから終わりへの遅れ。
The QoS class indicates what kind of QoS guarantees are expected by the application, e.g., strict guarantees or predictive, see Section 9.2.1. QoS parameters are expressed via a set of values:
QoSのクラスは、例えば、どういうQoS保証がアプリケーションで予想されているか、厳しい保証または予言的であるかを示します、とセクション9.2.1は見ます。 QoSパラメタは1セットの値で言い表されます:
o the "desired" values indicate the QoS desired by the application.
These values are assigned by the application and never modified by
the LRM.
o 「必要な」値はアプリケーションで望まれていたQoSを示します。 これらの値は、アプリケーションで割り当てられて、LRMによって決して変更されません。
o the "limit" values indicate the lowest QoS the application is
willing to accept. These values are also assigned by the application
and never modified by the LRM.
o 「限界」値はアプリケーションが受け入れても構わないと思っている中で最も低いQoSを示します。 これらの値は、また、アプリケーションで割り当てられて、LRMによって決して変更されません。
o the "actual" values indicate the QoS that the system is able to
provide. They are updated by the LRM at each node. The "actual"
values are always bounded by the "limit" and "desired" values.
o 「実際」の値はシステムが提供できるQoSを示します。 それらは各ノードでLRMによってアップデートされます。 「実際」の値はいつも境界がある「限界」の、そして、「必要な」値。
9.2.1 QoS Classes
9.2.1 QoSのクラス
Two QoS classes are defined:
2つのQoSのクラスが定義されます:
1 - QOS_PREDICTIVE /* QoSClass field value = 0x01, must be
supported*/
2 - QOS_GUARANTEED /* QoSClass field value = 0x10, optional */
1 --QOS_PREDICTIVE/*QoSClassは値の=0x01をさばきます、サポートしている*/が2であったに違いないなら--QOS_GUARANTEED/*QoSClass分野値の=0x10、任意の*/
o The QOS_PREDICTIVE class implies that the negotiated QoS may be
violated for short time intervals during the data transfer. An
application has to provide values that take into account the
"normal" case, e.g., the "desired" message rate is the allocated rate
for the transmission. Reservations are done for the "normal" case as
opposite to the peak case required by the QOS_GUARANTEED service
class. This QoS class must be supported by all implementations.
o QOS_PREDICTIVEのクラスは、交渉されたQoSがデータ転送のときに短い時間間隔の間違反されるかもしれないのを含意します。 アプリケーションは「正常な」ケースを考慮に入れる値を提供しなければなりません、例えば、「必要な」メッセージレートがトランスミッションの割り当てられた速度です。 QOS_GUARANTEEDサービスのクラスによって必要とされたピークケースと同じくらい反対の「正常な」ケースのために予約をします。 すべての実装でこのQoSのクラスをサポートしなければなりません。
o The QOS_GUARANTEED class implies that the negotiated QoS for the
stream is never violated during the data transfer. An application
has to provide values that take into account the worst possible
case, e.g., the "desired" message rate is the peak rate for the
transmission. As a result, sufficient resources to handle the peak
rate are reserved. This strategy may lead to overbooking of
resources, but it provides strict real-time guarantees. Support of
o QOS_GUARANTEEDのクラスは、ストリームのための交渉されたQoSがデータ転送の間決して違反されないのを含意します。 アプリケーションは最もひどく可能なケースを考慮に入れる値を提供しなければなりません、例えば、「必要な」メッセージレートがトランスミッションのピーク速度です。 その結果、ピークレートを扱うことができるくらいのリソースは予約されています。 この戦略はリソースのオーバーブッキングに導くかもしれませんが、それは厳しいリアルタイムの保証を提供します。 サポート
Delgrossi & Berger, Editors Experimental [Page 73] RFC 1819 ST2+ Protocol Specification August 1995
[73ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
this QoS class is optional.
このQoSのクラスは任意です。
If a LRM that doesn't support class QOS_GUARANTEED receives a FlowSpec containing QOS_GUARANTEED class, it informs the local ST agent. The ST agent may try different paths or delete the correspondent portion of the stream as described in Section 5.5.3, i.e., ReasonCode (FlowSpecError).
クラスがQOS_GUARANTEEDであるとサポートしないLRMがQOS_GUARANTEEDのクラスを含むFlowSpecを受けるなら、それは地元のSTエージェントに知らせます。 STエージェントは、セクション5.5.3で説明されるように異なった経路を試みるか、またはストリームの通信員部分を削除するかもしれません、すなわち、ReasonCode(FlowSpecError)。
9.2.2 Precedence
9.2.2 先行
Precedence is the importance of the connection being established. Zero represents the lowest precedence. The lowest level is expected to be used by default. 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.
先行は確立される接続の重要性です。 ゼロは最も低い先行を表します。 デフォルトで最も低いレベルによって使用されると予想されます。 一般に、先行と優先権の区別は先行が別のストリームから以前に遂行されたリソースを取ることが許可されているストリームを指定するということです、優先権がストリームが下げても構わないと最も思っているそれらのPDUsを特定しますが。
9.2.3 Maximum Data Size
9.2.3 最大のデータサイズ
This parameter is expressed in bytes. It represents the maximum amount of data, excluding ST and other headers, allowed to be sent in a messages as part of the stream. The LRM first checks whether it is possible to get the value desired by the application (DesMaxSize). If not, it updates the actual value (ActMaxSize) with the available size unless this value is inferior to the minimum allowed by the application (LimitMaxSize), in which case it informs the local ST agent that it is not possible to build the stream along this path.
このパラメタはバイトで言い表されます。 それは最大のデータ量を表します、ストリームの一部としてメッセージで送ることができたSTと他のヘッダーを除いて。 LRMは、最初に、アプリケーション(DesMaxSize)で値を望ませるのが可能であるかどうかチェックします。 そうでなければ、この値がアプリケーション(LimitMaxSize)で許容された最小限に劣っていない場合、有効なサイズで実価(ActMaxSize)をアップデートします、その場合、この経路に沿ってストリームを築き上げるのが可能でないことを地元のSTエージェントに知らせます。
9.2.4 Message Rate
9.2.4 メッセージレート
This parameter is expressed in messages/second. It represents the transmission rate for the stream. The LRM first checks whether it is possible to get the value desired by the application (DesRate). If not, it updates the actual value (ActRate) with the available rate unless this value is inferior to the minimum allowed by the application (LimitRate), in which case it informs the local ST agent that it is not possible to build the stream along this path.
このパラメタはメッセージ/秒で言い表されます。 それはストリームのために通信速度を表します。 LRMは、最初に、アプリケーション(DesRate)で値を望ませるのが可能であるかどうかチェックします。 そうでなければ、この値がアプリケーション(LimitRate)で許容された最小限に劣っていない場合、有効なレートで実価(ActRate)をアップデートします、その場合、この経路に沿ってストリームを築き上げるのが可能でないことを地元のSTエージェントに知らせます。
9.2.5 Delay and Delay Jitter
9.2.5 遅れと遅れジター
The delay parameter is expressed in milliseconds. It represents the maximum end-to-end delay for the stream. The LRM first checks whether it is possible to get the value desired by the application (DesMaxDelay). If not, it updates the actual value (ActMaxDelay) with the available delay unless this value is greater than the maximum delay allowed by the application (LimitMaxDelay), in which case it informs the local ST agent that it is not possible to build the
遅れパラメタはミリセカンドで言い表されます。 それはストリームのために終わりから終わりへの最大の遅れを表します。 LRMは、最初に、アプリケーション(DesMaxDelay)で値を望ませるのが可能であるかどうかチェックします。 そうでなければ、この値がアプリケーション(LimitMaxDelay)で許容された最大の遅れほど大きくない場合、利用可能な遅れで実価(ActMaxDelay)をアップデートします、その場合、建てるのが可能でないことを地元のSTエージェントに知らせます。
Delgrossi & Berger, Editors Experimental [Page 74] RFC 1819 ST2+ Protocol Specification August 1995
[74ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
stream along this path.
この経路をぞろぞろ通ってください。
The LRM also updates at each node the MinDelay field by incrementing it by the minimum possible delay to the next-hop. Information on the minimum possible delay allows to calculate the maximum end-to-end delay range, i.e., the time interval in which a data packet can be received. This interval should not exceed the DesMaxDelayRange value indicated by the application. The maximum end-to-end delay range is an upper bound of the delay jitter.
また、LRMは、各ノードで最小の可能な遅れで次のホップにそれを増加することによって、MinDelay分野をアップデートします。 最小の可能な遅れに関する情報で、終わりから端への遅れ最大の範囲(すなわち、データ・パケットを受け取ることができる時間間隔)について計算します。 この間隔はアプリケーションで示されたDesMaxDelayRange値を超えるべきではありません。 終わりから端への遅れ最大の範囲は遅れジターの上限です。
9.2.6 ST2+ FlowSpec Format
9.2.6 ST2+FlowSpec形式
The ST2+ FlowSpec has the following format:
ST2+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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QosClass | Precedence | 0(unused) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ActRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesMaxSize | LimitMaxSize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ActMaxSize | DesMaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LimitMaxDelay | ActMaxDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DesMaxDelayRange | ActMinDelay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QosClass| 先行| 0(未使用の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DesRate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LimitRate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActRate| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DesMaxSize| LimitMaxSize| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActMaxSize| DesMaxDelay| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LimitMaxDelay| ActMaxDelay| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DesMaxDelayRange| ActMinDelay| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The ST2+ FlowSpec.
図9: ST2+FlowSpec。
The LRM modifies only "actual" fields, i.e., those beginning with "Act". The user application assigns values to all other fields.
LRMは「実際」の分野だけ、すなわち、「条例」で始まるものを変更します。 ユーザアプリケーションは他のすべての分野に値を割り当てます。
o QoSClass indicates which of the two defined classes of service
applies. The two classes are: QOS_PREDICTIVE (QoSClass = 1) and
QOS_GUARANTEED (QoSClass = 2).
o QoSClassは、2つのもののどれがサービスのクラスを定義したかが適用されるのを示します。 2つのクラスは以下の通りです。 QOS_予言、(QoSClass=1)とQOS_は(QoSClass=2)を保証しました。
o Precedence indicates the stream's precedence. Zero represents the
lowest precedence, and should be the default value.
o 先行はストリームの先行を示します。 ゼロは、最も低い先行を表して、デフォルト値であるべきです。
o DesRate is the desired transmission rate for the stream in messages/
second. This field is set by the origin and is not modified by
o DesRateはメッセージ/秒のストリームのための必要な通信速度です。 この分野は、発生源によって設定されて、変更されません。
Delgrossi & Berger, Editors Experimental [Page 75] RFC 1819 ST2+ Protocol Specification August 1995
[75ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
intermediate agents.
仲介物質。
o LimitRate is the minimum acceptable transmission rate in messages/
second. This field is set by the origin and is not modified by
intermediate agents.
o LimitRateはメッセージ/秒の最小の許容できる通信速度です。 この分野は、発生源によって設定されて、仲介物質によって変更されません。
o ActRate is the actual transmission rate allocated for the stream in
messages/second. Each agent updates this field with the available
rate unless this value is less than LimitRate, in which case a
REFUSE is generated.
o ActRateはメッセージ/秒のストリームのために割り当てられた実際の通信速度です。 各エージェントはこの値がLimitRateほど以下でないなら有効なレートでこの分野をアップデートします、その場合、REFUSEが発生しています。
o DesMaxSize is the desired maximum data size in bytes that will be
sent in a message in the stream. This field is set by the origin.
o DesMaxSizeはストリームにおけるメッセージで送られるバイトで表現される必要な最大のデータサイズです。 この分野は発生源によって設定されます。
o LimitMaxSize is the minimum acceptable data size in bytes. This
field is set by the origin
o LimitMaxSizeはバイトで表現される最小の許容できるデータサイズです。 この分野は発生源によって設定されます。
o ActMaxSize is the actual maximum data size that may be sent in a
message in the stream. This field is updated by each agent based on
MTU and available resources. If available maximum size is less than
LimitMaxSize, the connection must be refused with ReasonCode
(CantGetResrc).
o ActMaxSizeはストリームにおけるメッセージで送られるかもしれない実際の最大のデータサイズです。 この分野はMTUと利用可能資源に基づく各エージェントによってアップデートされます。 有効な最大サイズがLimitMaxSizeより少ないなら、ReasonCode(CantGetResrc)と共に接続を拒否しなければなりません。
o DesMaxDelay is the desired maximum end-to-end delay for the stream
in milliseconds. This field is set by the origin.
o DesMaxDelayは終わりから終わりへのミリセカンドで表現されるストリームのための必要な最大の遅れです。 この分野は発生源によって設定されます。
o LimitMaxDelay is the upper-bound of acceptable end-to-end delay for
the stream in milliseconds. This field is set by the origin.
o LimitMaxDelayはミリセカンドで表現されるストリームのための終わりから終わりへの許容できる遅れの上限です。 この分野は発生源によって設定されます。
o ActMaxDelay is the maximum end-to-end delay that will be seen by
data in the stream. Each ST agent adds to this field the maximum
delay that will be introduced by the agent, including transmission
time to the next-hop ST agent. If the actual maximum exceeds
LimitMaxDelay, then the connection is refused with ReasonCode
(CantGetResrc).
o ActMaxDelayは終わりから終わりへのストリームにおけるデータによって見られる最大の遅れです。 それぞれのSTエージェントはエージェントによって導入される最大の遅れをこの分野に加えます、次のホップSTエージェントにトランスミッション時間を含めて。 実際の最大がLimitMaxDelayを超えているなら、接続はReasonCode(CantGetResrc)と共に拒否されます。
o DesMaxDelayRange is the desired maximum delay range that may be
encountered end-to-end by stream data in milliseconds. This value is
set by the application at the origin.
o DesMaxDelayRangeはミリセカンドで表現されるストリームデータによる遭遇している終わりから終わりであるかもしれない必要な最大の遅れ範囲です。 この値は発生源におけるアプリケーションで設定されます。
o ActMinDelay is the actual minimum end-to-end delay that will be
encountered by stream data in milliseconds. Each ST agent adds to
this field the minimum delay that will be introduced by the agent,
including transmission time to the next-hop ST agent. Each agent
must add at least 1 millisecond. The delay range for the stream can
be calculated from the actual maximum and minimum delay fields. It
is expected that the range will be important to some applications.
o ActMinDelayは終わりから終わりへのミリセカンドでストリームデータで遭遇する実際の最小の遅れです。 それぞれのSTエージェントはエージェントによって導入される最小の遅れをこの分野に加えます、次のホップSTエージェントにトランスミッション時間を含めて。 各エージェントは少なくとも1人のミリセカンドを加えなければなりません。 実際の最大の、そして、最小の遅れ分野からストリームのための遅れ範囲について計算できます。 範囲がいくつかのアプリケーションに重要になると予想されます。
Delgrossi & Berger, Editors Experimental [Page 76] RFC 1819 ST2+ Protocol Specification August 1995
[76ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10. ST2 Protocol Data Units Specification
10. ST2プロトコルデータ単位仕様
10.1 Data PDU
10.1 データPDU
IP and ST packets can be distinguished by the IP Version Number field, i.e., the first four (4) bits of the packet; ST has been assigned the value 5 (see [RFC1700]). There is no requirement for compatibility between IP and ST packet headers beyond the first four bits. (IP uses value 4.)
IPバージョンNumber分野でIPとSTパケットを区別できます、すなわち、パケットの最初の4(4)ビット。 値5をSTに割り当ててあります([RFC1700]を見てください)。 IPとSTパケットのヘッダーとの互換性のための要件は全く最初の4ビットを超えていません。 (IPは値4を使用します。)
The ST PDUs sent between ST agents consist of an ST Header encapsulating either a higher layer PDU or an ST Control Message. Data packets are distinguished from control messages via the D-bit (bit 8) in the ST header.
STエージェントの間に送られたST PDUsはPDUの、より高い層かST Control Messageのどちらかをカプセルに入れるST Headerから成ります。 STヘッダーのD-ビット(ビット8)でデータ・パケットはコントロールメッセージと区別されます。
The ST Header also includes an ST Version Number, a total length field, a header checksum, a unique id, and the stream origin 32-bit IP address. The unique id and the stream origin 32-bit IP address form the stream id (SID). This is shown in Figure 10. Please refer to Section 10.6 for an explanation of the notation.
また、ST HeaderはSTバージョンNumber、全長分野、ヘッダーチェックサム、ユニークなイド、および発生源の32ビットのストリームIPアドレスを含んでいます。 ユニークなイドと発生源の32ビットのストリームIPアドレスはストリームイド(SID)を形成します。 これは図10に示されます。 記法に関する説明についてセクション10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ST=5 | Ver=3 |D| Pri | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HeaderChecksum | UniqueID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OriginIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=3|D| Pri| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HeaderChecksum| UniqueID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OriginIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: ST Header
図10: 第ヘッダー
o ST is the IP Version Number assigned to identify ST packets. The
value for ST is 5.
o STはSTパケットを特定するために割り当てられたIPバージョンNumberです。 STのための値は5です。
o Ver is the ST Version Number. The value for the current ST2+ version
is 3.
o VerはSTバージョンNumberです。 現在のST2+バージョンのための値は3です。
o D (bit 8) is set to 1 in all ST data packets and to 0 in all SCMP
control messages.
o D(ビット8)はすべてのSTデータ・パケットの1と、そして、すべてのSCMPコントロールメッセージの0に設定されます。
o Pri (bits 9-11) is the packet-drop priority field with zero (0)
being lowest priority and seven the highest. The field is to be used
as described in Section 3.2.2.
o Pri(ビット9-11テロ)は最も低い優先度である(0)がなくて7が最も高いパケット滴の優先権分野です。 分野はセクション3.2.2で説明されるように使用されていることです。
Delgrossi & Berger, Editors Experimental [Page 77] RFC 1819 ST2+ Protocol Specification August 1995
[77ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o TotalBytes is the length, in bytes, of the entire ST packet, it
includes the ST Header but does not include any local network
headers or trailers. In general, all length fields in the ST
Protocol are in units of bytes.
o TotalBytesは長さです、バイトで全体のSTパケットでは、それがST Headerを含んでいますが、どんな企業内情報通信網ヘッダーやトレーラも含んでいません。 一般に、STプロトコルのすべての長さの分野がユニットのバイトであります。
o HeaderChecksum covers only the ST Header (12 bytes). The ST Protocol
uses 16-bit checksums here in the ST Header and in each Control
Message. For checksum computation, see Section 8.3.
o HeaderChecksumはST Header(12バイト)だけをカバーしています。 STプロトコルはここ、ST Headerと各Control Messageで16ビットのチェックサムを使用します。 チェックサム計算に関しては、セクション8.3を見てください。
o UniqueID is the first element of the stream ID (SID). It is locally
unique at the stream origin, see Section 8.1.
o UniqueIDはストリームID(SID)の最初の要素です。 セクション8.1は、それがストリーム発生源で局所的にユニークであることがわかります。
o OriginIPAddress is the second element of the SID. It is the 32-bit
IP address of the stream origin, see Section 8.1.
o OriginIPAddressはSIDの2番目の要素です。 セクション8.1は、それがストリーム発生源の32ビットのIPアドレスであると考えます。
Bits 12-15 must be set to zero (0) when using the flow specifications defined in this document, see Section 9. They may be set accordingly when other flow specifications are used, e.g., as described in [WoHD95].
セクション9は、本書では定義された流れ仕様を使用するときには(0)のゼロを合わせるようにビット12-15を設定しなければならないのを見ます。 他の流れ仕様が使用されているとき、それらは例えば、[WoHD95]で説明されるようにそれに従って、設定されるかもしれません。
10.1.1 ST Data Packets
10.1.1 STデータ・パケット
ST packets whose D-bit is non-zero are 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. ST agents will not pass data packets over a new hop whose setup is not complete.
D-ビットが非ゼロであるSTパケットはデータ・パケットです。 彼らの解釈は、より高い層のプロトコルのための問題であり、その結果、ここで指定されません。 データ・パケットは、STチェックサムによって保護されないで、誤りがあっても、より高い層のプロトコルに提供されるでしょう。 STエージェントはセットアップが完全でない新しいホップの上にデータ・パケットを通過しないでしょう。
10.2 Control PDUs
10.2 コントロールPDUs
SCMP control messages are exchanged between neighbor ST agents using a D-bit of zero (0). The control protocol follows a request-response model with all requests expecting responses. Retransmission after timeout (see Section 4.3) 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 is partitioned and a control message per partition is sent (see Section 5.1.2). All control messages have the following format
隣人STエージェントの間で(0)がないD-ビットを使用することでSCMPコントロールメッセージを交換します。 制御プロトコルは、応答を予想しながら、すべての要求で要求応答モデルに従います。 タイムアウト(セクション4.3を見る)が考慮するのにおいて使用されていた後に、Retransmissionはメッセージを失ったか、または無視しました。 コントロールメッセージはパケット境界に達しません。 ホップのMTUには、コントロールメッセージが大き過ぎるなら、情報を仕切ります、そして、1パーティションあたり1つのコントロールメッセージを送ります(セクション5.1.2を見てください)。 すべてのコントロールメッセージには、以下の形式があります。
Delgrossi & Berger, Editors Experimental [Page 78] RFC 1819 ST2+ Protocol Specification August 1995
[78ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: OpCodeSpecificData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : OpCodeSpecificData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: ST Control Message Format
図11: メッセージ・フォーマットを第制御してください。
o OpCode identifies the type of control message.
o OpCodeはコントロールメッセージのタイプを特定します。
o Options is used to convey OpCode-specific variations for a control
message.
o オプションは、コントロールメッセージのためにOpCode特有の変化を伝えるのに使用されます。
o 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 (4).
o TotalBytesはすべてのOpCodeの特定の分野と任意のパラメタを含むバイトで表現されるコントロールメッセージの長さです。 値はいつも4(4)で分割可能です。
o 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 (0) 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.
o 参照はトランザクション番号です。 要求コントロールメッセージの各送付者はストリームに関してユニークなメッセージにReference番号を割り当てます。 写しをReference番号は受信機によって使用されて、検出して、捨てます。 承認されていて、各承認は要求のReference番号を運びます。 そして、参照ゼロ(0)が決して使用されないで、Reference番号が、より古くなるように巻きつけて着るドレスで単調に増加していると思われる、 より最近、関係はよく定義されます。
o 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 from the same ST agent. Examples are CONNECT and CHANGE
messages that are first acknowledged hop-by-hop and then lead to an
ACCEPT or REFUSE response from each target.
o LnkReferenceはこの作成されるべき要求コントロールメッセージを引き起こした要求コントロールメッセージのReference分野を含んでいます。 それはただ一つの要求が同じSTエージェントから複数の応答につながる状況で使用されます。 例がCONNECTであり、最初に承認されるCHANGEメッセージは、ホップで跳んで、次に、各目標からACCEPTかREFUSE応答につながります。
o 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).
o SenderIPAddressはSTエージェントがコントロールメッセージを送るのに使用したネットワーク・インターフェースの32ビットのIPアドレスです。 パケットがSTエージェント(近く跳びホップ)によって進められるたびにこの値は変化します。
Delgrossi & Berger, Editors Experimental [Page 79] RFC 1819 ST2+ Protocol Specification August 1995
[79ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o 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 to be error free before
it is acted upon.
o チェックサムはコントロールメッセージのチェックサムです。 ビットが間違っていた状態で提供されるかもしれないパケットでコントロールメッセージを送るので、それが作用される前にエラーのなくなるようにそれぞれのコントロールメッセージをチェックしなければなりません。
o ReasonCode is set to zero (0 = NoError) in most SCMP messages.
Otherwise, it can be set to an appropriate value to indicate an
error situation as defined in Section 10.5.3.
o ReasonCodeはほとんどのSCMPメッセージで(0=NoError)のゼロを合わせるように用意ができています。 さもなければ、適切な値にそれがセクション10.5.3で定義されるようにエラー状態を示すように設定できます。
o OpCodeSpecificData 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 (0) are included to allow the
format to match that of the corresponding request message. The
OpCodeSpecificData may also contain optional parameters. The
specifics of OpCodeSpecificData are defined in Section 10.3.
o OpCodeSpecificDataはコントロールメッセージに関連しているどんな追加情報も含んでいます。 それは、特定のコントロールメッセージによって、以下でさらに説明されます。 いくつかの応答制御メッセージでは、(0)がない分野は、形式が対応する要求メッセージのものに合っているのを許容するために含まれています。 また、OpCodeSpecificDataは任意のパラメタを含むかもしれません。 OpCodeSpecificDataの詳細はセクション10.3で定義されます。
10.3 Common SCMP Elements
10.3 一般的な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 four (4) bytes, the parameter is padded with one to three zero (0) bytes. PBytes is thus always a multiple of four (4). Parameters can be present in any order.
いくつかの分野とパラメタ(一般的に要素に言及される)は2PDUsに共通です。 何度か彼らの記述を繰り返すことの代わりにそれらはここで詳細に説明されます。 多くの場合、パラメタの存在は任意です。 パラメタが容易に定義されて、分析されることを許可するために、それぞれがバイトで表現されるパラメタの長さを示すPBytesバイトがあとに続くPCodeバイトと同一視されています(PCode、PByte、およびどんな詰め物バイトも含んでいて)。 情報の長さが4(4)バイトの倍数でないなら、パラメタは1〜3ゼロ(0)バイトで水増しされます。 その結果、いつもPBytesは4(4)の倍数です。 パラメタは順不同に存在している場合があります。
10.3.1 FlowSpec
10.3.1 FlowSpec
The FlowSpec parameter (PCode = 1) is used in several SCMP messages to convey the ST2 flow specification. The FlowSpec parameter has the following format:
FlowSpecパラメタ(PCode=1)はST2流れ仕様を伝えるいくつかのSCMPメッセージで使用されます。 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 = 1 | PBytes | Version | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec detail :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| バージョン| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpecの詳細: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: FlowSpec Parameter
図12: FlowSpecパラメタ
Delgrossi & Berger, Editors Experimental [Page 80] RFC 1819 ST2+ Protocol Specification August 1995
[80ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o the Version field contains the FlowSpec version.
o バージョン分野はFlowSpecバージョンを含んでいます。
o the FlowSpec detail field contains the flow specification and is
transparent to the ST agent. It is the data structure to be passed
to the LRM. It must be 4-byte aligned.
o FlowSpec詳細分野は、流れ仕様を含んでいて、STエージェントにとって、透明です。 それはLRMに通過されるデータ構造です。 並べられた状態で、それは4バイトでなければなりません。
The Null FlowSpec, see Section 9.1, has no FlowSpec detail field. PBytes is set to four (4), and Version is set to zero (0). The ST2+ FlowSpec, see Section 9.2, is a 32-byte data structure. PBytes is set to 36, and Version is set to seven (7).
セクション9.1は、Null FlowSpecにはFlowSpec詳細分野が全くないのを見ます。 PBytesは4(4)に用意ができています、そして、バージョンが(0)のゼロに合うように設定されます。 セクション9.2は、ST2+FlowSpecが32バイトのデータ構造であると考えます。 PBytesは36に用意ができています、そして、バージョンは7(7)に設定されます。
10.3.2 Group
10.3.2 グループ
The Group parameter (PCode = 2) is an optional argument used to indicate that the stream is a member in the specified group.
Groupパラメタ(PCode=2)はストリームが指定されたグループのメンバーであることを示すのに使用される任意の議論です。
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 = 2 | PBytes = 16 | GroupUniqueID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GroupCreationTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GroupInitiatorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relationship | 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=2| PBytes=16| GroupUniqueID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GroupCreationTime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GroupInitiatorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 関係| N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Group Parameter
図13: グループパラメタ
o GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime
together form the GroupName field. They are allocated by the group
name generator function, see Section 8.2. GroupUniqueID and
GroupCreationTime are implementation specific and have only local
definitions.
o GroupUniqueID、GroupInitiatorIPAddress、および一緒にGroupCreationTimeはGroupName分野を形成します。 セクション8.2は、それらがグループ名ジェネレータ機能によって割り当てられるのを見ます。 GroupUniqueIDとGroupCreationTimeは実装特有であり、地方の定義しか持っていません。
o Relationship has the following format:
o 関係には、以下の形式があります:
0
0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (unused) |S|P|F|B|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0(未使用の)|S|P|F|B| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Relationship Field
図14: 関係分野
Delgrossi & Berger, Editors Experimental [Page 81] RFC 1819 ST2+ Protocol Specification August 1995
[81ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
The B, F, P, S bits correspond to Bandwidth, Fate, Path, and Subnet resources sharing, see Section 7. A value of 1 indicates that the relationship exists for this group. All combinations of the four bits are allowed. Bits 0-11 of the Relationship field are reserved for future use and must be set to 0.
B、F、P、SビットはBandwidthに対応している、Path、およびSubnetリソースが共有されて、Fateはセクション7を見ます。 1の値は、関係がこのグループのために存在するのを示します。 4ビットのすべての組み合わせが許されています。 Relationship分野のビット0-11を今後の使用のために予約されて、0に設定しなければなりません。
o N contains a legal value only if the B-bit is set. It is the value
of the N parameter to be used as explained in Section 7.1.1.
o B-ビットが設定される場合にだけ、Nは正当な値を含んでいます。 それはセクション7.1.1で説明されるように使用されるべきNパラメタの値です。
10.3.3 MulticastAddress
10.3.3 MulticastAddress
The MulticastAddress parameter (PCode = 3) is an optional parameter that is used when using IP encapsulation and setting up an IP multicast group. This parameter is used to communicate the desired IP multicast address to next-hop ST agents that should become members of the group, see Section 8.8.
MulticastAddressパラメタ(PCode=3)はIPカプセル化を使用して、IPマルチキャストグループを設立するとき使用された任意のパラメタです。 このパラメタはグループのメンバーになるべきである次のホップSTエージェントに必要なIPマルチキャストアドレスを伝えるのに使用されます、とセクション8.8は見ます。
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 | PBytes = 8 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPMulticastAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| PBytes=8| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPMulticastAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: MulticastAddress
図15: MulticastAddress
o IPMulticastAddress is the 32-bit IP multicast address to be used to
receive data packets for the stream.
o IPMulticastAddressはストリームのためにデータ・パケットを受けるのに使用されるべき32ビットのIPマルチキャストアドレスです。
10.3.4 Origin
10.3.4 発生源
The Origin parameter (PCode = 4) is used to identify the next higher protocol, and the SAP being used in conjunction with that protocol.
Originパラメタ(PCode=4)は、次の、より高いプロトコル、およびそのプロトコルに関連して使用される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 = 5 | PBytes | NextPcol |OriginSAPBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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=5| PBytes| NextPcol|OriginSAPBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : OriginSAP: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Origin
図16: 発生源
Delgrossi & Berger, Editors Experimental [Page 82] RFC 1819 ST2+ Protocol Specification August 1995
[82ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o 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 [RFC1700].
o NextPcolはSTの上で使用されるためにプロトコルを特定するのに逆多重化操作に使用される8ビットの分野です。NextPcolの値は、IPヘッダーのプロトコル分野と同じ数のスペースにあって、その結果、Assigned民数記RFC[RFC1700]で定義されます。
o OriginSAPBytes specifies the length of the OriginSAP, exclusive of
any padding required to maintain 32-bit alignment.
o OriginSAPBytesは32ビットの整列を維持するのに必要である詰め物を除いてOriginSAPの長さを指定します。
o OriginSAP identifies the origin's SAP associated with the NextPcol
protocol.
o OriginSAPは発生源のNextPcolプロトコルに関連しているSAPを特定します。
Note that the 32-bit IP address of the stream origin is not included in this parameter because it is always available as part of the ST header.
それがSTヘッダーの一部としていつも利用可能であるのでストリーム発生源の32ビットのIPアドレスがこのパラメタに含まれていないことに注意してください。
10.3.5 RecordRoute
10.3.5 RecordRoute
The RecordRoute parameter (PCode = 5) is used to request that the route between the origin and a target be recorded and delivered to the user application. The ST agent at the origin (or target) including this parameter, has to determine the parameter's length, indicated by the PBytes field. ST agents processing messages containing this parameter add their receiving IP address in the position indicated by the FreeOffset field, space permitting. If no space is available, the parameter is passed unchanged. When included by the origin, all agents between the origin and the target add their IP addresses and this information is made available to the application at the target. When included by the target, all agents between the target and the origin, inclusive, add their IP addresses and this information is made available to the application at the origin.
RecordRouteパラメタ(PCode=5)は、発生源と目標の間のルートがユーザアプリケーションに記録されて、提供されるよう要求するのに使用されます。 発生源(または、目標)におけるSTエージェントは、このパラメタを入れて、PBytes分野によって示されたパラメタの長さを測定しなければなりません。 このパラメタを含むメッセージを処理するSTエージェントは、彼らがFreeOffset分野によって示された位置にIPアドレスを受け取ると言い足します、スペースが可能にして。 どんなスペースも利用可能でないなら、パラメタは変わりがない状態で通過されます。 発生源によって含まれていると、発生源と目標の間のすべてのエージェントが、彼らのIPが扱うと言い足します、そして、アプリケーションは目標でこの情報を入手します。 目標によって含まれていると、目標と発生源の間のすべての包括的なエージェントが、彼らの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 = 5 | PBytes | 0 | FreeOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address 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=5| PBytes| 0 | FreeOffset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレスN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: RecordRoute
図17: RecordRoute
o PBytes is the length of the parameter in bytes. Length is determined
by the agent (target or origin) that first introduces the parameter.
o PBytesはバイトで表現されるパラメタの長さです。 長さは最初にパラメタを紹介するエージェント(目標か発生源)によって測定されます。
Delgrossi & Berger, Editors Experimental [Page 83] RFC 1819 ST2+ Protocol Specification August 1995
[83ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
Once set, the length of the parameter remains unchanged.
いったん設定されると、パラメタの長さは変わりがありません。
o FreeOffset indicates the offset, relative to the start of the
parameter, for the next IP address to be recorded. When the
FreeOffset is greater than, or equal to, PBytes the RecordRoute
parameter is full.
o FreeOffsetは、次のIPアドレスが記録されるためにパラメタの始まりに比例してオフセットを示します。 FreeOffsetが、よりすばらしい、等しい、PBytes、RecordRouteパラメタは完全です。
o IP Address is filled in, space permitting, by each ST agent
processing this parameter.
o スペースがそれぞれのSTエージェント処理でこのパラメタを可能にして、IP Addressは記入されます。
10.3.6 Target and TargetList
10.3.6 目標とTargetList
Several control messages use a parameter called TargetList (PCode = 6), which contains information about the targets to which the message pertains. For each Target in the TargetList, the information includes the 32-bit IP address of the target, the SAP applicable to the next higher layer protocol, and the length of the SAP (SAPBytes). Consequently, a Target structure can be of variable length. Each entry has the format shown in Figure 18.
いくつかのコントロールメッセージがTargetList(PCode=6)と呼ばれるパラメタを使用します。TargetListはメッセージが関係する目標の情報を含みます。 TargetListの各Targetに関しては、情報は目標(次の、より高い層のプロトコル、およびSAP(SAPBytes)の長さに適切なSAP)の32ビットのIPアドレスを含んでいます。 その結果、Target構造は可変長のものであることができます。 各エントリーには、図18に示された書式があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetBytes| SAPBytes| SAP: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Target
図18: 目標
o TargetIPAddress is the 32-bit IP Address of the Target.
o TargetIPAddressはTargetの32ビットのIP Addressです。
o TargetBytes is the length of the Target structure, beginning with
the TargetIPAddress.
o TargetIPAddressと共に始まって、TargetBytesはTarget構造の長さです。
o SAPBytes is the length of the SAP, excluding any padding required to
maintain 32-bit alignment.
o 32ビットの整列を維持するのに必要である詰め物を除いて、SAPBytesはSAPの長さです。
o SAP may be longer than 2 bytes and it includes a padding when
required. There would be no padding required for SAPs with lengths
of 2, 6, 10, etc., bytes.
o SAPは2バイトより長いかもしれません、そして、必要であると、それは詰め物を含んでいます。 SAPsに2、6、10などの長さ、バイトで必要である水増しがないでしょう。
Delgrossi & Berger, Editors Experimental [Page 84] RFC 1819 ST2+ Protocol Specification August 1995
[84ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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 | 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=6| PBytes| TargetCountはNと等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: TargetList
10.3.7 UserData
図19: TargetList10.3.7UserData
The UserData parameter (PCode = 7) is an optional parameter that may be used by the next higher protocol or an application to convey arbitrary information to its peers. This parameter is propagated in some control messages and its contents have no significance to ST agents. Note that since the size of control messages is limited by the smallest MTU in the path to the targets, the maximum size of this parameter cannot be specified a priori. If the size of this parameter causes a message to exceed the network MTU, an ST agent behaves as described in Section 5.1.2. The parameter must be padded to a multiple of 32 bits.
UserDataパラメタ(PCode=7)は任意の情報を同輩に伝えるのに次の、より高いプロトコルかアプリケーションで使用されるかもしれない任意のパラメタです。 このパラメタはいくつかのコントロールメッセージで伝播されます、そして、内容はSTエージェントに意味を全く持っていません。 コントロールメッセージのサイズが経路で最も小さいMTUによって目標に制限されるので先験的にこのパラメタの最大サイズを指定できないことに注意してください。 このパラメタのサイズがネットワークMTUを超えるメッセージを引き起こすなら、STエージェントはセクション5.1.2で説明されるように振る舞います。 32ビットの倍数にパラメタを水増ししなければなりません。
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 = 7 | PBytes | UserBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserInfo : 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=7| PBytes| UserBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserInfo: 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: UserData
図20: UserData
o UserBytes specifies the number of valid UserInfo bytes.
o UserBytesは有効なUserInfoバイトの数を指定します。
o UserInfo is arbitrary data meaningful to the next higher protocol
layer or application.
o UserInfoは次の、より高いプロトコル層かアプリケーションに重要な任意のデータです。
Delgrossi & Berger, Editors Experimental [Page 85] RFC 1819 ST2+ Protocol Specification August 1995
[85ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.3.8 Handling of Undefined Parameters
10.3.8 未定義のパラメタの取り扱い
An ST agent must be able to handle all parameters listed above. To support possible future uses, parameters with unknown PCodes must also be supported. If an agent receives a message containing a parameter with an unknown Pcode value, the agent should handle the parameter as if it was a UserData parameter. That is, the contents of the parameter should be ignored, and the message should be propagated, as appropriate, along with the related control message.
STエージェントは上にリストアップされたすべてのパラメタを扱うことができなければなりません。 また、可能な将来の用途をサポートするために、未知のPCodesがあるパラメタをサポートしなければなりません。 エージェントが未知のPcode値でパラメタを含むメッセージを受け取るなら、エージェントはまるでそれがUserDataパラメタであるかのようにパラメタを扱うべきです。 すなわち、パラメタのコンテンツは無視されるべきです、そして、メッセージは伝播されるべきです、適宜、関連するコントロールメッセージと共に。
10.4 ST Control Message PDUs
標準時10.4コントロールメッセージPDUs
ST Control messages are described in the following section. Please refer to Section 10.6 for an explanation of the notation.
ST Controlメッセージは以下のセクションで説明されます。 記法に関する説明についてセクション10.6を参照してください。
10.4.1 ACCEPT
10.4.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. ACCEPT is also issued as a positive response to a CHANGE message. It implies that the target accepts the proposed stream modification.
ACCEPT(OpCode=1)はCONNECTメッセージへの積極的な応答として目標によって発行されます。 それは、目標がCONNECTによって確立されたストリームに沿って発生源からデータを受け入れるように準備されるのを含意します。 また、ACCEPTはCHANGEメッセージへの積極的な応答として発行されます。 それは、目標が提案されたストリーム変更を受け入れるのを含意します。
ACCEPT is relayed by the ST agents from the target to the origin along the path established by CONNECT (or CHANGE) but in the reverse direction. ACCEPT must be acknowledged with ACK at each hop.
ACCEPTは経路に沿ってSTエージェントによって目標から発生源までCONNECT(または、CHANGE)にもかかわらず、反対の方向に確立していた状態でリレーされます。 各ホップのACKと共にACCEPTを承認しなければなりません。
Delgrossi & Berger, Editors Experimental [Page 86] RFC 1819 ST2+ Protocol Specification August 1995
[86ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMsgSize | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StreamCreationTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPHops | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxMsgSize| RecoveryTimeout| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StreamCreationTime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPHops| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRoute: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: ACCEPT Control Message
図21: コントロールメッセージを受け入れてください。
o Reference contains a number assigned by the ST agent sending ACCEPT
for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにSTエージェント送付ACCEPTによって割り当てられた数を含んでいます。
o LnkReference is the Reference number from the corresponding CONNECT
(or CHANGE)
o LnkReferenceは対応するCONNECTからのReference番号です。(変化してください)
o MaxMsgSize indicates the smallest MTU along the path traversed by
the stream. This field is only set when responding to a CONNECT
request.
o MaxMsgSizeはストリームによって横断された経路に沿って最も小さいMTUを示します。 CONNECT要求に応じるときだけ、この分野は設定されます。
o RecoveryTimeout reflects 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. This field
represents what can actually be supported by each participating
agent, and is only set when responding to a CONNECT request.
o 検出されるべき失敗したシステムの部品とどんな修正措置も取られるのを待つことを望んでいた状態で、RecoveryTimeoutはアプリケーションがそうであるミリセカンドの名目上の数を反映します。 この分野はそれぞれの参加しているエージェントが実際にサポートすることができて、CONNECT要求に応じるときだけ設定されることを表します。
o StreamCreationTime is the 32- bits system dependent timestamp copied
from the corresponding CONNECT request.
o StreamCreationTimeは対応するCONNECT要求からコピーされた32のビットシステムに依存するタイムスタンプです。
Delgrossi & Berger, Editors Experimental [Page 87] RFC 1819 ST2+ Protocol Specification August 1995
[87ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o IPHops is the number of IP encapsulated hops traversed by the
stream. This field is set to zero by the origin, and is incremented
at each IP encapsulating agent.
o IPHopsはストリームによって横断されたホップであるとカプセル化されたIPの数です。 この分野は、発生源によってゼロに設定されて、エージェントをカプセル化しながら、各IPで増加されます。
10.4.2 ACK
10.4.2 ACK
ACK (OpCode = 2) is used to acknowledge a request. The ACK message is not propagated beyond the previous-hop or next-hop ST agent.
ACK(OpCode=2)は、要求を承諾するのに使用されます。 ACKメッセージは前のホップか次のホップ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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 2 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: ACK Control Message
図22: ACKコントロールメッセージ
o Reference is the Reference number of the control message being
acknowledged.
o 承認されていて、参照はコントロールメッセージのReference番号です。
o ReasonCode is usually NoError, but other possibilities exist, e.g.,
DuplicateIgn.
o ReasonCodeは通常NoErrorですが、他の可能性は例えば存在しています。DuplicateIgn。
Delgrossi & Berger, Editors Experimental [Page 88] RFC 1819 ST2+ Protocol Specification August 1995
[88ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.3 CHANGE
10.4.3 変化
CHANGE (OpCode = 3) is used to change the FlowSpec of an established stream. The CHANGE message is processed similarly to CONNECT, except that it travels along the path of an established stream. CHANGE must be propagated until it reaches the related stream's targets. CHANGE must be acknowledged with ACK at each hop.
CHANGE(OpCode=3)は、確立したストリームのFlowSpecを変えるのに使用されます。 確立したストリームの経路に沿って移動するのを除いて、CHANGEメッセージは同様にCONNECTに処理されます。 関連するストリームの目標に達するまで、CHANGEを伝播しなければなりません。 各ホップのACKと共にCHANGEを承認しなければなりません。
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|I| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|I| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRoute: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: CHANGE Control Message
図23: 変化コントロールメッセージ
o G (bit 8) is used to request a global, stream-wide change; the
TargetList parameter should be omitted when the G bit is specified.
o G(ビット8)はグローバルで、流れの全体の変化を要求するのに使用されます。 Gビットが指定されるとき、TargetListパラメタは省略されるべきです。
o I (bit 7) is used to indicate that the LRM is permitted to interrupt
and, if needed, break the stream in the process of trying to satisfy
the requested change.
o 私(ビット7)は、LRMが中断して、必要であるなら要求された変化を満たそうとすることの途中に流れを壊すのが許容されているのを示すのに使用されます。
o Reference contains a number assigned by the ST agent sending CHANGE
for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにSTエージェント送付CHANGEによって割り当てられた数を含んでいます。
10.4.4 CONNECT
10.4.4 接続してください。
CONNECT (OpCode = 4) 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(OpCode=4)は既存の流れの新しい流れのセットアップ、添加または回収を要求します。 起源だけが、流れ、および1番目をセットアップするためにCONNECTsの始発を発行できます。
Delgrossi & Berger, Editors Experimental [Page 89] RFC 1819 ST2+ Protocol Specification August 1995
[89ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
CONNECT to each next-hop is used to convey the SID.
それぞれの次のホップへのCONNECTは、SIDを運ぶのに使用されます。
The next-hop initially responds with an ACK, which implies that the CONNECT was valid and is being processed. The next-hop will later relay back either an ACCEPT or REFUSE from each target. An intermediate ST agent that receives a CONNECT behaves as explained in Section 4.5.
次のホップは初めは、ACKと共に応じます。(ACKはCONNECTが有効であったのを含意して、処理されています)。 次のホップは後で各目標から後部のACCEPTかREFUSEのどちらかをリレーするでしょう。 CONNECTを受け取る中間的STエージェントはセクション4.5で説明されるように振る舞います。
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 |J N|S| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMsgSize | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| StreamCreationTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPHops | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Origin :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Group :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MulticastAddress :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|J N|S| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxMsgSize| RecoveryTimeout| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | StreamCreationTime| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPHops| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 起源: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRoute: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : 以下を分類してください。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : MulticastAddress: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: CONNECT Control Message
図24: コントロールメッセージを接続してください。
Delgrossi & Berger, Editors Experimental [Page 90] RFC 1819 ST2+ Protocol Specification August 1995
[90ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o JN (bits 8 and 9) indicate the join authorization level for the
stream, see Section 4.4.2.
o JN(ビット8と9)が示す、流れのために認可レベルを接合してください、そして、.2にセクション4.4を見てください。
o S (bit 10) indicates the NoRecovery option (Section 4.4.1). When the
S-bit is set (1), the NoRecovery option is specified for the stream.
o S(ビット10)はNoRecoveryオプション(セクション4.4.1)を示します。 S-ビットがセット(1)であるときに、NoRecoveryオプションは流れに指定されます。
o Reference contains a number assigned by the ST agent sending CONNECT
for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにSTエージェント送付CONNECTによって割り当てられた数を含んでいます。
o MaxMsgSize indicates the smallest MTU along the path traversed by
the stream. This field is initially set to the network MTU of the
agent issues the CONNECT.
o MaxMsgSizeは流れで横断された経路に沿って最も小さいMTUを示します。 この分野は初めはエージェント問題のネットワークMTUにCONNECTを設定することです。
o RecoveryTimeout is the nominal number of milliseconds that the
application is willing to wait for failed system component to be
detected and any corrective action to be taken.
o RecoveryTimeoutによるアプリケーションが待っても構わないと思っているミリセカンドの名目上の数が取るために検出されるべきシステムの部品とどんな修正措置にも失敗したということです。
o StreamCreationTime is the 32- bits system dependent timestamp
generated by the ST agent issuing the CONNECT.
o StreamCreationTimeはシステムに依存するタイムスタンプがCONNECTを発行するSTエージェントで発生させた32ビットです。
o IPHops is the number of IP encapsulated hops traversed by the
stream. This field is set to zero by the origin, and is incremented
at each IP encapsulating agent.
o IPHopsは要約のホップが流れで横断したIPの数です。 この分野は、起源によってゼロに設定されて、それぞれのIP要約のエージェントで増加されます。
Delgrossi & Berger, Editors Experimental [Page 91] RFC 1819 ST2+ Protocol Specification August 1995
[91ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.5 DISCONNECT
10.4.5 分離
DISCONNECT (OpCode = 5) is used by an origin to tear down an established stream or part of a stream, or by an intermediate ST agent that detects a failure between itself and its previous-hop, as distinguished by the ReasonCode. The DISCONNECT message specifies the list of targets that are to be disconnected. An ACK is required in response to a DISCONNECT message. The DISCONNECT message is propagated all the way to the specified targets. The targets are expected to terminate their participation in the stream.
DISCONNECT(OpCode=5)は流れの確立した流れか一部の下側に苦しむ起源、またはそれ自体とその前のホップの間の失敗を検出する中間的STエージェントによって使用されます、ReasonCodeによって区別されるように。 DISCONNECTメッセージは外されることになっている目標のリストを指定します。 ACKがDISCONNECTメッセージに対応して必要です。 DISCONNECTメッセージは指定された目標までのいっぱいに伝播されます。 目標が流れで彼らの参加を終えると予想されます。
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 = 5 |G| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=5|G| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GeneratorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: DISCONNECT Control Message
図25: コントロールメッセージを外してください。
o G (bit 8) is used to request a DISCONNECT of all the stream's
targets. TargetList should be omitted when the G-bit is set (1). If
TargetList is present, it is ignored.
o G(ビット8)は、すべての流れの目標のDISCONNECTを要求するのに使用されます。 G-ビットがセット(1)であるときに、TargetListは省略されるべきです。 TargetListが存在しているなら、それは無視されます。
o Reference contains a number assigned by the ST agent sending
DISCONNECT for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにSTエージェント送付DISCONNECTによって割り当てられた数を含んでいます。
o ReasonCode reflects the event that initiated the message.
o ReasonCodeはメッセージを開始した出来事を反映します。
o GeneratorIPAddress is the 32-bit IP address of the host that first
generated the DISCONNECT message.
o GeneratorIPAddressは最初にDISCONNECTメッセージを発生させたホストの32ビットのIPアドレスです。
Delgrossi & Berger, Editors Experimental [Page 92] RFC 1819 ST2+ Protocol Specification August 1995
[92ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.6 ERROR
10.4.6 誤り
ERROR (OpCode = 6) is sent in acknowledgment to a request in which an error is detected. No action is taken on the erroneous request. No ACK is expected. The ERROR message is not propagated beyond the previous-hop or next-hop ST agent. An ERROR is never sent in response to another ERROR. The receiver of an ERROR is encouraged to try again without waiting for a retransmission timeout.
承認でERROR(OpCode=6)を誤りが検出される要求に送ります。 誤った要求のときに行動を全く取りません。 ACKは全く予想されません。 ERRORメッセージは前のホップか次のホップSTエージェントを超えて伝播されません。 別のERRORに対応してERRORを決して送りません。 ERRORの受信機が再送タイムアウトを待たないで再試行するよう奨励されます。
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 = 6 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PDUInError :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=6| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : PDUInError: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: ERROR Control Message
図26: 誤り制御メッセージ
o Reference is the Reference number of the erroneous request.
o 参照は誤った要求のReference番号です。
o ReasonCode indicates the error that triggered the message.
o ReasonCodeはメッセージの引き金となった誤りを示します。
o PDUInError is the PDU in error, beginning with the ST Header. This
parameter is optional. Its length is limited by network MTU, and may
be truncated when too long.
o ST Headerと共に始まって、PDUInErrorは間違いPDUです。 このパラメタは任意です。 長さは、ネットワークMTUによって制限されて、長過ぎるときに、先端を切られるかもしれません。
Delgrossi & Berger, Editors Experimental [Page 93] RFC 1819 ST2+ Protocol Specification August 1995
[93ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.7 HELLO
10.4.7 こんにちは
HELLO (OpCode = 7) is used as part of the ST failure detection mechanism, see Section 6.1.
セクション6.1は、HELLO(OpCode=7)が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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 7 |R| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference = 0 | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloTimer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=7|R| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照=0| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloTimer| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 27: HELLO Control Message
図27: こんにちは、コントロールメッセージ
o R (bit 8) is used for the Restarted-bit.
o R(ビット8)はRestarted-ビットに使用されます。
o HelloTimer represents the time in millisecond since the agent was
restarted, modulo the precision of the field. It is used to detect
duplicate or delayed HELLO messages.
o エージェントが再出発されたので、HelloTimerはミリセカンドに時間を表して、法は分野の精度です。 それは、写しか遅れたHELLOメッセージを検出するのに使用されます。
Delgrossi & Berger, Editors Experimental [Page 94] RFC 1819 ST2+ Protocol Specification August 1995
[94ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.8 JOIN
10.4.8 接合してください。
JOIN (OpCode = 8) is used as part of the ST steam joining mechanism, see Section 4.6.3.
セクション4.6.3は、JOIN(OpCode=8)が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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 8 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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=8| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GeneratorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: JOIN Control Message
図28: コントロールメッセージを接合してください。
o Reference contains a number assigned by the ST agent sending JOIN
for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにSTエージェント送付JOINによって割り当てられた数を含んでいます。
o GeneratorIPAddress is the 32-bit IP address of the host that
generated the JOIN message.
o GeneratorIPAddressはJOINメッセージを発生させたホストの32ビットのIPアドレスです。
o TargetList is the information associated with the target to be added
to the stream.
o TargetListは流れに加えられるために目標に関連づけられた情報です。
Delgrossi & Berger, Editors Experimental [Page 95] RFC 1819 ST2+ Protocol Specification August 1995
[95ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.9 JOIN-REJECT
10.4.9 廃棄物を接合します。
JOIN-REJECT (OpCode = 9) is used as part of the ST steam joining mechanism, see Section 4.6.3.
セクション4.6.3は、JOIN-REJECT(OpCode=9)が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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 9 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GeneratorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=9| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GeneratorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: JOIN-REJECT Control Message
図29: 廃棄物を接合しているコントロールメッセージ
o Reference contains a number assigned by the ST agent sending the
REFUSE for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにREFUSEを送るSTエージェントによって割り当てられた数を含んでいます。
o LnkReference is the Reference number from the corresponding JOIN
message.
o LnkReferenceは対応するJOINメッセージからのReference番号です。
o ReasonCode reflects the reason why the JOIN request was rejected.
o ReasonCodeはJOIN要求が拒絶された理由を反映します。
o GeneratorIPAddress is the 32-bit IP address of the host that first
generated the JOIN-REJECT message.
o GeneratorIPAddressは最初にJOIN-REJECTメッセージを発生させたホストの32ビットのIPアドレスです。
Delgrossi & Berger, Editors Experimental [Page 96] RFC 1819 ST2+ Protocol Specification August 1995
[96ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.4.10 NOTIFY
10.4.10 通知してください。
NOTIFY (OpCode = 10) is issued by an ST agent to inform other ST agents of events that may be significant. NOTIFY may be propagated beyond the previous-hop or next-hop ST agent depending on the ReasonCode, see Section 10.5.3; NOTIFY must be acknowledged with an ACK.
NOTIFY(OpCode=10)は、重要であるかもしれない出来事について他のSTエージェントに知らせるためにSTエージェントによって発行されます。 セクション10.5.3は、ReasonCodeによって、NOTIFYが前のホップか次のホップSTエージェントを超えて伝播されるかもしれないのを見ます。 ACKと共にNOTIFYを承認しなければなりません。
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 = 10 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MaxMsgSize | RecoveryTimeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=10| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MaxMsgSize| RecoveryTimeout| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: NOTIFY Control Message
図30: コントロールメッセージに通知してください。
o Reference contains a number assigned by the ST agent sending the
NOTIFY for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにNOTIFYを送るSTエージェントによって割り当てられた数を含んでいます。
o ReasonCode identifies the reason for the notification.
o ReasonCodeは通知の理由を特定します。
o DetectorIPAddress is the 32-bit IP address of the ST agent that
detects the event.
o DetectorIPAddressは出来事を検出するSTエージェントの32ビットのIPアドレスです。
o MaxMsgSize is set when the MTU of the listed targets has changed
(e.g., due to recovery), or when the notification is generated after
a successful JOIN. Otherwise it is set to zero (0).
o 記載された目標のMTUが変化したか(例えば、回復のため)、または通知がうまくいっているJOINの後に発生するとき、MaxMsgSizeは用意ができています。 さもなければ、それが(0)のゼロに合うように設定されます。
Delgrossi & Berger, Editors Experimental [Page 97] RFC 1819 ST2+ Protocol Specification August 1995
[97ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o RecoveryTimeout is set when the notification is generated after a
successful JOIN. Otherwise it is set to zero (0).
o 通知がうまくいっているJOINの後に発生するとき、RecoveryTimeoutは用意ができています。 さもなければ、それが(0)のゼロに合うように設定されます。
o FlowSpec is present when the notification is generated after a
successful JOIN.
o 通知がうまくいっているJOINの後に発生するとき、FlowSpecは存在しています。
o TargetList is present when the notification is related to one or
more targets, or when MaxMsgSize is set
o 通知が1個以上の目標に関連するか、またはMaxMsgSizeが用意ができているとき、TargetListは存在しています。
o UserData is present if the notification is generated after a
successful JOIN and the UserData parameter was set in the ACCEPT
message.
o うまくいっているJOINとUserDataパラメタがACCEPTメッセージで用意ができた後に通知が発生するなら、UserDataは存在しています。
10.4.11 REFUSE
10.4.11 廃物
REFUSE (OpCode = 11) is issued by a target that either does not wish to accept a CONNECT message or wishes to remove itself from an established stream. It might also be issued by an intermediate ST agent in response to a CONNECT or CHANGE either to terminate a routing loop, or when a satisfactory next-hop to a target cannot be found. It may also be a separate command when an existing stream has been preempted by a higher precedence stream or an ST agent detects the failure of a previous-hop, next-hop, or the network between them. In all cases, the TargetList specifies the targets that are affected by the condition. Each REFUSE must be acknowledged by an ACK.
REFUSE(OpCode=11)はCONNECTメッセージを受け入れたがっていない目標によって発行されたいか、または確立した流れから立ち退きたがっています。 また、目標への満足できる次のホップを見つけることができないとき、それは、CONNECTかCHANGEに対応してルーティング輪を終えるために中間的STエージェントによって発行されるかもしれません。 また、既存の流れが、より高い先行の流れで先取りされたとき、それは別々のコマンドであるかもしれませんかSTエージェントが前のホップ、次のホップ、またはそれらの間のネットワークの失敗を検出します。 すべての場合では、TargetListは状態で影響を受ける目標を指定します。 ACKは各REFUSEを承認しなければなりません。
The REFUSE is relayed back by the ST agents to the origin (or intermediate ST agent that created the CONNECT or CHANGE) along the path traced by the CONNECT. The ST agent receiving the REFUSE will process it differently depending on the condition that caused it, as specified in the ReasonCode field. No special effort is made to combine multiple REFUSE messages since it is considered most unlikely that separate REFUSEs will happen to both pass through an ST agent at the same time and be easily combined, e.g., have identical ReasonCodes and parameters.
REFUSEはSTエージェントによってCONNECTによってたどられた経路に沿った起源(または、CONNECTかCHANGEを作成した中間的STエージェント)にリレーされます。 それを引き起こした条件に異なってよって、REFUSEを受け取るSTエージェントはそれを処理するでしょう、ReasonCode分野で指定されるように。 どんな特別な努力も別々のREFUSEsが同時にたまたまともにSTエージェントを通り抜けるのが最もありそうもないと考えられるので複数のREFUSEメッセージが結合させられて、容易に結合されないで、例えば、同じReasonCodesとパラメタを持ってください。
Delgrossi & Berger, Editors Experimental [Page 98] RFC 1819 ST2+ Protocol Specification August 1995
[98ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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 = 11 |G|E|N| 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DetectorIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ValidTargetIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: TargetList :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RecordRoute :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: UserData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=11|G|E|N| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DetectorIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ValidTargetIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RecordRoute: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : UserData: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: REFUSE Control Message
図31: コントロールメッセージを拒否してください。
o G (bit 8) is used to indicate that all targets down stream from the
sender are refusing. It is expected that this will be set most
commonly due to network failures. The TargetList parameter is
ignored or not present when this bit is set, and must be included
when not set.
o G(ビット8)は、送付者からの流れの下側へのすべての目標が拒否であることを示すのに使用されます。 これがネットワーク失敗のため最も一般的に設定されると予想されます。 このビットを設定されて、設定されないと含まなければならないとき、TargetListパラメタは、無視されているか、または存在していません。
o E (bit 9) is set by an ST agent to indicate that the request failed
and that the pre-change stream attributes, including resources, and
the stream itself still exist.
o E(ビット9)が要求が失敗して、リソースを含むプレ変化流れの属性と流れ自体がまだ存在しているのを示すようにSTエージェントによって設定されます。
o N (bit 10) is used to indicate that no further attempts to recover
the stream should be made. This bit must be set when stream recovery
should not be attempted, even in the case where the target
application has shut down normally (ApplDisconnect).
o N(ビット10)は、流れを回復するさらなる試みを全くするべきでないのを示すのに使用されます。 流れの回復を試みるべきでないとき、このビットを設定しなければなりません、通常、目標アプリケーションが停止した場合(ApplDisconnect)でさえ。
o Reference contains a number assigned by the ST agent sending the
REFUSE for use in the acknowledging ACK.
o 参照は承認しているACKにおける使用のためにREFUSEを送るSTエージェントによって割り当てられた数を含んでいます。
o LnkReference is either the Reference number from the corresponding
CONNECT or CHANGE, if it is the result of such a message, or zero
when the REFUSE was originated as a separate command.
o REFUSEが別々のコマンドとして溯源されたとき、LnkReferenceは対応するCONNECT、CHANGE、それがそのようなメッセージの結果であるか、そして、またはゼロからのReference番号です。
Delgrossi & Berger, Editors Experimental [Page 99] RFC 1819 ST2+ Protocol Specification August 1995
[99ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
o DetectorIPAddress is the 32-bit IP address of the host that first
generated the REFUSE message.
o DetectorIPAddressは最初にREFUSEメッセージを発生させたホストの32ビットのIPアドレスです。
o ValidTargetIPAddress is the 32-bit IP address of a host that is
properly connected as part of the stream. This parameter is only
used when recovering from stream convergence, otherwise it is set to
zero (0).
o ValidTargetIPAddressは流れの一部として適切に接されるホストの32ビットのIPアドレスです。 流れの集合から回復するときだけ、このパラメタは使用されます。さもなければ、それが(0)のゼロに合うように設定されます。
10.4.12 STATUS
10.4.12 状態
STATUS (OpCode = 12) is used to inquire about the existence of a particular stream identified by the SID. Use of STATUS is intended for collecting information from an neighbor ST agent, including general and specific stream information, and round trip time estimation. The use of this message type is described in Section 8.4.
STATUS(OpCode=12)は、SIDによって特定された特定の流れの存在について問い合わせをするのに使用されます。 STATUSの使用は情報集めのために隣人STエージェントから意図します、一般的で特定の流れの情報、および周遊旅行時間見積りを含んでいて。 このメッセージタイプの使用はセクション8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 12 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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=12| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: STATUS Control Message
図32: 状態コントロールメッセージ
o Reference contains a number assigned by the ST agent sending STATUS
for use in the replying STATUS-RESPONSE.
o 参照は返答しているSTATUS-RESPONSEにおける使用のためにSTエージェント送付STATUSによって割り当てられた数を含んでいます。
o TargetList is an optional parameter that when present indicates that
only information related to the specific targets should be relayed
in the STATUS-RESPONSE.
o TargetListはプレゼントが、情報だけが特定の目標に関連したのを示すときSTATUS-RESPONSEでリレーされるべきである任意のパラメタです。
10.4.13 STATUS-RESPONSE
10.4.13 状態応答
STATUS-RESPONSE (OpCode = 13) is the reply to a STATUS message. If the stream specified in the STATUS message is not known, the STATUS- RESPONSE will contain the specified SID but no other parameters. It will otherwise contain the current SID, FlowSpec, TargetList, and possibly Groups of the stream. It the full target list can not fit in a single message, only those targets that can be included in one
STATUS-RESPONSE(OpCode=13)はSTATUSメッセージに関する回答です。 STATUSメッセージで指定された流れが知られていないと、指定されたSIDを含んでいますが、STATUS- RESPONSEは他のどんなパラメタも含まないでしょう。 そうでなければ、それは流れの現在のSID、FlowSpec、TargetList、およびことによるとGroupsを含むでしょう。 それはリストがただ一つのメッセージで合うことができない完全な目標、1に含むことができるそれらの目標にすぎません。
Delgrossi & Berger, Editors Experimental [Page 100] RFC 1819 ST2+ Protocol Specification August 1995
[100ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
message will be included. As mentioned in Section 10.4.12, it is possible to request information on a specific target.
メッセージは含まれるでしょう。 セクション10.4.12で言及されるように、特定の目標の情報を要求するのは可能です。
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 = 13 | 0 | TotalBytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference | LnkReference = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SenderIPAddress |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | ReasonCode = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: FlowSpec :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Groups :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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=13| 0 | TotalBytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照| LnkReference=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SenderIPAddress| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム| ReasonCode=0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : FlowSpec: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : グループ: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : TargetList: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: STATUS-RESPONSE Control Message
図33: 状態応答制御メッセージ
o Reference contains a number assigned by the ST agent sending the
STATUS.
o 参照はSTATUSを送るSTエージェントによって割り当てられた数を含んでいます。
10.5 Suggested Protocol Constants
10.5 提案されたプロトコル定数
The ST Protocol uses several fields that must have specific values for the protocol to work, and also several values that an implementation must select. This section specifies the required values and suggests initial values for others. It is recommended that the latter be implemented as variables so that they may be easily changed when experience indicates better values. Eventually, they should be managed via the normal network management facilities.
STプロトコルは、プロトコルが扱う特定の値を持たなければならないいくつかの分野を使用して、また、実現が選択しなければならないいくつかの値を使用します。 このセクションは、必要な値を指定して、他のもののために初期の値を示します。 後者が経験が、より良い値を示すとき、容易にそれらを変えることができるように変数として実行されるのは、お勧めです。 結局、それらは正常なネットワークマネージメント施設を通って管理されるべきです。
ST uses IP Version Number 5.
STはIPバージョンNumber5を使用します。
When encapsulated in IP, ST uses IP Protocol Number 5.
IPで要約されると、STはIPプロトコルNumber5を使用します。
Delgrossi & Berger, Editors Experimental [Page 101] RFC 1819 ST2+ Protocol Specification August 1995
[101ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
10.5.1 SCMP Messages
10.5.1 SCMPメッセージ
1) ACCEPT 2) ACK 3) CHANGE 4) CONNECT 5) DISCONNECT 6) ERROR 7) HELLO 8) JOIN 9) JOIN-REJECT 10) NOTIFY 11) REFUSE 12) STATUS 13) STATUS-RESPONSE
1) 2を)受け入れてください。 ACK3) 変化4) 5を)接続してください。 分離6) 誤り7) こんにちは、8) 9を)接合してください。 廃棄物を接合している10) 11に)通知してください。 廃物12) 状態13) 状態応答
10.5.2 SCMP Parameters
10.5.2 SCMPパラメタ
1) FlowSpec 2) Group 3) MulticastAddress 4) Origin 5) RecordRoute 6) TargetList 7) UserData
1) FlowSpec2) グループ3) MulticastAddress4) 起源5) RecordRoute6) TargetList7) UserData
10.5.3 ReasonCode
10.5.3 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. The ReasonCode is an 8-bit field. Following values are defined:
いくつかの誤りがプロトコル処理の間、発生するかもしれません。 ただ一つの数のスペースからすべてのSTエラーコードを取ります。 現在定義された値とそれらの意味は以下のリストに提示されます。 新しいエラーコードが時々定義されるかもしれないことに注意してください。 すべての実現が優しい物腰で新法を扱うと予想されます。 未知のReasonCodeが遭遇するなら、致命的であると思われるべきです。 ReasonCodeは8ビットの分野です。 次の値は定義されます:
1 NoError No error has occurred.
2 ErrorUnknown An error not contained in this list has been
detected.
3 AccessDenied Access denied.
4 AckUnexpected An unexpected ACK was received.
5 ApplAbort The application aborted the stream abnormally.
6 ApplDisconnect The application closed the stream normally.
7 ApplRefused Applications refused requested connection or
change.
8 AuthentFailed The authentication function failed.
9 BadMcastAddress IP Multicast address is unacceptable in CONNECT
10 CantGetResrc Unable to acquire (additional) resources.
1 NoErrorいいえ誤りは発生しました。 2 このリストに含まれなかったErrorUnknown An誤りは検出されました。 否定された3AccessDenied Access。 4 AckUnexpected Anの予期していなかったACKを受け取りました。 5ApplAbort、アプリケーションは異常に流れを中止しました。 6ApplDisconnect、通常、アプリケーションは流れを終えました。 7ApplRefused Applicationsが要求された接続か変化を拒否しました。 8 認証機能が失敗したAuthentFailed。 IP Multicastが記述する9BadMcastAddressが(追加する)のリソースを取得するCONNECT10CantGetResrc Unableで容認できません。
Delgrossi & Berger, Editors Experimental [Page 102] RFC 1819 ST2+ Protocol Specification August 1995
[102ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
11 CantRelResrc Unable to release excess resources.
12 CantRecover Unable to recover failed stream.
13 CksumBadCtl Control PDU has a bad message checksum.
14 CksumBadST PDU has a bad ST Header checksum.
15 DuplicateIgn Control PDU is a duplicate and is being
acknowledged.
16 DuplicateTarget Control PDU contains a duplicate target, or an
attempt to add an existing target.
17 FlowSpecMismatch FlowSpec in request does not match
existing FlowSpec.
18 FlowSpecError An error occurred while processing the FlowSpec
19 FlowVerUnknown Control PDU has a FlowSpec Version Number that
is not supported.
20 GroupUnknown Control PDU contains an unknown Group Name.
21 InconsistGroup An inconsistency has been detected with the
streams forming a group.
22 IntfcFailure A network interface failure has been detected.
23 InvalidSender Control PDU has an invalid SenderIPAddress
field.
24 InvalidTotByt Control PDU has an invalid TotalBytes field.
25 JoinAuthFailure Join failed due to stream authorization level.
26 LnkRefUnknown Control PDU contains an unknown LnkReference.
27 NetworkFailure A network failure has been detected.
28 NoRouteToAgent Cannot find a route to an ST agent.
29 NoRouteToHost Cannot find a route to a host.
30 NoRouteToNet Cannot find a route to a network.
31 OpCodeUnknown Control PDU has an invalid OpCode field.
32 PCodeUnknown Control PDU has a parameter with an invalid
PCode.
33 ParmValueBad Control PDU contains an invalid parameter value.
34 PathConvergence Two branches of the stream join during the
CONNECT setup.
35 ProtocolUnknown Control PDU contains an unknown next-higher
layer protocol identifier.
36 RecordRouteSize RecordRoute parameter is too long to permit
message to fit a network's MTU.
37 RefUnknown Control PDU contains an unknown Reference.
38 ResponseTimeout Control message has been acknowledged but not
answered by an appropriate control message.
39 RestartLocal The local ST agent has recently restarted.
40 RestartRemote The remote ST agent has recently restarted.
41 RetransTimeout An acknowledgment has not been received after
several retransmissions.
42 RouteBack Route to next-hop through same interface as
previous-hop and is not previous-hop.
43 RouteInconsist A routing inconsistency has been detected.
44 RouteLoop A routing loop has been detected.
11 余分なリソースを発表するCantRelResrc Unable。 12 回復するCantRecover Unableは流れに失敗しました。 13 CksumBadCtl Control PDUには、悪いメッセージチェックサムがあります。 14 CksumBadST PDUには、悪いST Headerチェックサムがあります。 15 DuplicateIgn Control PDUは写しであり、承認されています。 16 DuplicateTarget Control PDUは写し目標、または既存の目標を加える試みを含んでいます。 17 要求におけるFlowSpecMismatch FlowSpecは既存のFlowSpecに合っていません。 18 FlowSpec19FlowVerUnknown Control PDUを処理すると、支持されないFlowSpecバージョンNumberは持たれていますが、FlowSpecError An誤りは発生しました。 20 GroupUnknown Control PDUは未知のGroup Nameを含んでいます。 21 流れがグループを作っていて、InconsistGroup An矛盾は検出されました。 22 IntfcFailure Aネットワーク・インターフェースの故障は検出されました。 23 InvalidSender Control PDUには、無効のSenderIPAddress分野があります。 24 InvalidTotByt Control PDUには、無効のTotalBytes分野があります。 25 JoinAuthFailure Joinは流れの認可レベルのため失敗しました。 26 LnkRefUnknown Control PDUは未知のLnkReferenceを含んでいます。 27 NetworkFailure Aネットワークの故障は検出されました。 28 NoRouteToAgent CannotはSTエージェントにとってルートを見つけます。 29 NoRouteToHost Cannotはホストにとってルートを見つけます。 30 NoRouteToNet Cannotはネットワークにおいてルートを見つけます。 31 OpCodeUnknown Control PDUには、無効のOpCode分野があります。 32 PCodeUnknown Control PDUには、無効のPCodeがあるパラメタがあります。 33 ParmValueBad Control PDUは無効のパラメタ値を含んでいます。 34 流れのPathConvergence TwoブランチはCONNECTセットアップの間、接合します。 35 ProtocolUnknown Control PDUは未知の次の、より高い層のプロトコル識別子を含んでいます。 36RecordRouteSize RecordRouteパラメタはネットワークのMTUに合うメッセージを可能にすることができないくらい長いです。 37 RefUnknown Control PDUは未知のReferenceを含んでいます。 38ResponseTimeout Controlメッセージは、適切なコントロールメッセージによって承認されますが、答えられていません。 39 地元のSTエージェントのRestartLocalは最近、再開しました。 40 リモートSTエージェントのRestartRemoteは最近、再開しました。 41 RetransTimeout An承認は数個の「再-トランスミッション」の後に受けられていません。 42 同じことを通した次のホップへのRouteBack Routeは前のホップとして連結して、前のホップではありません。 43 RouteInconsist Aルーティング矛盾は検出されました。 44RouteLoop Aルーティング輪は検出されました。
Delgrossi & Berger, Editors Experimental [Page 103] RFC 1819 ST2+ Protocol Specification August 1995
[103ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
45 SAPUnknown Control PDU contains an unknown next-higher
layer SAP (port).
46 SIDUnknown Control PDU contains an unknown SID.
47 STAgentFailure An ST agent failure has been detected.
48 STVer3Bad A received PDU is not ST Version 3.
49 StreamExists A stream with the given SID already exists.
50 StreamPreempted The stream has been preempted by one with a
higher precedence.
51 TargetExists A CONNECT was received that specified an
existing target.
52 TargetUnknown A target is not a member of the specified
stream.
53 TargetMissing A target parameter was expected and is not
included, or is empty.
54 TruncatedCtl Control PDU is shorter than expected.
55 TruncatedPDU A received ST PDU is shorter than the ST Header
indicates.
56 UserDataSize UserData parameter too large to permit a
message to fit into a network's MTU.
45 SAPUnknown Control PDUはSAP(ポート)の未知の次の、より高い層を含んでいます。 46 SIDUnknown Control PDUは未知のSIDを含んでいます。 47 STAgentFailure An STエージェントの故障は検出されました。 48 STVer3BadのA容認されたPDUはSTバージョン3ではありません。 与えられたSIDとの49StreamExists Aの流れは既に存在しています。 50StreamPreempted、流れは1時までに、より高い先行で先取りされました。 既存の目標を指定した51TargetExists AのCONNECTを受け取りました。 52TargetUnknown A目標は指定された流れのメンバーではありません。 53TargetMissing A目標パラメタは、予想されて、含まれていないか、または空になることです。 54 TruncatedCtl Control PDUは予想より短いです。 55 TruncatedPDUのA容認されたST PDUはST Headerが示すより短いです。 ネットワークのMTUに収まるメッセージを可能にすることができないくらい大きい56UserDataSize UserDataパラメタ。
10.5.4 Timeouts and Other Constants
10.5.4 タイムアウトと他の定数
SCMP uses retransmission to effect reliability and thus has several "retransmission timers". Each "timer" is modeled by an initial time interval (ToXxx), which may get updated dynamically through measurement of control traffic, and a number of times (NXxx) to retransmit a message before declaring a failure. All time intervals are in units of milliseconds. Note that the variables are described for reference purposes only, different implementations may not include the identical variables.
SCMPは効果の信頼性に「再-トランスミッション」を使用して、その結果、数個の「再送信タイマー」を持っています。 各「タイマ」は初回間隔(ToXxx)のそばでモデル化されます。(間隔は、失敗を宣言する前にメッセージを再送するためにダイナミックに測定しコントロール交通について、幾度か(NXxx)アップデートされるかもしれません)。 すべての時間間隔がユニットのミリセカンドであります。 変数が参照目的だけのために説明されることに注意してください、そして、異なった実現は同じ変数を含む必要はありません。
Value Timeout Name Meaning
------------------------------------------------------------------------
500 ToAccept Initial hop-by-hop timeout for acknowledgment of
ACCEPT
3 NAccept ACCEPT retries before failure
500 ToChange Initial hop-by-hop timeout for acknowledgment of
CHANGE
3 NChange CHANGE retries before failure
5000 ToChangeResp End-to-End CHANGE timeout for receipt of ACCEPT
or REFUSE
500 ToConnect Initial hop-by-hop timeout for acknowledgment of
CONNECT
5 NConnect CONNECT retries before failure
5000 ToConnectResp End-to-End CONNECT timeout for receipt of ACCEPT
or REFUSE from targets by origin
500 ToDisconnect Initial hop-by-hop timeout for acknowledgment of
DISCONNECT
値のタイムアウト名前意味------------------------------------------------------------------------ 500 ホップごとのCHANGE3NChange CHANGEの承認のための失敗500ToChange Initialタイムアウトが失敗の前に5000年のToChangeResp Endから終わりへのACCEPTの領収書のためのCHANGEタイムアウトかREFUSEを再試行する前にホップごとのACCEPT3NAccept ACCEPTの承認のためのToAccept Initialタイムアウトは再試行されます; 500 ホップごとのCONNECT5NConnect CONNECTの承認のためのToConnect Initialタイムアウトは失敗の前にDISCONNECTの承認のためにホップごとの起源500ToDisconnect Initialタイムアウトで目標から5000年のToConnectResp Endから終わりへのACCEPTの領収書のためのCONNECTタイムアウトかREFUSEを再試行します。
Delgrossi & Berger, Editors Experimental [Page 104] RFC 1819 ST2+ Protocol Specification August 1995
[104ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
3 NDisconnect DISCONNECT retries before failure
500 ToJoin Initial hop-by-hop timeout for acknowledgment of
JOIN
3 NJoin JOIN retries before failure
500 ToJoinReject Initial hop-by-hop timeout for acknowledgment of
JOIN-REJECT
3 NJoinReject JOIN-REJECT retries before failure
5000 ToJoinResp Timeout for receipt of CONNECT or JOIN-REJECT
from origin or intermediate hop
500 ToNotify Initial hop-by-hop timeout for acknowledgment of
NOTIFY
3 NNotify NOTIFY retries before failure
500 ToRefuse Initial hop-by-hop timeout for acknowledgment of
REFUSE
3 NRefuse REFUSE retries before failure
500 ToRetryRoute Timeout for receipt of ACCEPT or REFUSE from
targets during failure recovery
5 NRetryRoute CONNECT retries before failure
1000 ToStatusResp Timeout for receipt of STATUS-RESPONSE
3 NStatus STATUS retries before failure
10000 HelloTimerHoldDown Interval that Restarted bit must be set
after ST restart
5 HelloLossFactor Number of consecutively missed HELLO
messages before declaring link failure
2000 DefaultRecoveryTimeout Interval between successive HELLOs
to/from active neighbors
3 失敗500ToRefuse Initialがホップで跳ぶ前に失敗のCONNECTの領収書のための5000ToJoinResp TimeoutかNOTIFY3NNotify NOTIFYの承認のためのホップごとの起源か中間的ホップ500ToNotify InitialタイムアウトからのJOIN-REJECTが再試行する前にホップごとのJOIN-REJECT3NJoinReject JOIN-REJECTの承認のための失敗500ToJoinReject Initialタイムアウトが再試行される前にホップごとのJOIN3NJoin JOINの承認のための失敗500ToJoin Initialタイムアウトが再試行される前にNDisconnect DISCONNECTは再試行します; STがリンクの故障が2000DefaultRecoveryであると宣言する前に連続して逃されたHELLOメッセージの5HelloLossFactor Numberを再開した後にRestartedが噛み付いた失敗10000HelloTimerHoldDown Intervalが用意ができなければならない前に失敗のACCEPTの領収書のための500ToRetryRoute Timeoutか失敗回復5NRetryRoute CONNECTの間の目標からのREFUSEが失敗の前にSTATUS-RESPONSE3NStatus STATUS再試行の領収書のために1000ToStatusResp Timeoutを再試行する前にREFUSE3NRefuse REFUSEの承認のためのタイムアウトは再試行されます。活発な隣人からの/への連続したHELLOsの間のタイムアウトInterval
10.6 Data Notations
10.6 データ記法
The convention in the documentation of Internet Protocols is to express numbers in decimal and to picture data with the most significant octet on the left and the least significant octet on the right.
インターネットプロトコルのドキュメンテーションにおけるコンベンションは権利における左の、そして、最も重要でない八重奏で最も重要な八重奏で小数とピクチャ・データに数を表すことになっています。
The order of transmission of the header and data described in this document is resolved to the octet level. Whenever a diagram shows a group of octets, the order of transmission of those octets is the normal order in which they are read in English. For example, in the following diagram the octets are transmitted in the order they are numbered.
本書では説明されたヘッダーとデータの伝達の注文を八重奏レベルに決議します。 ダイヤグラムが八重奏のグループを示しているときはいつも、それらの八重奏の送信の注文はそれらが英語で読まれる通常のオーダーです。 例えば、以下のダイヤグラムで、八重奏はオーダーで伝えられて、それらが番号付であるということです。
Delgrossi & Berger, Editors Experimental [Page 105] RFC 1819 ST2+ Protocol Specification August 1995
[105ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 | 7 | 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 9 | 10 | 11 | 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 3 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 6 | 7 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 9 | 10 | 11 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: Transmission Order of Bytes
図34: バイトのトランスミッション命令
Whenever an octet represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labeled 0 is the most significant bit. For example, the following diagram represents the value 170 (decimal).
八重奏が数値量を表すときはいつも、ダイヤグラムで最も噛み付かれた左は、高位か最上位ビットです。 すなわち、0とラベルされたビットは最も重要なビットです。 例えば、以下のダイヤグラムは値170の(小数)を表します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1 0 1 0 1 0 1 0| +-+-+-+-+-+-+-+-+
Figure 35: Significance of Bits
図35: ビットの意味
Similarly, whenever a multi-octet field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-octet quantity is transmitted the most significant octet is transmitted first.
同様に、マルチ八重奏分野が数値量を表すときはいつも、大部分が噛み付いた全体の分野の左は最も重要なビットです。 マルチ八重奏量が伝えられるとき、最も重要な八重奏は最初に、伝えられます。
Fields whose length is fixed and fully illustrated are shown with a vertical bar (|) at the end; fixed fields whose contents are abbreviated are shown with an exclamation point (!); variable fields are shown with colons (:). Optional parameters are separated from control messages with a blank line. The order of parameters is not meaningful.
長さが固定されていて、完全に例証される分野が縦棒で示される、(|、)、終わりに。 コンテンツが簡略化されている固定分野は感嘆符(!)で示されます。 変数フィールドがコロンで示される、(:、) 任意のパラメタは空白行でコントロールメッセージと切り離されます。 パラメタの注文は重要ではありません。
11. References
11. 参照
[RFC1071] Braden, R., Borman, D., and C. Partridge,
"Computing the Internet Checksum", RFC 1071,
USC/Information Sciences Institute,
Cray Research, BBN Laboratories, September 1988.
[RFC1071] ブレーデン、R.、ボーマン、D.、およびC.ヤマウズラ、「インターネットチェックサムを計算します」、RFC1071、科学が設けるUSC/情報、クレイリサーチ、BBN研究所(1988年9月)。
[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
STD 5, RFC 1112, Stanford University, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、スタンフォード大学、1989年8月。
Delgrossi & Berger, Editors Experimental [Page 106] RFC 1819 ST2+ Protocol Specification August 1995
[106ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
[WoHD95] L. Wolf, R. G. Herrtwich, L. Delgrossi: Filtering
Multimedia Data in Reservation-based Networks,
Kommunikation in Verteilten Systemen 1995 (KiVS),
Chemnitz-Zwickau, Germany, February 1995.
[WoHD95]L.ヴォルフ、R.G.Herrtwich、L.Delgrossi: 1995年2月にVerteilten Systemen1995(KiVS)、ケムニッツ-ツビカウ(ドイツ)で予約を拠点とするネットワーク、Kommunikationのマルチメディアデータをフィルターにかけます。
[RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122,
USC/Information Sciences Institute, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、科学が設けるUSC/情報、10月1989日
[Jaco88] Jacobson, V.: Congestion Avoidance and Control, ACM
SIGCOMM-88, August 1988.
[Jaco88] ジェーコブソン、V.: 輻輳回避とコントロール、ACM SIGCOMM-88、1988年8月。
[KaPa87] Karn, P. and C. Partridge: Round Trip Time Estimation,
ACM SIGCOMM-87, August 1987.
[KaPa87] Karn、P.、およびC.ヤマウズラ: 1987年8月に旅行時間見積り、ACM SIGCOMM-87を一周させてください。
[RFC1141] Mallory, T., and A. Kullberg, "Incremental Updating
of the Internet Checksum", RFC 1141, BBN, January 1990.
[RFC1141]マロリー・ワイス症候群、T.とA.Kullberg、「インターネットチェックサムの増加のアップデート」RFC1141、BBN、1990年1月。
[RFC1363] Partridge, C., "A Proposal Flow Specification",
RFC 1363, BBN, September 1992.
[RFC1363] ヤマウズラ、C.、「提案流れ仕様」、RFC1363、BBN、1992年9月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DARPA, September 1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、DARPA、1981年9月。
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers",
STD 2, RFC 1700, USC/Information Sciences Institute,
October 1994.
[RFC1700] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[RFC1190] Topolcic C., "Internet Stream Protocol Version 2
(ST-II)", RFC 1190, CIP Working Group, October 1990.
[RFC1190]Topolcic C.、「インターネット流れのプロトコルバージョン2、(第-、II、)、」、RFC1190、CIP作業部会、10月1990
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, USC/Information Sciences Institute,
MIT, Xerox PARC, June 1994.
[RFC1633] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、科学が設けるUSC/情報、MIT、ゼロックスPARC、1994年6月。
[VoHN93] C. Vogt, R. G. Herrtwich, R. Nagarajan: HeiRAT: the
Heidelberg Resource Administration Technique - Design
Philosophy and Goals, Kommunikation In Verteilten
Systemen, Munich, Informatik Aktuell, Springer-Verlag,
Heidelberg, 1993.
[VoHN93]C.フォークト、R.G.Herrtwich、R.Nagarajan: HeiRAT: ハイデルベルグリソース政権のテクニック--Verteilten Systemen、ミュンヘンInformatik Aktuell、追出石-Verlag、ハイデルベルグ1993で哲学と目標、Kommunikationを設計してください。
[Cohe81] D. Cohen: A Network Voice Protocol NVP-II, University of
Southern California, Los Angeles, 1981.
[Cohe81]D.コーエン: ネットワーク声のプロトコルNVP-II、南カリフォルニア、ロサンゼルス1981年の大学。
[Cole81] R. Cole: PVP - A Packet Video Protocol, University of
Southern California, Los Angeles, 1981.
[Cole81]R.コール: PVP--パケットビデオプロトコル、南カリフォルニア、ロサンゼルス1981年の大学。
Delgrossi & Berger, Editors Experimental [Page 107] RFC 1819 ST2+ Protocol Specification August 1995
[107ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
[DeAl92] L. Delgrossi (Ed.) The BERKOM-II Multimedia Transport
System, Version 1, BERKOM Working Document, October,
1992.
[DeAl92]L.Delgrossi編 BERKOMがドキュメントを扱って、BERKOM-IIマルチメディアは1992年10月にシステム、バージョン1を輸送します。
[DHHS92] L. Delgrossi, C. Halstrick, R. G. Herrtwich, H.
Stuettgen: HeiTP: a Transport Protocol for ST-II,
GLOBECOM'92, Orlando (Florida), December 1992.
[DHHS92] L.Delgrossi、C.Halstrick、R.G.Herrtwich、H.Stuettgen: HeiTP: トランスポート・プロトコル、第-、II、GLOBECOM92年、オーランド(フロリダ)、12月1992
[Schu94] H. Schulzrinne: RTP: A Transport Protocol for Real-Time
Applications. Work in Progress, 1994.
[Schu94]H.Schulzrinne: RTP: リアルタイムのアプリケーションのためのトランスポート・プロトコル。 進歩、1994年に働いてください。
12. Security Considerations
12. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
13. Acknowledgments and Authors' Addresses
13. 承認と作者のアドレス
Many individuals have contributed to the work described in this memo. We thank the participants in the ST Working Group for their input, review, and constructive comments. George Mason University C3I Center for hosting an interim meeting. Murali Rajagopal for his efforts on ST2+ state machines. Special thanks are due to Steve DeJarnett, who served as working group co-chair until summer 1993.
多くの個人がこのメモで説明された仕事に貢献しました。 私たちは彼らの入力、レビュー、および建設的なコメントについてST作業部会の関係者に感謝します。 当座のミーティングを主催するためのジョージメイスン大学C3Iセンター。 ST2+州のマシンにおける彼の努力のためのMurali Rajagopal。 特別な感謝はスティーブDeJarnettのためです。(DeJarnettはワーキンググループの共同議長として1993年夏まで勤めました)。
We would also like to acknowledge the authors of [RFC1190]. All authors of [RFC1190] should be considered authors of this document since this document contains much of their text and ideas.
また、[RFC1190]の作者を承認したいと思います。 このドキュメントが彼らのテキストと考えの多くを含んでいるので、[RFC1190]のすべての作者がこのドキュメントの作者であると考えられるべきです。
Delgrossi & Berger, Editors Experimental [Page 108] RFC 1819 ST2+ Protocol Specification August 1995
[108ページ]RFC1819ST2+プロトコル仕様1995年8月に実験的なDelgrossiとバーガー、エディターズ
Louis Berger BBN Systems and Technologies 1300 North 17th Street, Suite 1200 Arlington, VA 22209
第17North通り、ルイスバーガーBBN Systemsと技術1300スイート1200アーリントン、ヴァージニア 22209
Phone: 703-284-4651 EMail: lberger@bbn.com
以下に電話をしてください。 703-284-4651 メールしてください: lberger@bbn.com
Luca Delgrossi Andersen Consulting Technology Park 449, Route des Cretes 06902 Sophia Antipolis, France
ルカDelgrossiアンダーセンコンサルティングTechnology Park449、ソフィアAntipolis、Route des Cretes06902フランス
Phone: +33.92.94.80.92 EMail: luca@andersen.fr
以下に電話をしてください。 +33.92 .94 .80 .92 メール: luca@andersen.fr
Dat Duong BBN Systems and Technologies 1300 North 17th Street, Suite 1200 Arlington, VA 22209
第17North通り、Dat Duong BBNシステムと技術1300スイート1200アーリントン、ヴァージニア 22209
Phone: 703-284-4760 EMail: dat@bbn.com
以下に電話をしてください。 703-284-4760 メールしてください: dat@bbn.com
Steve Jackowski Syzygy Communications Incorporated 269 Mt. Hermon Road Scotts Valley, CA 95066
スティーブJackowski連接コミュニケーションは269Hermon道路Scottsバレー山、カリフォルニア 95066を取り入れました。
Phone: 408-439-6834 EMail: stevej@syzygycomm.com
以下に電話をしてください。 408-439-6834 メールしてください: stevej@syzygycomm.com
Sibylle Schaller IBM ENC Broadband Multimedia Communications Vangerowstr. 18 D69020 Heidelberg, Germany
SibylleシャーラーIBM ENC Broadbandマルチメディア通信Vangerowstr。 18 D69020ハイデルベルグ(ドイツ)
Phone: +49-6221-5944553 EMail: schaller@heidelbg.ibm.com
以下に電話をしてください。 +49-6221-5944553はメールされます: schaller@heidelbg.ibm.com
Delgrossi & Berger, Editors Experimental [Page 109]
Delgrossiとバーガー、エディターズ、実験的[109ページ]
一覧
スポンサーリンク
