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
Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
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点を移動する必要があることをそのピアに知らせることを可能にするストリーム制御伝送プロトコル（SCTP）の拡張を記述しています。 SCTPアソシエーションの両側には、この拡張をサポートする場合には、上位層プロトコルに部分的に信頼性の高いデータ伝送サービスを提供するために、SCTPの実装で使用することができます。このメモは、INITとINIT ACK、及び新しいFORWARD TSNチャンク・タイプの新しいパラメータで構成プロトコル拡張を記述し、この機構を介して上位層に提供することができる部分的に信頼性の高いサービスの一例を提供します。
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 . . . . . . . . . . . . . . . . . . .
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）RFC 2960 [2]それは、もはや一つまたは複数のデータチャンクを受信するように期待するべきであるピアにシグナリングするSCTP送信者を可能にする拡張を記述する。
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交換では、単一の新しいパラメータ
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、（おそらくまだ受信および/または承認されていない可能性が過去一つ以上のデータチャンクをスキップします）。
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アソシエーションの上に部分的に信頼できるトランスポートサービスを提供するために使用することができます。私たちは、トランスポートサービスが受信者にメッセージを送信しようとする中でどうあるべきか、永続規定する規則、メッセージごとに、ユーザーが指定することができるサービスとして、部分的に信頼性の高い輸送サービスを定義します。
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).
部分的に信頼性の高いサービスの一例は、この文書、すなわち「時限式の信頼性」サービスに指定されています。このサービスは、サービスの利用者が送信者が送信/メッセージを再送信しようとするべきである時間の長さの制限（これは基本プロトコルで既に「寿命」パラメータの自然な拡張である）を示すことを可能にします。
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チャンクが必要であるという事実以外、他に注意してください。 APIと送信者側の実装だけでは、サービスを上位層に定義されている方法によって影響を受けます。したがって、原則的に、オン・ワイヤープロトコルを変更することなく、特定のSCTPの実装では、部分的に信頼性の高いサービスの多くの品種を実装することが可能です。受信者の唯一の役割が正しくFORWARD TSNチャンクを解釈するのであるから。また、SCTPの受信機は、必ずしも、これにより、送信者は、もはや送信しないことを決定した過去のメッセージをスキップし、部分的に信頼性の高いサービスのセマンティクスが送信者によって使用されているか知る必要はありません。 （または再送信）。
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 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.
それにもかかわらず、IETFのアプリケーション層プロトコルの設計者が特定のSCTP実装によって提供される標準的なサービス定義にその上位層プロトコルの要件を満たすことができるように、部分的に信頼性の高いサービスの標準的な定義の限られた数は、IETFで標準化されることをお勧めします。そのような定義は、「時限式の信頼性」は、この文書に含まれています。必要がオン・ザ・ワイヤプロトコルへのさらなる変更なしに応じてこの文書で提案された拡張機能を与え、他の定義を標準化することができます。
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.
通常の信頼性のSCTPデータトラフィックがするようにPR-SCTPによって運ば2.部分的に信頼性の高いデータトラフィックは、同じ通信障害の検出と保護機能をお楽しみいただけます。これはすぐに失敗した送信先アドレスを検出する能力を含む、フェイルオーバー代替宛先アドレスに、データ受信機が到達不能になった場合に通知されます。
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.)
SCTPは、TCPフレンドリー強制ので、これは非常に望ましい - 4 PR-SCTPは、信頼性の高い、または部分的に信頼できるかどうか、すべてのデータトラフィックのための同じ輻輳制御と輻輳回避を採用（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.
そのため、信頼性SCTP、および信頼性のないメッセージのチャンク束ねる機能の5.単一PR-SCTPアソシエーション上で多重化することができます。したがって、IPデータグラム（したがって、ネットワークのオーバーヘッド）の数は、別のプロトコルを使用して、データのこれらの異なるタイプを送信するのではなく減少させることができます。また、この多重化は、信頼性と信頼性の低い接続のための別のポートを使用して対ポートを節約することができます。
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].
キーワードは、REQUIREDは、、NOT SHALL、、、すべきでないものとはならない（MUST NOT）RFC 2119 [1、彼らは、この文書に表示されたときに、BCP 14で説明したように解釈されるべきである、MAY、推奨しません、推奨、およびオプションしなければなりません]。
Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are governed by the rules in Section 1.6 of RFC 2960 [2].
トランスポートシーケンス番号（TSNを）上の比較演算は、RFC 2960のセクション1.6のルールによって支配されている[2]。
The following new OPTIONAL parameter is added to the INIT and INIT ACK chunks.
次の新しいオプションのパラメータはINITとINIT ACKチャンクに追加されます。
Parameter Name Status Type Value
-------------------------------------------------------------
Forward-TSN-Supported OPTIONAL 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チャンクの送信者は（詳細についてはセクション3.3を参照）が前方TSNチャンクをサポートすることが可能であることをピアに通知するために、このオプションのパラメータを含むかもしれません。次のようにこのパラメータの書式は定義されています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 bit u_int
タイプ：16ビットu_int
49152, indicating Forward-TSN-Supported parameter
フォワード-TSN-サポートされているパラメータを示す49152、
Length: 16 bit u_int
長さ：16ビットu_int
Indicates the size of the parameter, i.e., 4.
パラメータの大きさを示し、すなわち、4。
The following new chunk type is defined:
次の新しいチャンクタイプが定義されます。
Chunk Type Chunk Name
------------------------------------------------------
192 (0xC0) Forward Cumulative TSN (FORWARD TSN)
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.
いくつか欠けているのTSNが送信者によって送信または再送信されるべきではないデータチャンクに関連付けられているため、このチャンクは前方その累積受信TSNポイントを調整するために、データの受信を知らせるために、データの送信者によって使用されなければなりません。
Forward Cumulative TSN chunk has the following format:
フォワード累積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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を示しています。この値を受信すると、データ受信装置は、受信されたような任意の欠落のTSNがより早く、またはこの値に等しい検討、及びその後の袋のギャップとしてそれらを報告停止しなければなりません。
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のストリームの再順序付けキューに残っているの配信を可能にするために、ストリーム-Nとストリームシーケンス-Nフィールドを使用することができます。このフィールドは、TSNのは、順不同としてマークされているDATAチャンクに対応報告してはなりません。注文したDATAチャンクの場合、このフィールドは記入されなければなりません。
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チャンクにフォワード-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.
エンドポイントは、パラメータを含めるしないことを選択した場合、その後、組合の生活の間に時間がない時に、それはFORWARD TSNを送信したり、処理できることに注意してください。これは、代わりにそれはどんなFORWARD TSNの受信時にピアにエラーを返す、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の受信機が順方向TSN-サポートパラメータを検出し、フォワードTSNチャンクタイプをサポートしていない場合、受信機は、RFC 2960のセクション3.3.3で定義された規則に従わなければならない[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の受信機は、フォワードTSN-サポートパラメータを検出し、それが順TSNチャンクタイプをサポートしていない場合、受信機は、RFC 2960のセクション3.3.3で定義された規則に従わなければならない[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の受信機は前方-TSN-サポートされているパラメータを検出し、それがフォワード-TSNチャンクタイプをサポートしない場合、受信機は、INIT-ACKチャンクでフォワード-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.
エンドポイントは、パラメータを含めるしないことを選択した場合、その後、組合の生活の間に時間がない時に、それはFORWARD TSNを送信したり、処理できることに注意してください。これは、代わりにそれはどんなFORWARD TSNの受信時にピアにエラーを返す、FORWARD TSNチャンクをサポートしていないかのように行動しなければなりません。
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チャンクをサポートしているエンドポイントは、そのエンドポイントを前方-TSN-サポートされているパラメータが含まれていませんINITを受信した場合：
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でフォワード-TSN-サポートされているパラメータを含み、oはピアがFORWARD TSNチャンクをサポートしていないという事実を記録する必要があり、組合の存続期間中いつでもFORWARD TSNチャンクを送ってはいけませんoは、oはSHOULD上位層は、そのような通知を要求した場合、上位層に通知します。
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.
部分的に信頼性の高いデータ転送のためFORWARD TSNチャンク機能を使用したいSCTPエンドポイントは、リモートエンドポイントがないことを示す、（COOKIEにバンドルまたはINIT-ACKで認識されていないパラメータとしてのいずれか）リモートエンドポイントからの操作エラーを受信した場合フォワード-TSN-サポートされているパラメータを認識しない、ローカルエンドポイントは、部分的に信頼性の高いデータ転送をサポートするリモートエンドポイントの無力のその上位層に通知する必要があります。
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チャンクを送信してはならないことに注意してください。
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の実装は、特定のデータチャンクは、（例えば節において「時限信頼性」の定義のようないくつかの特定の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は、別のサービス定義から変化してもよいです。しかし、TSNが「見捨てられた」されたときに実行されるアクションを管理する規則は、サービス定義の間で変化しません。これらのルールは、3.5節に含まれています。
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.
TSNが「見捨てられた」されたときに（どんなPR-SCTPサービス定義のルールごとに有効であるとして）Oアクションは、送信側PR-SCTPの実装は、PR-SCTPの実装はSACK Oの受信時に取らなければならない特別なアクションoを取る必要がありますFORWARD TSNチャンクの生成を管理する規則。
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」を維持し、これは_new_プロトコル変数であり、その値は必ずしも「累積SCTPと同じではありませんRFC 2960のセクション1.4で定義されるようにTSNのAckポイント」[2]、及びその文書の全体にわたって説明したように）。
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）は、（第4節を参照）、特定のPR-SCTPサービス定義の規則によって支配される、SCTPデータ送信者は、すでにTSNが割り当てられている特定のデータチャンクが「放棄されるべきであることを決意を行うことができます」。
When a data chunk is "abandoned", the sender MUST treat the data
chunk as being finally acked and no longer outstanding.
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] RFC 2960の7.2.2項で定義されており、この「捨てられた」データチャンクをもとにcwndを進めてはならないようpartial_bytes_ackedに「捨てられた」データチャンクを信用してはなりません。
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.
それは断片化されたメッセージの一部である場合TSNは、「放棄」されA3）は、他の全ての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を受信するたびにRFC 2960のセクション6.2.1で定義されるように、それは最初に通常の手順を使用してSACKを処理しなければならない[2]。
The data sender MUST then perform the following additional steps:
データの送信者は、次の追加手順を実行する必要があります。
C1) Let SackCumAck be the Cumulative TSN ACK carried in the
received SACK.
If (Advanced.Peer.Ack.Point < SackCumAck), then update
Advanced.Peer.Ack.Point to be equal to SackCumAck.
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が累積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 ... ...
... ... Adv.Ack.Pt-> 102 102 103 103はAdv.Ack.P-> 104放棄104を放棄放棄ACKさACKさは、105 105 106がACKさ106がACKさ放棄しました...
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.
ステップC1とC2の後に、「Advanced.Peer.Ack.Point」を受信SACKで運ば累積TSN ACKより大きい場合C3）、データ送信側はデータを送信しなければならないの最新値を含むFORWARD TSNチャンクを受信機"Advanced.Peer.Ack.Point"。以下ルールF2で定義されている送信者がFORWARD TSNの送信を遅らせることができることに留意されたいです。実装上の注意：それは、アドレスが確認されているものでなければなりませんという唯一の制限に送信しようとする送信先アドレスへと実装決定です。
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 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.
C4）チャンクが有効なストリームとシーケンス番号（すなわち、それが指示された）を有している場合には、各「放棄」TSN、FORWARD TSNの送信者が決定しなければならないため。チャンクが有効なストリームとシーケンス番号を持っている場合、送信者はFORWARD TSNにストリームとシーケンス番号を含まなければなりません。この情報は、簡単にストリームの再注文キュー上の任意の鎖TSNの待機を見つけるために、受信機を可能にします。各ストリームは、一度だけ報告されるべきです。これは、複数の捨てられたメッセージが同じストリームで発生した場合、その後、唯一の最高捨てられたストリームのシーケンス番号が報告されていることを意味します。 FORWARD TSNの合計サイズは、単一のMTUに収まらない場合は、FORWARD TSNの送信者は、単一の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が送信された場合、送信者は少なくとも一つの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.
C5 - A5）T3-RTXタイマーが期限切れになるときはいつでも、任意の宛先に、送信者はC2で概説した手順に従って、「Advanced.Peer.Ack.Point」を推進しようとする必要があります。
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）のデータ送信者は、常に効率のためのアウトバウンド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.
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チャンクの送信に適用された遅延は200ミリ秒を超えてはならないし、500ミリ秒を超えてはなりません。言い換えれば、実装は500msの下に、この値を下げるかもしれませんが、500ミリ秒を超える、それを発生させてはなりません。
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 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.
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）SACKで運ば累積TSN ACKがよりも早い場合、RFC 2960に記載されているようにアウトオブオーダ袋の検出基準が同じままでなければならないことがあり、SACKのみアウトオブオーダーであると考えられます（すなわち、比較は「Advanced.Peer.Ack.Point」に対して行われてはならない）以前の受信SACK。
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).
チャンクを「放棄」する決定がなされた場合、RFC 2960で指定されたチャンクを後で（例えば、いずれかの方法で再送信のためにマークされていたであろう場合F5）、関係なく、そのような決定がなされているか、適切な輻輳調整が行われてはなりませんT3-タイムアウトや高速再送によります）。
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の受信側実装は、サービス定義は、ホストA.すべての送信側の機能によってサポートされていなくても、エンドポイントBに送信者によって使用される任意のPR-SCTPサービス定義をサポートすることが可能であること必要なことは、受信側が正しくセクション3.3で指定されるようにフォワードTSN-サポートパラメータを処理し、正しく以下に示すようにFORWARD TSNチャンクの受信を扱うことです。
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.
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:
到着したFORWARD TSNに運ば新しい累積TSNが103であると仮定すると：
in-queue before processing in-queue after processing the FORWARD TSN ==> the FORWARD TSN and further advancement
イン・キュー==> FORWARD TSNし、さらに発展FORWARD TSNを処理した後に、キュー処理する前に、
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 104受信 - - 103が欠落して103 - cum.TSN.Pt-> 102 102受信部105はcum.TSN.Pt-> 105 107 107が受信した受信欠落106を欠落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.
以上の処理後、データ受信器はより早く、または新しい累積TSNポイントに等しい欠落した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を扱わなければなりませんし、その累積をアップデートしてはいけませんTSN。受信機は、以前のSACKを示すことができる、そのような重複は、ネットワーク内で失われたので、そのピア（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チャンクは、到着データチャンクを受信した場合（すなわち、RFC 2960 [2]のセクション6.2で指定された遅延された袋のルールに従う）としてSACKを送信する目的のために、受信機は、同じ規則に従わなければならない任意の時間。
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.
データチャンクは、（順序付き配信を示す）「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。そのような任意の二本鎖のデータは、上位層のアプリケーションにすぐに利用できるようにすべきです。
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を使用したアプリケーションは、可能な欠落しているメッセージに注意する必要があります。ストリーム・シーケンス番号は、介在するメッセージがスキップされたことを決定するために、このような場合に、使用することができます。介入のメッセージが欠落している場合は、メッセージを処理するか、他のいくつかの是正措置をとるために、アプリケーションの決定です。
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ポイントに等しい一の以上のTSNが欠落している任意の部分再組立てメッセージを削除する必要があります。受信機は、部分配信APIを呼び出した場合には、通知は、メッセージが部分的に完了しません配信される上位層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が到着しない場合（すなわち、並べ替えをネットワークに起因する）、次いで、受信機は、[2]、重複データを処理するためのRFC 2960で定義された通常の規則に従う、FORWARD TSNを受信し、累積確認応答ポイントを更新した後、なお。これは、受信機はチャンクをドロップすると、次のアウトバウンドSACKチャンク内の重複としてそれを報告することを意味します。
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標準を書きたいことが人のために、提供するサービスの標準的な定義を参照できることが重要です。必要に応じて、追加のサービスを定義するためのガイドラインを提供しつつ、このセクションでは、そのようなサービスの例の定義を提供します。それぞれのそのようなサービスは、別々の新しい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は、ある特定の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サービスの仕様のためのガイドラインを提供します。
o Finally, Section 4.4 describes some additional usage notes that upper layer protocol designers and implementors may find helpful.
O最後に、4.4節では、上位層プロトコルの設計者と実装者は役に立ちかもしれないいくつかの追加の使用上の注意について説明します。
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節は、RFC 2960の一部（E）は、[2]を参照してくださいその文書。）
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は、第1の送信を送信した場合は、ベース・プロトコルでは、メッセージは、通常の信頼性のあるメッセージとして送信しなければなりません。混雑のエピソードの間、これは他の（非存続期間の期限が切れ）のメッセージのために使用されている可能性が再送廃棄物の帯域幅として、特に残念なことです。
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.
メッセージのライフタイムパラメータがSCTP_LIFETIME_RELIABLE（又は不特定の参照セクション5）である場合TR1）が、そのメッセージは、単に基地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.
それは限り寿命がまだ満了していないとして、通常の信頼性のSCTPメッセージであるかのようTR2）寿命パラメータは（セクション5を参照）SCTP_LIFETIME_RELIABLEされていない場合は、その後、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を割り当ててはならないが、その代わりに、上位層に通知を発行し、メッセージを放棄すべきです。
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送信者は、メッセージの寿命を評価しなければなりません。メッセージの有効期間が満了している場合は、
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.
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はいつでも、メッセージの寿命を評価することができます。 TSNが割り当てられていない期限切れのメッセージがルールTR3あたりとして取り扱うことができます。 TSNを割り当てられている期限切れのメッセージがルールTR4あたりとして取り扱うことができます。
TR6) The sending application MUST NOT change the lifetime parameter once the message is passed to the sending SCTP.
メッセージを送信するSCTPに渡された後TR6）送信側アプリケーションは、寿命パラメータを変更しないでください。
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.
実装注：ルールTR1〜TR4を介して、各メッセージのために別個のタイマーを維持するために、実装が必要回避するような方法で設計されています。代わりに、寿命がアクションがすでにTSN割り当て、送信、または再送タイムアウトの満了として、取られているメッセージの寿命の点で評価することのみ必要です。ルールTR5は有効期限が切れる時点ですぐに評価され、その寿命を必要とせずに、他の都合の機会に寿命を評価するための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."
ことを指摘しながら、RFC 2960のセクション10.1 [2]、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.
このセクションでは、我々は、FORWARD-TSNチャンクはピアによってサポートされているかどうかを示すために、SCTPサービスのユーザを許可するプリミティブ関連付けるために添加され得る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:
RFC 2960 ASSOCIATEプリミティブが「上層が特定のピアエンドポイントへの関連付けを開始することを可能にする」ことを示しています。これは次のように構成されています。
Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]
フォーマット：ASSOCIATE（ローカルSCTPインスタンス名、宛先輸送ADDR、アウトバウンドストリーム数） - >アソシエーションID [、送信先トランスポートADDRリスト] [、アウトバウンドストリーム数]
This extension adds one new OPTIONAL return value, such that the new primitive reads as follows:
この拡張は、次のように新しいプリミティブを読み込むように、1つの新しいオプションの戻り値を追加します。
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、アウトバウンドストリーム数） - >アソシエーションID [、送信先トランスポート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.
注：プリミティブASSOCIATEは、非ブロッキング呼び出しとして実装されている場合は、RFC 2960を1として、新しいオプションの戻り値は通信UP通知を使用して関連パラメータで渡されなければなりません。
The new OPTIONAL parameter "forward tsn supported" is a boolean flag:
新しいオプションのパラメータは、「サポートされ、前方TSNは、」ブールフラグです。
(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)
フォーマット：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".
ブール・パラメータを有効、trueに設定されている場合、将来の終点団体時にPR-SCTPを可能にします。ブール・パラメータがfalseに設定されている場合は、ローカルエンドポイントは、PR-SCTPのサポートをアドバタイズしませんので、今後の関連付け機能を無効にします。すなわち、PR-SCTPを有効にするために、ユーザが「真」に設定可能フラグをこのAPIオプションを呼び出す必要があります、このオプションはデフォルトで無効にすることをお勧めします。
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。
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:
好ましくは、この説明は、任意のものを示し、RFC 2960のセクション10で提供する抽象APIでプリミティブ[2]を参照すべきです。
* 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),
既存のプリミティブに追加する*追加のパラメータ（これらは任意であるべきであり、デフォルト値が示されなければなりません）、
* 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.)
送信側の実装によって使用されるルールの説明は、場合まだ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を割り当てられているメッセージの送信または再送信を放棄し、0回以上送信され、おそらくは再送信されていてもよい時を決定します。
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.
（そのメッセージが「放棄」された場合、セクション3.4で定義されるように、すなわち、）送信側の実装がTSNを割り当てられているメッセージを送信することを断念（G1）、送信側は、マークしなければならないTSNその前方にTSNの対象として、およびFORWARD TSNチャンクの送信に関するセクション3.4の規則に従わなければなりません。
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サービスのための標準的なサービス名は「時限信頼性」です。
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オーバー例えば、ファイバチャネルまたはSCSI）のために有用です。 PR-SCTPを使用すると、これが可能になる - 上位層は、単純に欠落しているデータを検出するために、そのストリームの到着したユーザメッセージのストリームシーケンス番号を調べる必要があります。注、そのストリーム上のすべてのメッセージが順番に送信された場合、この検出にのみ動作します、すなわち、「U」ビットがセットされていません。
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 - ユーザインタフェース表示実装によって定義され、メッセージが完全に信頼できるとみなされるべきであることを示すために使用されます。
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.カロ・ジュニア、ジョンLoughney、ジョンピーターソン、イバン・ロドリゲス・アリアス、イアンRytina、チップシャープなどに感謝したいと思います。
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].
この文書では、以外SCTPへの新たな安全保障上の懸念、既にRFC 2960で文書化を導入していない[2]。具体的には、この文書[4] [2] RFC 3436により識別RFC 2960内で順序付けられていないデータと同じセキュリティ上の問題を共有します。 PR-SCTP拡張を使用するアプリケーションは、トランスポート層セキュリティを使用しないでください。さらなる詳細は、RFC 3436に見出すことができる[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
MIMは、既におよび/または源泉徴収を変化させることができるので、メッセージを引き起こす能力をスキップすること（すなわち、FORWARD TSNチャンク）は、のman-in-the-middle（MIM）のための新たな攻撃を提供していません注意してくださいデータは、効果的にメッセージをスキップします。しかし、FORWARD TSNチャンクは、簡単のために作るためのメカニズムを提供してい
MIM to skip selective messages when the application has this feature enabled since the MIM would have less state to maintain.
MIMアプリケーションはMIMが維持するために以下の状態を持っているであろうからこの機能が有効になっていたときに、選択的メッセージをスキップします。
IANA has assigned 192 as a new chunk type to SCTP.
IANAは、SCTPの新しいチャンクタイプとして192を割り当てています。
IANA has assigned 49152 as a new parameter type code to SCTP.
IANAは、SCTPの新しいパラメータ型コードとして49152が割り当てられています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[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、 "プロトコルの新世代のための建築に関する注意事項"、SIGCOMM 1990頁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、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。
Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA
ランドールR.スチュワートシスコシステムズ、株式会社8725西ヒギンズロードスイート300シカゴ、IL 60631 USA
Phone: +1-815-477-2127 EMail: rrs@cisco.com
電話：+ 1-815-477-2127 Eメール：rrs@cisco.com
Michael A. Ramalho Cisco Systems, Inc. 1802 Rue de la Porte Wall Township, NJ 07719-3784 USA
マイケルA. Ramalhoシスコシステムズ株式会社1802年ルー・デ・ラ・ポルトウォールタウンシップ、ニュージャージー州07719から3784 USA
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
私はIEモトローラ社1501 W.シュウ再ドライブをXオリンピックアイスQ、＃2309アーリントンハイツ、IL 60004 USA
Phone: +1-847-632-3028 EMail: qxie1@email.mot.com
電話：+ 1-847-632-3028 Eメール：qxie1@email.mot.com
Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
マイケルTuexen大学。応用科学ミュンスターStegerwaldstrの。 39 48565シュタインフルトドイツ
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
コンピュータと情報科学のニューアークのデラウェア州省のフィリップT.コンラッド大学、DE 19716 USA
Phone: +1 302 831 8622 EMail: conrad@acm.org URI: http://www.cis.udel.edu/~pconrad
電話：+1 302 831 8622 Eメール：conrad@acm.org URI：http://www.cis.udel.edu/~pconrad
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。