RFC3758 日本語訳
3758 Stream Control Transmission Protocol (SCTP) Partial ReliabilityExtension. R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad. May 2004. (Format: TXT=50999 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Stewart
Request for Comments: 3758 M. Ramalho
Category: Standards Track Cisco Systems, Inc.
Q. Xie
Motorola, Inc.
M. Tuexen
Univ. of Applied Sciences Muenster
P. Conrad
University of Delaware
May 2004
コメントを求めるワーキンググループR.スチュワートの要求をネットワークでつないでください: 3758年のM.Ramalhoカテゴリ: 規格はP.コンラッドデラウエア大学2004年5月に応用科学MuensterのシスコシステムズInc.Q.シェモトローラM.Tuexen大学を追跡します。
Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension
制御伝動のプロトコルの(SCTP)部分的な信頼性の拡大を流してください。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
This memo describes an extension to the Stream Control Transmission Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism.
このメモはSCTP終点が累積しているackポイントを前方へ動かせるべきであると同輩に合図できるStream Control Transmissionプロトコル(SCTP)に拡大について説明します。 SCTP協会の両側がこの拡大を支持するとき、上側の層のプロトコルへの部分的に信頼できるデータ通信サービスを提供するのにSCTP実現でそれを使用できます。 このメモは、INITとINIT ACKのための新しいパラメタから成るプロトコル拡大と新しいFORWARD TSN塊タイプについて説明して、このメカニズムで上側の層に提供できる部分的に信頼できるサービスに関する1つの例を提供します。
Stewart, et al. Standards Track [Page 1] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[1ページ]RFC3758SCTP
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of Protocol Extensions. . . . . . . . . . . . . 2
1.2. Overview of New Services Provided to the Upper Layer . . 3
1.3. Benefits of PR-SCTP . . . . . . . . . . . . . . . . . . 4
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Changes to support PR-SCTP . . . . . . . . . . . . . 5
3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK. . 5
3.2. Forward Cumulative TSN Chunk Definition (FORWARD TSN). . 5
3.3. Negotiation of Forward-TSN-Supported parameter . . . . . 7
3.3.1. Sending Forward-TSN-Supported param in INIT . . . 7
3.3.2. Receipt of Forward-TSN-Supported parameter in
INIT or INIT-ACK. . . . . . . . . . . . . . . . . 7
3.3.3. Receipt of Op. Error for Forward-TSN-Supported
Param . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Definition of "abandoned" in the context of PR-SCTP. . . 8
3.5. Sender Side Implementation of PR-SCTP. . . . . . . . . . 9
3.6. Receiver Side Implementation of PR-SCTP. . . . . . . . . 12
4. Services provided by PR-SCTP to the upper layer. . . . . . . . 14
4.1. PR-SCTP Service Definition for "timed reliability" . . . 15
4.2. PR-SCTP Association Establishment. . . . . . . . . . . . 16
4.3. Guidelines for defining other PR-SCTP Services . . . . . 17
4.4. Usage Notes. . . . . . . . . . . . . . . . . . . . . . . 19
5. Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 プロトコル拡大の概観。 . . . . . . . . . . . . 2 1.2. 新種業務の概観は上側の層. . 3 1.3に供給されました。 PR-SCTP.4 2の利益。 コンベンション。 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Changesについて議定書の中で述べて、PR-SCTP.53.1を支持してください。 イニットとイニットACKのための支持された前進のTSNパラメタ。 . 5 3.2. 累積しているTSN塊定義(前進のTSN)を進めてください。 . 5 3.3. Forward-TSNによって支持されたパラメタ. . . . . 7 3.3.1の交渉。 INIT. . . 7 3.3.2でForward-TSNによって支持されたparamを送ります。 INITかINIT-ACKのForward-TSNによって支持されたパラメタの領収書。 . . . . . . . . . . . . . . . . 7 3.3.3. オプアートの領収書。 支持された前進のTSN Param. . . . . . . . . . . . . . . . . . . . . . 8 3.4のための誤り。 PR-SCTPの文脈で「捨てられること」の定義。 . . 8 3.5. PR-SCTPの送付者サイド実現。 . . . . . . . . . 9 3.6. PR-SCTPの受信機サイド実現。 . . . . . . . . 12 4. PR-SCTPによって上側の層に提供されたサービス。 . . . . . . . 14 4.1. 「調節された信頼性」.154.2のためのPR-SCTP Service Definition。 PR-SCTP協会設立。 . . . . . . . . . . . 16 4.3. 他のPR-SCTP Services.174.4を定義するためのガイドライン。 使用上の注意。 . . . . . . . . . . . . . . . . . . . . . . 19 5. 変数。 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. 承認。 . . . . . . . . . . . . . . . . . . . . . . . 19 7. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 19 8. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 20 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1。 引用規格. . . . . . . . . . . . . . . . . . 20 9.2。 有益な参照. . . . . . . . . . . . . . . . . 20 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 20 11。 完全な著作権宣言文…
1. Introduction
1. 序論
This memo describes an extension to the Stream Control Transmission Protocol (SCTP) RFC 2960 [2] that allows an SCTP sender to signal to its peer that it should no longer expect to receive one or more DATA chunks.
このメモはSCTP送付者がそれがもう1つ以上のDATA塊を受けると予想するべきでない同輩に合図できるStream Control Transmissionプロトコル(SCTP)RFC2960[2]に拡大について説明します。
1.1. Overview of Protocol Extensions
1.1. プロトコル拡大の概観
The protocol extension described in this document consists of two new elements:
本書では説明されたプロトコル拡大は2つの新しい要素から成ります:
1. a single new parameter in the INIT/INIT-ACK exchange that
indicates whether the endpoint supports the extension
1. 終点が拡大を支持するかどうかを示すINIT/INIT-ACK交換におけるただ一つの新しいパラメタ
Stewart, et al. Standards Track [Page 2] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[2ページ]RFC3758SCTP
2. a single new chunk type, FORWARD TSN, that indicates that the
receiver should move its cumulative ack point forward (possibly
skipping past one or more DATA chunks that may not yet have been
received and/or acknowledged.)
2. 単独の新しい塊タイプ、受信機が累積しているackポイントを前方へ動かせるはずであるのを示すFORWARD TSN(ことによると、まだ受け取る、そして/または、承認されていないかもしれない1つ以上のDATA塊を超えてスキップします。)
1.2. Overview of New Services Provided to the Upper Layer
1.2. 上側の層に提供された新種業務の概観
When this extension is supported by both sides of an SCTP association, it can be used to provide partially reliable transport service over an SCTP association. We define partially reliable transport service as a service that allows the user to specify, on a per message basis, the rules governing how persistent the transport service should be in attempting to send the message to the receiver.
この拡大がSCTP協会の両側で後押しされているとき、部分的に信頼できる輸送サービスをSCTP協会の上に提供するのにそれを使用できます。 私たちはユーザがメッセージ基礎(メッセージを受信機に送るのを試みるのにおいて輸送サービスがどれくらいしつこいはずであるかを治める規則)あたりのaで指定できるサービスと部分的に信頼できる輸送サービスを定義します。
One example of partially reliable service is specified in this document, namely a "timed reliability" service. This service allows the service user to indicate a limit on the duration of time that the sender should try to transmit/retransmit the message (this is a natural extension of the "lifetime" parameter already in the base protocol).
部分的に信頼できるサービスに関する1つの例がすなわち、このドキュメント、「調節された信頼性」サービスで指定されます。 このサービスで、サービス利用者は送付者がメッセージを伝えようとするか、または再送しようとするべきである(これは既にベースプロトコルで、「生涯」パラメタの自然な拡大です)時間の持続時間における限界を示すことができます。
In addition to this example, we will also show that defining the semantics of a particular partially reliable service involves two elements, namely:
また、この例に加えて私たちが、特定に部分的に信頼できるサービスの意味論を定義すると2つの要素が伴われるのを示すつもりである、すなわち:
1. how the service user indicates the level of reliability required
for a particular message, and
そして1. サービス利用者がどう信頼性のレベルを示すかが特定のメッセージに必要である。
2. how the sender side implementation uses that reliability level to
determine when to give up on further retransmissions of that
message.
2. 送付者サイド実現は、いつそのメッセージの一層の「再-トランスミッション」に見切りをつけるかを決定するのにどうその信頼性レベルを使用するか。
Note that other than the fact that the FORWARD-TSN chunk is required, neither of these two elements impacts the "on-the-wire" protocol; only the API and the sender side implementation are affected by the way in which the service is defined to the upper layer. Therefore, in principle, it is feasible to implement many varieties of partially reliable services in a particular SCTP implementation without changing the on-the-wire protocol. Also, the SCTP receiver does not necessarily need to know which semantics of partially reliable service are being used by the sender, since the receiver's only role is to correctly interpret FORWARD TSN chunks, thereby skipping past messages that the sender has decided to no longer transmit (or retransmit).
FORWARD-TSN塊が必要であるという事実以外に、これらの2つの要素のどちらも「ワイヤ」のプロトコルに影響を与えないことに注意してください。 APIと送付者サイド実現だけがサービスが上側の層と定義される方法で影響を受けます。 したがって、原則として、ワイヤの上のプロトコルを変えないで特定のSCTP実現における、多くの種類の部分的に信頼できるサービスを実行するのは可能です。 また、SCTP受信機は、必ず部分的に信頼できるサービスのどの意味論が送付者によって使用されているかを知る必要があるというわけではありません、受信機の唯一の役割が正しくその結果、FORWARD TSN塊、送付者が、もう伝わらないと決めたという(再送してください)メッセージを超えたスキップを解釈することであるので。
Nevertheless, it is recommended that a limited number of standard definitions of partially reliable services be standardized by the IETF so that the designers of IETF application layer protocols can
それにもかかわらず、部分的に信頼できるサービスの限られた数の標準定義がIETF応用層プロトコルのデザイナーが標準化できるようにIETFによって標準化されるのは、お勧めです。
Stewart, et al. Standards Track [Page 3] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[3ページ]RFC3758SCTP
match the requirements of their upper layer protocols to standard service definitions provided by a particular SCTP implementation. One such definition, "timed reliability", is included in this document. Given the extensions proposed in this document, other definitions may be standardized as the need arises without further changes to the on-the-wire protocol.
特定のSCTP実現で提供された標準のサービス定義にそれらの上側の層のプロトコルの要件を合わせてください。 「調節された信頼性」というそのような定義の1つは本書では含まれています。 本書では提案された拡大を考えて、他の定義は必要に応じてワイヤの上のプロトコルへの一層の変化なしで標準化されるかもしれません。
1.3. Benefits of PR-SCTP
1.3. PR-SCTPの利益
Hereafter, we use the notation "Partial Reliable Stream Control Transmission Protocol (PR-SCTP)" to refer to the SCTP protocol, extended as defined in this document.
今後、私たちは、本書では定義されるように広げられたSCTPプロトコルを示すのに記法「部分的な信頼できる流れの制御伝動プロトコル(PR-SCTP)」を使用します。
The following are some of the advantages for integrating partially reliable data service into SCTP, i.e., benefits of PR-SCTP:
↓これはすなわち、SCTP、PR-SCTPの利益と確実な資料サービスを部分的に統合するための利点のいくつかです:
1. Some application layer protocols may benefit from being able to
use a single SCTP association to carry both reliable content, --
such as text pages, billing and accounting information, setup
signaling -- and unreliable content, e.g., state that is highly
sensitive to timeliness, where generating a new packet is more
advantageous than transmitting an old one [3].
1. いくつかの応用層プロトコルがテキストページや支払いや課金情報、セットアップシグナリングなどの信頼できる内容とあてにならない内容、例えば、タイムリーに非常に敏感な状態の両方を運ぶ単一のSCTP協会を使用できることから利益を得るかもしれません。(そこでは、新しいパケットを発生させるのが古いもの[3]を伝えるより有利です)。
2. Partially reliable data traffic carried by PR-SCTP will enjoy the
same communication failure detection and protection capabilities
as the normal reliable SCTP data traffic does. This includes the
ability to quickly detect a failed destination address, fail-over
to an alternate destination address, and be notified if the data
receiver becomes unreachable.
2. PR-SCTPによって運ばれた部分的に信頼できるデータ通信量はデータ通信量がする正常な信頼できるSCTPとして同じ通信障害検出と保護能力を楽しむでしょう。 データ受信装置が手が届かなくなるなら、これはすぐに失敗した送付先アドレス、交互の送付先アドレスへのフェイルオーバーを検出している、通知されるべき能力を含んでいます。
3. In addition to providing unordered, unreliable data transfer as
UDP does, PR-SCTP can provide ordered, unreliable data transfer
service.
3. UDPとしての順不同の、頼り無いデータ転送がする提供に加えて、PR-SCTPは注文されて、頼り無いデータ転送サービスを提供できます。
4. PR-SCTP employs the same congestion control and congestion
avoidance for all data traffic, whether reliable or partially
reliable - this is very desirable since SCTP enforces TCP-
friendliness (unlike UDP.)
4. PR-SCTPはすべてのデータ通信量のための同じ輻輳制御と輻輳回避を使います、信頼できるか、または部分的に信頼できることにかかわらず--SCTPがTCP友情を実施するので、これは非常に望ましいです。(UDPと異なった。)
5. Because of the chunk bundling function of SCTP, reliable and
unreliable messages can be multiplexed over a single PR-SCTP
association. Therefore, the number of IP datagrams (and hence the
network overhead) can be reduced instead of having to send these
different types of data using separate protocols. Additionally,
this multiplexing allows for port savings versus using different
ports for reliable and unreliable connections.
5. SCTPの塊バンドリング機能のために、単一のPR-SCTP協会の上に信頼できてあてにならないメッセージを多重送信できます。 したがって、別々のプロトコルを使用することでこれらの異なったタイプに関するデータを送らなければならないことの代わりにIPデータグラム(そして、したがって、ネットワークオーバーヘッド)の数は減少できます。 さらに、信頼できて頼り無い接続に異なったポートを使用することに対してこのマルチプレクシングはポート貯蓄を考慮します。
Stewart, et al. Standards Track [Page 4] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[4ページ]RFC3758SCTP
2. Conventions
2. コンベンション
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [1].
キーワードが解釈しなければならない、本書では現れるとき、BCP14(RFC2119[1])で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりません。
Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are governed by the rules in Section 1.6 of RFC 2960 [2].
Transport Sequence民数記(TSNs)に関する比較と演算はRFC2960[2]のセクション1.6の規則で支配されます。
3. Protocol Changes to support PR-SCTP
3. Changesについて議定書の中で述べて、PR-SCTPを支持してください。
3.1. Forward-TSN-Supported Parameter For INIT and INIT ACK
3.1. イニットとイニットACKのための支持された前進のTSNパラメタ
The following new OPTIONAL parameter is added to the INIT and INIT ACK chunks.
以下の新しいOPTIONALパラメタはINITとINIT ACK塊に加えられます。
Parameter Name Status Type Value ------------------------------------------------------------- Forward-TSN-Supported OPTIONAL 49152 (0xC000)
パラメタ名前状態タイプ価値------------------------------------------------------------- 支持された前進のTSNの任意の49152(0xC000)
At the initialization of the association, the sender of the INIT or INIT ACK chunk MAY include this OPTIONAL parameter to inform its peer that it is able to support the Forward TSN chunk (see Section 3.3 for further details). The format of this parameter is defined as follows:
協会の初期化のときに、INITかINIT ACK塊の送付者は、Forward TSN塊を支持できることを(さらに詳しい明細についてはセクション3.3を見てください)同輩に知らせるためにこのOPTIONALパラメタを入れるかもしれません。 このパラメタの書式は以下の通り定義されます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 49152 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメータの型=49152| パラメタの長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bit u_int
以下をタイプしてください。 16ビットのu_int
49152, indicating Forward-TSN-Supported parameter
49152 Forward-TSNによって支持されたパラメタを示すこと。
Length: 16 bit u_int
長さ: 16ビットのu_int
Indicates the size of the parameter, i.e., 4.
すなわち、パラメタ、4のサイズを示します。
3.2 Forward Cumulative TSN Chunk Definition (FORWARD TSN)
3.2 前進の累積しているTSN塊定義(前進のTSN)
The following new chunk type is defined:
以下の新しい塊タイプは定義されます:
Chunk Type Chunk Name ------------------------------------------------------ 192 (0xC0) Forward Cumulative TSN (FORWARD TSN)
塊タイプ塊名------------------------------------------------------ 192 (0xC0)前進の累積しているTSN(前進のTSN)
Stewart, et al. Standards Track [Page 5] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[5ページ]RFC3758SCTP
This chunk shall be used by the data sender to inform the data receiver to adjust its cumulative received TSN point forward because some missing TSNs are associated with data chunks that SHOULD NOT be transmitted or retransmitted by the sender.
この塊は、SHOULD NOTが送付者によって伝えられるか、または再送されることをいくつかのなくなったTSNsがデータ塊に関連しているので前方に累積している容認されたTSNポイントを調整するデータ受信装置に知らせるのにデータ送付者によって使用されるものとします。
Forward Cumulative TSN chunk has the following format:
前進のCumulative TSN塊には、以下の形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 192 | Flags = 0x00 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Cumulative TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-1 | Stream Sequence-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream-N | Stream Sequence-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =192をタイプしてください。| 旗=0×00| 長さは変数と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 新しい累積しているTSN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れ-1| 流れの系列-1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 流れ-N| 流れの系列-N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags:
塊旗:
Set to all zeros on transmit and ignored on receipt.
すべてのゼロにオンなセットは、領収書の上で伝えて、無視しました。
New Cumulative TSN: 32 bit u_int
新しい累積しているTSN: 32ビットのu_int
This indicates the new cumulative TSN to the data receiver. Upon
the reception of this value, the data receiver MUST consider
any missing TSNs earlier than or equal to this value as received,
and stop reporting them as gaps in any subsequent SACKs.
これは新しい累積しているTSNをデータ受信装置に示します。この価値のレセプションでは、データ受信装置は、受け取るようにどんななくなったTSNsもこの値と、より初期であるか、または等しいと考えて、どんなその後のSACKsのギャップとしても彼らを報告するのを止めなければなりません。
Stream-N: 16 bit u_int
流れ-N: 16ビットのu_int
This field holds a stream number that was skipped by this
FWD-TSN.
この分野はこのFWD-TSNによってスキップされた流れの番号を保持します。
Stream Sequence-N: 16 bit u_int
系列-Nを流してください: 16ビットのu_int
This field holds the sequence number associated with the stream
that was skipped. The stream sequence field holds the largest
stream sequence number in this stream being skipped. The receiver
of the FWD-TSN's can use the Stream-N and Stream Sequence-N fields
to enable delivery of any stranded TSN's that remain on the stream
re-ordering queues. This field MUST NOT report TSN's corresponding
to DATA chunks that are marked as unordered. For ordered DATA
chunks this field MUST be filled in.
この分野はサボられた流れに関連している一連番号を保持します。 流れの系列分野はサボられるこの流れで最も大きい流れの一連番号を保持します。 FWD-TSNの受信機は、流れの再注文待ち行列に残っている撚り合わされているTSNのどんなものの配送も可能にするのにStream-NとStream Sequence-N分野を使用できます。 この分野は、TSNが順不同のマークされるDATA塊に対応すると報告してはいけません。 命令されたDATA塊において、この分野に記入しなければなりません。
Stewart, et al. Standards Track [Page 6] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[6ページ]RFC3758SCTP
3.3. Negotiation of Forward-TSN-Supported parameter
3.3. Forward-TSNによって支持されたパラメタの交渉
3.3.1. Sending Forward-TSN-Supported param in INIT
3.3.1. INITでForward-TSNによって支持されたparamを送ります。
If an SCTP endpoint supports the FORWARD TSN chunk, then any time it sends an INIT during association establishment, it MAY include the Forward-TSN-supported parameter in the INIT chunk to indicate this fact to its peer.
SCTP終点がFORWARD TSN塊を支持するなら、協会設立の間、INITを送る何時でも、それは、この事実を同輩に示すためにINIT塊にForward-TSNによって支持されたパラメタを含むかもしれません。
Note that if the endpoint chooses NOT to include the parameter, then at no time during the life of the association can it send or process a FORWARD TSN. It MUST instead act as if it does NOT support the FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any FORWARD TSN.
終点がパラメタを含むようにNOTを選ぶなら、いかなる時も協会の人生の間FORWARD TSNを送ることができないか、処理できないことに注意してください。 それは代わりにまるでFORWARD TSN塊を支持しないかのように行動しなければなりません、どんなFORWARD TSNを受け取り次第ERRORを同輩に返して。
3.3.2. Receipt of Forward-TSN-Supported parameter in INIT or INIT-ACK
3.3.2. INITかINIT-ACKのForward-TSNによって支持されたパラメタの領収書
When a receiver of an INIT detects a Forward-TSN-Supported parameter and does not support the Forward-TSN chunk type, the receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960 [2].
INITの受信機がForward-TSNによって支持されたパラメタを検出して、Forward-TSN塊タイプを支持しないとき、受信機は.3セクション3.3RFC2960[2]で定義された規則に従わなければなりません。
When a receiver of an INIT-ACK detects a Forward-TSN-Supported parameter and it does not support the Forward-TSN chunk type, the receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960 [2].
INIT-ACKの受信機がForward-TSNによって支持されたパラメタを検出して、Forward-TSN塊タイプを支持しないとき、受信機は.3セクション3.3RFC2960[2]で定義された規則に従わなければなりません。
When a receiver of an INIT detects a Forward-TSN-Supported parameter and it does support the Forward-TSN chunk type, the receiver MAY respond with a Forward-TSN-supported parameter in the INIT-ACK chunk.
INITの受信機がForward-TSNによって支持されたパラメタを検出して、Forward-TSN塊タイプを支持すると、受信機はINIT-ACK塊におけるForward-TSNによって支持されたパラメタで応じるかもしれません。
Note that if the endpoint chooses NOT to include the parameter, then at no time during the life of the association can it send or process a FORWARD TSN. It MUST instead act as if it does NOT support the FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any FORWARD TSN.
終点がパラメタを含むようにNOTを選ぶなら、いかなる時も協会の人生の間FORWARD TSNを送ることができないか、処理できないことに注意してください。 それは代わりにまるでFORWARD TSN塊を支持しないかのように行動しなければなりません、どんなFORWARD TSNを受け取り次第ERRORを同輩に返して。
When an endpoint that supports the FORWARD TSN chunk receives an INIT that does not contain the Forward-TSN-Supported Parameter, that endpoint:
FORWARD TSN塊を支持する終点がINITを受けるとき、それはForward-TSNによって支持されたParameterを含んでいません、その終点:
o MAY include the Forward-TSN-Supported parameter in the INIT-ACK,
o SHOULD record the fact that the peer does not support the FORWARD
TSN chunk,
o MUST NOT send a FORWARD TSN chunk at any time during the
associations life,
o SHOULD inform the upper layer if the upper layer has requested
such notification.
o いつでも協会人生の間、INIT-ACKのForward-TSNによって支持されたパラメタ、同輩がFORWARD TSN塊を支持しないという事実、oがFORWARD TSN塊を送ってはいけないというo SHOULD記録を含むかもしれません、と上側の層がそのような通知を要求したなら、o SHOULDは上側の層を知らせます。
Stewart, et al. Standards Track [Page 7] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[7ページ]RFC3758SCTP
3.3.3. Receipt of Op. Error for Forward-TSN-Supported Param
3.3.3. オプアートの領収書。 支持された前進のTSN Paramのための誤り
When an SCTP endpoint that desires to use the FORWARD TSN chunk feature for partially reliable data transfer receives an operational error from the remote endpoint (either bundled with the COOKIE or as an unrecognized parameter in the INIT-ACK), indicating that the remote endpoint does not recognize the Forward-TSN-Supported parameter, the local endpoint SHOULD inform its upper layer of the remote endpoint's inability to support partially reliable data transfer.
SCTP終点であるときに、部分的に信頼できるデータにFORWARD TSN塊機能を使用する願望が移されるのが遠く離れた終点(COOKIEと共に束ねられるか、INIT-ACKの認識されていないパラメタのどちらかとしての)から誤操作を受けます、遠く離れた終点がForward-TSNによって支持されたパラメタを認識しないのを示します、と地方の終点SHOULDは遠く離れた終点のものが確実な資料転送を部分的に支持できない上側の層のことを知らせます。
The local endpoint may then choose to either:
次に、地方の終点はどちらかに選ばれるかもしれません:
1) end the initiation process (in cases where the initiation process
has already ended, the endpoint may need to send an ABORT) in
consideration of the peer's inability to supply the requested
features for the new association, or
または1) 開始過程(開始過程が既に終わった場合では、終点は、ABORTを送る必要があるかもしれない)が同輩のものが新連合のための要求された特徴を提供できないことを考慮して終わりになってください。
2) continue the initiation process (in cases where the initiation
process has already completed, the endpoint MUST just mark the
association as not supporting partial reliability), but with the
understanding that partially reliable data transmission is not
supported. In this case, the endpoint receiving the operational
error SHOULD note that the FORWARD TSN chunk is not supported, and
MUST NOT transmit a FORWARD TSN chunk at any time during the life
of the association.
2) 開始過程(過程が既に終了した開始、終点がそうしなければならない場合では、まさしくどんなサポートの部分的な信頼性としても協会をマークしない)を続けていますが部分的に信頼できるデータ送信が支持されないという条件で。 この場合、いつでも協会の人生の間、FORWARD TSN塊を支持して、FORWARD TSN塊が誤操作SHOULD注意ですが、受信される終点は伝えなければなりません。
3.4. Definition of "abandoned" in the context of PR-SCTP
3.4. PR-SCTPの文脈で「捨てられること」の定義
At some point, a sending PR-SCTP implementation MAY determine that a particular data chunk SHOULD NOT be transmitted or retransmitted further, in accordance with the rules governing some particular PR- SCTP service definition (such as the definition of "timed reliability" in Section 4.1.) For purposes of this document, we define the term "abandoned" to refer to any data chunk about which the SCTP sender has made this determination.
何らかのポイントでは、送付PR-SCTP実現は、特定のデータ塊SHOULD NOTが、より遠くに伝えられるか、または再送されることを決定するかもしれません、何らかの特定のPR SCTPサービス定義(セクション4.1との「調節された信頼性」の定義などの)を治める規則に従って このドキュメントの目的のために、私たちはSCTP送付者がこの決断をしたどんなデータ塊についても言及するために「捨てられる」という用語を定義します。
Each PR-SCTP service defines the rules for determining when a TSN is "abandoned", and accordingly, the rules that govern how, whether, and when to "abandon" a TSN may vary from one service definition to another. However, the rules governing the actions taken when a TSN is "abandoned" do NOT vary between service definitions; these rules are included in Section 3.5.
それぞれのPR-SCTPサービスはTSNがいつ「捨てられるか」を決定するために規則を決めます、そして、それに従って、どのようにを治める規則であり、捨てていつTSNを「捨てるか」は1つのサービス定義から別のものに異なるかもしれません。 しかしながら、TSNが「捨てられる」とき取られた行動を治める規則はサービス定義の間で異なりません。 これらの規則はセクション3.5に含まれています。
Stewart, et al. Standards Track [Page 8] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[8ページ]RFC3758SCTP
3.5. Sender Side Implementation of PR-SCTP
3.5. PR-SCTPの送付者サイド実現
The sender side implementation of PR-SCTP is identical to that of the base SCTP protocol, except for:
以下を除いて、PR-SCTPの送付者サイド実現はベースSCTPプロトコルのものと同じです。
o actions a sending side PR-SCTP implementation must take when a TSN
is "abandoned" (as per the rules of whatever PR-SCTP service
definition is in effect)
o special actions that a PR-SCTP implementation must take upon
receipt of SACK
o rules governing the generation of FORWARD TSN chunks.
o TSNがあるとき、送付サイドPR-SCTP実現が取らなければならない行動はPR-SCTP実現がFORWARD TSN塊の世代を決定するSACK o規則を受け取り次第取らなければならないo特別な行動を「捨てた」(いかなる有効なPR-SCTPサービス定義の規則に従って)。
In detail, these exceptions are as follows:
詳細に、これらの例外は以下の通りです:
A1) The sender maintains an "Advanced.Peer.Ack.Point" for each peer
to track a theoretical cumulative TSN point of the peer (Note,
this is a _new_ protocol variable and its value is NOT
necessarily the same as the SCTP "Cumulative TSN Ack Point" as
defined in Section 1.4 of RFC 2960 [2], and as discussed
throughout that document.)
A1) 各同輩が同輩の理論上の累積しているTSNポイントを追跡するように、送付者は"Advanced.Peer.Ack.Point"を維持します。(RFC2960[2]、そのドキュメント中で議論するようにこれが_の新しい_プロトコル変数であり、値が必ずセクション1.4で定義されるSCTP「累積しているTSN Ackポイント」と同じであるというわけではないことに注意してください。)
A2) From time to time, as governed by the rules of a particular PR-
SCTP service definition (see Section 4), the SCTP data sender may
make a determination that a particular data chunk that has
already been assigned a TSN SHOULD be "abandoned".
A2) SCTPデータ送付者は特定のPR SCTPサービス定義(セクション4を見る)の規則で治められるように時々、TSN SHOULDが既に割り当てられた特定のデータ塊がある決断を「捨てること」のようにするかもしれません。
When a data chunk is "abandoned", the sender MUST treat the data
chunk as being finally acked and no longer outstanding.
データ塊が「捨てられる」とき、送付者は最終的にackedされていてもう傑出していないとしてデータ塊を扱わなければなりません。
The sender MUST NOT credit an "abandoned" data chunk to the
partial_bytes_acked as defined in Section 7.2.2 of RFC 2960 [2],
and MUST NOT advance the cwnd based on this "abandoned" data
chunk.
送付者は、_が.2セクション7.2RFC2960[2]で定義されるようにackedした部分的な_バイトへ「捨てられた」データ塊を掛けてはいけなくて、この「捨てられた」データ塊に基づくcwndを進めてはいけません。
A3) When a TSN is "abandoned", if it is part of a fragmented message,
all other TSN's within that fragmented message MUST be abandoned
at the same time.
A3) TSNがそれが断片化しているメッセージの一部であるなら同時に「捨てられる」とき、その断片化しているメッセージの中のTSNの他のすべてのものを捨てなければなりません。
A4) Whenever the data sender receives a SACK from the data receiver,
it MUST first process the SACK using the normal procedures as
defined in Section 6.2.1 of RFC 2960 [2].
A4) データ送付者がデータ受信装置からSACKを受け取るときはいつも、.1セクション6.2RFC2960[2]で定義されるように正常な手順を用いて、それは最初に、SACKを処理しなければなりません。
Stewart, et al. Standards Track [Page 9] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[9ページ]RFC3758SCTP
The data sender MUST then perform the following additional steps:
次に、データ送付者は以下の追加ステップを実行しなければなりません:
C1) Let SackCumAck be the Cumulative TSN ACK carried in the
received SACK.
C1) SackCumAckが容認されたSACKで運ばれたCumulative TSN ACKであることをさせてください。
If (Advanced.Peer.Ack.Point < SackCumAck), then update
Advanced.Peer.Ack.Point to be equal to SackCumAck.
(Advanced.Peer.Ack.Point<SackCumAck)であるなら、SackCumAckと等しくなるようにAdvanced.Peer.Ack.Pointをアップデートしてください。
C2) Try to further advance the "Advanced.Peer.Ack.Point" locally,
that is, to move "Advanced.Peer.Ack.Point" up as long as the
chunk next in the out-queue space is marked as "abandoned",
as shown in the following example:
C2) 出ている待ち行列スペースの次の塊が「捨てられる」ように著しい限り、さらにすなわち、局所的で、移動"Advanced.Peer.Ack.Point"に"Advanced.Peer.Ack.Point"を進めるようにしてください、以下の例に示されるように:
Assuming that a SACK arrived with the Cumulative TSN ACK =
102 and the Advanced.Peer.Ack.Point is updated to this
value:
SACKがCumulative TSN ACK=102とAdvanced.Peer.Ack.Pointと共に到着したと仮定するのをこの値にアップデートします:
out-queue at the end of ==> out-queue after Adv.Ack.Point
normal SACK processing local advancement
地方の前進を処理する後に出ている待ち行列の=>の端の出ている待ち行列のAdv.Ack.Point正常なSACK
... ...
Adv.Ack.Pt-> 102 acked 102 acked
103 abandoned 103 abandoned
104 abandoned Adv.Ack.P-> 104 abandoned
105 105
106 acked 106 acked
... ...
... ... ackedされて、102は捨てられた103をackedしました。副詞Ack.Pt>102、103 104が捨てた捨てられた104捨てられたAdv.Ack.P->105 105 106はackedされた106をackedしました… ...
In this example, the data sender successfully advanced the
"Advanced.Peer.Ack.Point" from 102 to 104 locally.
この例では、データ送付者は102〜104まで局所的に首尾よく"Advanced.Peer.Ack.Point"を進めました。
C3) If, after step C1 and C2, the "Advanced.Peer.Ack.Point" is
greater than the Cumulative TSN ACK carried in the received
SACK, the data sender MUST send the data receiver a FORWARD
TSN chunk containing the latest value of the
"Advanced.Peer.Ack.Point". Note that the sender MAY delay
the sending of a FORWARD TSN as defined in rule F2 below.
IMPLEMENTATION NOTE: It is an implementation decision as to
which destination address it is to be sent to, the only
restriction being that the address MUST be one that is
CONFIRMED.
C3) "Advanced.Peer.Ack.Point"がステップC1とC2の後にCumulative TSN ACKが容認されたSACKで運んだより大きいなら、データ送付者は"Advanced.Peer.Ack.Point"の最新の値を含むFORWARD TSN塊をデータ受信装置に送らなければなりません。 送付者が以下の規則F2で定義されるようにFORWARD TSNの発信を遅らせるかもしれないことに注意してください。 実現注意: それはどの送付先アドレスに送られることになっているかへの実現決定です、唯一の制限がアドレスがCONFIRMEDであるものであるに違いないということであり。
C4) For each "abandoned" TSN, the sender of the FORWARD TSN MUST
determine if the chunk has a valid stream and sequence number
(i.e., it was ordered). If the chunk has a valid stream and
sequence number, the sender MUST include the stream and
sequence number in the FORWARD TSN. This information will
enable the receiver to easily find any stranded TSN's waiting
C4) それぞれの「捨てられた」TSNに関しては、FORWARD TSN MUSTの送付者は、塊で有効な流れと一連番号があるかどうかと(すなわち、それを注文しました)決心しています。 塊に有効な流れと一連番号があるなら、送付者はFORWARD TSNで流れと一連番号を入れなければなりません。 この情報は、受信機が容易にどんな撚り合わされているTSNの待ちにも当たるのを可能にするでしょう。
Stewart, et al. Standards Track [Page 10] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[10ページ]RFC3758SCTP
on stream reorder queues. Each stream SHOULD only be
reported once; this means that if multiple abandoned messages
occur in the same stream, then only the highest abandoned
stream sequence number is reported. If the total size of the
FORWARD TSN does NOT fit in a single MTU, then the sender of
the FORWARD TSN SHOULD lower the Advanced.Peer.Ack.Point to
the last TSN that will fit in a single MTU.
流れの追加注文待ち行列に関して。 それぞれがSHOULDを流します。一度単に報告されてください。 これは、複数の捨てられたメッセージが同じ流れで現れるなら最も高い捨てられた流れの一連番号だけが報告されることを意味します。 FORWARD TSNの総サイズが独身のMTUをうまくはめ込まないなら、FORWARD TSN SHOULDの送付者は独身のMTUをうまくはめ込む最後のTSNにAdvanced.Peer.Ack.Pointを下ろします。
C5) If a FORWARD TSN is sent, the sender MUST assure that at
least one T3-rtx timer is running. IMPLEMENTATION NOTE: Any
destination's timer may be used for the purposes of rule C5.
C5) FORWARD TSNを送るなら、送付者は、少なくとも1個のT3-rtxタイマが動いていることを保証しなければなりません。 実現注意: どんな目的地のタイマも規則C5の目的に使用されるかもしれません。
A5) Any time the T3-rtx timer expires, on any destination, the sender
SHOULD try to advance the "Advanced.Peer.Ack.Point" by following
the procedures outlined in C2 - C5.
A5) いつでも、T3-rtxタイマは期限が切れます、どんな目的地でも送付者SHOULDはC2に概説された手順に従うことで"Advanced.Peer.Ack.Point"を進めようとします--C5。
The following additional rules govern the generation of FORWARD TSN chunks:
以下の付則はFORWARD TSN塊の世代を決定します:
F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other
than circumstances described in this document.
F1) 終点は本書では説明された事情以外のどんな目的にもFORWARD TSNを使用してはいけません。
F2) The data sender SHOULD always attempt to bundle an outgoing
FORWARD TSN with outbound DATA chunks for efficiency.
F2) データ送付者SHOULDは、いつも効率のために外国行きのDATA塊で出発しているFORWARD TSNを束ねるのを試みます。
A sender MAY even choose to delay the sending of the FORWARD TSN
in the hope of bundling it with an outbound DATA chunk.
送付者は、外国行きのDATA塊でそれを束ねることを希望してFORWARD TSNの発信を遅らせるのを選びさえするかもしれません。
IMPLEMENTATION NOTE: An implementation may wish to limit the
number of duplicate FORWARD TSN chunks it sends by either only
sending a duplicate FORWARD TSN every other SACK or waiting a
full RTT before sending a duplicate FORWARD TSN.
実現注意: 実現は、写しFORWARD TSNを送る前に他のあらゆるSACKを写しFORWARD TSNに送るか、または完全なRTTを待ちに送るだけでありながら、それがどちらかで送る写しFORWARD TSN塊の数を制限したがっているかもしれません。
IMPLEMENTATION NOTE: An implementation may allow the maximum
delay for generating a FORWARD TSN to be configured either
statically or dynamically in order to meet the specific timing
requirements of the protocol being carried, but see the next
rule:
実現注意: 実現は運ばれるプロトコルの特定のタイミング必要条件を満たすために静的かダイナミックに構成されるためにFORWARD TSNを発生させるための最大の遅れを許容するかもしれませんが、次の規則を見てください:
F3) Any delay applied to the sending of FORWARD TSN chunk SHOULD NOT
exceed 200ms and MUST NOT exceed 500ms. In other words, an
implementation MAY lower this value below 500ms but MUST NOT
raise it above 500ms.
F3) FORWARD TSN塊SHOULD NOTの発信に適用されたどんな遅れも200msを超えていて、500ms. In他の単語は超えてはいけなくて、実現は、この値を500msの下に下げるかもしれませんが、500ms.の上でそれを上げてはいけません。
NOTE: Delaying the sending of FORWARD TSN chunks may cause delays
in the receiver's ability to deliver other data being held at the
receiver for re-ordering. The values of 200ms and 500ms match
以下に注意してください。 FORWARD TSN塊の発信を遅らせるのは再注文のために受信機に保持される他のデータを送る受信機の性能で遅れをきたすかもしれません。 200msと500msの値は合っています。
Stewart, et al. Standards Track [Page 11] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[11ページ]RFC3758SCTP
the required values for the delayed acknowledgement in RFC 2960
[2] since delaying a FORWARD TSN has the same consequences but in
the reverse direction.
以来FORWARD TSNを遅らせると同じ結果にもかかわらず、反対の方向に持たれているRFC2960[2]での遅れた承認のための必要な値。
F4) The detection criterion for out-of-order SACKs MUST remain the
same as stated in RFC 2960, that is, a SACK is only considered
out-of-order if the Cumulative TSN ACK carried in the SACK is
earlier than that of the previous received SACK (i.e., the
comparison MUST NOT be made against "Advanced.Peer.Ack.Point").
F4) 故障しているSACKsのための検出評価基準はRFC2960に述べられているように同じままで残らなければなりません、すなわち、SACKはそれより早くSACKで運ばれたCumulative TSN ACKが前の容認されたSACKのもの("Advanced.Peer.Ack.Point"に対してすなわち、比較をしてはいけない)である場合にだけ故障していると考えられます。
F5) If the decision to "abandon" a chunk is made, no matter how such
a decision is made, the appropriate congestion adjustment MUST be
made as specified in RFC 2960 if the chunk would have been marked
for retransmission later (e.g., either by T3-Timeout or by Fast
Retransmit).
F5) 決定であるなら、塊が塊がそうするならそのような決定がどのように人工であり、指定されるとして適切な混雑調整をしなければならないというRFC2960のことであってもされる「放棄」に後で(例えば、T3-タイムアウトかFast Retransmit)「再-トランスミッション」のためにマークされてください、そうした。
3.6. Receiver Side Implementation of PR-SCTP
3.6. PR-SCTPの受信機サイド実現
The receiver side implementation of PR-SCTP at an SCTP endpoint A is capable of supporting any PR-SCTP service definition used by the sender at endpoint B, even if that service definition is not supported by the sending side functionality of host A. All that is necessary is that the receiving side correctly handle the Forward- TSN-Supported parameter as specified in Section 3.3, and correctly handle the receipt of FORWARD TSN chunks as specified below.
SCTP終点AのPR-SCTPの受信機サイド実現は以下で指定されるように必要であるのが、受信側が正しくセクション3.3の指定されるとしてのForward- TSNによって支持されたパラメタを扱って、正しくFORWARD TSN塊の領収書を扱うということであるということであるホストA.Allの送付サイドの機能性によって支持されないで、定義がそのサービス定義がそうであっても終点Bで送付者で利用したどんなPR-SCTPサービスも支持できます。
DATA chunk arrival at a PR-SCTP receiver proceeds exactly as for DATA chunk arrival at a base protocol SCTP receiver---that is, the receiver MUST perform the same TSN handling, including duplicate detection, gap detection, SACK generation, cumulative TSN advancement, etc. as defined in RFC 2960 [2]---with the following exceptions and additions.
PR-SCTP受信機へのDATA塊到着はちょうどベースプロトコルSCTP受信機へのDATA塊到着のように続きます。---すなわち、受信機は同じTSN取り扱いを実行しなければなりません、写し検出、すき間検出、SACK世代、RFC2960[2]で定義される累積しているTSN前進などを含んでいて---以下の例外と追加で。
When a FORWARD TSN chunk arrives, the data receiver MUST first update its cumulative TSN point to the value carried in the FORWARD TSN chunk, and then MUST further advance its cumulative TSN point locally if possible, as shown by the following example:
FORWARD TSN塊が到着すると、データ受信装置は、最初にFORWARD TSN塊で運ばれた値に累積しているTSNポイントをアップデートしなければならなくて、できれば、さらに局所的に累積しているTSNポイントを進めなければなりません、以下の例によって示されるように:
Assuming that the new cumulative TSN carried in the arrived
FORWARD TSN is 103:
新しい累積しているTSNが到着したFORWARD TSNで運んだと仮定するのは、103です:
in-queue before processing in-queue after processing
the FORWARD TSN ==> the FORWARD TSN and further
advancement
FORWARD TSNでさらなるFORWARD TSN=を処理した後に、待ち行列の>を処理する前に、待ち行列の前進
Stewart, et al. Standards Track [Page 12] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[12ページ]RFC3758SCTP
cum.TSN.Pt-> 102 received 102 --
103 missing 103 --
104 received 104 --
105 received cum.TSN.Pt-> 105 received
106 missing 106 missing
107 received 107 received
... ...
104 -- 105に受け取られた103 -- 104を逃す102が102 -- 103に受けたcum.TSN.Pt->が容認された107が受け取った107を逃しながら106を逃す105が受けたcum.TSN.Pt->106を受け取りました… ...
In this example, the receiver's cumulative TSN point is first
updated to 103 and then further advanced to 105.
この例では、受信機の累積しているTSNポイントを最初に、103にアップデートして、次に、さらに105に進めます。
After the above processing, the data receiver MUST stop reporting any missing TSNs earlier than or equal to the new cumulative TSN point.
上の処理の後に、データ受信装置は、どんななくなったTSNsも新しい累積しているTSNポイントと、より初期であるか、または等しいと報告するのを止めなければなりません。
Note, if the "New Cumulative TSN" value carried in the arrived FORWARD TSN chunk is found to be behind or at the current cumulative TSN point, the data receiver MUST treat this FORWARD TSN as out-of- date and MUST NOT update its Cumulative TSN. The receiver SHOULD send a SACK to its peer (the sender of the FORWARD TSN) since such a duplicate may indicate the previous SACK was lost in the network.
到着したFORWARD TSN塊で運ばれた「新しい累積しているTSN」値が背中であることがわかっているか、またはデータ受信装置が出かけるとして現在の累積しているTSNポイントでこのFORWARD TSNを扱わなければならないなら注意する、-、-デートしてください、そして、NOTはCumulative TSNをアップデートしなければなりませんか? そのような写しが、前のSACKがネットワークでなくされたのを示すかもしれないので、受信機SHOULDは同輩(FORWARD TSNの送付者)にSACKを送ります。
Any time a FORWARD TSN chunk arrives, for the purposes of sending a SACK, the receiver MUST follow the same rules as if a DATA chunk had been received (i.e., follow the delayed sack rules specified in RFC 2960 [2] section 6.2).
いつでも、FORWARD TSN塊は到着します、SACKを送る目的のために受信機はまるでDATA塊を受け取ったかのように(すなわち、RFC2960[2]部6.2で指定された遅れた袋の規則に従ってください)同じ規則に従わなければなりません。
Whenever a DATA chunk arrives with the 'U' bit set to '0' (indicating ordered delivery) and is out of order, the receiver must hold the chunk for reordering. Since it is possible with PR-SCTP that a DATA chunk being waited upon will not be retransmitted, special actions will need to be taken upon the arrival of a FORWARD TSN.
DATA塊が'0'に設定された'U'ビット(命令された配送を示す)と共に到着して、不適切であるときはいつも、受信機は再命令するための塊を保持しなければなりません。 待たれるDATA塊が再送されないのが、PR-SCTPで可能であるので、特別な動きは、FORWARD TSNの到着が持っていかれる必要があるでしょう。
In particular, during processing of a FORWARD TSN, the receiver MUST use the stream sequence information to examine all of the listed stream reordering queues, and immediately make available for delivery stream sequence numbers earlier than or equal to the stream sequence number listed inside the FORWARD TSN. Any such stranded data SHOULD be made immediately available to the upper layer application.
FORWARD TSNの処理の間、特に、受信機は、FORWARD TSNの中に記載された流れの一連番号と、より早いか、または等しい状態ですぐに待ち行列を再命令すると配送流れの一連番号に利用可能にする記載された流れのすべてを調べるのに流れの系列情報を使用しなければなりません。 どんなそのようなものもデータSHOULDをより合わせました。すぐに、上側の層のアプリケーションに利用可能に作られてください。
An application using PR-SCTP receiving data should be aware of possible missing messages. The stream sequence number can be used, in such a case, to determine that an intervening message has been skipped. When intervening messages are missing, it is an application decision to process the messages or to take some other corrective action.
データを受け取りながらPR-SCTPを使用するアプリケーションは可能ななくなったメッセージを意識しているべきです。 介入しているメッセージをスキップしてあることを決定するのにこのような場合には流れの一連番号を使用できます。 介入しているメッセージがなくなるとき、それはメッセージを処理するか、またはある他の修正措置を取るというアプリケーション決定です。
Stewart, et al. Standards Track [Page 13] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[13ページ]RFC3758SCTP
After receiving and processing a FORWARD TSN, the data receiver MUST take cautions in updating its re-assembly queue. The receiver MUST remove any partially reassembled message, which is still missing one or more TSNs earlier than or equal to the new cumulative TSN point. In the event that the receiver has invoked the partial delivery API, a notification SHOULD also be generated to inform the upper layer API that the message being partially delivered will NOT be completed.
FORWARD TSNを受けて、処理した後に、再アセンブリ待ち行列をアップデートして、データ受信装置は警告を中に入れなければなりません。 受信機はどんな部分的に組み立て直されたメッセージも取り除かなければなりません。(それは、まだなくなった新しい累積しているTSNと、より早いか等しい1TSNsポイント以上です)。 受信機は一部受け渡しAPI、a通知SHOULDを呼び出しました、また、発生して、部分的に渡されたメッセージ存在が終了しないことを上側の層のAPIに知らせてください。
Note that after receiving a FORWARD TSN and updating the cumulative acknowledgement point, if a TSN that was skipped does arrive (i.e., due to network reordering), then the receiver will follow the normal rules defined in RFC 2960 [2] for handling duplicate data. This implies that the receiver will drop the chunk and report it as a duplicate in the next outbound SACK chunk.
スキップされたTSNが到着すると(すなわち、ネットワーク再命令のため)FORWARD TSNを受けて、累積している承認ポイントをアップデートした後に受信機が取り扱い重複データのためのRFC2960[2]で定義された正常な規則に従うことに注意してください。 これは、受信機が次の外国行きのSACK塊における写しとして塊とレポートを止めるのを含意します。
4. Services provided by PR-SCTP to the upper layer
4. PR-SCTPによって上側の層に提供されたサービス
As described in Section 1.2, it is feasible to implement a variety of partially reliable transport services using the new protocol mechanisms introduced in Section 3; introducing these new services requires making changes only at the sending side API, and the sending side protocol implementation. Thus, there may be a temptation to standardize only the protocol, and leave the service definition as "implementation specific" or leave it to be defined in "informational" documents.
セクション1.2で説明されるように、セクション3で紹介された新しいプロトコルメカニズムを使用するさまざまな部分的に信頼できる輸送サービスを実行するのは可能です。 これらの新種業務を導入するのは、単に送付サイドAPI、および送付サイドプロトコル実現のときに変更を行うのを必要とします。 したがって、「情報」のドキュメントで定義されるべきそれは、プロトコルだけを標準化する誘惑であり、サービス定義を「実現特有」を残すか、またはいなくなるかもしれません。
However, for those who may wish to write IETF standards for upper layer protocols implemented over PR-SCTP, it is important to be able to refer to a standard definition of services provided. Therefore, this section provides example definitions of one such service, while also providing guidelines for the definition of additional services as required. Each such service may be proposed as a separate new RFC.
しかしながら、PR-SCTPの上で実行された上側の層のプロトコルの規格をIETFに書きたがっているかもしれない人に関して、サービスの標準定義について言及できるのが提供されたのは、重要です。 したがって、このセクションはまた、必要に応じて追加サービスの定義のためのガイドラインを提供している間、そのようなサービスの1つの例の定義を提供します。 そのような各サービスは別々の新しいRFCとして提案されるかもしれません。
Section 4 is organized as follows:
セクション4は以下の通り組織化されます:
o Section 4.1 provides the definition of one specific PR-SCTP
service: timed reliability.
o セクション4.1は特定に1つのPR-SCTPサービスの定義を提供します: 信頼性を調節しました。
o Section 4.2 describes how a particular PR-SCTP service definition
is requested by the upper layer during association establishment,
and how the upper layer is notified if that request cannot be
satisfied.
o セクション4.2は、特定のPR-SCTPサービス定義が協会設立の間、上側の層によってどのように要求されるか、そして、その要望に応じることができないなら上側の層がどのように通知されるかを説明します。
o Section 4.3 then provides guidelines for the specification of PR-
SCTP services other then the one defined in this memo.
o そして、セクション4.3は次に、他のPR SCTPサービスの仕様のためのガイドラインにこのメモで定義されたものを提供します。
Stewart, et al. Standards Track [Page 14] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[14ページ]RFC3758SCTP
o Finally, Section 4.4 describes some additional usage notes that
upper layer protocol designers and implementors may find helpful.
o 最終的に、セクション4.4は上側の層のプロトコルデザイナーと作成者が役立っているのがわかるかもしれないいくつかの追加使用上の注意について説明します。
4.1. PR-SCTP Service Definition for "timed reliability"
4.1. 「調節された信頼性」のためのPR-SCTP Service Definition
The "timed reliability" service is a natural extension of the "lifetime" concept already present in the base SCTP protocol.
「調節された信頼性」サービスはベースSCTPプロトコルにおける既に現在の「生涯」概念の自然な拡大です。
When this service is requested for an SCTP association, it changes the meaning of the lifetime parameter specified in the SEND primitive (see Section 10.1, part (E) of RFC 2960 [2]; note that the parameter is spelled "life time" in that document.)
このサービスがSCTP協会のために要求されているとき、それはSENDで原始的に指定された生涯パラメタの意味を変えます。(セクション10.1、RFC2960[2]の部分(E)を見てください; パラメタがそのドキュメントのつづられた「人生時間」であると述べてください。)
In the base SCTP protocol, the lifetime parameter is used to avoid sending stale data. When a lifetime value is indicated for a particular message and that lifetime expires, SCTP cancels the sending of this message, and notifies the ULP if the first transmission of the data does not take place (because of rwnd or cwnd limitations, or for any other reason). However, in the base protocol, if SCTP has sent the first transmission before the lifetime expires, then the message MUST be sent as a normal reliable message. During episodes of congestion this is particularly unfortunate, as retransmission wastes bandwidth that could have been used for other (non-lifetime expired) messages.
ベースSCTPプロトコルでは、生涯パラメタは、聞き古したデータを送るのを避けるのに使用されます。 SCTPはこのメッセージの発信を取り消して、生涯値が特定のメッセージのために示されて、その寿命が期限が切れて、データの最初の伝達が行われないなら(rwndかcwnd制限のためいかなる他の理由のでも)、ULPに通知します。 しかしながら、ベースプロトコルでは、寿命が期限が切れる前にSCTPが最初のトランスミッションを送ったなら、正常な信頼できるメッセージとしてメッセージを送らなければなりません。 混雑のエピソードの間、これは特に不幸です、他の(非寿命は期限が切れました)メッセージに使用されたかもしれない「再-トランスミッション」廃棄物帯域幅として。
When the "timed reliability" service is invoked, this latter restriction is removed. Specifically, when the "timed reliability" service is in effect, the following rules govern all messages that are sent with a lifetime parameter:
「調節された信頼性」サービスを呼び出すとき、この後者の制限を取り除きます。 「調節された信頼性」サービスが有効であるときに、明確に、以下の規則は生涯パラメタで送られるすべてのメッセージを支配します:
TR1) If the lifetime parameter of a message is SCTP_LIFETIME_RELIABLE
(or unspecified see Section 5), that message is treated as a
normal reliable SCTP message, just as in the base SCTP protocol.
TR1) メッセージの生涯パラメタがSCTP_LIFETIME_RELIABLEである、(不特定である、セクション5)、そのメッセージが正常な信頼できるSCTPメッセージとして扱われるのを見てください、ちょうどベースSCTPプロトコルのように。
TR2) If the lifetime parameter is not SCTP_LIFETIME_RELIABLE (see
Section 5), then the SCTP sender MUST treat the message just as
if it were a normal reliable SCTP message, as long as the
lifetime has not yet expired.
TR2) 生涯パラメタがSCTP_LIFETIME_RELIABLE(セクション5を見る)でないなら、SCTP送付者はまるでまさしくそれが正常な信頼できるSCTPメッセージであるかのようにメッセージを扱わなければなりません、寿命がまだ期限が切れていない限り。
TR3) Before assigning a TSN to any message, the SCTP sender MUST
evaluate the lifetime of that message. If it is expired, the
SCTP sender MUST NOT assign a TSN to that message, but instead,
SHOULD issue a notification to the upper layer and abandon the
message.
TR3) どんなメッセージにもTSNを割り当てる前に、SCTP送付者はそのメッセージの生涯を評価しなければなりません。 それが満期であるなら、SCTP送付者がそのメッセージにTSNを割り当ててはいけませんが、SHOULDは代わりに、上側の層に通知書を発行して、メッセージを捨てます。
TR4) Before transmitting or retransmitting a message for which a TSN
is already assigned, the SCTP sender MUST evaluate the lifetime
of the message. If the lifetime of the message is expired, the
TR4) TSNが既に割り当てられるメッセージを伝えるか、または再送する前に、SCTP送付者はメッセージの生涯を評価しなければなりません。 メッセージの寿命が満期であるなら
Stewart, et al. Standards Track [Page 15] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[15ページ]RFC3758SCTP
SCTP sender MUST "abandon" the message, as per the rules
specified in Section 3.5 marking that TSN as eligible for
forward TSN. Note that this meets the requirement G1 defined in
Section 4.3. IMPLEMENTATION NOTE: An implementation SHOULD
delay TSN assignment as mentioned in RFC 2960 [2] Section 10.1.
In such a case, the lifetime parameter should be checked BEFORE
assigning a TSN, thus allowing a message to be abandoned without
the need to send a FORWARD TSN.
SCTP送付者はメッセージを「捨てなければなりません」、前進のTSNに適任であるとしてそのTSNをマークしながらセクション3.5で指定された規則に従って。 これがセクション4.3で定義された要件G1に会うことに注意してください。 実現注意: RFC2960[2]部10.1で言及される実現SHOULD遅れTSN課題。 このような場合には、生涯パラメタはTSNを割り当てるチェックのBEFOREであるべきです、その結果、FORWARD TSNを送る必要性なしで捨てられるべきメッセージを許容します。
TR5) The sending SCTP MAY evaluate the lifetime of messages at
anytime. Expired messages that have not been assigned a TSN MAY
be handled as per rule TR3. Expired messages that HAVE been
assigned a TSN MAY be handled as per rule TR4.
TR5) 発信しているSCTP MAYはいつでもメッセージの生涯を評価します。 TSN MAYはそれに割り当てられていません。満期のメッセージ、規則TR3に従って、扱われてください。 TSN MAYが割り当てられたHAVEが規則TR4に従って扱われるという満期のメッセージ。
TR6) The sending application MUST NOT change the lifetime parameter
once the message is passed to the sending SCTP.
TR6) メッセージがいったん発信しているSCTPに通過されると、送付アプリケーションは生涯パラメタを変えてはいけません。
Implementation Note: Rules TR1 through TR4 are designed in such a way as to avoid requiring the implementer to maintain a separate timer for each message; instead, the lifetime need only be evaluated at points in the life of the message where actions are already being taken, such as TSN assignment, transmission, or expiration of a retransmission timeout. Rule TR5 is intended to give the SCTP implementor flexibility to evaluate lifetime at any other convenient opportunity, WITHOUT requiring that lifetime be evaluated immediately at the point in time where it expires.
実現注意: implementerが各メッセージのために別々のタイマを維持するのが必要であることを避けるほどTR1からTR4がそのような方法で設計されているという規則。 代わりに、寿命はポイントで行動が既に取られているメッセージの人生で評価されるだけでよいです、再送タイムアウトのTSN課題、トランスミッション、または満了などのように。 いかなる他の便利な機会(それが期限が切れる寿命が時間内にすぐポイントで評価されるのを必要とするWITHOUT)でも生涯を評価するために規則TR5がSCTP作成者の柔軟性を与えることを意図します。
4.2. PR-SCTP Association Establishment
4.2. PR-SCTP協会設立
An upper layer protocol (ULP) that uses PR-SCTP may need to know whether PR-SCTP can be supported on a given association. Therefore, the ULP needs to have some indication of whether the FORWARD-TSN chunk is supported by its peer.
PR-SCTPを使用するプロトコル(ULP)上側の層は、与えられた協会でPR-SCTPを支持できるかどうかを知る必要があるかもしれません。 したがって、ULPはFORWARD-TSN塊が同輩によって支持されるかどうかいくつかのしるしを必要とします。
Section 10.1 of RFC 2960 [2] describes abstract primitives for the ULP-to-SCTP interface, while noting that "individual implementations must define their own exact format, and may provide combinations or subsets of the basic functions in single calls."
「個々の実現は、それら自身の正確な書式を定義しなければならなくて、基本機能の組み合わせか部分集合をただ一つの呼び出しに提供するかもしれません」と述べている間、RFC2960[2]のセクション10.1はULPからSCTPへのインタフェースのための抽象的な基関数について説明します。
In this section, we describe one additional return value that may be added to the ASSOCIATE primitive to allow an SCTP service user to indicate whether the FORWARD-TSN chunk is supported by its peer.
このセクションで、私たちはSCTPサービス利用者が、FORWARD-TSN塊が同輩によって支持されるかどうかを示すのを許容するためには原始のASSOCIATEに高められるかもしれない1つの追加リターン価値について説明します。
RFC 2960 indicates that the ASSOCIATE primitive "allows the upper layer to initiate an association to a specific peer endpoint". It is structured as follows:
RFC2960は、ASSOCIATE基関数が「上側の層が特定の同輩終点に協会を開始するのを許容すること」を示します。 それは以下の通り構造化されます:
Stewart, et al. Standards Track [Page 16] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[16ページ]RFC3758SCTP
Format: ASSOCIATE(local SCTP instance name, destination transport
addr, outbound stream count)
-> association id [,destination transport addr list]
[,outbound stream count]
形式: ASSOCIATE(ローカルのSCTP例の名、目的地輸送addr、外国行きの流れのカウント)->協会イド[目的地輸送addrリスト][外国行きの流れのカウント]
This extension adds one new OPTIONAL return value, such that the new primitive reads as follows:
この拡大が、ある新しいOPTIONALが値を返すと言い足すので、新しい基関数は以下の通り読みます:
Format: ASSOCIATE(local SCTP instance name, destination transport
addr, outbound stream count )
-> association id [,destination transport addr list]
[,outbound stream count] [,forward tsn supported]
形式: ASSOCIATE(ローカルのSCTP例の名、目的地輸送addr、外国行きの流れのカウント)->協会イド[目的地輸送addrリスト][外国行きの流れのカウント][支持されたtsnを進めてください]
NOTE: As per RFC 2960, if the ASSOCIATE primitive is implemented as a non-blocking call, the new OPTIONAL return value shall be passed with the association parameters using the COMMUNICATION UP notification.
以下に注意してください。 RFC2960に従って、基関数はASSOCIATEであるなら非ブロッキング要求(協会パラメタがCOMMUNICATION UP通知を使用している状態でリターン値が通過されるものとする新しいOPTIONAL)として実行されます。
The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
「支持された前進のtsn」という新しいOPTIONALパラメタは論理演算子旗です:
(0) false [default] indicates that FORWARD TSN is not enabled by both
endpoints.
(0) 誤った[デフォルト]は、FORWARD TSNが両方の終点によって有効にされないのを示します。
(1) true indicates that FORWARD TSN is enabled on both endpoints.
(1) 本当に、FORWARD TSNが両方の終点で有効にされるのを示します。
We also add a new primitive to allow the user application to enable/ disable the PR-SCTP service on its endpoint before an association is established.
また、私たちは、協会が設立される前にユーザアプリケーションが終点でPR-SCTPサービスを可能にするか、または無効にするのを許容するために新しい基関数を加えます。
Format: ENABLE_PRSCTP(local SCTP instance name, boolean enable)
形式: _PRSCTPを有効にしてください。(ローカルのSCTP例の名、論理演算子、可能にする、)
The boolean parameter enable, if set to true, will enable PR-SCTP upon future endpoint associations. If the boolean parameter is set to false, then the local endpoint will not advertise support of PR- SCTP and thus disable the feature on future associations. It is recommended that this option be disabled by default, i.e., in order to enable PR-SCTP, the user will need to call this API option with the enable flag set to "true".
本当に設定されるなら、論理演算子パラメタは意志を可能にします。未来の終点協会でPR-SCTPを有効にしてください。 論理演算子パラメタが誤っているのに設定されると、地方の終点は、PR SCTPのサポートの広告を出して、その結果、今後の協会に関する特徴を無効にしないでしょう。 すなわち、このオプションがPR-SCTPを有効にするためにデフォルトで無効にされるのは、お勧めです、このAPIオプションを呼ぶ意志がそうしなければならないユーザ、「本当に」旗のセットを可能にしてください。
4.3. Guidelines for defining other PR-SCTP Services
4.3. 他のPR-SCTP Servicesを定義するためのガイドライン
Other PR-SCTP services may be defined and implemented as dictated by the needs of upper layer protocols. If such upper layer protocols are to be standardized and require some particular PR-SCTP service other than the one defined in this document (i.e., "timed reliability"), then those additional PR-SCTP services should also be specified and standardized in a new RFC.
他のPR-SCTPサービスは、上側の層のプロトコルの必要性によって書き取られるように定義されて、実行されるかもしれません。 そのような上側の層のプロトコルが標準化されて、本書では(すなわち、「信頼性を調節する」)定義されたもの以外の何らかの特定のPR-SCTPサービスを必要とすることであるなら、また、それらの追加PR-SCTPサービスは、新しいRFCで指定されて、標準化されるべきです。
Stewart, et al. Standards Track [Page 17] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[17ページ]RFC3758SCTP
It is suggested that any such additional service definitions be modeled after the contents of Section 4.1. In particular, the service definition should provide:
そのようなどんな追加サービス定義もセクション4.1のコンテンツに倣われることが提案されます。 特に、サービス定義は提供されるべきです:
1. A description of how the service user specifies any parameters
that need to be associated with a particular message (and/or any
other communication that takes place between the application and
the SCTP transport sender) that provides the SCTP transport sender
with the information needed to determine when to give up on
transmission of a particular message.
1. サービス利用者がどうSCTP輸送送付者に情報を提供する特定のメッセージ(そして/または、アプリケーションとSCTP輸送送付者の間の場所を取るいかなる他のコミュニケーションも)に関連している必要があるどんなパラメタも指定するかに関する記述は、いつ特定のメッセージの伝達に見切りをつけるかを決定する必要がありました。
Preferably, this description should reference the primitives in
the abstract API provided in Section 10 of RFC 2960 [2],
indicating any:
望ましくは、この記述はRFC2960[2]のセクション10に提供された抽象的なAPIで基関数に参照をつけるべきです、いずれも示して:
* changes to the interpretation of the existing parameters of
existing primitives,
* 既存の基関数の既存のパラメタの解釈への変化
* additional parameters to be added to existing primitives (these
should be OPTIONAL, and default values should be indicated),
* 既存の基関数(これらはOPTIONALであるべきです、そして、デフォルト値は示されるべきである)に追加されるべき追加パラメタ
* additional primitives that may be needed.
* 必要であるかもしれない追加基関数。
2. A description of the rules used by the sender side implementation
to determine when to give up on messages that have not yet been
assigned a TSN. This description should also indicate what
protocol events trigger the evaluation, and what actions to take
(e.g., notifications.)
2. いつ、TSNがまだ割り当てられていないメッセージに見切りをつけるかを決定するのに送付者サイド実現で使用される規則の記述。 また、この記述はどんなプロトコルイベントが評価の引き金となるか、そして、どんな行動を取ったらよいかを示すべきです。(例えば、通知。)
3. A description of the rules used by the sender side implementation
to determine when to give up on the transmission or retransmission
of messages that have already been assigned a TSN, and may have
been transmitted and possibly retransmitted zero or more times.
3. いつトランスミッションに見切りをつけるかを決定するのに送付者サイド実現で使用される規則の記述かそうしたメッセージの「再-トランスミッション」が、TSNが既に割り当てられて、伝えられた、ことによると再送されたゼロか以上回であったかもしれません。
Items (2) and (3) in the list above should also indicate what protocol events trigger the evaluation, and what actions to take if the determination is made that the sender should give up on transmitting the message (e.g., notifications to the ULP.)
また、上記のリストの項目(2)と(3)はどんなプロトコルイベントが評価の引き金となるか、そして、決断をするなら取るメッセージを送る送付者が見切りをつけるべきであるすべての動作を示すはずです。(例えば、ULPへの通知。)
Note that in any PR-SCTP service, the following rule MUST be specified to avoid a protocol deadlock:
どんなPR-SCTPサービスでも、プロトコル行き詰まりを避けるために以下の規則を指定しなければならないことに注意してください:
(G1) When the sender side implementation gives up on transmitting a
message that has been assigned a TSN (i.e., when that message is
"abandoned", as defined in Section 3.4), the sender side MUST
mark that TSN as eligible for forward TSN, and the rules in
Section 3.4 regarding the sending of FORWARD TSN chunks MUST be
followed.
(G1) 送付者サイド実現が、TSNが割り当てられたメッセージを送るのに見切りをつけるとき(すなわち、そのメッセージはいつセクション3.4で定義されるように「捨てられますか」)、送付者側は前進のTSNに適任であるとしてそのTSNをマークしなければならなくて、FORWARD TSN塊の発信に関するセクション3.4の規則に従わなければなりません。
Stewart, et al. Standards Track [Page 18] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[18ページ]RFC3758SCTP
Finally, a PR-SCTP service definition should specify a "canonical service name" to uniquely identify the service, and distinguish it from other PR-SCTP services. This name can then be used in upper layer protocol standards to indicate which PR-SCTP service definition is required by that upper layer protocol. It can also be used in the documentation of APIs of PR-SCTP implementations to indicate how an upper layer indicates which definition of PR-SCTP service should apply. The canonical service name for the PR-SCTP service defined in Section 4.1 is "timed reliability".
最終的に、PR-SCTPサービス定義は、唯一サービスを特定するために「正準なサービス名」を指定して、他のPR-SCTPサービスとそれを区別するべきです。 そして、どのPR-SCTPサービス定義がその上側の層のプロトコルによって必要とされるかを示すのに上側の層のプロトコル標準にこの名前を使用できます。 また、上側の層が、どのPR-SCTPサービスの定義が適用されるべきであるかをどう示すかを示すのにPR-SCTP実現のAPIのドキュメンテーションでそれを使用できます。 セクション4.1で定義されたPR-SCTPサービスのための正準なサービス名は「調節された信頼性」です。
4.4. Usage Notes
4.4. 使用上の注意
Detecting missing data in a PR-SCTP stream is useful for some applications (e.g., Fibre channel or SCSI over IP). With PR-SCTP, this becomes possible - the upper layer simply needs to examine the stream sequence number of the arrived user messages of that stream to detect any missing data. Note, this detection only works when all the messages on that stream are sent in order, i.e., the "U" bit is not set.
PR-SCTPの流れで欠測値を検出するのはいくつかのアプリケーション(例えば、IPの上のFibreチャンネルかSCSI)の役に立ちます。 PR-SCTPと共に、これは可能になります--上側の層は、単にどんな欠測値も検出するその流れの到着したユーザメッセージの流れの一連番号を調べる必要があります。 注意、整然とした状態でその流れに関するすべてのメッセージを送るときだけ、この検出は働いています、すなわち、「U」ビットは設定されません。
5. Variables
5. 変数
This section defines variables used throughout this document:
このセクションはこのドキュメント中で使用される変数を定義します:
SCTP_LIFETIME_RELIABLE - A user interface indication defined by an implementation and used to indicate when a message is to be considered fully reliable.
SCTP_LIFETIME_RELIABLE--実現で定義されて、メッセージがいつ完全に信頼できると考えられるかことであることを示すのに使用されるユーザーインタフェース指示。
6. Acknowledgments
6. 承認
The authors would like to thank Brian Bidulock, Scott Bradner, Jon Berger, Armando L. Caro Jr., John Loughney, Jon Peterson, Ivan Arias Rodriguez, Ian Rytina, Chip Sharp, and others for their comments.
作者は彼らのコメントについてブライアンBidulock、スコット・ブラドナー・ジョン・バーガー、アルマンドL.ケアロJr.、ジョンLoughney、ジョン・ピーターソン、イワン・Ariasロドリゲス、イアンRytina、Chipシャープ、および他のものに感謝したがっています。
7. Security Considerations
7. セキュリティ問題
This document does not introduce any new security concerns to SCTP other than the ones already documented in RFC 2960 [2]. In particular, this document shares the same security issues as unordered data within RFC 2960 [2] identified by RFC 3436 [4]. An application using the PR-SCTP extension should not use transport layer security; further details can be found in RFC 3436 [4].
このドキュメントは既にRFC2960[2]に記録されたもの以外のSCTPにどんな新しい安全上の配慮も紹介しません。 特に、このドキュメントはRFC3436[4]によって特定されたRFC2960[2]の中で順不同のデータと同じ安全保障問題を共有します。 PR-SCTP拡張子を使用するアプリケーションはトランスポート層セキュリティを使用するべきではありません。 RFC3436[4]で詳細を見つけることができます。
Note that the ability to cause a message to be skipped (i.e, the FORWARD TSN chunk) does not provide any new attack for a Man-In-the- Middle (MIM), since the MIM already is capable of changing and/or withholding data, thus effectively skipping messages. However, the FORWARD TSN chunk does provide a mechanism to make it easier for a
スキップされるべきメッセージ(i.e、FORWARD TSN塊)を引き起こす能力が少しの新しい攻撃も中のManに供給しないことに注意してください、-、-中央です(MIM)、MIMはデータを変える、そして/または、差し控えるのが既にできるので、その結果、事実上、スキップは通信します。 しかしながら、FORWARD TSN塊は、それをaには、より簡単にするようにメカニズムを提供します。
Stewart, et al. Standards Track [Page 19] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[19ページ]RFC3758SCTP
MIM to skip selective messages when the application has this feature enabled since the MIM would have less state to maintain.
MIM以来アプリケーションでこの特徴を可能にするとき選択しているメッセージをスキップするMIMには、維持するより少ない状態があるでしょう。
8. IANA Considerations
8. IANA問題
IANA has assigned 192 as a new chunk type to SCTP.
IANAは新しい塊タイプとして192をSCTPに割り当てました。
IANA has assigned 49152 as a new parameter type code to SCTP.
IANAは新しいパラメータの型コードとして49152をSCTPに割り当てました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[2] スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
9.2. Informative References
9.2. 有益な参照
[3] Clark, D. and D. Tennenhouse, "Architectural Considerations for
a New Generation of Protocols", SIGCOMM 1990 pp. 200-208,
September 1990.
[3] クラーク、D.とD.Tennenhouse、「プロトコルの新しい世代建築問題」SIGCOMM1990ページ 200-208と、1990年9月。
[4] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
[4]JungmaierとA.とレスコラとE.とM.Tuexen、「流れの制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、2002年12月。
10. Authors' Addresses
10. 作者のアドレス
Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA
ランドルR.スチュワートシスコシステムズInc.8725西ヒギンズ道路Suite300IL60631シカゴ(米国)
Phone: +1-815-477-2127 EMail: rrs@cisco.com
以下に電話をしてください。 +1-815-477-2127 メールしてください: rrs@cisco.com
Stewart, et al. Standards Track [Page 20] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[20ページ]RFC3758SCTP
Michael A. Ramalho Cisco Systems, Inc. 1802 Rue de la Porte Wall Township, NJ 07719-3784 USA
Rue de laポルトWall Township、マイケルA.RamalhoシスコシステムズInc.1802ニュージャージー07719-3784米国
Phone: +1.732.449.5762 EMail: mramalho@cisco.com
以下に電話をしてください。 +1.732 .449 .5762 メール: mramalho@cisco.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA
シェモトローラ1501W.シュアーのドライブ、#2309アーリントンハイツ、IL60004米国をQiaobingします。
Phone: +1-847-632-3028 EMail: qxie1@email.mot.com
以下に電話をしてください。 +1-847-632-3028 メールしてください: qxie1@email.mot.com
Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学Muenster StegerwaldstrのマイケルTuexen大学。 39 48565Steinfurtドイツ
EMail: tuexen@fh-muenster.de
メール: tuexen@fh-muenster.de
Phillip T. Conrad University of Delaware Department of Computer and Information Sciences Newark, DE 19716 USA
コンピュータと情報科学ニューアーク、DE19716米国のフィリップT.コンラッドデラウエア大学部
Phone: +1 302 831 8622 EMail: conrad@acm.org URI: http://www.cis.udel.edu/~pconrad
以下に電話をしてください。 +1 8622年の302 831メール: conrad@acm.org ユリ: http://www.cis.udel.edu/~pconrad
Stewart, et al. Standards Track [Page 21] RFC 3758 SCTP Partial Reliability Extension May 2004
スチュワート、他 信頼性の拡大2004年5月に部分的な標準化過程[21ページ]RFC3758SCTP
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Stewart, et al. Standards Track [Page 22]
スチュワート、他 標準化過程[22ページ]
一覧
スポンサーリンク
