[要約] RFC 3286は、Stream Control Transmission Protocol（SCTP）の概要と目的を説明している。 SCTPは、信頼性の高いデータ転送とフロー制御を提供するプロトコルである。 このRFCは、SCTPの基本的な機能と利点を理解するための導入となっている。
Network Working Group L. Ong
Request for Comments: 3286 Ciena Corporation
Category: Informational J. Yoakum
Nortel Networks
May 2002
An Introduction to the Stream Control Transmission Protocol (SCTP)
ストリーム制御伝送プロトコル（SCTP）の紹介
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol.
このドキュメントは、ストリーム制御伝送プロトコル（SCTP）によってサポートされる機能の高レベルの紹介を提供します。汎用輸送プロトコルとして、SCTPの潜在的なユーザー向けのガイドとして意図されています。
The Stream Control Transmission Protocol (SCTP) is a new IP transport protocol, existing at an equivalent level with UDP (User Datagram Protocol) and TCP (Transmission Control Protocol), which provide transport layer functions to many Internet applications. SCTP has been approved by the IETF as a Proposed Standard [1]. The error check algorithm has since been modified [2]. Future changes and updates will be reflected in the IETF RFC index.
Stream Control Transmission Protocol（SCTP）は、UDP（ユーザーデータグラムプロトコル）とTCP（伝送制御プロトコル）と同等のレベルに存在する新しいIP Transport Protocolであり、多くのインターネットアプリケーションに輸送層機能を提供します。SCTPは、提案された標準としてIETFによって承認されています[1]。エラーチェックアルゴリズムはその後変更されました[2]。将来の変更と更新は、IETF RFCインデックスに反映されます。
Like TCP, SCTP provides a reliable transport service, ensuring that data is transported across the network without error and in sequence. Like TCP, SCTP is a session-oriented mechanism, meaning that a relationship is created between the endpoints of an SCTP association prior to data being transmitted, and this relationship is maintained until all data transmission has been successfully completed.
TCPと同様に、SCTPは信頼できる輸送サービスを提供し、データがネットワーク全体でエラーなしで順番に輸送されるようにします。TCPと同様に、SCTPはセッション指向のメカニズムです。つまり、データが送信される前にSCTPアソシエーションのエンドポイント間に関係が作成され、すべてのデータ伝送が正常に完了するまでこの関係が維持されます。
Unlike TCP, SCTP provides a number of functions that are critical for telephony signaling transport, and at the same time can potentially benefit other applications needing transport with additional performance and reliability. The original framework for the SCTP definition is described in [3].
TCPとは異なり、SCTPはテレフォニーシグナリングトランスポートに重要な多くの機能を提供し、同時に、パフォーマンスと信頼性を備えた輸送を必要とする他のアプリケーションに潜在的に利益をもたらす可能性があります。SCTP定義の元のフレームワークは[3]で説明されています。
SCTP is a unicast protocol, and supports data exchange between exactly 2 endpoints, although these may be represented by multiple IP addresses.
SCTPはユニキャストプロトコルであり、正確に2つのエンドポイント間のデータ交換をサポートしますが、これらは複数のIPアドレスで表される場合があります。
SCTP provides reliable transmission, detecting when data is discarded, reordered, duplicated or corrupted, and retransmitting damaged data as necessary. SCTP transmission is full duplex.
SCTPは、信頼性の高い送信を提供し、データが破棄、並べ替え、複製、または破損したときに検出され、必要に応じて損傷したデータを再送信します。SCTP伝送は完全な二重です。
SCTP is message oriented and supports framing of individual message boundaries. In comparison, TCP is byte oriented and does not preserve any implicit structure within a transmitted byte stream without enhancement.
SCTPはメッセージ指向であり、個々のメッセージ境界のフレーミングをサポートしています。それに比べて、TCPはバイト指向であり、送信されたバイトストリーム内の暗黙の構造を強化せずに保存しません。
SCTP is rate adaptive similar to TCP, and will scale back data transfer to the prevailing load conditions in the network. It is designed to behave cooperatively with TCP sessions attempting to use the same bandwidth.
SCTPはTCPと同様のレート適応型であり、ネットワーク内の一般的な負荷条件へのデータ転送を縮小します。同じ帯域幅を使用しようとするTCPセッションと協力的に振る舞うように設計されています。
The name Stream Control Transmission Protocol is derived from the multi-streaming function provided by SCTP. This feature allows data to be partitioned into multiple streams that have the property of independently sequenced delivery, so that message loss in any one stream will only initially affect delivery within that stream, and not delivery in other streams.
名前ストリーム制御伝送プロトコルは、SCTPによって提供されるマルチストリーミング関数から導出されます。この機能により、データを個別にシーケンスされた配信のプロパティを持つ複数のストリームに分割できるようになるため、1つのストリームのメッセージの損失は、最初にそのストリーム内の配信にのみ影響し、他のストリームでは配信されません。
In contrast, TCP assumes a single stream of data and ensures that delivery of that stream takes place with byte sequence preservation. While this is desirable for delivery of a file or record, it causes additional delay when message loss or sequence error occurs within the network. When this happens, TCP must delay delivery of data until the correct sequencing is restored, either by receipt of an out-of-sequence message, or by retransmission of a lost message.
対照的に、TCPは単一のデータストリームを想定し、バイトシーケンスの保存でそのストリームの配信が行われることを保証します。これはファイルまたはレコードの配信には望ましいものですが、ネットワーク内でメッセージの損失またはシーケンスエラーが発生すると、追加の遅延が発生します。これが発生した場合、TCPは、アウトシーケンスメッセージの受信または紛失メッセージの再送信により、正しいシーケンスが復元されるまでデータの配信を遅らせる必要があります。
For a number of applications, the characteristic of strict sequence preservation is not truly necessary. In telephony signaling, it is only necessary to maintain sequencing of messages that affect the same resource (e.g., the same call, or the same channel). Other messages are only loosely correlated and can be delivered without having to maintain overall sequence integrity.
多くのアプリケーションでは、厳密なシーケンス保存の特性は本当に必要ではありません。テレフォニーシグナル伝達では、同じリソースに影響を与えるメッセージのシーケンスを維持することのみが必要です（たとえば、同じコール、または同じチャネル）。他のメッセージはゆるく相関しているだけであり、全体的なシーケンスの整合性を維持することなく配信できます。
Another example of possible use of multi-streaming is the delivery of multimedia documents, such as a web page, when done over a single session. Since multimedia documents consist of objects of different sizes and types, multi-streaming allows transport of these components to be partially ordered rather than strictly ordered, and may result in improved user perception of transport.
マルチストリーミングの使用の可能性のある別の例は、1回のセッションで行われた場合のWebページなどのマルチメディアドキュメントの配信です。マルチメディアドキュメントはさまざまなサイズとタイプのオブジェクトで構成されているため、マルチストリーミングにより、これらのコンポーネントの輸送を厳密に順序付けするのではなく、部分的に注文することができ、輸送のユーザー認識が改善される可能性があります。
At the same time, transport is done within a single SCTP association, so that all streams are subjected to a common flow and congestion control mechanism, reducing the overhead required at the transport level.
同時に、輸送は単一のSCTP協会内で行われるため、すべてのストリームが共通の流れと渋滞制御メカニズムにさらされ、輸送レベルで必要なオーバーヘッドが減少します。
SCTP accomplishes multi-streaming by creating independence between data transmission and data delivery. In particular, each payload DATA "chunk" in the protocol uses two sets of sequence numbers, a Transmission Sequence Number that governs the transmission of messages and the detection of message loss, and the Stream ID/Stream Sequence Number pair, which is used to determine the sequence of delivery of received data.
SCTPは、データ送信とデータ配信の間に独立性を生み出すことにより、マルチストリーミングを達成します。特に、プロトコル内の各ペイロードデータ「チャンク」は、メッセージの送信とメッセージ損失の検出を支配するトランスミッションシーケンス番号、および使用されるストリームID/ストリームシーケンス番号ペアを支配する2セットのシーケンス番号を使用します。受信データの配信のシーケンスを決定します。
This independence of mechanisms allows the receiver to determine immediately when a gap in the transmission sequence occurs (e.g., due to message loss), and also whether or not messages received following the gap are within an affected stream. If a message is received within the affected stream, there will be a corresponding gap in the Stream Sequence Number, while messages from other streams will not show a gap. The receiver can therefore continue to deliver messages to the unaffected streams while buffering messages in the affected stream until retransmission occurs.
このメカニズムの独立性により、受信機は、伝送シーケンスのギャップが発生したとき（メッセージの損失により）、ギャップに続いて受信したメッセージが影響を受けるストリーム内であるかどうかをすぐに決定できます。影響を受けるストリーム内でメッセージが受信されると、ストリームシーケンス番号に対応するギャップがありますが、他のストリームからのメッセージはギャップを示しません。したがって、受信者は、再送信が発生するまで影響を受けたストリームでメッセージをバッファリングしながら、影響を受けていないストリームにメッセージを配信し続けることができます。
Another core feature of SCTP is multi-homing, or the ability for a single SCTP endpoint to support multiple IP addresses. The benefit of multi-homing is potentially greater survivability of the session in the presence of network failures. In a conventional single-homed session, the failure of a local LAN access can isolate the end system, while failures within the core network can cause temporary unavailability of transport until the IP routing protocols can reconverge around the point of failure. Using multi-homed SCTP, redundant LANs can be used to reinforce the local access, while various options are possible in the core network to reduce the dependency of failures for different addresses. Use of addresses with different prefixes can force routing to go through different carriers, for example, route-pinning techniques or even redundant core networks can also be used if there is control over the network architecture and protocols.
SCTPのもう1つのコア機能は、マルチホミング、または単一のSCTPエンドポイントが複数のIPアドレスをサポートする機能です。マルチホーミングの利点は、ネットワークの障害の存在下でのセッションの潜在的に大きな生存性です。従来のシングルホームセッションでは、ローカルLANアクセスの障害がエンドシステムを分離することができますが、コアネットワーク内の障害は、IPルーティングプロトコルが障害点を中心に再構成するまで、輸送の一時的な利用不能を引き起こす可能性があります。マルチホームのSCTPを使用して、冗長LANを使用してローカルアクセスを強化できますが、さまざまなアドレスの障害の依存度を低減するために、コアネットワークではさまざまなオプションが可能です。さまざまな接頭辞を使用してアドレスを使用すると、ルーティングにさまざまなキャリアを通過させることができます。たとえば、ネットワークアーキテクチャとプロトコルを制御する場合、ルートピンニングテクニックや冗長コアネットワークも使用できます。
In its current form, SCTP does not do load sharing, that is, multi-homing is used for redundancy purposes only. A single address is chosen as the "primary" address and is used as the destination for all DATA chunks for normal transmission. Retransmitted DATA chunks use the alternate address(es) to improve the probability of reaching the remote endpoint, while continued failure to send to the primary address ultimately results in the decision to transmit all DATA chunks to the alternate until heartbeats can reestablish the reachability of the primary.
現在の形式では、SCTPは負荷共有を行いません。つまり、マルチホーミングは冗長性の目的でのみ使用されます。単一のアドレスが「プライマリ」アドレスとして選択され、通常の伝送のためのすべてのデータチャンクの宛先として使用されます。再送信されたデータチャンクは、代替アドレスを使用してリモートエンドポイントに到達する確率を改善しますが、最終的には、ハートビートがハートビートが到達可能性を再確立できるようになるまで、すべてのデータチャンクを代替に送信する決定を最終的に決定します。主要な。
To support multi-homing, SCTP endpoints exchange lists of addresses during initiation of the association. Each endpoint must be able to receive messages from any of the addresses associated with the remote endpoint; in practice, certain operating systems may utilize available source addresses in round robin fashion, in which case receipt of messages from different source addresses will be the normal case. A single port number is used across the entire address list at an endpoint for a specific session.
マルチホーミングをサポートするために、SCTPエンドポイントは、協会の開始中のアドレスのリストを交換します。各エンドポイントは、リモートエンドポイントに関連付けられたアドレスのいずれかからメッセージを受信できる必要があります。実際には、特定のオペレーティングシステムは、ラウンドロビンファッションで利用可能なソースアドレスを利用する場合があります。この場合、異なるソースアドレスからのメッセージの受信が通常のケースになります。特定のセッションのエンドポイントのアドレスリスト全体で単一のポート番号が使用されます。
In order to reduce the potential for security issues, it is required that some response messages be sent specifically to the source address in the message that caused the response. For example, when the server receives an INIT chunk from a client to initiate an SCTP association, the server always sends the response INIT ACK chunk to the source address that was in the IP header of the INIT.
セキュリティの問題の可能性を減らすために、応答を引き起こしたメッセージのソースアドレスに特別に応答メッセージを送信する必要があります。たとえば、サーバーがSCTPアソシエーションを開始するためにクライアントからINITチャンクを受信すると、サーバーは常にINITのIPヘッダーにあるソースアドレスに応答INIT ACKチャンクを送信します。
The SCTP Initiation Procedure relies on a 4-message sequence, where DATA can be included on the 3rd and 4th messages of the sequence, as these messages are sent when the association has already been validated. A "cookie" mechanism has been incorporated into the sequence to guard against some types of denial of service attacks.
SCTP開始手順は、協会が既に検証されているときにこれらのメッセージが送信されるため、シーケンスの3番目と4番目のメッセージにデータを含めることができる4メッセージシーケンスに依存しています。「Cookie」メカニズムがシーケンスに組み込まれており、一部の種類のサービス攻撃を防ぎます。
The "cookie" mechanism guards specifically against a blind attacker generating INIT chunks to try to overload the resources of an SCTP server by causing it to use up memory and resources handling new INIT requests. Rather than allocating memory for a Transmission Control Block (TCB), the server instead creates a Cookie parameter with the TCB information, together with a valid lifetime and a signature for authentication, and sends this back in the INIT ACK. Since the INIT ACK always goes back to the source address of the INIT, the blind attacker will not get the Cookie. A valid SCTP client will get the Cookie and return it in the COOKIE ECHO chunk, where the SCTP server can validate the Cookie and use it to rebuild the TCB. Since the server creates the Cookie, only it needs to know the format and secret key, this is not exchanged with the client.
「Cookie」メカニズムは、盲目の攻撃者を生成する盲目の攻撃者に対して特別に警備しており、SCTPサーバーのリソースをメモリとリソースを使用して新しいINITリクエストを処理するリソースを使用することにより、SCTPサーバーのリソースをオーバーロードしようとします。メモリを送信制御ブロック（TCB）に割り当てるのではなく、サーバーは代わりに、有効な寿命と認証の署名とともに、TCB情報を使用してCookieパラメーターを作成し、これをinit ackに送り返します。INIT ACKは常にINITのソースアドレスに戻るため、ブラインド攻撃者はCookieを取得しません。有効なSCTPクライアントは、Cookieを取得し、Cookie Echo Chunkに返します。CTCPサーバーはCookieを検証し、TCBを再構築するために使用できます。サーバーはCookieを作成するため、フォーマットとシークレットキーを知る必要があるため、これはクライアントと交換されません。
Otherwise, the SCTP Initiation Procedure follows many TCP conventions, so that the endpoints exchange receiver windows, initial sequence numbers, etc. In addition to this, the endpoints may exchange address lists as discussed above, and also mutually confirm the number of streams to be opened on each side.
それ以外の場合は、SCTP開始手順は多くのTCP規則に従い、エンドポイントを交換レシーバーウィンドウ、初期シーケンス番号などに追跡します。これに加えて、エンドポイントは上記のようにアドレスリストを交換することができ、両側に開いた。
Multi-homing adds to the potential that messages will be received out of sequence or with different address pairs. This is a particular concern during initiation of the association, where without procedures for resolving the collision of messages, you may easily end up with multiple parallel associations between the same endpoints. To avoid this, SCTP incorporates a number of procedures to resolve parallel initiation attempts into a single association.
マルチホーミングは、メッセージが順序外または異なるアドレスペアで受信される可能性を追加します。これは、メッセージの衝突を解決するための手続きがなければ、同じエンドポイント間の複数の並列関連性に簡単に終わる可能性がある協会の開始中の特に懸念事項です。これを回避するために、SCTPには、単一の関連付けへの並列開始試行を解決するための多くの手順が組み込まれています。
DATA chunk exchange in SCTP follows TCP's Selective ACK procedure. Receipt of DATA chunks is acknowledged by sending SACK chunks, which indicate not only the cumulative Transmission Sequence Number (TSN) range received, but also any non-cumulative TSNs, implying gaps in the received TSN sequence. Following TCP procedures, SACKs are sent using the "delayed ack" method, normally one SACK per every other received packet, but with an upper limit on the delay between SACKs and an increase to once per received packet when there are gaps detected.
SCTPのデータチャンク交換は、TCPの選択的ACK手順に従います。データチャンクの受領は、受信した累積伝送シーケンス番号（TSN）範囲だけでなく、受信したTSNシーケンスのギャップを暗示する非累積TSNSも示すサックチャンクを送信することで認められます。TCP手順に続いて、サックは「遅延ACK」メソッドを使用して送信されます。通常は、他のすべての受信パケットごとに1つのサックですが、検出されたギャップがある場合、サック間の遅延が上限し、受信パケットごとに1回増加します。
Flow and Congestion Control follow TCP algorithms. The advertised receive window indicates buffer occupancy at the receiver, while a per-path congestion window is maintained to manage the packets in flight. Slow start, Congestion avoidance, Fast recovery and Fast retransmit are incorporated into the procedures as described in RFC 2581, with the one change being that the endpoints must manage the conversion between bytes sent and received and TSNs sent and received, since TSN is per chunk rather than per byte.
フローと混雑制御は、TCPアルゴリズムに従います。広告された受信ウィンドウは、レシーバーでのバッファーの占有率を示し、一方、飛行中のパケットを管理するためにパスごとの混雑ウィンドウが維持されます。スロースタート、混雑回避、迅速な回復、迅速な再送信がRFC 2581で説明されているように手順に組み込まれます。1つの変更は、エンドポイントが送信および受信したバイトと送信および受信の間の変換を管理する必要があることです。バイトごとではなく。
The application can specify a lifetime for data to be transmitted, so that if the lifetime has expired and the data has not yet been transmitted, it can be discarded (e.g., time-sensitive signaling messages). If the data has been transmitted, it must continue to be delivered to avoid creating a hole in the TSN sequence.
アプリケーションは、送信されるデータの寿命を指定することができます。そのため、寿命が切れてデータがまだ送信されていない場合、廃棄される可能性があります（たとえば、時間感受性のシグナリングメッセージ）。データが送信されている場合、TSNシーケンスに穴が作成されないように、引き続き配信する必要があります。
SCTP Shutdown uses a 3-message procedure to allow graceful shutdown, where each endpoint has confirmation of the DATA chunks received by the remote endpoint prior to completion of the shutdown. An Abort procedure is also provided for error cases when an immediate shutdown must take place.
SCTPシャットダウンは、3メッセージの手順を使用して優雅なシャットダウンを可能にします。各エンドポイントには、シャットダウンが完了する前にリモートエンドポイントが受信したデータチャンクの確認があります。即時シャットダウンが行われなければならない場合、エラーケースの場合も中止手順が提供されます。
Note that SCTP does not support the function of a "half-open" connection as can occur in TCP, when one side indicates that it has no more data to send, but the other side can continue to send data indefinitely. SCTP assumes that once the shutdown procedure begins, both sides will stop sending new data across the association, and only need to clear up acknowledgements of previously sent data.
SCTPは、TCPで発生する可能性のある「ハーフオープン」接続の関数をサポートしていないことに注意してください。一方が送信するデータがないことを示している場合、反対側はデータを無期限に送信し続けることができます。SCTPは、シャットダウン手順が開始されると、双方が協会全体で新しいデータの送信を停止し、以前に送信されたデータの承認をクリアする必要があると想定しています。
The SCTP Message includes a common header plus one or more chunks, which can be control or data. The common header has source and destination port numbers to allow multiplexing of different SCTP associations at the same address, a 32-bit verification tag that guards against insertion of an out-of-date or false message into the SCTP association, and a 32-bit checksum (this has been modified to use the CRC-32c polynomial [2]) for error detection.
SCTPメッセージには、共通のヘッダーと1つ以上のチャンクが含まれています。一般的なヘッダーには、同じアドレスで異なるSCTP関連の多重化を可能にするソースと宛先ポート番号、SCTP協会への誤ったメッセージの挿入に対して警告する32ビット検証タグ、および32-ビットチェックサム（これは、エラー検出のためにCRC-32C多項式[2]を使用するように変更されています）。
Each chunk includes chunk type, flag field, length and value. Control chunks incorporate different flags and parameters depending on the chunk type. DATA chunks in particular incorporate flags for control of segmentation and reassembly, and parameters for the TSN, Stream ID and Stream Sequence Number, and a Payload Protocol Identifier.
各チャンクには、チャンクタイプ、フラグフィールド、長さ、値が含まれます。コントロールチャンクは、チャンクタイプに応じて、さまざまなフラグとパラメーターを組み込みます。特にデータチャンクには、セグメンテーションと再組み立ての制御のためのフラグ、TSN、ストリームIDとストリームシーケンス番号、およびペイロードプロトコル識別子のパラメーターが組み込まれています。
The Payload Protocol ID has been included for future flexibility. It is envisioned that the functions of protocol identification and port number multiplexing will not be as closely linked in the future as they are in current usage. Payload Protocol ID will allow the protocol being carried by SCTP to be identified independent of the port numbers being used.
ペイロードプロトコルIDは、将来の柔軟性のために含まれています。プロトコルの識別とポート番号の多重化の機能は、現在の使用法ほど密接にリンクされないことが想定されています。ペイロードプロトコルIDは、使用されているポート番号とは無関係に、SCTPによってプロトコルを携帯するプロトコルを識別することを可能にします。
The SCTP message format naturally allows support of bundling of multiple DATA and control chunks in a single message, to improve transport efficiency. Use of bundling is controllable by the application, so that bundling of initial transmission can be prohibited. Bundling will naturally occur on retransmission of DATA chunks, to further reduce any chance of congestion.
SCTPメッセージ形式は、自然に複数のデータのバンドルをサポートし、単一のメッセージでチャンクを制御することを可能にし、輸送効率を向上させます。バンドルの使用はアプリケーションによって制御可能であるため、初期伝送のバンドルが禁止されます。束縛の可能性をさらに減らすために、データチャンクの再送信時に自然にバンドリングが発生します。
Retransmission of DATA chunks occurs from either (a) timeout of the retransmission timer; or (b) receipt of SACKs indicating the DATA chunk has not been received. To reduce the potential for congestion, the rate of retransmission of DATA chunks is limited. The retransmission timeout (RTO) is adjusted based on estimates of the round trip delay and backs off exponentially as message loss increases.
データチャンクの再送信は、（a）再送信タイマーのタイムアウトのいずれかから発生します。または（b）データチャンクが受信されていないことを示す袋の受領。輻輳の可能性を減らすために、データチャンクの再送信率は限られています。再送信タイムアウト（RTO）は、往復遅延の推定に基づいて調整され、メッセージの損失が増加すると指数関数的に後退します。
In an active association with fairly constant DATA transmission, SACKs are more likely to cause retransmission than the timeout. To reduce the chance of an unnecessary retransmission, a 4 SACK rule is used, so that retransmission only occurs on receipt of the 4th SACK that indicates that the chunk is missing. This is intended to avoid retransmits due to normal occurrences such as packets received out of sequence.
かなり一定のデータ送信とのアクティブな関連性では、サックはタイムアウトよりも再送信を引き起こす可能性が高くなります。不必要な再送信の可能性を減らすために、4サックルールが使用されているため、再送信は、チャンクが欠落していることを示す4番目のサックの受領時にのみ発生します。これは、シーケンスから受け取ったパケットなどの通常の発生のために再送信を避けることを目的としています。
A count is maintained of the number of retransmissions to a particular destination address without successful acknowledgement. When this count exceeds a configured maximum, the address is declared inactive, notification is given to the application, and the SCTP begins to use an alternate address for the sending of DATA chunks.
カウントは、認識を成功させることなく、特定の宛先アドレスへの再送信の数について維持されます。このカウントが構成された最大値を超えると、アドレスが非アクティブであると宣言され、アプリケーションに通知が与えられ、SCTPはデータチャンクの送信に代替アドレスを使用し始めます。
Also, Heartbeat chunks are sent periodically to all idle destinations (i.e., alternate addresses), and a counter is maintained on the number of Heartbeats sent to an inactive destination without receipt of a corresponding Heartbeat Ack. When this counter exceeds a configured maximum, that destination address is also declared inactive.
また、ハートビートチャンクは定期的にすべてのアイドル宛先（つまり、代替アドレス）に送られ、対応するハートビートACKを受信せずに非アクティブな宛先に送られたハートビートの数についてカウンターが維持されます。このカウンターが構成された最大値を超えると、その宛先アドレスも非アクティブと宣言されます。
Heartbeats continue to be sent to inactive destination addresses until an Ack is received, at which point the address can be made active again. The rate of sending Heartbeats is tied to the RTO estimation plus an additional delay parameter that allows Heartbeat traffic to be tailored according to the needs of the user application.
ハートビートは、ACKが受信されるまで非アクティブな宛先アドレスに送信され続けます。その時点で、アドレスを再びアクティブにすることができます。ハートビートを送信するレートは、RTO推定に加えて、ユーザーアプリケーションのニーズに応じてハートビートトラフィックを調整できる追加の遅延パラメーターに関連付けられています。
A count is maintained across all destination addresses on the number of retransmits or Heartbeats sent to the remote endpoint without a successful Ack. When this exceeds a configured maximum, the endpoint is declared unreachable, and the SCTP association is closed.
ACKを成功させることなく、リモートエンドポイントに送信された再送信またはハートビートの数のすべての宛先アドレスでカウントが維持されます。これが構成された最大値を超えると、エンドポイントは到達不能であると宣言され、SCTPアソシエーションは閉じられます。
The specification includes a model of the primitives exchanged between the application and the SCTP layer, intended as informational material rather than a formal API statement. A socket-based API is being defined to simplify migration of TCP or UDP applications to the use of SCTP.
仕様には、アプリケーションとSCTP層の間で交換されるプリミティブのモデルが含まれており、正式なAPIステートメントではなく情報資料として意図されています。ソケットベースのAPIは、SCTPの使用にTCPまたはUDPアプリケーションの移行を簡素化するために定義されています。
In addition to the verification tag and cookie mechanisms, SCTP specifies the use of IPSec if strong security and integrity protection is required. The SCTP specification does not itself define any new security protocols or procedures.
検証タグとCookieメカニズムに加えて、SCTPは、強力なセキュリティと整合性の保護が必要な場合はIPSECの使用を指定します。SCTP仕様自体は、新しいセキュリティプロトコルまたは手順を定義するものではありません。
Extensions to IPSec are under discussion to reduce the overhead required to support multi-homing. Also, work is in progress on the use of Transport Layer Security (TLS) over SCTP [4].
IPSECへの拡張は、マルチホミングをサポートするために必要なオーバーヘッドを減らすために議論されています。また、SCTPを介した輸送層セキュリティ（TLS）の使用に関する作業が進行中です[4]。
The SCTP format allows new chunk types, flags and parameter fields to be defined as extensions to the protocol. Any extensions must be based on standard agreements within the IETF, as no vendor-specific extensions are supported in the protocol.
SCTP形式では、新しいチャンクタイプ、フラグ、パラメーターフィールドをプロトコルの拡張として定義できます。拡張機能は、プロトコルではベンダー固有の拡張機能がサポートされていないため、IETF内の標準契約に基づいている必要があります。
Chunk Type values are organized into four ranges to allow extensions to be made with a pre-defined procedure for responding if a new Chunk Type is not recognized at the remote endpoint. Responses include: whole packet discard; packet discard with reporting; ignoring the chunk; ignoring with reporting. Similar pre-defined responses are specified for unrecognized Parameter Type values.
チャンクタイプの値は、リモートエンドポイントで新しいチャンクタイプが認識されていない場合に応答するための事前定義された手順で拡張機能を作成できる4つの範囲に編成されます。応答には以下が含まれます。パケット廃棄全体。レポートでパケット破棄;チャンクを無視する;報告で無視します。認識されていないパラメーター型値に対して、同様の事前定義された応答が指定されています。
Chunk Parameter Type values are in principle independent ranges for each Chunk Type. In practice, the values defined in the SCTP specification have been coordinated so that a particular parameter type will have the same Chunk Parameter Type value across all Chunk Types. Further experience will determine if this alignment needs to be maintained or formalized.
チャンクパラメータータイプの値は、各チャンクタイプの原則的に独立した範囲です。実際には、SCTP仕様で定義されている値が調整されており、特定のパラメータータイプがすべてのチャンクタイプで同じチャンクパラメータータイプ値を持つようになります。さらなる経験により、このアライメントを維持する必要があるか、正式化する必要があるかどうかが判断されます。
[1] 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.
[1] 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、2000年10月。
[2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work in Progress.
[2] スチュワート、シャープ、他al。、「SCTPチェックサムの変更」、進行中の作業。
[3] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M. and C. Sharp, "Framework Architecture for Signaling Transport", RFC 2719, October 1999.
[3] Ong、L.、Rytina、I.、Garcia、M.、Schwarzbauer、H.、Coene、L.、Lin、H.、Juhasz、I.、Holdrege、M. and C. Sharp、「Sharping Architecture for Signal Transport"、RFC 2719、1999年10月。
[4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in Progress.
[4] Jungmeier、Rescorla、Tuexen、「TLS over SCTP」は進行中の作業です。
Lyndon Ong Ciena Corporation 10480 Ridgeview Drive Cupertino, CA 95014
Lyndon Ong Ciena Corporation 10480 Ridgeview Drive Cupertino、CA 95014
EMail: lyong@ciena.com
John Yoakum Emerging Opportunities Nortel Networks
John Yoakumは、Nortel Networksを新たに出現しています
EMail: yoakum@nortelnetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。