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.
著作権（C）インターネット協会（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.
ストリーム制御伝送プロトコル（SCTP）は、多くのインターネットアプリケーションへのトランスポート層機能を提供するUDP（ユーザデータグラムプロトコル）およびTCP（伝送制御プロトコル）と同等のレベルでは、既存の、新しいIPトランスポートプロトコルです。 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は、ユニキャストプロトコルであり、これらは、複数のIPアドレスによって表されることができるが、正確に2エンドポイント間のデータ交換をサポートします。
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によって提供されるマルチストリーミング機能に由来します。この機能は、いずれかのストリーム内のそのメッセージの損失のみ最初に他のストリームにおけるそのストリーム内送達はなく、配信に影響を与えるように、データは、独立して、配列決定の送達特性を有する複数のストリームに分割されることを可能にします。
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.
単一のセッションを介して行われたときに、マルチストリーミングの活用可能性の別の例は、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 /ストリーム・シーケンス番号のペアの二組を使用し受信データの配信の順序を決定します。
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のもう一つのコア機能は、マルチホーミング、または複数のIPアドレスをサポートするために、単一のSCTP終点のための機能です。マルチホーミングの利点は、ネットワーク障害の存在下でのセッションの潜在的に大きな生存です。 IPルーティングプロトコルが障害点の周り再収束できるまでコアネットワーク内の障害が輸送の一時的な使用不能を引き起こす可能性がありながら、従来のシングルホームセッションでは、ローカルLANアクセスの失敗は、エンドシステムを単離することができます。マルチホーム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 - メッセージシーケンス、に依存しています。 「クッキー」のメカニズムは、サービス拒否攻撃のいくつかのタイプのを防ぐために配列に組み込まれています。
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.
具体的には、新しいINIT要求を処理し、メモリやリソースを使用させることにより、SCTPサーバのリソースをオーバーロードしようとするINITチャンクを生成するブラインド攻撃者に対して「クッキー」のメカニズムガード。むしろ、伝送制御ブロック（TCB）のためにメモリを割り当てるよりも、サーバーではなく、一緒に、有効寿命および認証のための署名で、TCB情報をクッキーパラメータを作成し、INIT ACKでこれを返送します。 INIT ACKがいつもINITの送信元アドレスに戻っているので、ブラインド攻撃者はクッキーを取得することはありません。有効なSCTPクライアントは、クッキーを取得し、SCTPサーバがクッキーを検証し、TCBを再構築するために使用することができCOOKIE ECHOチャンク、それを返します。サーバーはクッキーを作成するので、それだけは形式と秘密鍵を知っている必要があり、これは、クライアントとの間で交換されていません。
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の手順に従います。 DATAチャンクの受信は、受信されたTSNシーケンスのギャップを意味する、SACKの累積的な送信シーケンス番号（TSN）が受信範囲だけでなく示しチャンクだけでなく、任意の非累積のTSNを送信することによって確認されます。 TCPの手順に従って、袋は、「遅延ACK」方法、他のすべての受信パケットあたり通常1つのSACKを使用して送信されるが、検出されたギャップがある場合袋と増加との間の遅延の上限で一回あたりのパケットを受信します。
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に記載されているようにTSNチャンクごとであるため、スロースタート、輻輳回避、高速リカバリ及び高速再送信は、1つの変更は、エンドポイントが送信され、受信されたTSNは送信と受信したバイトの間の変換を管理しなければならないことであると、手順に組み込まれていますむしろバイト当たりより。
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.
片側には、それはそれ以上伝送するデータを持っていることを示しているが、他の側は無期限にデータを送信し続けることができ、TCP、中に発生する可能性がありますようSCTPは「ハーフオープン」接続の機能をサポートしていないことに注意してください。 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メッセージフォーマットは、自然輸送効率を向上させるために、単一のメッセージに複数のデータ及び制御チャンクのバンドルのサポートを可能にします。最初の送信のバンドルを禁止することができるように同梱の使用は、アプリケーションによって制御可能です。バンドルは、当然、さらに混雑のチャンスを減らすために、DATAチャンクの再送信に発生します。
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.
DATAチャンクの再送信は再送タイマーの（a）は、タイムアウトのいずれかから発生します。または（b）データチャンクを示す袋の受信は、受信されていません。渋滞の可能性を減らすために、DATAチャンクの再送信のレートが制限されています。再送タイムアウト（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 SACKルールが使用されているので、その再送が唯一のチャンクが欠落していることを示している第四SACKを受信したときに発生します。これは、このような順序で受信パケットとして、正常発生に再送を回避するためです。
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はDATAチャンクの送信のための代替アドレスを使用し始めます。
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.
仕様では、アプリケーションと情報資料ではなく、正式なAPI文として意図SCTP層、間で交換プリミティブのモデルを含んでいます。ソケットベースの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.
強力なセキュリティと完全性保護が必要な場合は、検証タグとクッキーのメカニズムに加えて、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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.およびV.パクソン、 "ストリーム制御伝送プロトコル"、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]オング、L.、Rytina、I.、ガルシア、M.、Schwarzbauer、H.、Coene、L.、リン、H.、ユハス、I.、ホールドレッジ、M.とC.シャープ、「フレームワークのアーキテクチャシグナリング交通」、RFC 2719、1999年10月のため。
[4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in Progress.
[4] Jungmeier、レスコラとTuexen、 "TLSオーバーSCTP" が進行中で働いています。
Lyndon Ong Ciena Corporation 10480 Ridgeview Drive Cupertino, CA 95014
リンドン・オングCienaの株式会社10480 Ridgeviewドライブクパチーノ、CA 95014
EMail: lyong@ciena.com
メールアドレス：lyong@ciena.com
John Yoakum Emerging Opportunities Nortel Networks
ジョン・ヨーカム新興機会ノーテルネットワークス
EMail: yoakum@nortelnetworks.com
メールアドレス：yoakum@nortelnetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。