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

Stream Control Transmission Protocol (SCTP) 部分信頼性拡張

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 (C) The Internet Society (2004). All Rights Reserved.

著作権（c）The Internet Society（2004）。無断転載を禁じます。

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 Associationの両側がこの拡張機能をサポートする場合、SCTP実装では、上層のプロトコルに部分的に信頼できるデータ送信サービスを提供するために使用できます。このメモは、InitとInit ACKの新しいパラメーターと新しいフォワードTSNチャンクタイプで構成されるプロトコル拡張を説明し、このメカニズムを介して上層に提供できる部分的に信頼できるサービスの1つの例を提供します。

   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送信者が1つ以上のデータチャンクを受け取ることを期待していないことをSCTP送信者が同僚に信号できるようにするため、Stream Control Transmission Protocol（SCTP）RFC 2960 [2]の拡張を説明しています。

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ポイントを前方に移動する必要があることを示す単一の新しいチャンクタイプ、フォワードTSN（おそらく、まだ受信および/または認められていない可能性のある1つ以上のデータチャンクをスキップする可能性があります。）

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).

部分的に信頼できるサービスの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. 送信者側の実装がその信頼性レベルを使用して、そのメッセージのさらなる再送信をいつgiveめるかを決定する方法。

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).

フォワード-TSNチャンクが必要であるという事実以外に、これら2つの要素のいずれも「ワイヤー」プロトコルに影響しないことに注意してください。APIと送信者側の実装のみが、サービスが上層に定義される方法によって影響を受けます。したがって、原則として、ワイヤー内のプロトコルを変更せずに、特定のSCTP実装に多くの種類の部分的に信頼できるサービスを実装することが可能です。また、受信者の唯一の役割は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によって部分的に信頼できるサービスの限られた数の標準定義を標準化することをお勧めします。そのような定義の1つである「タイミングされた信頼性」は、このドキュメントに含まれています。このドキュメントで提案されている拡張機能を考えると、その他の定義は、オンザワイヤプロトコルをさらに変更することなく、必要性が生じるにつれて標準化される可能性があります。

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データグラムの数（したがってネットワークオーバーヘッド）を減らすことができます。さらに、この多重化により、信頼性の高い信頼性の低い接続のために異なるポートを使用することと、ポートの節約が可能になります。

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].

キーワードは、このドキュメントに表示される場合、BCP 14、RFC 2119 [1に記載されているように解釈される場合、必要な、必要も、要求も、推奨、推奨、推奨、推奨、推奨、推奨、推奨、推奨、推奨、推奨されない、または推奨されてはならない、してはならない、そうでなければ、推奨してはならない、してはならない、そうでなければならない、してはならない、しないでください。]。

Comparisons and arithmetic on Transport Sequence Numbers (TSNs) are governed by the rules in Section 1.6 of RFC 2960 [2].

輸送シーケンス番号（TSNS）の比較と算術は、RFC 2960のセクション1.6のルールに準拠しています[2]。

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)
        

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チャンクをサポートできることをピアに通知するために、この任意 (OPTIONAL) のパラメータを含めてもよいです (MAY)（詳細についてはセクション3.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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Parameter Type = 49152     |  Parameter Length = 4         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type: 16 bit u_int

タイプ：16ビットu_int

49152, indicating Forward-TSN-Supported parameter

49152、フォワードTSNサポートパラメーターを示しています

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.
        

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をすべて受信済みとみなし、以降のSACKでそれらをギャップとして報告するのをやめなければなりません (MUST)。

Stream-N: 16 bit u_int

Stream-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

Stream Sequence-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の受信者は、Stream-NおよびStream Sequence-Nフィールドを使用して、ストリーム並べ替えキューに残っている取り残されたTSNの配信を可能にすることができます。このフィールドは、順序なしとしてマークされたDATAチャンクに対応するTSNを報告してはなりません (MUST NOT)。順序付きDATAチャンクの場合、このフィールドに入力しなければなりません (MUST)。

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-supportedパラメータを含めてもよいです (MAY)。

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チャンクをサポートしていないかのように動作しなければならず (MUST)、FORWARD TSNを受信した際にはピアにERRORを返さなければなりません。

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-Supportedパラメータを検出し、Forward-TSNチャンクタイプをサポートしていない場合、受信者はRFC 2960 [2] のセクション3.3.3で定義されている規則に従わなければなりません (MUST)。

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-Supportedパラメータを検出し、Forward-TSNチャンクタイプをサポートしていない場合、受信者はRFC 2960 [2] のセクション3.3.3で定義されている規則に従わなければなりません (MUST)。

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-Supportedパラメータを検出し、Forward-TSNチャンクタイプをサポートしている場合、受信者はINIT-ACKチャンクにForward-TSN-supportedパラメータを含めて応答してもよいです (MAY)。

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チャンクをサポートしていないかのように動作しなければならず (MUST)、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:

フォワード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.
        

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エンドポイントが、リモートエンドポイントがForward-TSN-Supportedパラメータを認識しないことを示す運用エラーをリモートエンドポイントから受信した場合（COOKIEにバンドルされているか、INIT-ACK内の認識されないパラメータとして）、ローカルエンドポイントは、リモートエンドポイントが部分的に信頼性のあるデータ転送をサポートできないことを自身の上位層に通知すべきです (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) 開始プロセスを終了します（開始プロセスがすでに終了している場合、エンドポイントは中止を送信する必要があるかもしれません）、ピアが新しい協会に要求された機能を提供できないことを考慮して、または

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) 開始プロセスを継続します（開始プロセスがすでに完了している場合、エンドポイントは単にアソシエーションを部分信頼性をサポートしていないとマークしなければなりません (MUST)）。ただし、部分的に信頼性のあるデータ送信がサポートされていないことを理解した上で行います。この場合、運用エラーを受信したエンドポイントは、FORWARD TSNチャンクがサポートされていないことに留意すべきであり (SHOULD)、アソシエーションの存続期間中はいかなる時もFORWARD TSNチャンクを送信してはなりません (MUST NOT)。

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の「期限付き信頼性」の定義など）を管理する規則に従って、特定のデータチャンクをこれ以上送信または再送信すべきではない (SHOULD NOT) と判断してもよいです (MAY)。本書の目的のために、SCTP送信者がこの決定を下したデータチャンクを指す用語として「放棄された (abandoned)」を定義します。

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.

o アクションTSNが「放棄」されている場合（どんなPR-SCTPサービス定義が有効である場合の規則に従って）送信側のPR-SCTP実装が行わなければなりません）フォワード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）送信者は、ピアごとにピアごとに「advanced.peer.ack.point」を維持します。TSN ACKポイント「RFC 2960 [2]のセクション1.4で定義されており、そのドキュメント全体で説明されています。

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) 特定のPR-SCTPサービス定義の規則（セクション4を参照）に従って、SCTPデータ送信者は、すでにTSNが割り当てられている特定のデータチャンクを「放棄」すべきである (SHOULD) と随時判断することがあります。

When a data chunk is "abandoned", the sender MUST treat the data chunk as being finally acked and no longer outstanding.

データチャンクが「放棄」された場合、送信者はそのデータチャンクを最終的にACKされたものとして扱い、未解決 (outstanding) ではなくなったものとして扱わなければなりません (MUST)。

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.

送信者は、RFC 2960 [2] のセクション7.2.2で定義されているpartial_bytes_ackedに「放棄された」データチャンクを算入してはならず (MUST NOT)、この「放棄された」データチャンクに基づいてcwndを進めてはなりません (MUST NOT)。

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も同時に放棄しなければなりません (MUST)。

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 [2] のセクション6.2.1で定義されている通常の手順を使用してSACKを処理しなければなりません (MUST)。

The data sender MUST then perform the following additional steps:

その後、データ送信者は次の追加の手順を実行しなければなりません (MUST)。

C1) Let SackCumAck be the Cumulative TSN ACK carried in the received SACK.

c1）SackCumAckを、受信した袋に掲載された累積TSN ACKとします。

If (Advanced.Peer.Ack.Point < SackCumAck), then update Advanced.Peer.Ack.Point to be equal to SackCumAck.

if（advanced.peer.ack.point <SackCumAck）に、advanced.peer.ack.pointを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:

累積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.Pt-> 102 acked                      102 acked
                    103 abandoned                    103 abandoned
                    104 abandoned        Adv.Ack.P-> 104 abandoned
                    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) ステップC1およびC2の後、「Advanced.Peer.Ack.Point」が受信したSACKに含まれるCumulative TSN ACKより大きい場合、データ送信者はデータ受信者に「Advanced.Peer.Ack.Point」の最新値を含むFORWARD TSNチャンクを送信しなければなりません (MUST)。送信者は、以下の規則F2で定義されているようにFORWARD TSNの送信を遅延させてもよい (MAY) ことに注意してください。実装上の注意: どの宛先アドレスに送信されるかは実装の判断ですが、そのアドレスは確認済み (CONFIRMED) でなければならない (MUST) という唯一の制限があります。

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の送信者は、チャンクに有効なストリームおよびシーケンス番号があるか（すなわち順序付きであったか）を判断しなければなりません (MUST)。チャンクに有効なストリームおよびシーケンス番号がある場合、送信者はストリームおよびシーケンス番号をFORWARD TSNに含めなければなりません (MUST)。この情報により、受信者はストリーム並べ替えキューで待機している取り残されたTSNを容易に見つけることができます。各ストリームは1回だけ報告すべきです (SHOULD)。つまり、同じストリームで複数の放棄されたメッセージが発生した場合、最も高い放棄されたストリームシーケンス番号のみが報告されます。FORWARD TSNの合計サイズが単一のMTUに収まらない場合、FORWARD TSNの送信者は、単一のMTUに収まる最後のTSNまでAdvanced.Peer.Ack.Pointを下げるべきです (SHOULD)。

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タイマーが動作していることを保証しなければなりません (MUST)。実装上の注意: 規則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タイマーが満了するたびに、送信者はC2〜C5で概説されている手順に従って「Advanced.Peer.Ack.Point」を進めようと試みるべきです (SHOULD)。

The following additional rules govern the generation of FORWARD TSN chunks:

次の追加のルールは、フォワードTSNチャンクの生成を支配しています。

F1) An endpoint MUST NOT use the FORWARD TSN for any purposes other than circumstances described in this document.

F1) エンドポイントは、本書に記載されている状況以外のいかなる目的でもFORWARD TSNを使用してはなりません (MUST NOT)。

F2) The data sender SHOULD always attempt to bundle an outgoing FORWARD TSN with outbound DATA chunks for efficiency.

F2) データ送信者は、効率化のために、送信するFORWARD TSNを送信DATAチャンクと常にバンドルすることを試みるべきです (SHOULD)。

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の送信を遅延させることを選択してもよいです (MAY)。

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.

実装注：実装は、重複するTSNを他のすべてのサックのみを送信するか、完全なRTTを待ってから重複した前方TSNを送信することによって、送信される重複した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:

実装注：実装により、実行中のプロトコルの特定のタイミング要件を満たすために、前方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チャンクの送信に適用されるいかなる遅延も、200msを超えるべきではなく (SHOULD NOT)、500msを超えてはなりません (MUST NOT)。言い換えると、実装はこの値を500ms未満に下げてもよいですが (MAY)、500msを超えて上げてはなりません (MUST NOT)。

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.

注：フォワードTSNチャンクの送信を遅らせると、受信者が受信機に保持されている他のデータを再注文のために配信する能力が遅れている場合があります。200msと500msの値は、RFC 2960 [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) 順序外SACKの検出基準は、RFC 2960に規定されているものと同じままでなければなりません (MUST)。すなわち、SACKは、SACKに含まれるCumulative TSN ACKが以前に受信したSACKのそれより前である場合にのみ順序外とみなされます（すなわち、「Advanced.Peer.Ack.Point」との比較を行ってはなりません (MUST NOT)）。

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) チャンクを「放棄」する決定がなされた場合、そのような決定がどのように下されたかに関係なく、そのチャンクが後で（例えばT3-TimeoutまたはFast Retransmitによって）再送信のためにマークされていたはずであれば、RFC 2960で指定されている適切な輻輳調整を行わなければなりません (MUST)。

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サポートされたパラメーターを正しく処理し、以下に指定する前方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.

PR-SCTP受信側へのDATAチャンクの到着は、基本プロトコルSCTP受信側へのDATAチャンクの到着とまったく同じように進行します——すなわち、受信側は、RFC 2960 [2] で定義されている重複検出、ギャップ検出、SACK生成、Cumulative TSNの前進などの同じTSN処理を実行しなければなりません (MUST)——ただし、以下の例外と追加事項があります。

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チャンクが到着した場合、データ受信側はまずそのCumulative TSNポイントをFORWARD TSNチャンクに含まれる値に更新しなければならず (MUST)、次に、以下の例で示すように、可能であれば累積TSNポイントをローカルでさらに前進させなければなりません (MUST)。

Assuming that the new cumulative TSN carried in the arrived FORWARD TSN is 103:

到着前のTSNで運ばれる新しい累積TSNは103であると仮定すると：

       in-queue before processing      in-queue after processing
            the FORWARD TSN      ==>   the FORWARD TSN and further
                                                advancement
        

       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
                    ...                            ...
        

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.

上記の処理の後、データ受信側は、新しいCumulative TSNポイント以前の欠落しているTSNの報告を停止しなければなりません (MUST)。

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チャンクに含まれる「New Cumulative TSN」値が現在のCumulative TSNポイントより前または同じであることが判明した場合、データ受信側はこのFORWARD TSNを期限切れとして扱わなければならず (MUST)、そのCumulative TSNを更新してはなりません (MUST NOT)。このような重複は以前のSACKがネットワークで失われたことを示している可能性があるため、受信側はそのピア（FORWARD TSNの送信者）にSACKを送信すべきです (SHOULD)。

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チャンクを受信した場合と同じ規則に従わなければなりません (MUST)（すなわち、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.

データチャンクが「U」ビットが「0」に設定されている（順序付けされた配達を示す）に到着し、順番に到着するたびに、受信者は並べ替えのためにチャンクを保持する必要があります。PR-SCTPでは、データチャンクが待機されていることが再送信されない可能性があるため、前方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内にリストされているストリームシーケンス番号以前のストリームシーケンス番号を直ちに配信可能にしなければなりません (MUST)。このような取り残されたデータは、上位層アプリケーションに直ちに利用可能にすべきです (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受信データを使用したアプリケーションは、欠落しているメッセージの可能性を認識する必要があります。このような場合、ストリームシーケンス番号を使用して、介在するメッセージがスキップされていることを判断できます。介在するメッセージが欠落している場合、メッセージを処理したり、他の是正措置を講じることができます。

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を受信して処理した後、データ受信側は再アセンブリキューの更新に注意を払わなければなりません (MUST)。受信側は、新しいCumulative TSNポイント以前の1つ以上のTSNが依然として欠落している部分的に再アセンブルされたメッセージを削除しなければなりません (MUST)。受信側が部分配信APIを呼び出していた場合、部分的に配信されたメッセージが完了しないことを上位層APIに通知するための通知も生成すべきです (SHOULD)。

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を受信して累積確認ポイントを更新した後、スキップされたTSNが到着した場合（つまり、ネットワークの並べ替えにより）、レシーバーは重複したデータを処理するためにRFC 2960 [2]で定義されている通常のルールに従います。。これは、レシーバーがチャンクを落とし、次のアウトバウンドサックチャンクで重複として報告することを意味します。

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サービスの仕様のガイドラインを提供します。

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 Primitiveで指定された生涯パラメーターの意味を変更します（RFC 2960のセクション10.1、パート（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プロトコルでは、古くなったデータの送信を避けるためにlifetimeパラメータが使用されます。特定のメッセージに対して生存期間の値が指定され、その生存期間が満了すると、SCTPはこのメッセージの送信をキャンセルし、データの最初の送信が行われなかった場合（rwndやcwndの制限、その他の理由による）、ULPに通知します。しかし、基本プロトコルでは、生存期間が満了する前にSCTPが最初の送信を行った場合、そのメッセージは通常の信頼性のあるメッセージとして送信しなければなりません (MUST)。輻輳時には、他の（生存期間が満了していない）メッセージに使用できたはずの帯域幅が再送信によって浪費されるため、これは特に好ましくありません。

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) lifetimeパラメータがSCTP_LIFETIME_RELIABLE（セクション5を参照）でない場合、生存期間がまだ満了していない限り、SCTP送信者はそのメッセージを通常の信頼性のあるSCTPメッセージであるかのように扱わなければなりません (MUST)。

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送信者はそのメッセージの生存期間を評価しなければなりません (MUST)。満了している場合、SCTP送信者はそのメッセージにTSNを割り当ててはならず (MUST NOT)、代わりに上位層に通知を発行してメッセージを放棄すべきです (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 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.

TR4) すでにTSNが割り当てられているメッセージを送信または再送信する前に、SCTP送信者はメッセージの生存期間を評価しなければなりません (MUST)。メッセージの生存期間が満了している場合、SCTP送信者は、そのTSNをFORWARD TSNの対象としてマークし、セクション3.5で規定されている規則に従ってメッセージを「放棄」しなければなりません (MUST)。これはセクション4.3で定義されている要件G1を満たすことに留意してください。実装上の注意: 実装は、RFC 2960 [2] セクション10.1に記載されているように、TSNの割り当てを遅延させるべきです (SHOULD)。そのような場合、TSNを割り当てる前にlifetimeパラメータをチェックすべきであり、これにより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が割り当てられていない満了メッセージは、規則TR3に従って処理してもよいです (MAY)。TSNが割り当てられている満了メッセージは、規則TR4に従って処理してもよいです (MAY)。

TR6) The sending application MUST NOT change the lifetime parameter once the message is passed to the sending SCTP.

TR6) メッセージが送信側SCTPに渡された後は、送信側アプリケーションはlifetimeパラメータを変更してはなりません (MUST NOT)。

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は、フォワード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 [2]のセクション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.

このセクションでは、SCTPサービスユーザーがフォワードTSNチャンクがピアによってサポートされているかどうかを示すために、アソシエイトプリミティブに追加される可能性のある追加の返品値について説明します。

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: Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]

RFC 2960は、アソシエイトプリミティブが「上層が特定のピアエンドポイントに関連性を開始できる」ことを示しています。次のように構造化されています：形式：Associate（ローカルSCTPインスタンス名、宛先輸送ADDR、アウトバウンドストリームカウント） - > Association ID [、Destination Transport addr List] [、Autbound Stream Count]

This extension adds one new OPTIONAL return value, such that the new primitive reads as follows:

この拡張機能により、1つの新しい任意 (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、アウトバウンドストリームカウント） - > Association ID [、Destination Transport addr List] [、Autbound Stream Count] [、Forward 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.

注: RFC 2960に基づき、ASSOCIATEプリミティブがノンブロッキング呼び出しとして実装されている場合、この新しい任意 (OPTIONAL) の戻り値は、COMMUNICATION UP通知を使用してアソシエーションパラメータとともに渡されるものとします。

The new OPTIONAL parameter "forward tsn supported" is a boolean flag:

新しい任意 (OPTIONAL) のパラメータ「forward tsn supported」はブールフラグです。

(0) false [default] indicates that FORWARD TSN is not enabled by both endpoints.

(0) false [デフォルト]は、フォワードTSNが両方のエンドポイントによって有効になっていないことを示します。

(1) true indicates that FORWARD TSN is enabled on both endpoints.

(1) trueは、両方のエンドポイントでフォワード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オプションを「true」に設定してこの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輸送送信者に、決定に必要な情報を提供するために必要な情報を提供する特定のメッセージの送信をいつgiveめます。

Preferably, this description should reference the primitives in the abstract API provided in Section 10 of RFC 2960 [2], indicating any:

好ましくは、この説明は、RFC 2960 [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を割り当てられていないメッセージをいつgiveめる時期を決定します。また、この説明は、どのプロトコルイベントが評価をトリガーし、どのアクションをとるべきかを示している必要があります（たとえば、通知）。

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. Sender側の実装で使用されているルールの説明は、既にTSNを割り当てられており、送信され、ゼロ以上に再送信されたメッセージの送信または再送信をいつgiveめます。

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）は、どのプロトコルイベントが評価をトリガーするか、および送信者がメッセージの送信をgiveめなければならない決定が行われた場合に実行するアクションを示す必要があります（例えば、ULPへの通知。））

Note that in any PR-SCTP service, the following rule MUST be specified to avoid a protocol deadlock:

いかなるPR-SCTPサービスにおいても、プロトコルのデッドロックを回避するために以下の規則を指定しなければならない (MUST) ことに注意してください。

(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をFORWARD TSNの対象としてマークしなければならず (MUST)、FORWARD TSNチャンクの送信に関するセクション3.4の規則に従わなければなりません (MUST)。

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実装のAPIのドキュメントで使用して、上層がPR-SCTPサービスのどの定義を適用するかを示す方法を示すこともできます。セクション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.

著者は、ブライアン・ビドロック、スコット・ブラッドナー、ジョン・バーガー、アルマンド・L・カロ・ジュニア、ジョン・ラフニー、ジョン・ピーターソン、イヴァン・アリアス・ロドリゲス、イアン・リティナ、チップ・シャープなどに感謝したいと思います。

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].

このドキュメントでは、RFC 2960 [2]ですでに文書化されているもの以外に、SCTPに新しいセキュリティ上の懸念は導入されていません。 特に、このドキュメントは、RFC 3436 [4]によって特定されたRFC 2960 [2]内の非注文データと同じセキュリティ問題を共有しています。 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 to skip selective messages when the application has this feature enabled since the MIM would have less state to maintain.

MIMはすでに変更および/または源泉徴収できるため、メッセージをスキップする（つまり、フォワードTSNチャンク）を使用する能力（つまり、フォワードTSNチャンク）は、中間の男（MIM）に新しい攻撃を提供しないことに注意してください。データ、したがってメッセージを効果的にスキップします。ただし、Forward TSN Chunkは、MIMがこの機能を有効にしている場合に、MIMが選択的なメッセージを簡単にスキップできるようにするメカニズムを提供します。

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に割り当てました。

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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] 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.

[3] Clark, D. and D. Tennenhouse, "Architectural Considerations for a New Generation of Protocols", SIGCOMM 1990 pp. 200-208, September 1990.

[3] Clark, D. and D. Tennenhouse、「新世代のプロトコルに対する建築上の考慮事項」、Sigcomm 1990pp。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., Rescorla, E. and M. Tuexen、「ストリーム制御伝送プロトコルを介した輸送層セキュリティ」、RFC 3436、2002年12月。

Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA

Randall R. Stewart Cisco Systems、Inc。8725 West Higgins Road Suite 300 Chicago、IL 60631 USA

Phone: +1-815-477-2127 EMail: rrs@cisco.com Michael A. Ramalho Cisco Systems, Inc. 1802 Rue de la Porte Wall Township, NJ 07719-3784 USA

電話：1-815-477-2127メール：rrs@cisco.com Michael A. Ramalho Cisco Systems、Inc。1802 Rue de la Porte Wall Township、NJ 07719-3784 USA

   Phone: +1.732.449.5762
   EMail: mramalho@cisco.com
        

Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA

Qiaobing Xie Motorola、Inc。1501 W. Shure Drive、＃2309 Arlington Heights、IL 60004 USA

   Phone: +1-847-632-3028
   EMail: qxie1@email.mot.com
        

Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany

マイケル・チュークセン大学。Applied Sciences MuensterStegerwaldStraßeの。39 48565 Steinfurtドイツ

   EMail: tuexen@fh-muenster.de
        

Phillip T. Conrad University of Delaware Department of Computer and Information Sciences Newark, DE 19716 USA

フィリップT.コンラード大学デラウェア大学コンピューター情報科学部ニューアーク、19716年米国

   Phone: +1 302 831 8622
   EMail: 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）The Internet Society（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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。