RFC3286 日本語訳
3286 An Introduction to the Stream Control Transmission Protocol(SCTP). L. Ong, J. Yoakum. May 2002. (Format: TXT=22644 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Ong Request for Comments: 3286 Ciena Corporation Category: Informational J. Yoakum Nortel Networks May 2002
コメントを求めるワーキンググループL.オングの要求をネットワークでつないでください: 3286年のCiena社のカテゴリ: 情報のJ.Yoakumノーテルは2002年5月をネットワークでつなぎます。
An Introduction to the Stream Control Transmission Protocol (SCTP)
ストリーム制御伝動プロトコルへの序論(SCTP)
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはStream Control Transmissionプロトコル(SCTP)によってサポートされた能力に高い平らな序論を提供します。 それは汎用のトランスポート・プロトコルとしてのSCTPの潜在的ユーザのためのガイドとして意図します。
1. Introduction
1. 序論
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プロトコル(SCTP)は新しいIPトランスポート・プロトコルです、UDP(ユーザー・データグラム・プロトコル)とTCP(通信制御プロトコル)(多くのインターネットアプリケーションにトランスポート層機能を提供する)と共に同等なレベルで存在していて。 SCTPはProposed Standard[1]としてIETFによって承認されました。 エラーチェックアルゴリズムは以来、変更されています。[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]で説明されます。
Ong & Yoakum Informational [Page 1] RFC 3286 SCTP Overview May 2002
[1ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
2. Basic SCTP Features
2. 基本のSCTPの特徴
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セッションが、同じ帯域幅を使用するのを試みていて協力して振る舞うように設計されています。
3. SCTP Multi-Streaming Feature
3. SCTPのマルチストリーミングの特徴
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によって提供されたマルチストリーミングの機能から名前Stream Control Transmissionプロトコルを得ます。 この特徴は、データが独自に配列された配送の特性を持っている複数のストリームに仕切られるのを許容します、どんなストリームでもメッセージの損失は初めは、配送ではなく、他のストリームにおけるそのストリームの中で配送に影響するだけでしょう。
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
マルチストリーミングの活用可能性に関する別の例はマルチメディアドキュメントの配送です、ウェブページのように、ただ一つのセッションの間、すると。 マルチメディアドキュメントが異なったサイズとタイプのオブジェクトから成るので、マルチストリーミングはこれらのコンポーネントの輸送を許容します。
Ong & Yoakum Informational [Page 2] RFC 3286 SCTP Overview May 2002
[2ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
to be partially ordered rather than strictly ordered, and may result in improved user perception of transport.
厳密に命令して、もたらすかもしれないよりむしろ部分的に命令されるのは輸送のユーザ認知を改良しました。
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はデータ伝送とデータの間で独立を作成するのによるマルチストリーミングの配送を実行します。 特に、プロトコルのそれぞれのペイロードDATA「塊」は2セットの一連番号、メッセージの伝達とメッセージの損失の検出を治めるTransmission Sequence Number、およびStream ID/ストリームSequence Number組を使用します。(組は、受信データの配送の系列を決定するのに使用されます)。
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.
メカニズムからのこの独立で、受信機はすぐに、トランスミッション系列のギャップがいつ起こるか、そして、(例えば、メッセージの損失のため)また、影響を受けるストリームの中にギャップに続いて、受け取られたメッセージがあるかどうか決定できます。 影響を受けるストリームの中にメッセージを受け取ると、対応するギャップがStream Sequence Numberにあるでしょう、他のストリームからのメッセージはギャップを示さないでしょうが。 したがって、受信機は、「再-トランスミッション」が現れるまで影響を受けるストリームにおけるメッセージをバッファリングしている間、影響を受けないストリームにメッセージを提供し続けることができます。
4. SCTP Multi-Homing Feature
4. SCTPマルチホーミング機能
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の別のコアの特徴は、マルチホーミング、または単一のSCTP終点が複数のIPアドレスをサポートする能力です。 マルチホーミングの利益はネットワーク失敗があるときセッションの潜在的によりすばらしい生存性です。 中、a従来、シングル家へ帰る、セッション、地方のLANアクセスの失敗はエンドシステムを隔離できます、コアネットワークの中の失敗がIPルーティング・プロトコルは失敗のポイントの周りのreconvergeを引き起こすことができるまで輸送の一時的な使用不能を引き起こす場合がありますが 使用、マルチ、家へ帰り、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
現在のフォームでは、SCTPは負荷分割法をしません、すなわち、マルチの家へ帰りが冗長目的だけに使用されます。 ただ一つのアドレスは、「プライマリ」のアドレスとして選ばれていて、通常のトランスミッションのためのすべてのDATA塊に目的地として使用されます。 再送されたDATA塊
Ong & Yoakum Informational [Page 3] RFC 3286 SCTP Overview May 2002
[3ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
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.
代替アドレス(es)を使用して、遠く離れた終点に達するという確率を改良してください、結局プライマリアドレスに発信しない場合鼓動が予備選挙の可到達性を回復させることができるまですべてのDATA塊を補欠に伝えるという決定をもたらしますが。
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塊を送ります。
5. Features of the SCTP Initiation Procedure
5. SCTP開始手順の特徴
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 Initiation Procedureは4メッセージの系列を当てにします、既に協会を有効にしたとき、これらのメッセージを送るとき。(そこでは、系列に関する3番目と4番目のメッセージにDATAを含むことができます)。 何人かのタイプのサービス不能攻撃に用心するために「クッキー」メカニズムを系列に組み入れてあります。
5.1 Cookie Mechanism
5.1 クッキーメカニズム
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.
「クッキー」メカニズムは特にメモリを使いきることを引き起こすことによってSCTPサーバに関するリソースを積みすぎようとするためにINITに塊を生成する盲目の攻撃者とリソース取り扱いに対して新しいINIT要求を警備します。 Transmission Control Block(TCB)のためのメモリを割り当てるよりむしろ、サーバは、代わりに有効な生涯、認証のための署名と共にTCB情報でCookieパラメタを作成して、INIT ACKのこの後部を送ります。 INIT ACKがいつもINITのソースアドレスに戻るので、盲目の攻撃者はCookieを手に入れないでしょう。 有効なSCTPクライアントは、Cookieを手に入れて、COOKIE ECHO塊でそれを返すでしょう、SCTPサーバがCookieを有効にして、TCBを再建するのにそれを使用できるところで。 サーバがCookieを作成するので、形式と秘密鍵を知るのが必要であり、これはクライアントと共に交換されません。
Ong & Yoakum Informational [Page 4] RFC 3286 SCTP Overview May 2002
[4ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
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 Initiation Procedureが多くのTCPコンベンションに続くので、終点は受信機の窓、初期シーケンス番号などを交換します。 これに加えて、終点は、上で議論するように住所録を交換して、また、それぞれの側で開かれるために互いにストリームの数を確認するかもしれません。
5.2 INIT Collision Resolution
5.2 イニット衝突解決
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は、平行な開始試みに単一の協会に変えるために多くの手順を取り入れます。
6. SCTP DATA Exchange Features
6. 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のDATA塊交換はTCPのSelective ACK手順に続いて起こります。 DATA塊の領収書はSACK塊にもかかわらず、どんな非累積しているTSNsも送ることによって、受け取ったことを知らせられます、容認されたTSN系列のギャップを含意して。塊は累積しているTransmission Sequence Number(TSN)範囲だけが受信されたのを示しません。 TCP手順に従って、SACKsを「遅れたack」メソッド、通常他の各容認されたパケットあたり1SACKを使用させますが、SACKsの間の遅れに関する上限とギャップがあるときの容認されたパケットあたりの一度への増加で検出します。
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アルゴリズム広告を出すのが受ける流れとCongestion Control尾行は受信機で占有をバッファリングします窓が、示す、1経路あたり1つの混雑ウィンドウが飛行でパケットを管理するために維持されますが。 遅れた出発、回復とFastが再送するFastはRFC2581で説明されるように手順に組み入れられます、終点がバイトの間の変換を管理しなければならないということであることが送って、受けた1回の変化とTSNsを送って、受け取っていて、Congestion回避、TSNが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系列の穴を作成するのを避けるために提供され続けなければなりません。
Ong & Yoakum Informational [Page 5] RFC 3286 SCTP Overview May 2002
[5ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
7. SCTP Shutdown Features
7. SCTP閉鎖機能
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 Shutdownは優雅な閉鎖を許すのに3メッセージの手順を用います、閉鎖の完成の前に遠く離れた終点でDATA塊の確認を受け取るところで各終点で。 また、即座の閉鎖が行われなければならないとき、Abort手順を誤り事件に提供します。
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は、停止手順がいったん始まると、両側が、協会の向こう側に新しいデータを送るのを止めて、以前に送られたデータの承認を解決する必要であるだけであると仮定します。
8. SCTP Message Format
8. 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 Messageは一般的なヘッダーと1つ以上の塊を含んでいます。(コントロールか塊はデータであるかもしれません)。 一般的なヘッダーは、ソースと目的地に同じアドレス、時代遅れであるか誤ったメッセージの挿入にSCTP協会に用心する32ビットの検証タグ、および32ビットのチェックサムで異なったSCTP協会を多重送信するのを許容するために数を移植させます。(これは誤り検出に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.
各塊は塊タイプ、旗の分野、長さ、および値を含んでいます。 コントロール塊は塊タイプに頼る異なった旗とパラメタを組み込みます。 DATA塊は、特に分割のコントロールと再アセンブリのために旗を盛込んで、TSN、Stream ID、Stream Sequence Number、および有効搭載量プロトコルIdentifierのためにパラメタを盛込みます。
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.
有効搭載量Protocol 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とコントロール塊のバンドリングのサポートを許します。 バンドリングの使用は、初期のトランスミッションのバンドリングを禁止できるくらいアプリケーションで制御可能です。 バンドリングは、さらに混雑のどんな可能性も小さくするためにDATA塊の「再-トランスミッション」に自然に起こるでしょう。
Ong & Yoakum Informational [Page 6] RFC 3286 SCTP Overview May 2002
[6ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
9. Error Handling
9. エラー処理
9.1 Retransmission
9.1 Retransmission
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塊のRetransmissionは(a) 再送信タイマーのタイムアウトから起こります。 (b) または、DATA塊を示すSACKsの領収書は受け取られていません。 混雑の可能性を減少させるために、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.
かなり一定のDATAトランスミッションとの活動的な協会で、SACKsはタイムアウトより「再-トランスミッション」を引き起こしそうです。 不要な「再-トランスミッション」の可能性を小さくするのに、4SACK定規は使用されています、「再-トランスミッション」が塊がなくなるのを示す第4SACKを受け取り次第現れるだけであるように。 これは、避けるために意図しています。順序が狂って受け取られたパケットなどの通常の発生のため再送します。
9.2 Path Failure
9.2 経路失敗
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.
また、定期的にすべての活動していない目的地(すなわち、代替アドレス)にHeartbeat塊を送ります、そして、対応するHeartbeat Ackの領収書なしで不活発な目的地に送られたHeartbeatsの数でカウンタを維持します。 また、このカウンタが構成された最大を超えているとき、その送付先アドレスは不活発であると宣言されます。
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が受け取られていて、再びそのポイントでアドレスをアクティブにすることができるまで続けています。 送付HeartbeatsのレートはRTO見積りとユーザアプリケーションの必要性に従ってHeartbeatトラフィックが合わせるのを許容する追加遅れパラメタに結ばれます。
9.3 Endpoint Failure
9.3 終点失敗
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なしで遠く離れた終点に送られたHeartbeats。 これが構成された最大を超えているとき、終点は手が届かないと宣言されます、そして、SCTP協会は閉じられます。
Ong & Yoakum Informational [Page 7] RFC 3286 SCTP Overview May 2002
[7ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
10. API
10. API
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は、TCPかUDPアプリケーションの移行をSCTPの使用に簡素化するために定義されています。
11. Security Considerations
11. セキュリティ問題
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への拡大は議論中であります。 また、仕事はTransport Layer Security(TLS)の使用のときにSCTP[4]で進行しています。
12. Extensions
12. 拡大
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.
塊Type値は新しいChunk Typeが遠く離れた終点で認識されないなら応じるための事前に定義された手順で拡大をするのを許容する4つの範囲に組織化されます。 応答は: 全体のパケット破棄。 報告によるパケット破棄。 塊を無視します。 報告で、無視します。 同様の事前に定義された応答は認識されていないParameter Type値に指定されます。
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.
塊Parameter Type値は原則として各Chunk Typeのための独立している範囲です。 実際には、SCTP仕様に基づき定義された値は、特定のパラメータの型がすべてのChunk Typesの向こう側に同じChunk Parameter Type値を持つように、調整されました。 さらなる経験は、この整列が、維持されるか、または正式にされる必要であるかどうか決定するでしょう。
Ong & Yoakum Informational [Page 8] RFC 3286 SCTP Overview May 2002
[8ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
13. Informative References
13. 有益な参照
[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.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[2] Stewart, Sharp, et. al., "SCTP Checksum Change", Work in Progress.
[2] etスチュワート、シャープ、アル、「SCTPチェックサム変化」、ProgressのWork。
[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.とJuhaszとI.とHoldregeとM.と鋭く、「シグナリングのためのフレームワークアーキテクチャは輸送する」C.、RFC2719、1999年10月。
[4] Jungmeier, Rescorla and Tuexen, "TLS Over SCTP", Work in Progress.
[4] 「SCTPの上のTLS」というJungmeier、レスコラ、およびTuexenは進行中で働いています。
14. Authors' Addresses
14. 作者のアドレス
Lyndon Ong Ciena Corporation 10480 Ridgeview Drive Cupertino, CA 95014
リンドンオングCiena社10480のRidgeview Driveカルパチーノ、カリフォルニア 95014
EMail: lyong@ciena.com
メール: lyong@ciena.com
John Yoakum Emerging Opportunities Nortel Networks
機会のノーテルネットワークとして現れるジョンYoakum
EMail: yoakum@nortelnetworks.com
メール: yoakum@nortelnetworks.com
Ong & Yoakum Informational [Page 9] RFC 3286 SCTP Overview May 2002
[9ページ]RFC3286SCTP概要2002年5月の情報のオングとYoakum
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Ong & Yoakum Informational [Page 10]
オングとYoakum情報です。[10ページ]
一覧
スポンサーリンク