Network Working Group R. Stewart Request for Comments: 2960 Q. Xie Category: Standards Track Motorola K. Morneault C. Sharp Cisco H. Schwarzbauer Siemens T. Taylor Nortel Networks I. Rytina Ericsson M. Kalla Telcordia L. Zhang UCLA V. Paxson ACIRI October 2000 Stream Control Transmission Protocol このメモのステータス この文書はインターネットコミュニティのためのインターネット標 準トラックプロトコルを記述し、改善のための議論や提言を求める ものである。このプロトコルにおける標準化状態については「イン ターネット公式プロトコル標準」(STD 1)の最新エディションを参 照されたい。この文書の配布に制限はない。 Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. (日本語訳について)----------------------------------------------------- この日本語訳は舟阪淳一が個人的に訳したものです。誤訳も含まれていると 思いますので、ご利用の際は注意してください。また不備をみつけられましたら ご連絡ください。この注意書きを残していれば、自由に改変、再配布できる ものとします。 連絡先 http://mary.net.info.hiroshima-cu.ac.jp/cgi-bin/mailaccept.pl ----------------------------------------------------------------------- Abstract この文書はStream Control Transmission Protocol (SCTP)を記述 する。SCTPはIPネットワーク上でPSTN信号メッセージを送信するた めに設計されたが、より広い応用が可能である。 SCTPはIPのようなコネクションレスのパケットネットワーク上で動 作する、信頼性のあるトランスポートプロトコルである。このプロ トコルはそのユーザに以下のサービスを提供する: -- 確認応答付きのエラー無しduplicate無しのユーザデータ 配送 -- 観測された経路MTUの大きさに合うように行うデータ分割 Stewart, et al. Standards Track [Page 1] RFC 2960 Stream Control Transmission Protocol October 2000 -- 複数のストリーム内でのユーザメッセージの順序通りの 配送、および個々のユーザメッセージの到着順処理オプション -- 1つのSCTPパケットに複数のユーザメッセージを詰めこむ オプションのバンドリング機能 -- 片方または両方のアソシエーション端におけるマルチホー ミングをサポートすることによって実現するネットワークレベルの フォールトトレランス(耐故障性) SCTPの設計は適切な(appropriate)輻輳回避動作とフラッディング 及びマスカレード攻撃に対する防御を含んでいる。 Stewart, et al. Standards Track [Page 2] RFC 2960 Stream Control Transmission Protocol October 2000 Table of Contents 1. Introduction.................................................. 5 1.1 Motivation.................................................. 6 1.2 Architectural View of SCTP.................................. 6 1.3 Functional View of SCTP..................................... 7 1.3.1 Association Startup and Takedown........................ 8 1.3.2 Sequenced Delivery within Streams....................... 9 1.3.3 User Data Fragmentation................................. 9 1.3.4 Acknowledgement and Congestion Avoidance................ 9 1.3.5 Chunk Bundling ......................................... 10 1.3.6 Packet Validation....................................... 10 1.3.7 Path Management......................................... 11 1.4 Key Terms................................................... 11 1.5 Abbreviations............................................... 15 1.6 Serial Number Arithmetic.................................... 15 2. Conventions.................................................... 16 3. SCTP packet Format............................................ 16 3.1 SCTP Common Header Field Descriptions....................... 17 3.2 Chunk Field Descriptions.................................... 18 3.2.1 Optional/Variable-length Parameter Format............... 20 3.3 SCTP Chunk Definitions...................................... 21 3.3.1 Payload Data (DATA)..................................... 22 3.3.2 Initiation (INIT)....................................... 24 3.3.2.1 Optional or Variable Length Parameters.............. 26 3.3.3 Initiation Acknowledgement (INIT ACK)................... 30 3.3.3.1 Optional or Variable Length Parameters.............. 33 3.3.4 Selective Acknowledgement (SACK)........................ 33 3.3.5 Heartbeat Request (HEARTBEAT)........................... 37 3.3.6 Heartbeat Acknowledgement (HEARTBEAT ACK)............... 38 3.3.7 Abort Association (ABORT)............................... 39 3.3.8 Shutdown Association (SHUTDOWN)......................... 40 3.3.9 Shutdown Acknowledgement (SHUTDOWN ACK)................. 40 3.3.10 Operation Error (ERROR)................................ 41 3.3.10.1 Invalid Stream Identifier.......................... 42 3.3.10.2 Missing Mandatory Parameter........................ 43 3.3.10.3 Stale Cookie Error................................. 43 3.3.10.4 Out of Resource.................................... 44 3.3.10.5 Unresolvable Address............................... 44 3.3.10.6 Unrecognized Chunk Type............................ 44 3.3.10.7 Invalid Mandatory Parameter........................ 45 3.3.10.8 Unrecognized Parameters............................ 45 3.3.10.9 No User Data....................................... 46 3.3.10.10 Cookie Received While Shutting Down............... 46 3.3.11 Cookie Echo (COOKIE ECHO).............................. 46 3.3.12 Cookie Acknowledgement (COOKIE ACK).................... 47 3.3.13 Shutdown Complete (SHUTDOWN COMPLETE).................. 48 4. SCTP Association State Diagram................................. 48 Stewart, et al. Standards Track [Page 3] RFC 2960 Stream Control Transmission Protocol October 2000 5. Association Initialization..................................... 52 5.1 Normal Establishment of an Association...................... 52 5.1.1 Handle Stream Parameters................................ 54 5.1.2 Handle Address Parameters............................... 54 5.1.3 Generating State Cookie................................. 56 5.1.4 State Cookie Processing................................. 57 5.1.5 State Cookie Authentication............................. 57 5.1.6 An Example of Normal Association Establishment.......... 58 5.2 Handle Duplicate or unexpected INIT, INIT ACK, COOKIE ECHO, and COOKIE ACK.............................................. 60 5.2.1 Handle Duplicate INIT in COOKIE-WAIT or COOKIE-ECHOED States................................. 60 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT........ 61 5.2.3 Unexpected INIT ACK..................................... 61 5.2.4 Handle a COOKIE ECHO when a TCB exists.................. 62 5.2.4.1 An Example of a Association Restart................. 64 5.2.5 Handle Duplicate COOKIE ACK............................. 66 5.2.6 Handle Stale COOKIE Error............................... 66 5.3 Other Initialization Issues................................. 67 5.3.1 Selection of Tag Value.................................. 67 6. User Data Transfer............................................. 67 6.1 Transmission of DATA Chunks................................. 69 6.2 Acknowledgement on Reception of DATA Chunks................. 70 6.2.1 Tracking Peer's Receive Buffer Space.................... 73 6.3 Management Retransmission Timer............................. 75 6.3.1 RTO Calculation......................................... 75 6.3.2 Retransmission Timer Rules.............................. 76 6.3.3 Handle T3-rtx Expiration................................ 77 6.4 Multi-homed SCTP Endpoints.................................. 78 6.4.1 Failover from Inactive Destination Address.............. 79 6.5 Stream Identifier and Stream Sequence Number................ 80 6.6 Ordered and Unordered Delivery.............................. 80 6.7 Report Gaps in Received DATA TSNs........................... 81 6.8 Adler-32 Checksum Calculation............................... 82 6.9 Fragmentation............................................... 83 6.10 Bundling .................................................. 84 7. Congestion Control .......................................... 85 7.1 SCTP Differences from TCP Congestion Control................ 85 7.2 SCTP Slow-Start and Congestion Avoidance.................... 87 7.2.1 Slow-Start.............................................. 87 7.2.2 Congestion Avoidance.................................... 89 7.2.3 Congestion Control...................................... 89 7.2.4 Fast Retransmit on Gap Reports.......................... 90 7.3 Path MTU Discovery.......................................... 91 8. Fault Management.............................................. 92 8.1 Endpoint Failure Detection.................................. 92 8.2 Path Failure Detection...................................... 92 Stewart, et al. Standards Track [Page 4] RFC 2960 Stream Control Transmission Protocol October 2000 8.3 Path Heartbeat.............................................. 93 8.4 Handle "Out of the blue" Packets............................ 95 8.5 Verification Tag............................................ 96 8.5.1 Exceptions in Verification Tag Rules.................... 97 9. Termination of Association..................................... 98 9.1 Abort of an Association..................................... 98 9.2 Shutdown of an Association.................................. 98 10. Interface with Upper Layer....................................101 10.1 ULP-to-SCTP................................................101 10.2 SCTP-to-ULP................................................111 11. Security Considerations.......................................114 11.1 Security Objectives........................................114 11.2 SCTP Responses To Potential Threats........................115 11.2.1 Countering Insider Attacks.............................115 11.2.2 Protecting against Data Corruption in the Network......115 11.2.3 Protecting Confidentiality.............................115 11.2.4 Protecting against Blind Denial of Service Attacks.....116 11.2.4.1 Flooding...........................................116 11.2.4.2 Blind Masquerade...................................118 11.2.4.3 Improper Monopolization of Services................118 11.3 Protection against Fraud and Repudiation...................119 12. Recommended Transmission Control Block (TCB) Parameters.......120 12.1 Parameters necessary for the SCTP instance.................120 12.2 Parameters necessary per association (i.e. the TCB)........120 12.3 Per Transport Address Data.................................122 12.4 General Parameters Needed..................................123 13. IANA Considerations...........................................123 13.1 IETF-defined Chunk Extension...............................123 13.2 IETF-defined Chunk Parameter Extension.....................124 13.3 IETF-defined Additional Error Causes.......................124 13.4 Payload Protocol Identifiers...............................125 14. Suggested SCTP Protocol Parameter Values......................125 15. Acknowledgements..............................................126 16. Authors' Addresses............................................126 17. References....................................................128 18. Bibliography..................................................129 Appendix A .......................................................131 Appendix B .......................................................132 Full Copyright Statement .........................................134 1. はじめに この節はSCTPの開発に至った理由、SCTPの提供するサービス、お よびプロトコルの詳細な記述を理解するために必要な基礎概念につ いて説明する。 Stewart, et al. Standards Track [Page 5] RFC 2960 Stream Control Transmission Protocol October 2000 1.1 動機づけ TCP[RFC793] はIPネットワークにおいて信頼性のあるデータ転送の 主な手段として多大なる貢献をして(perform immense service)きた。しかしながら 多くの最近のアプリケーションはTCPには制限が多いと気づき、 UDP[RFC768]の上に独自の信頼性のあるデータ転送プロトコルを実 装(incorporate)している。ユーザが回避したいと考える制限には 以下のものがある。 -- TCPは信頼性のあるデータ転送と厳密な順序通りのデータ 転送の両方を提供する。順序制御ぬきで信頼性を必要とするアプリ ケーションもあれば、データの一部が順序通りであれば十分なもの もある。これらのどちらの場合もTCPによって起こるhead-of-line ブロッキングが不要な遅延を引き起こす。 -- TCPのもつストリーム指向の性質はたびたび不便となる。 アプリケーションはそのメッセージをとりだすために境界に印をつ けねばならず、ある無理のない時間のうちに完全なメッセージが転 送されることを保証するためにpush機能を明示して使わなければな らない。 -- TCPソケットの使用範囲が限定されているために、マルチ ホーム化されたホストを用いて高可用性のデータ転送を提供するし ようとすると複雑になってしまう。 -- TCPはSYN攻撃のようなDoS(サービス不能)攻撃に比較的弱い。 IPネットワークを経由するPSTN signalingの転送は、このような TCPの制限のすべてが密接に関わってくる応用例である。 この応用例がSCTPの開発を直接動機づけしてきたのではあるが、他 の応用もその要求にSCTPがマッチするかもしれない。 1.2 SCTPの構造概要 SCTPはSCTPユーザアプリケーション(SCTPユーザと略す)とIPのよう なコネクションレスのパケットネットワークサービスとの間の層と してみることができる。この文書では以降、SCTPがIPの上で動作す ることを想定する。SCTPにより提供される基本的なサービスは、 SCTPユーザ同士の間での信頼性のあるメッセージの配送である。 SCTPはこのサービスを、2つのSCTP端末の間のアソシエーション (the context of an association)lとして実現する。この文書の10 節では、SCTPとSCTPユーザ層の間の境界に位置するAPIについて述 べる。 SCTPはもともとコネクション指向であるが、SCTPのアソシエーショ ンはTCPのコネクションよりも広い概念である。SCTPは各SCTP端末 (1.4節)に、自分がSCTPパケットを送受信できるトランスポートア Stewart, et al. Standards Track [Page 6] RFC 2960 Stream Control Transmission Protocol October 2000 ドレスのリスト(すなわち複数のIPアドレスとSCTPポート)を通信相 手に渡す(アソシエーション確立時)手段を提供する。アソシエーショ ンは、それぞれの端末のトランスポートアドレスリストから作り得 る全ての可能な送信元と送信先の組み合わせを用いた配送を含む。 _____________ _____________ | SCTP User | | SCTP User | | Application | | Application | |-------------| |-------------| | SCTP | | SCTP | | Transport | | Transport | | Service | | Service | |-------------| |-------------| | |One or more ---- One or more| | | IP Network |IP address \/ IP address| IP Network | | Service |appearances /\ appearances| Service | |_____________| ---- |_____________| SCTP Node A |<-------- Network transport ------->| SCTP Node B Figure 1: An SCTP Association 1.3 SCTPの機能概要 SCTPのトランスポートサービスは多数の機能に分解することができ る。それらの機能を図2に示し、この節の以降で説明する。 Stewart, et al. Standards Track [Page 7] RFC 2960 Stream Control Transmission Protocol October 2000 SCTP User Application ----------------------------------------------------- _____________ ____________________ | | | Sequenced delivery | | Association | | within streams | | | |____________________| | startup | | | ____________________________ | and | | User Data Fragmentation | | | |____________________________| | takedown | | | ____________________________ | | | Acknowledgement | | | | and | | | | Congestion Avoidance | | | |____________________________| | | | | ____________________________ | | | Chunk Bundling | | | |____________________________| | | | | ________________________________ | | | Packet Validation | | | |________________________________| | | | | ________________________________ | | | Path Management | |_____________| |________________________________| Figure 2: Functional View of the SCTP Transport Service 1.3.1 アソシエーションの確立と切断 アソシエーションはSCTPユーザからの要求により始められる(10節 のASSOCIATE(またはSEND)プリミティブの記述を参照)。 アソシエーション初期化の間、Karn and Simpsonによるもの [RFC2522]と似たクッキーメカニズムがセキュリティ攻撃から防御 するために採用されている。このクッキーメカニズムは4ウェイハ ンドシェイクを用いており、最後の2ウェイでは高速なセットアッ プのためにユーザデータを運ぶことが許されている。初期化 (startup)の順序はこの文書の5節に記述されている。 SCTPはSCTPユーザからの要求に際して、activeなアソシエーション を丁寧に閉じる(graceful close)ようにしている。10節のSHUTDOWN プリミティブの記述を参照のこと。SCTPはユーザからの要求(ABORT プリミティブ)により、またはSCTP層で検出されたエラー条件の結 果として、(アソシエーションを)乱暴に閉じる(ungraceful close) こともできる。9節では丁寧な終了と乱暴な終了の両方について記 述している。 Stewart, et al. Standards Track [Page 8] RFC 2960 Stream Control Transmission Protocol October 2000 SCTPは、片方の端末が閉じているのにもう一方の端末がデータ転送 を続けるといった(TCPのような)ハーフオープン状態をサポートし ていない。いずれかの端末がシャットダウンを行うとき、それぞれ の端末のアソシエーションはユーザからの新しいデータを受けつけ ず、丁寧な終了の間はキューに残ったデータのみを転送する(9節参 照)。 1.3.2 ストリーム中の順序通りの配送 SCTPにおいて「ストリーム」という用語は、同じストリームの中の メッセージ同士の関係の観点でいえば(with respect to other messages within the same stream)、上位プロトコルに順序通りに 配送されるユーザメッセージのつながりを指す。これはTCPとは対 照的であり、TCPではストリームはバイトのつながりを指す(この文 書ではバイトは8ビットと仮定する)。 SCTPユーザはアソシエーションの開始(startup)時に、そのアソシ エーションでサポートされるストリームの数を指定することができ る。この数は相手端末と交渉することになる(5.1.1節参照)。ユー ザメッセージにはストリーム番号が関連づけられる(SEND、RECEIVE プリミティブ、10節)。内部的には、SCTPはSCTPユーザから渡され たメッセージのそれぞれにストリームシーケンス番号をわりあてる。 受診側ではSCTPが、与えられたストリームの中でメッセージが順序 通りにSCTPユーザに配送されることを保証する。しかしながら、1 つのストリームが次の順序通りなユーザメッセージを待ってブロッ クされていても、他のストリームからの配送は続けられる。 SCTPはこの順序通りの配送サービスを省略するメカニズムを提供す る。このメカニズムを使って送られたユーザメッセージは、受信さ れるとすぐにSCTPユーザに届けられる。 1.3.3 ユーザデータの分割 SCTPは必要があればユーザメッセージを分割し、下層に渡される SCTPパケットをパスMTUに合わせる。受信の際には分割された部分 は、SCTPユーザに渡される前に完全なメッセージへと再構成される。 1.3.4 受信確認と輻輳回避 SCTPはユーザデータの分割された部分や分割されていないメッセー ジのそれぞれに転送シーケンス番号(TSN)を割り当てる。このTSNは ストリームレベルで割り当てられるストリームシーケンス番号とは 独立である。 受信側端末は、たとえ順序にギャップがあろうとも、全てのTSNの 受信に対して受信確認をする。このようにして、信頼性のある配送 は順序通りのストリーム配送とは機能的に分けて維持される。 Stewart, et al. Standards Track [Page 9] RFC 2960 Stream Control Transmission Protocol October 2000 受信確認と輻輳回避の機能は、時間通りに受信確認応答が届かない ときのためのものである。パケットの再送は、TCPと同様に輻輳回 避手順が調整する。この機能に関連したプロトコル手順についての 詳細な記述は6節と7節を参照のこと。 1.3.5 チャンクのバンドル 3節で述べられるように、下層に渡されるSCTPパケットは、共通ヘッ ダとそれに続くひとつまたはそれ以上のチャンクから成る。それぞ れのチャンクはユーザデータか、あるいはSCTPの制御情報を含む。 SCTPのチャンクバンドリング機能は、受信側における完全なSCTPパ ケットの組み立てと分解のためのものである。 輻輳時にはたとえユーザがSCTPにバンドルしないように要求したと しても、SCTPの実装はそのままバンドリングを続けてもよい(MAY)。 ユーザによるバンドリングの中止は、(少しでも多くバンドリング しようとするために)配送前に少しの時間待ちあわせるSCTPの実装 にのみ影響する。ユーザ層がバンドリングを中止するとき、輻輳時 や再送時に行われるバンドリングを除いて、この短い遅延は禁じら れる。 1.3.6 パケットの正当性確認 必須のVerificationタグフィールドと32ビットのチェックサムフィー ルド(Appendix BのAdler-32チェックサムについての記述を参照)が SCTPの共通ヘッダに含まれる。Verificationタグの値はアソシエー ションの開始時にアソシエーションを構成する各端末で選ばれる。 予期されるVerificationタグ値を持たないパケットが受信されると、 このパケットは破棄される。これはblindマスカレード攻撃、およ び以前のアソシエーションに属していたすでに無効になったSCTPパ ケットを防ぐためである。各SCTPパケットの送信者は、ネットワー クにおけるデータ破壊も防ぐためにAdler-32チェックサムをつける べきである。不正なAdler-32チェックサムをもったSCTPパケットを 受けとった端末は、そのパケットを(silently)破棄する。 Stewart, et al. Standards Track [Page 10] RFC 2960 Stream Control Transmission Protocol October 2000 1.3.7 パス(経路)の管理 SCTP送信者はSCTPパケットの宛先として使われるトランスポートア ドレスの組を、10節で記述されるプリミティブによって操ることが できる。SCTPのパス管理機能は、SCTPユーザによる指令やふさわし い宛先アドレスの組についての現在検知されている到達性 (reachability)をもとに、それぞれの送出パケットの宛先トランス ポートアドレスを選ぶ。このパス管理機能は、その他のパケットの トラフィックが到達性の情報を提供するのにふさわしくないときに ハートビートを用いて到達性を監視し、相手側のトランスポートア ドレスの到達性が変化したときにSCTPユーザに助言する。パス管理 機能は、アソシエーション開始時に手元(local)のトランスポート アドレスのふさわしい組を相手に知らせ、また相手から返されたト ランスポートアドレスの組をSCTPユーザに知らせる役割をもつ。 アソシエーション開始時に、各SCTP端末が使うプライマリパスが定 義され、このパスがSCTPパケットの通常送信に用いられる。 受信側端末では、パス管理機能は、受信したSCTPパケットを処理す る前に、そのパケットが属している正当なSCTPアソシエーションの 存在を確認する役割をもつ。 注意: パス管理とパケットの正当性確認は同時に行われる。従って、 上記では分けて書かれているが、実際には別々の項目としては処理 できない。 1.4 キーワード ここまでの節でSCTPを記述するいくつかの用語はすでに紹介されて いる。この節ではキーワードとその定義をまとめる。 o アクティブな宛先トランスポートアドレス: 送信側の端末がユーザメッセージを受け取り可能と考えている相手 側端末のトランスポートアドレス。 o バンドリング: オプションの多重化処理であり、これによって1つ以上のユーザメッ セージが同じSCTPパケットによって運ばれる。それぞれのユーザメッ セージは自身のデータチャンクをもつ。 o チャンク: SCTPパケットの中の情報単位であり、チャンクヘッダとチャンクに 固有の内容から成る。 o 輻輳ウインドウ(cwnd): 送信者が特定の宛先トランスポートアドレスに、受信確認応答を受 ける前に送ることのできるデータ量を制限するSCTP変数であり、バ イト単位で示される。 Stewart, et al. Standards Track [Page 11] RFC 2960 Stream Control Transmission Protocol October 2000 o 累積TSN確認応答ポイント: SACKの累積TSN確認応答フィールドによって受信が確認された最後 のデータチャンクのTSN o アイドル宛先アドレス: ある長さの時間、ユーザメッセージが送られていないアドレス。こ の場合の時間は通常ハートビートの間隔かまたはそれ以上の長さで ある。 o インアクティブ宛先トランスポートアドレス: エラーのためにインアクティブでありユーザメッセージの転送がで きないと考えられるアドレス。 o メッセージ＝ユーザメッセージ: 上位プロトコル(ULP)からSCTPに渡されたデータ。 o メッセージ認証コード(MAC): 秘密鍵を用いた暗号技術によりハッシュ関数を用いた完全性確認の メカニズム。メッセージ認証コードは典型的には、1つの秘密鍵を 共有している2つの組織の間で送信されたデータの正当性を確認す るために用いられる。SCTPにおいては端末がCOOKIE ECHOチャンク で返されたState Cookie情報の正当性を確認するために用いられる。 "MAC"という言葉は異なる文脈で異なる意味をもつ。SCTPはこの用 語を[RFC2104]と同様の意味で用いる。 o ネットワークバイトオーダー: 上位バイトほど先に来るオーダー(ビッグエンディアンとして知ら れているオーダー) o 順序通りのメッセージ: あるストリームの中で、これまで送られたユーザメッセージとの関 係として、順序通りに送られるユーザメッセージのこと。? o 未処理TSN(あるSCTP端末における): 端末によって送信されたが、まだそれについての受信確認応答が受 領されていないTSN(および対応するDATAチャンク) o パス(経路): あるSCTP端末が相手のSCTP端末がもつある宛先トランスポートアド レスへと送り出すパケットの取る経路。異なる宛先トランスポート アドレスへの送出は必ずしも別の(separate)経路になることを保証 されなくてもよい。 o プライマリパス: プライマリパスは、相手端末へ送出されるパケットにデフォルトで (特に指定しない限り)設定される宛先アドレスと送信元アドレスで ある。ここで定義が送信元アドレスを含むのは、データ送信者がマ ルチホーム環境であるときに、返答チャンクで使われる返信パスや パケットがどのインタフェースから送られるかをよりよく制御する ために、実装が宛先と送信元のアドレスの両方を指定したいと思う かもしれない(MAY)からである。 Stewart, et al. Standards Track [Page 12] RFC 2960 Stream Control Transmission Protocol October 2000 o 受信ウインドウ(rwnd): データの送信者が相手端末の最も直近に計算した受信ウインドウサ イズ(バイト単位)を保存しておくためのSCTP変数。この値によって 送信者は、受信側読み込みバッファの空きスペースの目安とするこ とができる。 o SCTPアソシエーション: SCTP端末間につくられるプロトコル上の関係であり、二つのSCTP端 末とVerificationタグや現在アクティブな配送シーケンス番号 (TSN)などのプロトコル状態情報から構成される。あるアソシエー ションはアソシエーションを構成する端末によって使われるトラン スポートアドレスによって一意に識別される。二つのSCTP端末はあ る時点でその間に1つを超えるアソシエーションをつくってはなら ない(MUST NOT)。 o SCTP端末: SCTPパケットの論理的な送信者と受信者のこと。マルチホーム化さ れたホストにおいてはあるSCTP端末は、SCTPパケットを送ることの できる候補となる宛先トランスポートアドレスの組み合わせとして、 またSCTPパケットを受け取ることのできる送信元トランスポートア ドレスの組み合わせとして、相手に示される。あるSCTP端末によっ て使われる全てのトランスポートアドレスは同じポート番号を使わ なければならないが、複数のIPアドレスを使うことはできる。ある SCTP端末によって使われているあるトランスポートアドレスは他の SCTP端末に使われてはならない。いいかえると、あるトランスポー トアドレスは一つのSCTP端末に対して一意である。 o SCTPパケット(あるいはパケット): SCTPとコネクションレスのパケットネットワーク(例えばIP)の間のインタフェースでやりとりされるデータ配送の単位。SCTPパケットは、共通SCTPヘッダ、可能なSCTP制御チャンク、およびSCTP DATAチャンクにカプセル化されたユーザデータを含む。 o SCTPユーザアプリケーション(SCTPユーザ): SCTPサービスを利用する上位層の論理的なアプリケーションのこと。 上位層プロトコル(ULP)とも呼ばれる。 o スロースタート閾値: SCTP変数のひとつで、SCTP端末がある宛先トランスポートアドレス に対してスロースタートを行うか輻輳回避を行うかを決定するため に使われる閾値である。ssthreshはバイト単位である。 o ストリーム: あるSCTP端末からもう一つのSCTP端末への単方向の論理的なチャンネルのことであり、この中では非順序配送サービスとして送られたもの以外の全てのユーザメッセージは順序通りに送られる。 注意: 逆方向のストリーム間のストリーム番号の関係は、厳密にはアプリケーションがどう使うかにかかっている。これらの関係を必要ならば(if they are so desired)構築し管理するのはSCTPユーザの仕事である。 Stewart, et al. Standards Track [Page 13] RFC 2960 Stream Control Transmission Protocol October 2000 o ストリームシーケンス番号: SCTPの内部で、与えられたストリームの中でユーザメッセージの順 序通りの配送を保証するために使われる16ビットのシーケンス番号。 ユーザメッセージのそれぞれに一つのストリームシーケンス番号が つけられる。 o タイタグ: 前回のアソシエーションで用いたVerificationタグ。このタグは新 しく再始動するアソシエーションを、再始動していない元々のアソ シエーションと関連づけられるように、状態クッキーの中で使われ る。 o 送信制御ブロック (TCB): 存在する他のSCTP端末へのアソシエーションのそれぞれについて、 SCTP端末が作成する内部データ構造。TCBは端末が対応するアソシ エーションを管理維持するための全ての状態と管理情報を含む。 o 送信シーケンス番号 (TSN): SCTPの内部で使われる32ビットのシーケンス番号。受信側のSCTP端 末が受信確認応答を行い、重なった配送を検出できるように、ユー ザデータを含むそれぞれのチャンクに1つのTSNがつけられる。 o トランスポートアドレス: トランスポートアドレスは伝統的にネットワーク層のアドレス、ト ランスポート層のプロトコル、およびトランスポート層のポート番 号で定義される。IP上で動くSCTPの場合、トランスポートアドレス はIPアドレスとSCTPのポート番号(ここではSCTPがトランスポート プロトコル)で定義される。 o (ある端末における)受信未確認のTSN: 端末によって受信はされているが、これに対する受信確認応答がま だ送信されていないTSN(および対応するDATAチャンク)。あるいは 反対に、すでに送信されているがまだ受信確認応答が受信されてい ないTSN。 o 非順序メッセージ: 非順序メッセージは、他の非順序メッセージや順序メッセージも含 んだあらゆるメッセージとの関係の中で、順序が保証されない (unordered)。非順序メッセージは同一ストリームの中で順序メッ セージよりも先または後に送られるかもしれない。 o ユーザメッセージ: SCTPとユーザとの間のインタフェースでやりとりされるデータ配送の単位。 o 検証(Verification)タグ: ランダムに生成される32ビットの符号なし整数。検証タグにより受 信者は、受けとったSCTPパケットが現在のアソシエーションに属し ており、以前のアソシエーションで使われていた古い無効なパケッ トではないことを検証できる。 Stewart, et al. Standards Track [Page 14] RFC 2960 Stream Control Transmission Protocol October 2000 1.5. 略記 MAC - Message Authentication Code [RFC2104] (メッセージ認証コード) RTO - Retransmission Time-out (再送タイムアウト) RTT - Round-trip Time (往復時間) RTTVAR - Round-trip Time Variation (往復時間の変動量) SCTP - Stream Control Transmission Protocol SRTT - Smoothed RTT (平滑化RTT) TCB - Transmission Control Block (配送制御のための情報) TLV - Type-Length-Value Coding Format (タイプ-長さ-値の形) TSN - Transmission Sequence Number (配送シーケンス番号) ULP - Upper-layer Protocol (上位層プロトコル) 1.6 シリアル番号の計算(Arithmetic) 実際の送信シーケンス番号空間は非常に広いながらも有限であるこ とを覚えておくことが大事である。この空間は0から2**32-1までの 範囲である。この空間は有限であるので、送信シーケンス番号を扱 う全ての計算では2**32で余り(modulo)をとらなくてはならない。 この符号なしの計算は、2**32-1から0にまた戻ることによってシー ケンス番号の関係を維持する。コンピュータの剰余(module)計算に は難しいところ(subtleties)があり、これらの値の比較をプログラ ミングする際には細心の注意(great care)を払うべきである。TSN に関していえば、シンボル"=<"は小なりまたは等しい(2**32の余り) ことを意味する。 この文書においてTSNについての比較と計算は、[RFC1982]で定義さ れたシリアル番号計算のSERIAL_BITS = 32の場合を利用するべきで ある(SHOULD)。 端末は、現在の送信ウインドウの開始TSNより2**31-1以上大 きなTSNをもったDATAチャンクを送るべきではない(SHOULD NOT)。 もし送ってしまうとTSNの比較によって問題が起きるであろう。 送信シーケンス番号(TSN)は2**32-1に達すると最初に戻る。すなわ ち、TSN = 2**32-1を送信した後、DATAチャンクが使わなければな らない(MUST)次のTSNはTSN = 0である。 ストリームシーケンス番号についてのあらゆる計算は、[RFC1982] で定義されたシリアル番号計算のSERIAL_BITS = 16の場合を利用す るべきである(SHOULD)。 Stewart, et al. Standards Track [Page 15] RFC 2960 Stream Control Transmission Protocol October 2000 本文書におけるその他のすべての計算と比較には通常の計算 (arithmetic)が用いられる。 2. Conventions キーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, および OPTIONAL, が本文書中にあらわれたときは、[RFC2119]に記述され ている通りに解釈されるものとする。 3. SCTPパケットのフォーマット SCTPパケットは一つの共通ヘッダといくつかのチャンクからなる。チャンクは制御情報かユーザデータを含む。 SCTPパケットのフォーマットは以下に示された通りである。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ INIT、INIT ACKおよびSHUTDOWN COMPLETEチャンクを除いて、MTUの サイズまでは1つのSCTPパケットに複数のチャンクをバンドル(訳注: 一緒に)してよい。INIT、INIT ACKおよびSHUTDOWN COMPLETEチャン クは他のチャンクとバンドルしてはならない(MUST NOT)。チャンク のバンドルの詳細については6.10節を参照のこと。 ユーザデータメッセージが1つのSCTPパケットに納まらない場合、 6.9節で定義された方法によって複数のチャンクに分割してよい。 SCTPパケットの全ての整数フィールドは、特に注記しない限り、ネッ トワークバイトオーダで送信されなければならない(MUST)。 Stewart, et al. Standards Track [Page 16] RFC 2960 Stream Control Transmission Protocol October 2000 3.1 SCTP共通ヘッダフィールドの記述(Descriptions) SCTP共通ヘッダのフォーマット 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 送信元ポート番号: 16 bits (符号なし整数) SCTP送信者のポート番号である。これは受信者がこのパケットがど のアソシエーションに属しているかを識別するために、送信元のIP アドレス、SCTP送信先ポート、およびおそらくは送信先のIPアドレ スとともに用いられる。 送信先ポート番号: 16 bits (符号なし整数) このパケットが送られるべきSCTPポート番号である。受信ホストは 多重化されて送られているSCTPパケットを正しい受信端末・アプリ ケーションに渡すためにこのポート番号を使うであろう。 検証タグ: 32 bits (符号なし整数) このパケットの受信者は検証タグを、送信者が正しいかどうか検証するために用いる。送信にあたり、以下の例外を除き、この検証タグの値はアソシエーション初期化の間に相手端末から受けとったInitiateタグの値にしなければならない。 - INITチャンクを含むパケットは検証タグをゼロにしなけれ ばならない(MUST)。 - Tビットが設定されたSHUTDOWN-COMPLETEチャンクを含むパ ケットは、SHUTDOWN-ACKチャンクを含んだパケットからコピーされ た検証タグを持たなければならない(MUST)。 - ABORTチャンクを含むパケットはABORTを送信する原因となっ たパケットから検証タグをコピーしているかもしれない。詳細は 8.4節と8.5節を参照のこと。 INITチャンクはそれを運ぶSCTPパケットの中で唯一のチャンクでな ければならない(MUST)。 Stewart, et al. Standards Track [Page 17] RFC 2960 Stream Control Transmission Protocol October 2000 チェックサム: 32 bits (符号なし整数) このフィールドはそのSCTPパケットのチェックサムを含む。この計 算については6.8節で議論される。SCTPはチェックサムの計算のた めに付録Bで述べられているAdler-32アルゴリズムを用いる。 3.2 チャンクフィールドの記述 以下の図はSCTPパケットとして送られるチャンクのフィールドフォー マットを示している。各チャンクはチャンク型フィールド、チャン ク固有のフラグフィールド、チャンク長フィールド、および値フィー ルドで形成される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンク型: 8 bits (符号なし整数) このフィールドはチャンク値フィールドに含まれている情報の型を 指定する。とり得る値は0から254までである。255という値は拡張 フィールドとして将来の使用のために予約されている。 チャンク型の値は以下のように定義される: ID Value Chunk Type ----- ---------- 0 - ペイロードデータ (DATA) 1 - 初期化 (INIT) 2 - 初期化の確認応答 (INIT ACK) 3 - 選択的確認応答 (SACK) 4 - ハートビート要求 (HEARTBEAT) 5 - ハートビートの確認応答 (HEARTBEAT ACK) 6 - 中断 (ABORT) 7 - 終了 (SHUTDOWN) 8 - 終了の確認応答 (SHUTDOWN ACK) 9 - 操作エラー (ERROR) 10 - 状態クッキー (COOKIE ECHO) 11 - クッキーの確認応答 (COOKIE ACK) 12 - 明示輻輳通知エコーのための予約 (ECNE) 13 - 輻輳ウインドウの縮小のための予約 (CWR) Stewart, et al. Standards Track [Page 18] RFC 2960 Stream Control Transmission Protocol October 2000 14 - 終了処理の完了 (SHUTDOWN COMPLETE) 15 to 62 - IETFにより予約 63 - IETFにより定義された拡張チャンク 64 to 126 - IETFにより予約 127 - IETFにより定義された拡張チャンク 128 to 190 - IETFにより予約 191 - IETFにより定義された拡張チャンク 192 to 254 - IETFにより予約 255 - IETFにより定義された拡張チャンク チャンク型には、チャンクを処理する受信側の端末がそのチャンクを認識できないときにとるべき行動を高位2ビットが指定できるように、値がわりあてられている。 00 - このSCTPパケットの処理をやめてパケットを棄却せよ。パ ケット内で以降のいずれのチャンクも処理してはならない。 01 - このSCTPパケットの処理をやめてパケットを棄却せよ。パ ケット内で以降のいずれのチャンクも処理してはならない。また" 認識できないパラメータ型"(ERRORチャンクまたはINIT ACKチャン クに含まれる)を用いて、認識できないパラメータを報告する。 10 - このチャンクは飛ばし、処理を継続せよ。 11 - このチャンクは飛ばし、処理を継続せよ。ただし、"認識 できないチャンク型"をエラーの原因としてERRORチャンクで報告せ よ。 注意: ECNEおよびCWRチャンク型は明示輻輳通知(ECN)を将来使 うために予約されている。 チャンクフラグ: 8 bits これらのビットの使い方はチャンクタイプで指定されたチャンクタ イプ次第である。特に指定のない限り、これらはゼロに設定されて 送信され、受信時には無視される。 チャンク長: 16 bits (符号なし整数) この値は、チャンク型、チャンクフラグ、チャンク長、およびチャ ンク値のフィールドを含んだチャンクのサイズをバイト単位で示す。 このため、チャンク値フィールドが長さ0の場合、このチャンク長 フィールドは4に設定される。チャンク長フィールドはパディング を数えない。 Stewart, et al. Standards Track [Page 19] RFC 2960 Stream Control Transmission Protocol October 2000 チャンク値: 可変長 チャンク値のフィールドはチャンクの中で配送される実データを含 む。このフィールドの使い方とフォーマットはチャンク型次第であ る。 チャンクの合計の長さ(タイプと長さと値のフィールドを含む)は4 バイトの倍数でなくてはならない(MUST)。チャンク長が4の倍数で なければ、送信者は全て0のバイトでつめものをしなければならず (MUST)、この詰めもの(padding)はチャンク長には含まれない。送 信者は3バイトを越える詰めものをしないようにするべきである。 受信者は詰めもののバイトを無視しなければならない。 SCTPで定義されているチャンクは3.3節に詳しく記述されている。 またIETFによって定義された拡張チャンクのガイドラインは本文書 の13.1節でみつかるであろう。 3.2.1 オプション／可変長パラメータのフォーマット SCTP制御チャンクのチャンク値は必須フィールドのチャンク型に特 有のヘッダと、それに続く0またはそれ以上のパラメータから成る。 1つのチャンクに含まれるオプションと可変長のパラメータは以下 に示されるような型-長さ-値(Type-Length-Value)フォーマットで 定義される。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクパラメータ型: 16 bits (符号なし整数) この型フィールドはパラメータの型を示す16ビットの識別子である。 とり得る値は0から65534までである。 65535という値はIETFで定義された拡張のために予約されている。 SCTPチャンクの記述で特に指定されているもの以外の値はIETFによっ て使用が予約されている。 Stewart, et al. Standards Track [Page 20] RFC 2960 Stream Control Transmission Protocol October 2000 チャンクパラメータ長: 16 bits (符号なし整数) パラメータ長フィールドは、パラメータ型、パラメータ長、および パラメータ値フィールドを含んだパラメータのサイズを含む。した がって、長さ0のパラメータ値フィールドをもつパラメータは長さ フィールドが4となる。このパラメータ長はパディングを含まない。 チャンクパラメータ値: 可変長 パラメータ値フィールドはパラメータの中で実際に送られる情報を含む。 パラメータの合計の長さ(型、パラメータ長、および値フィールド を含む)は4バイトの整数倍でなければならない(MUST)。パラメータ 長が4バイトの整数倍でない場合、送信者はパラメータの最後(パラ メータ値フィールドの後)に全て0のバイトでパディングする。パディ ングの長さはパラメータ長フィールドには含まれない。送信者は3 バイトを超えてパディングするべきではない(SHOULD NOT)。受信者 はパディングされたバイトを無視しなければならない(MUST)。 パラメータ型は、これを処理する端末がパラメータ型を理解できな い場合にとるべき行動を高位2ビットで指定できるようにコード化 されている。 00 - このSCTPパケットの処理を中止し破棄する。このパケット の中のそれ以上のチャンクは処理しない。 01 - このSCTPパケットの処理を中止し破棄する。このパケット の中のそれ以上のチャンクは処理しない。認識できないパラメータ を「認識できないパラメータ型」に入れて報告する(ERRORまたは INIT ACKチャンクに入れて)。 10 - このパラメータは飛ばし、処理を続ける。 11 - このパラメータは飛ばし処理を続けるが、認識できないパ ラメータを「認識できないパラメータ型」に入れて報告する(ERROR またはINIT ACKチャンクに入れて)。 実際のSCTPパラメータは各SCTPチャンクの節で定義される。IETFに よって定義されたパラメータ拡張についてのルールは13.2節で定義 されている。 3.3 SCTPチャンクの定義 本セクションはさまざまなSCTPチャンク型のフォーマットを定義する。 Stewart, et al. Standards Track [Page 21] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.1 Payload Data (DATA) (0) DATAチャンクは以下のフォーマットを用いなければならない(MUST): 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 = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (seq n of Stream S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 予約: 5 bits 全て0に設定すべきであり、受信者は無視するべきである。 U bit: 1 bit 非順序ビット((U)nordered bit)はもし1に設定されると、このチャ ンクは非順序DATAチャンクであり、このDATAチャンクにはストリー ムシーケンス番号がわりあてられていないことを示す。したがって、 このチャンクの受信者はストリームシーケンス番号フィールドを無 視しなければならない(MUST)。 (必要なら)再構成後、非順序DATAチャンクは受信者によって並び替 えの作業なしに上位層に渡されなければならない(MUST)。 非順序ユーザメッセージが分割されている場合、いずれの断片もU ビットを1に設定しなければならない(MUST)。 B bit: 1 bit 先頭断片ビット((B)eginning fragment bit)は設定されると、ユー ザメッセージの最初の断片であることを示す。 E bit: 1 bit 最後尾断片ビット((E)nding fragment bit)は設定されると、ユー ザメッセージの最後の断片を示す。 Stewart, et al. Standards Track [Page 22] RFC 2960 Stream Control Transmission Protocol October 2000 分割されていないユーザメッセージはBビットとEビットの両方を1 にするだろう。以下の表にまとめられているように、BビットとEビッ トの両方が0の場合は複数(訳注: 3つ以上)に分割されたユーザメッ セージの中間の断片であることを示す。 B E Description ============================================================ | 1 0 | First piece of a fragmented user message | +----------------------------------------------------------+ | 0 0 | Middle piece of a fragmented user message | +----------------------------------------------------------+ | 0 1 | Last piece of a fragmented user message | +----------------------------------------------------------+ | 1 1 | Unfragmented Message | ============================================================ | Table 1: Fragment Description Flags | ============================================================ ユーザメッセージが複数のチャンクに分割されている場合、受信者 はTSNを参照してメッセージを再構成する。この意味するところは、 分割されたユーザメッセージの各断片のTSNは厳密に整列していな ければならない(MUST)ということである。 長さ: 16 bits (符号なし整数) このフィールドは型フィールドの最初からパディングを除いたユー ザデータフィールドの最後までのDATAチャンクの長さをバイト単位 で示す。ユーザデータフィールドを含まないDATAチャンクは長さが 16に設定されるだろう(16バイトを示す)。 TSN : 32 bits (符号なし整数) この値はこのDATAチャンクのTSNを示す。TSNの正しい範囲は0から 4294967295(2**32-1)までである。TSNは4294967295に達したあとは 0に戻る。 ストリーム識別子 S: 16 bits (符号なし整数) 後に続くユーザデータが所属するストリームを指定する。 ストリームシーケンス番号 n: 16 bits (符号なし整数) この値は後続のユーザデータの、ストリームSの中でのストリーム シーケンス番号を示す。正当な範囲は0から65535までである。 ユーザメッセージが配送のためにSCTPによって分割された場合、メッ セージの各断片には同じストリームシーケンス番号が含まれなけれ ばならない(MUST)。 Stewart, et al. Standards Track [Page 23] RFC 2960 Stream Control Transmission Protocol October 2000 ペイロードプロトコル識別子: 32 bits (符号なし整数) この値はアプリケーション(すなわち上位層)が指定するプロトコル 識別子を示す。この値は上位層からSCTPにわたされ、相手端末に送 られる。この識別子はSCTPには使われず、このDATAチャンクによっ て運ばれている情報の種類を識別するために、相手アプリケーショ ンのみならず、どこかのネットワーク機器で使われるかもしれない。 このフィールドは分割されたDATAチャンクにおいても送られる必要 がある(ネットワーク途中のエージェントにも利用可能であること を保証するために)。 値0は、このペイロードデータに対して上位層が、アプリケーション識別子を指定しなかったことを示す。 ユーザデータ: 可変長 これはペイロードのユーザデータである。実装はデータの終端を4 バイト境界に至るまで、全て0のバイトでパディングしなければな らない(MUST)。パディングはいずれも長さフィールドの計算に含ん ではならない(MUST NOT)。送信者は3バイトを超えるパディングを 行ってはならない(MUST never)。 3.3.2 初期化 (INIT) (1) このチャンクは2つの端末の間でSCTPのアソシエーションを初期化 するために使われる。INITチャンクのフォーマットは以下に示す通 りである: 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 = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ INITチャンクは以下のパラメータを含む。特に注記しない限り、い ずれのパラメータもINITチャンクに高々1つしか含まれてはならな い(MUST)。 Stewart, et al. Standards Track [Page 24] RFC 2960 Stream Control Transmission Protocol October 2000 Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Variable Parameters Status Type Value ------------------------------------------------------------- IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Cookie Preservative Optional 9 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Supported Address Types (Note 4) Optional 12 注意 1: INITチャンクは複数のアドレスを含むことができ、そ のアドレスはIPv4および／またはIPv6のいかなる組みあわせでもよ い。 注意 2: ECN可能フィールドは明示型輻輳通知の将来の利用のた めに予約されている。 注意 3: INITチャンクは2つ以上のHost name addressパラメー タを含んではならない(MUST NOT)。さらに、INITの送信者は他のど んなアドレス型もHost name addressと組み合わせてはならない (MUST NOT)。INITの受信者は受信したINITチャンクの中にHost Name addressパラメータが存在するならば、他のアドレス型は無視 しなければならない(MUST)。 注意 4: このパラメータが存在する場合、送信端末がサポート する全てのアドレス型を指定する。このパラメータが含まれていな い場合、送信端末はどのアドレス型もサポート可能であることを示 す。 INITのチャンクフラグフィールドは予約されており、中の全てのビッ トは送信者により0に設定されるべきであり、受信者には無視され るべきである。INIT中のパラメータの並びは任意の順序で処理でき る。 初期化タグ: 32 bits (符号なし整数) INITの受信者(応答端末)は初期化タグパラメータの値を記録する。 このINITの受信者はこのアソシエーションにおいて送信する全ての SCTPパケットの検証タグフィールドにこの値を入れなければならな い(MUST)。 初期化タグは0以外ならばどんな値であってもよい。タグ値の選択 についてのさらなる説明は5.3.1節を参照のこと。 Stewart, et al. Standards Track [Page 25] RFC 2960 Stream Control Transmission Protocol October 2000 受信したINITチャンクの初期化タグの値が0であった場合、受信者 はこれをエラーとして扱い、ABORTを送ってこのアソシエーション を閉じなければならない。 受信者ウインドウ量広告(a_rwnd): 32 bits (符号なし整数) この値はINITの送信者がこのウインドウのために予約し利用できる バッファスペースをバイト単位で示す。アソシエーションが存在す る間、このバッファスペースは小さくする(すなわち、このアソシ エーションから利用できるバッファが奪われる)べきではない (SHOULD)。しかしながら、端末はSACKチャンクの中で送るa_rwndの 値を変更してもよい。 出力ストリーム数 (OS): 16 bits (符号なし整数) INITチャンクの送信者がこのアソシエーションにおいて作成したい 出力ストリーム数を定義する。値0を用いてはならない(MUST NOT)。 注意: OS値が0であるINITを受信したら、このアソシエーショ ンを中止するべきである(SHOULD)。 入力ストリーム数 (MIS) : 16 bits (符号なし整数) 相手端末がこのアソシエーションに作成することのできるストリー ムの、このINITチャンクの送信者が許容可能な最大数を定義する。 値0を用いてはならない(MUST NOT)。 注意: 実際のストリーム数のための交渉はないが、そのかわ り両端末は要求をうけた数と提供される数のうち小さい方を用いる ことだろう。詳しくは5.1.1節を参照のこと。 注意: MIS値が0のINITを受けとったら、そのアソシエーショ ンを中止するべきである(SHOULD)。 初期TSN (I-TSN) : 32 bits (符号なし整数) 送信者が使おうとする初期TSNを定義する。正当な値の範囲は0から 4294967295までである。このフィールドは初期化タグフィールドの 値に設定されてもよい(MAY)。 3.3.2.1 INITにおけるオプションの、あるいは可変長のパラメータ 以下のパラメータは3.2.1節で定義される型−長さ−値フォーマッ トに従う。型−長さ−値フィールドはいずれも前節で定義された固 定長フィールドの後に来なければならない(MUST)。 Stewart, et al. Standards Track [Page 26] RFC 2960 Stream Control Transmission Protocol October 2000 IPv4 Address Parameter (5) 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 = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Address: 32 bits (符号なし整数) 送信端末のIPv4アドレスを含む。バイナリでコード化されたIPアド レスである。 IPv6 Address Parameter (6) 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 = 6 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Address: 128 bit (符号なし整数) 送信端末のIPv6アドレスを含む。アドレスはバイナリでコード化さ れている。 注意: 送信者はIPv4射影IPv6アドレス[RFC2373]を使っては ならず(MUST NOT)、かわりにIPv4アドレスに対してはIPv4アドレス パラメータを用いるべきである。 SCTP共通ヘッダ内の送信元ポート番号と組みあわせることにより、 IPv4またはIPv6アドレスパラメータの値は、INITの送信者が初期化 しようとしているアソシエーションでサポートすることになるであ ろうトランスポートアドレスを示す。すなわちこのアソシエーショ ンが存在する間、INITの送信者から送信されるIPデータグラムの送 信元アドレスフィールドにはこのIPアドレスが入ることだろうし、 またINITの受信者から送られるIPデータグラムの宛先アドレスとし て使われることになるだろう。 Stewart, et al. Standards Track [Page 27] RFC 2960 Stream Control Transmission Protocol October 2000 INITの送信者がマルチホーム環境にある場合、一つのINITチャンク に2つ以上のIPアドレスパラメータを含むことができる。さらに、 マルチホーム環境にある端末は異なるネットワークにアクセスする かもしれないので、一つのINITチャンクに2つ以上のアドレス型が あってもよい。すなわち、IPv4とIPv6のアドレスは同じINITチャン クの中にあってもよい。 INITが少なくともひとつのIPアドレスパラメータを含むなら、INIT チャンクを含むIPデータグラムの送信元アドレスとINITの中で提供 される追加アドレスのいずれも、INITを受信した端末が送信する際 の宛先アドレスとして使ってよい。INITがひとつもIPアドレスパラ メータを含んでいない場合、INITを受信した端末は受信したIPデー タグラムの送信元アドレスを、そのアソシエーションにとって唯一 の宛先アドレスとして用いなければならない(MUST)。 INITやINIT-ACKの中でひとつもIPアドレスパラメータを用いないこ とは、アソシエーションをNATボックスを越えて動作させる代替手 段のひとつであることに注意。 Cookie Preservative (9) INITの送信者は、このINITの受信者に状態クッキーの有効期限が長 いことを知らせるために、このパラメータを使うだろう。 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 = 9 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested Cookie Life-span Increment (msec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Suggested Cookie Life-span Increment: 32 bits (unsigned integer) このパラメータは、送信者が受信者に希望するデフォルトのクッキー 有効期間に加算する幅(increment)をミリ秒で示す。 このオプションパラメータは、送信者の以前のアソシエーション確 立試行が有効期間切れの状態クッキーを扱おうとしたエラーにより 失敗した相手に対し、再度アソシエーション確立を試行する場合に INITチャンクに付加されるべきである。受信者は自身のセキュリティ 上の理由により、提示された有効期間の延長を無視してもよい(MAY)。 Stewart, et al. Standards Track [Page 28] RFC 2960 Stream Control Transmission Protocol October 2000 Host Name Address (11) INITの送信者はこのパラメータを使って(自身のIPアドレスのかわ りに)自身のホスト名を相手に渡すことができる。この名前を解決 するのは相手の仕事となる。このパラメータを使うことで、アソシ エーションをNATボックス経由で動作させやすくなるかもしれない。 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 = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Host Name: variable length このフィールドはRFC1123 Section 2.1 [RFC1123]の「ホスト名規 則 (host name syntax)」に沿った名前を含む。このホスト名を解 決する手段についてはSCTPの関知する範囲を越える。 注意: ホスト名文字列には少なくともひとつのヌル終端子が含まれ、この終端子も長さに含まれなければならない。 Supported Address Types (12) INITの送信者はサポートしている全てのアドレス型を列挙するためこのパラメータを使う。 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 = 12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type #1 | Address Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address Type: 16 bits (unsigned integer) ここには対応するアドレスTLVの型の値が入る(例: IPv4 = 5, IPv6 = 6, Hostname = 11)。 Stewart, et al. Standards Track [Page 29] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.3 初期化確認応答 (INIT ACK) (2): INIT ACKチャンクはSCTPアソシエーションの初期化に対して確認応 答するために使われる。 INIT ACKのパラメータの部分はINITチャンクと同様の書式である。 INIT ACKはINITに加えてさらに2つの可変パラメータ、状態クッキー および理解不能パラメータを用いる。 INIT ACKチャンクの書式は以下である。 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 = 2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Optional/Variable-Length Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 初期化タグ: 32 bits (unsigned integer) INIT ACKの受信者はこの初期化タグパラメータの値を記録する。 INIT ACKの受信者がこのアソシエーションにおいて送信する全ての SCTPパケットの検証タグフィールドにはこの値を入れなければなら ない(MUST)。 初期化タグは0という値をとってはならない(MUST NOT)。初期化タ グの値の選択についてさらに詳しく知りたい場合は5.3.1節を参照 のこと。 受信したINIT ACKチャンクの初期化タグの値が0であると判明した 場合、受信者はこれをエラーとして扱い、ABORTを送信することに よってアソシエーションを閉じなければならない(MUST)。 Stewart, et al. Standards Track [Page 30] RFC 2960 Stream Control Transmission Protocol October 2000 Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned integer) この値は、このウインドウに関してINIT ACKの送信者が確保したバッ ファスペースの大きさをバイト単位で示す。アソシエーションの存 在期間において、このバッファスペースは縮小すべきではない(す なわち、このアソシエーションのために確保されたバッファを取り さるべきではない)(SHOULD)。 Number of Outbound Streams (OS): 16 bits (unsigned integer) このINIT ACKチャンクの送信者がこのアソシエーションにおいて作 成したい送出ストリームの数を定義する。値として0を用いてはな らない(MUST NOT)。 注意: この送出ストリーム数の値が0のINIT ACKを受信したら、こ のアソシエーションとそのTCBは破棄するべきである(SHOULD)。 Number of Inbound Streams (MIS) : 16 bits (unsigned integer) このINIT ACKチャンクの送信者が相手に対して、このアソシエーショ ンの中に作成を許可できる最大のストリーム数を定義する。値とし て0を用いてはならない(MUST NOT)。 注意: 実際のストリーム数についての交渉は行われないが、そのか わり、2つの端末はmin(要求、提供)の値を使うだろう(訳注: 要求 された数とこちらが提供できる数の小さい方の値)。詳細は5.1.1節 を参照のこと。 注意: 受信ストリーム数の値が0となったINIT ACKを受けとったら、 このアソシエーションとそのTCBは破棄するべきである(SHOULD)。 Initial TSN (I-TSN) : 32 bits (unsigned integer) INIT-ACKの送信者が使うであろうTSNの初期値を定義する。有効な範囲は0から4294967295までである。このフィールドは初期化タグフィールドの値としてもよい(MAY)。 Fixed Parameters Status ---------------------------------------------- Initiate Tag Mandatory Advertised Receiver Window Credit Mandatory Number of Outbound Streams Mandatory Number of Inbound Streams Mandatory Initial TSN Mandatory Stewart, et al. Standards Track [Page 31] RFC 2960 Stream Control Transmission Protocol October 2000 Variable Parameters Status Type Value ------------------------------------------------------------- State Cookie Mandatory 7 IPv4 Address (Note 1) Optional 5 IPv6 Address (Note 1) Optional 6 Unrecognized Parameters Optional 8 Reserved for ECN Capable (Note 2) Optional 32768 (0x8000) Host Name Address (Note 3) Optional 11 Note 1: INIT ACKチャンクはIPアドレスパラメータをいくつでも含むことができる。これらのパラメータはIPv4と、またはIPv6のどのような組み合わせでもよい。 Note 2: ECN可能フィールドは明示輻輳通知(Explicit Congestion Notification)の将来の利用のため予約されている。 Note 3: INIT ACKチャンクは2つ以上のホスト名アドレスパラメータを含んではならない(MUST NOT)。INIT ACKの送信者はさらに、INIT ACKの中にホスト名アドレスとともに他のアドレス型を組みあわせてはならない(MUST NOT)。INIT ACKの受信者は、ホスト名アドレスパラメータが含まれている場合、他のアドレス型を無視しなければならない(MUST)。 実装上の注意: 実装は可変長の状態クッキーおよび(AND)可変長のアドレスリストのためにきわめて大きく(1500バイトを超える)なったINIT ACKを受信できるように準備しておかねばならない(MUST)。例えばINITへの返答者が送りたいIPv4アドレスを1000個もっているなら、INIT ACKにこれを格納するために少なくとも8,000バイトを必要とするだろう。 SCTP共通ヘッダに含まれる送信元ポートと組みあわせて、INIT ACKの中のそれぞれのIPアドレスパラメータはINIT ACKの受信者に対し、INIT ACKの送信者が初期化しようとしているアソシエーションの有効期間にわたってサポートする正当なトランスポートアドレスを示す。 INIT ACKが少なくともひとつのIPアドレスパラメータを含んでいた場合、INIT-ACKの受信者はINIT ACKを含むIPデータグラムの送信元アドレスとINIT ACKに含まれるどの追加アドレスも宛先として用いてよい。INIT ACKがIPアドレスパラメータを含んでいなかった場合は、INIT-ACKの受信者はIPデータグラムの送信元アドレスをそのアソシエーションの唯一の宛先アドレスとして用いなければならない(MUST)。 状態クッキーと認識不可能パラメータは3.2.1節で定義された型−長さ−値のフォーマットを用いており、以下のように記述される。その他のフィールドはINITチャンクの対応する部分と同様に定義される。 Stewart, et al. Standards Track [Page 32] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.3.1 オプションまたは可変長のパラメータ 状態クッキー パラメータ型の値: 7 パラメータの長さ: 可変長、クッキーの大きさに依存 パラメータの値: このパラメータの値は、このINIT ACK送信者がアソシエーションを 作成するのに必要な全ての状態やパラメータの情報と、メッ セージ認証コード(MAC)を含まなければならない(MUST)。状態クッ キーの定義について、詳細は5.1.3節を参照のこと。 認識不可能パラメータ: パラメータ型の値: 8 パラメータの長さ: 可変長 パラメータの値: このパラメータは、INITが送信者に報告すべきであると指定されて いる値をもった認識不可能パラメータを含んでいる場合、INITチャ ンクの送出元に返される。このパラメータの値はINITチャンクから コピーされたパラメータ型、長さ、および値のフィールド付きの認 識不可能パラメータを含むだろう。 3.3.4 選択確認応答 (SACK) (3): このチャンクは受信したDATAチャンクに確認応答し、DATAチャンク の順序列の中にあるギャップをTSNによって相手端末に知らせるた めに送られる。 SACKは累積TSN確認応答と受信ウインドウサイズ広告(a_rwnd)の各 パラメータを含まなければならない(MUST)。 定義より、累積TSN確認応答パラメータの値は受信TSN列の断絶の前 にある最後のTSNであり、これの次のTSNはSACKを送信する端末によっ てまだ受信されていない。したがって、このパラメータはこれ以下 の全てのTSNが受信されたことを確認応答する。 SACK受信者によるa_rwndの扱い方は6.2.1節で詳細に議論する。 Stewart, et al. Standards Track [Page 33] RFC 2960 Stream Control Transmission Protocol October 2000 SACKはまた0個またはそれ以上のギャップAckブロックを含む。各ギャッ プAckブロックは受信TSN順序列の中にある断絶に続く受信TSNの部 分列を確認応答する。定義より、ギャップAckブロックによって確 認応答される全てのTSNは累積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 = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 送信時は全て0とし、受信時は無視する。 累積TSN確認応答: 32 bits (符号なし整数) このパラメータは断絶の前に順序通りに受けとったDATAチャ ンク列の最後のTSNを含む。 受信ウインドウ量広告 (a_rwnd): 32 bits (符号なし整数) このフィールドはこのSACKの送信者の更新された受信バッファ スペースをバイト単位で示す。詳しくは6.2.1節を参照のこと。 Stewart, et al. Standards Track [Page 34] RFC 2960 Stream Control Transmission Protocol October 2000 ギャップAckブロックの数: 16 bits (符号なし整数) このSACKに含まれているギャップAckブロックの数を示す。 重複TSNの数: 16 bit このフィールドは端末が受けとった重複TSNの数を含む。重 複TSNのそれぞれが、以下のギャップAckブロックリストに挙げられ る。 ギャップAckブロック: このフィールドはギャップAckブロックを含む。これらはそ れぞれのギャップAckブロックについて、ギャップAckブロック数フィー ルドで定義されたギャップAckブロックの数になるまで繰り返され る。(累積TSN確認応答+ギャップAckブロック始点)以上で、かつ(累 積TSN確認応答+ギャップAckブロック終点)以下であるTSNをもつ全 てのDATAチャンクは正しく受信されたとみなされる。 Gap Ack Block Start: 16 bits (unsigned integer) あるGap Ack Blockの開始位置にあたるTSNのオフセットを示す。実 際のTSN番号を計算するには、累積TSN確認番号にこのオフセットを 足せばよい。この計算されたTSNが受信されたこのGap Ack Blockの 先頭TSNを示す。 Gap Ack Block End: 16 bits (unsigned integer) あるGap Ack Blockの終了位置にあたるTSNのオフセットを示す。実 際のTSN番号を計算するには、累積TSN確認番号にこのオフセットを 足せばよい。この計算されたTSNが、受信されたDATAチャンクのう ち、このGap Ack Blockの中で最後のTSNを示す。 例えば、受信者が選択確認応答(Selective ACK)を送ろうとしたと き、以下のDATAチャンクが新しく到着していたとしよう。 Stewart, et al. Standards Track [Page 35] RFC 2960 Stream Control Transmission Protocol October 2000 ---------- | TSN=17 | ---------- | | <- still missing ---------- | TSN=15 | ---------- | TSN=14 | ---------- | | <- still missing ---------- | TSN=12 | ---------- | TSN=11 | ---------- | TSN=10 | ---------- このとき、SACKのパラメータ部分は(送信者が新しいa_rwndを4660 としたと仮定すると)以下のように構成されなければならない (MUST): +--------------------------------+ | Cumulative TSN Ack = 12 | +--------------------------------+ | a_rwnd = 4660 | +----------------+---------------+ | num of block=2 | num of dup=0 | +----------------+---------------+ |block #1 strt=2 |block #1 end=3 | +----------------+---------------+ |block #2 strt=5 |block #2 end=5 | +----------------+---------------+ 重複TSN: 32 bits (unsigned integer) 最後のSACKが送られてから、あるTSNが何度重複して受信されたかを示す。受信者が(SACKを送る前に)重複TSNを受けとったときはいつでも、それを重複リストに付け加える。それぞれのSACKを送ったあとで、重複回数は0に戻される。 例えば、受信者がTSN19を3回受けとったなら、送出するSACKに19を2回列挙するだろう。そのSACKの送出後、さらにひとつのTSN19を受けとったなら、次の送出SACKに重複として19を列挙するだろう。 Stewart, et al. Standards Track [Page 36] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.5 ハートビート要求 (HEARTBEAT) (4): 端末は現存のアソシエーションで定義されている特定の宛先トランスポートアドレスの到達性を検知するために、相手端末に対しこのチャンクを送るべきである。 パラメータフィールドは送信者にしか理解できない可変長の不透明な(opaque)データ構造であるハートビート情報を含む。 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 = 4 | Chunk Flags | Heartbeat Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (Variable-Length) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 送信時は0とし、受信時は無視する。 ハートビート長: 16 bits (unsigned integer) チャンクヘッダとハートビート情報フィールドを含むチャンクのサイズをバイト単位で指定する。 ハートビート情報: variable length 3.2.1節で記述されたフォーマットを用いた可変長パラメータとして定義される、すなわち: Variable Parameters Status Type Value ------------------------------------------------------------- Heartbeat Info Mandatory 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Info Type=1 | HB Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Sender-specific Heartbeat Info / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart, et al. Standards Track [Page 37] RFC 2960 Stream Control Transmission Protocol October 2000 送信者特有のハートビート情報フィールドは通常、このHEARTBEATチャンクが送り出された時点の送信者における現在時刻とこのHEARTBEATが送られる宛先トランスポートアドレスについての情報を含む(8.3節参照)。 3.3.6 ハートビート確認応答 (HEARTBEAT ACK) (5): 端末はHEARTBEATチャンクへの返答として、相手端末にこのチャンクを送るべきである(8.3節参照)。HEARTBEAT ACKは常に、この確認応答が返答しようとしているHEARTBEATチャンクを含むIPデータグラムの送信元IPアドレスに対して送られる。 パラメータフィールドは可変長の不透明な(opaque)データ構造を含む。 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 = 5 | Chunk Flags | Heartbeat Ack Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (Variable-Length) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 送信時は0とし、受信時は無視する。 ハートビート確認応答長: 16 bits (unsigned integer) チャンクヘッダとハートビート情報フィールドを含むチャンクのサイズをバイト単位で指定する。 ハートビート情報: variable length このフィールドは、このハートビート確認応答が返答しようとしているハートビート要求に含まれるハートビート情報パラメータを含まなければならない(MUST)。 Variable Parameters Status Type Value ------------------------------------------------------------- Heartbeat Info Mandatory 1 Stewart, et al. Standards Track [Page 38] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.7 アソシエーションの中止(Abort) (ABORT) (6): ABORTチャンクはアソシエーションを閉じるためにアソシエーションの相手に対して送られる。ABORTチャンクは受信者に対し中止の理由を知らせるために、原因パラメータを含むかもしれない。DATAチャンクはABORTとバンドルしてはならない(MUST NOT)。制御チャンク(INIT、INIT ACKおよび、SHUTDOWN COMPLETEを除く)はABORTとバンドルしてもよいが、SCTPパケットの中でABORTの前に配置しなければならない(MUST)。さもなくばそれらの制御チャンクは受信者によって無視されるだろう。 端末がフォーマットエラーとなるABORTや、存在しないアソシエーションに対するABORTを受けとったなら、これを静かに(silently)破棄しなければならない(MUST)。さらにどんな状況であろうとも、ABORTを受信した端末はこのABORTへの返答として自身のABORTを送信してはならない(MUST NOT)。 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 = 6 |Reserved |T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / zero or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 予約: 7 bits 送信時には0とし受信時には無視する。 T bit: 1 bit 送信者が破壊したTCBがあればTビットを0とする。もし送信者がTCBをもっていなければこのビットを1にすべきである。 Note: 検証のためこのチャンクには特別のルールが適用される。詳しくは8.5.1節を参照のこと。 チャンク長: 16 bits (unsigned integer) チャンクヘッダと存在するすべてのエラー原因フィールドを含むチャンクのバイト単位でのサイズとする。 エラー原因の定義については3.3.10節を参照のこと。 Stewart, et al. Standards Track [Page 39] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.8 アソシエーションのシャットダウン(Shutdown) (SHUTDOWN) (7): アソシエーションを確立している端末は相手との間でアソシエーションを上品に(graceful)閉じるためにこのチャンクを使わなければならない(MUST)。このチャンクは以下のフォーマットである。 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 = 7 | Chunk Flags | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 送信時には0とし受信時には無視する。 チャンク長: 16 bits (unsigned integer) パラメータの長さを示す。8となる。 累積TSN確認応答: 32 bits (unsigned integer) このパラメータはギャップの前に連続して受信されたもののうち最後のチャンクのTSNを含む。 注意: SHUTDOWNメッセージはGap Ack Blocksを含まないので、受信が順序通りでなかったTSNを確認応答するためには使うことができない。SACKにおいて以前含まれていたが今回は含まれていないGap Ack Blocksはデータ受信者が該当のDATAチャンクを破棄したことを示す。SHUTDOWNはGap Ack Blocksを含まないので、SHUTDOWNの受信者はGap Ack Blockが含まれていないからといってデータが破棄されたと解釈するべきではない(破棄についての情報は6.2節を参照)。 3.3.9 シャットダウン確認応答 (SHUTDOWN ACK) (8): このチャンクはシャットダウン処理の完了時にSHUTDOWNチャンクへの返答として用いなければならない(MUST)。詳細は9.2節を参照のこと。 SHUTDOWN ACKチャンクにパラメータはない。 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 = 8 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stewart, et al. Standards Track [Page 40] RFC 2960 Stream Control Transmission Protocol October 2000 チャンクフラグ: 8 bits 送信時は0とし受信時は無視する。 3.3.10 操作(Operation)エラー (ERROR) (9): 端末は相手端末になんらかのエラーの条件を知らせるためにこのチャンクを送る。このチャンクは一つ以上のエラー原因を含む。操作エラー(チャンク)自身は致命的ではないが、致命的な条件を報告するためにABORTチャンクとともに使われるだろう。このチャンクには以下のパラメータがある。 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 = 9 | Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / one or more Error Causes / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 送信時は0とし、受信時は無視する。 長さ: 16 bits (unsigned integer) チャンクヘッダと存在する全てのエラー原因フィールドを含むチャンクのサイズをバイト単位で指定する。 エラー原因は3.2.1節で記述されたフォーマットを用いて可変長パラメータとして定義される。すなわち: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 原因コード: 16 bits (unsigned integer) 報告されるエラー条件の型を定義する。 Stewart, et al. Standards Track [Page 41] RFC 2960 Stream Control Transmission Protocol October 2000 Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 原因パラメータの長さ: 16 bits (unsigned integer) 原因コード(Cause Code)、原因パラメータの長さ(Cause Length)、および原因特有の情報フィールド(Cause-Specific Information)を含むパラメータのサイズをバイト単位で指定する。 原因特有の情報: variable length このフィールドはエラー条件の詳細を含む。 3.3.10.1 - 3.3.10.10節で、SCTPのエラー原因を定義する。IETFで新しいエラー原因を定義するためのガイドラインについては13.3節で議論する。 3.3.10.1 Invalid Stream Identifier (1) エラー原因 --------------- Invalid Stream Identifier: 端末が存在しないストリームに対して送られたDATAチャンクを受けとったことを示す。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=1 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ストリーム識別子: 16 bits (unsigned integer) 受信してエラーとなったDATAチャンクのストリーム識別子を含む。 Stewart, et al. Standards Track [Page 42] RFC 2960 Stream Control Transmission Protocol October 2000 予約: 16 bits このフィールドは予約されている。送信時には全て0とし、受信時には無視する。 3.3.10.2 Missing Mandatory Parameter (2) エラー原因 --------------- 必須パラメータの不足: 受信したINITまたはINIT ACKの中にひとつ以上の必須TLVパラメータが含まれていないことを示す。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=2 | Cause Length=8+N*2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params=N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #1 | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 不足パラメータの数: 32 bits (unsigned integer) このフィールドは原因特有の情報フィールドに含まれているパラメータの数を含む。 不足パラメータの型: 16 bits (unsigned integer) 各フィールドはぬけている必須パラメータの型(訳注: 型を示す数字)を含むだろう。 3.3.10.3 有効期限切れクッキーのエラー (3) エラー原因 -------------- 有効期限切れクッキーのエラー: 有効期限の切れた正当な状態クッキーの受信を示す +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=3 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measure of Staleness (usec.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 有効期限切れからの時間: 32 bits (unsigned integer) このフィールドは現在時刻と状態クッキーが有効期限切れした時刻との差をミリ秒で示す。 Stewart, et al. Standards Track [Page 43] RFC 2960 Stream Control Transmission Protocol October 2000 このエラー原因の送信者は、有効期限切れからの時間フィールドにゼロでない値を入れることで状態クッキーがいつ有効期限切れしたかを報告することができる(MAY)。送信者がこの情報を提供したくない場合は、有効期限切れからの時間フィールドをゼロにすべきである。 3.3.10.4 資源不足 (4) エラー原因 --------------- 資源不足(Out of Resource): 送信者が資源不足であることを示す。これは通常ABORTと組み合わせて、あるいはABORTの中に入れて送られる。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=4 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.10.5 解決できないアドレス (5) エラー原因 --------------- 解決できないアドレス: この送信者が指定されたアドレスパラメータを解決できないことを示す(例えばこの送信者がそのアドレスの型をサポートしていない場合)。これは通常ABORTと組み合わせて、あるいはABORTの中に入れて送られる。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=5 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unresolvable Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 解決できないアドレス(Unresolvable Address): variable length 解決できないアドレスフィールドにはアドレスパラメータ(またはホスト名パラメータ)の完全な型、長さ、値を入れる。このパラメータは解決できないアドレスまたはホスト名を含む。 3.3.10.6 認識できないチャンク型 (6) エラー原因 --------------- 認識できないチャンク型: このエラー原因は、受信者がこのチャンクを理解できず、チャンク型の上位ビットが01または11になっている場合に、このチャンクの送信元に返される。 Stewart, et al. Standards Track [Page 44] RFC 2960 Stream Control Transmission Protocol October 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 認識できないチャンク: variable length 認識できないチャンクフィールドには、SCTPパケットの中から認識できなかったチャンクを、チャンク型、チャンクフラグ、およびチャンク長を完全にそろえて入れる。 3.3.10.7 不当な必須パラメータ (7) エラー原因 --------------- 不当な必須パラメータ: このエラー原因はINITまたはINIT ACKチャンクの必須パラメータのひとつが不当な値に設定されていたときに、このチャンクの送信元に返される。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=7 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.10.8 認識できないパラメータ (8) エラー原因 --------------- 認識できないパラメータ: 受信者がINIT ACKチャンクにある一つ以上のオプショナルTLVパラメータを認識できない場合、このエラー原因がINIT ACKチャンクの送信元に返される。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=8 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 認識できないパラメータ: variable length 認識できないパラメータフィールドにはINIT ACKチャンクからTLVの完全な形でコピーした認識できないパラメータを入れる。このエラー原因は通常、INIT ACKに返答するCOOKIE ECHOチャンクの送信者が認識できないパラメータを報告するとき、COOKIE ECHOチャンクとバンドルされたERRORチャンクに入れられる。 Stewart, et al. Standards Track [Page 45] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.10.9 ユーザデータ無し (9) エラー原因 --------------- ユーザデータ無し: このエラー原因は受信したDATAチャンクにユーザデータが含まれていなかった場合、DATAチャンクの送信元に返される。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=9 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / TSN value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TSN値: 32 bits (+unsigned integer) TSN値フィールドにはユーザデータフィールドのないDATAチャンクのTSNを入れる。 このエラー原因は通常ABORTチャンクに入れて返される(6.2節参照)。 3.3.10.10 シャットダウン中のクッキー受信 (10) エラー原因 --------------- シャットダウン中のクッキー受信: 端末がSHUTDOWN-ACK-SENT状態の間にCOOKIE ECHOを受信した。このエラーは通常再送されるSHUTDOWN ACKにバンドルされたERRORチャンクに入れて返される。 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3.11 クッキーエコー (COOKIE ECHO) (10): このチャンクはアソシエーションの初期化中のみに用いる。初期化 プロセスを完了するために、アソシエーションの初期化を行いたい 端末から相手に対して送られる。このチャンクはこのアソシエーショ ン内で送られるどのDATAチャンクよりも前に位置しなければならな い(MUST)が、同じパケットに一つ以上のDATAチャンクとともにバン ドルされてもよい(MAY)。 Stewart, et al. Standards Track [Page 46] RFC 2960 Stream Control Transmission Protocol October 2000 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 = 10 |Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bit 送信の際には0とし、受信の際には無視する。 長さ: 16 bits (unsigned integer) バイトで表したチャンクのサイズ。4バイトのチャンクヘッダとクッ キーのサイズを含む。 クッキー: 可変長 このフィールドには前に受信したINIT ACKの中の状態クッキーを正 確にコピーしなければならない。 実装は相互運用性を保証するためにこのクッキーをできるだけ小さ くするべきである(SHOULD)。 3.3.12 クッキー確認応答 (COOKIE ACK) (11): このチャンクはアソシエーションの初期化中にのみ用いる。COOKIE ECHOチャンクの受信を確認するために使われる。このチャンクはこ のアソシエーションの中でDATAやSACKチャンクよりも先に送られな ければならない(MUST)が、同じSCTPパケット内に一つ以上のDATAチャ ンクまたはSACKチャンクとともにバンドルされてもよい(MAY)。 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 = 11 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 送信の際には0とし、受信の際には無視される。 Stewart, et al. Standards Track [Page 47] RFC 2960 Stream Control Transmission Protocol October 2000 3.3.13 シャットダウン完了 (SHUTDOWN COMPLETE) (14): このチャンクはシャットダウン処理の完了時にSHUTDOWN ACKチャンクを受けとったことを知らせるために使われなければならない(MUST)。詳細は9.2節を参照のこと。 SHUTDOWN COMPLETEチャンクはパラメータを持たない。 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 = 14 |Reserved |T| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ チャンクフラグ: 8 bits 予約: 7 bits 送信においては0とし、受信の際には無視される。 T bit: 1 bit Tビットは送信者が破棄したTCPを保持していたならば0とさ れる。送信者がTCBを持っていないならば、このビットは1とされる。 注意: 検証のために特別のルールがこのチャンクに適用される。 詳細は8.5.1節を参照のこと。 4. SCTPアソシエーションの状態遷移図 SCTPアソシエーションの存在する間、SCTP端末のアソシエーションはさまざまなイベントに反応してある状態からある別の状態へ遷移する。アソシエーションの状態を遷移させる可能性のあるイベントは以下を含む: o SCTPユーザの根本的(primitive)な要求、例えば[ASSOCIATE]、[SHUTDOWN]、[ABORT] o INIT、COOKIE ECHO、ABORT、SHUTDOWNなどの制御チャンクの受信 o いくつかのタイムアウトイベント 以下の図に示される状態遷移図は状態遷移に加えて、原因となるイ ベントと結果としてなされる行動も合わせて示す。エラー条件のい くつかは状態遷移図に示されていないことに注意のこと。すべての 特殊な場合についての完全な記述はテキスト中に書かれているはず である。 Stewart, et al. Standards Track [Page 48] RFC 2960 Stream Control Transmission Protocol October 2000 注意: チャンク名は全て大文字で書き、パラメータ名は最初の 文字を大文字とする(例えば、COOKIE ECHOチャンク型、State Cookieパラメータ)。状態遷移を引き起こすイベントやメッセージ が1つ以上起こり得るときは、(A),(B)等と示す。 ----- -------- (frm any state) / \ / rcv ABORT [ABORT] rcv INIT | | | ---------- or ---------- --------------- | v v delete TCB snd ABORT generate Cookie \ +---------+ delete TCB snd INIT ACK ---| CLOSED | +---------+ / \ [ASSOCIATE] / \ --------------- | | create TCB | | snd INIT | | strt init timer rcv valid | | COOKIE ECHO | v (1) ---------------- | +------------+ create TCB | | COOKIE-WAIT| (2) snd COOKIE ACK | +------------+ | | | | rcv INIT ACK | | ----------------- | | snd COOKIE ECHO | | stop init timer | | strt cookie timer | v | +--------------+ | | COOKIE-ECHOED| (3) | +--------------+ | | | | rcv COOKIE ACK | | ----------------- | | stop cookie timer v v +---------------+ | ESTABLISHED | +---------------+ Stewart, et al. Standards Track [Page 49] RFC 2960 Stream Control Transmission Protocol October 2000 (from the ESTABLISHED state only) | | /--------+--------\ [SHUTDOWN] / \ -------------------| | check outstanding | | DATA chunks | | v | +---------+ | |SHUTDOWN-| | rcv SHUTDOWN/check |PENDING | | outstanding DATA +---------+ | chunks | |------------------ No more outstanding | | ---------------------| | snd SHUTDOWN | | strt shutdown timer | | v v +---------+ +-----------+ (4) |SHUTDOWN-| | SHUTDOWN- | (5,6) |SENT | | RECEIVED | +---------+ +-----------+ | \ | (A) rcv SHUTDOWN ACK | \ | ----------------------| \ | stop shutdown timer | \rcv:SHUTDOWN | send SHUTDOWN COMPLETE| \ (B) | delete TCB | \ | | \ | No more outstanding | \ |----------------- | \ | send SHUTDOWN ACK (B)rcv SHUTDOWN | \ | strt shutdown timer ----------------------| \ | send SHUTDOWN ACK | \ | start shutdown timer | \ | move to SHUTDOWN- | \ | ACK-SENT | | | | v | | +-----------+ | | SHUTDOWN- | (7) | | ACK-SENT | | +----------+- | | (C)rcv SHUTDOWN COMPLETE | |----------------- | | stop shutdown timer | | delete TCB | | Stewart, et al. Standards Track [Page 50] RFC 2960 Stream Control Transmission Protocol October 2000 | | (D)rcv SHUTDOWN ACK | |-------------- | | stop shutdown timer | | send SHUTDOWN COMPLETE | | delete TCB | | \ +---------+ / \-->| CLOSED |<--/ +---------+ Figure 3: State Transition Diagram of SCTP 注意: 1) 受信したCOOKIE ECHOの中の状態クッキーが正当でない場合 (すなわち完全性チェックを通過できなかった場合)、受信者は何も メッセージを出さずに(silently)このパケットを破棄しなければな らない(MUST)。あるいは、受信した状態クッキーが期限切れだった 場合(5.1.5節を参照)、受信者はERRORチャンクを返送しなければな らない(MUST)。いずれの場合も、受信者はCLOSED状態のままである。 2) もしT1-initタイマが切れたならば、端末はSCTP状態を変更 せずに、INITを再送しT1-initタイマを再始動させなければならな い(MUST)。この作業はMax.Init.Retransmits回まで繰り返されなけ ればならない(MUST)。その後(訳注: 最終的にINITの返事が得られ なかった場合)、端末は初期化プロセスを中止しSCTPユーザにエラー を報告しなければならない(MUST)。 3) もしT1-cookieタイマが切れたならば、端末はSCTP状態を変 更することなく、COOKIE ECHOを再送し、T1-cookieタイマを再始動 させなければならない(MUST)。この作業はMax.Init.Retransmits回 まで繰り返されなければならない(MUST)。その後(訳注: 最終的に COOKIE ECHOの返事が得られなかった場合)、端末は初期化プロセス を中止しSCTPユーザにエラーを報告しなければならない(MUST)。 4) SHUTDOWN-SENT状態において端末は受信したDATAチャンクの いずれに対しても遅延なく受信確認応答をしなければならない (MUST)。 5) SHUTDOWN-RECEIVED状態においては、端末はSCTPユーザから のいかなる新しい送信要求も受け付けてはならない(MUST NOT)。 6) SHUTDOWN-RECEIVED状態においては、端末はデータを送信ま たは再送し、送信キューにある全てのデータが送信されたときには この状態から遷移しなければならない(MUST)。 7) SHOUTDOWN-ACK-SENT状態においては、端末はSCTPユーザから のいかなる新しい送信要求も受け付けてはならない。 CLOSED状態はアソシエーションが確立されていない(すなわち存在 しない)ことを示すために使われる。 Stewart, et al. Standards Track [Page 51] RFC 2960 Stream Control Transmission Protocol October 2000 5. アソシエーションの初期化(Initialization) あるSCTP端末("A")から他のSCTP端末("Z")に最初のデータを配送す る前に、二つの端末はその間にSCTPアソシエーションを確立するた めに初期化処理を完了させなければならない。 ある端末のSCTPユーザは他のSCTP端末へのSCTPアソシエーションを 初期化するためにASSOCIATEプリミティブを使うべきである。 実装上の注意: SCTPユーザの視点からはアソシエーションは、 ASSOCIATEプリミティブ(10.1節B参照)を起動することなしに、宛先 端末への最初のユーザデータの送信によって初期化されることによ り暗黙のうちに確立されるかもしれない。初期化を始めるSCTPは INITとINIT ACKのための全ての必須およびオプションのパラメータ としてデフォルト値を採用するだろう。 一旦アソシエーションが確立されると、両端末においてデータ送信 のための一方向ストリームが開かれる(5.1.1節参照)。 5.1 アソシエーションの通常確立 初期化処理は以下のステップから成る(SCTP端末"A"がSCTP端末"Z"とアソシエーションを確立しようとし、"Z"が新しいアソシエーションを受け入れたと仮定する): A) "A"は最初にINITチャンクを"Z"に送る。"A"はINIT内の初期 化タグフィールドに自身の検証タグ(Tag_A)を入れる。Tag_Aは1か ら4294967295までの範囲にある乱数であるべきである(SHOULD)(タ グ値の選定については5.3.1節参照)。INITの送信後、"A"はT1-init タイマを始動させ、COOKIE-WAIT状態に入る。 B) "Z"は即座にINIT ACKチャンクで返答することだろう。INIT ACKの宛先IPアドレスはこのINIT ACKが返答するINITの送信元アド レスに設定しなければならない(MUST)。返答においては他のパラメー タを入れるのに加えて、"Z"は検証タグフィールドをTag_Aに設定し、 初期化タグフィールドに自身の検証タグ(Tag_Z)も含めなければな らない。 さらに"Z"は状態クッキーを生成しINIT ACKに付けて送らなければ ならない(MUST)。状態クッキーの生成については5.1.3節を参照の こと。 注意: INIT ACKとともに状態クッキーパラメータを送信した 後、"Z"は新しいアソシエーションに対してリソースを少しも割り 当ててはならず、いずれの状態も保存してはならない(MUST NOT)。 さもなければ"Z"はリソース攻撃に対して弱くなってしまう。 Stewart, et al. Standards Track [Page 52] RFC 2960 Stream Control Transmission Protocol October 2000 C) "Z"からのINIT ACK受信時に、"A"はT1-initタイマを止め COOKIE-WAIT状態から遷移するだろう。それから"A"はINIT ACKチャ ンクとともに受信した状態クッキーをCOOKIE ECHOチャンクに含め て送信し、T1-cookieタイマを始動させ、COOKIE-ECHOED状態に入る だろう。 注意: COOKIE ECHOチャンクは処理待ちの送信データチャン クとバンドルしてもよいが、COOKIE ECHOチャンクはこのパケット の最初のチャンクでなければならず(MUST)、COOKIE ACKが返される まで送信者はそれ以外のパケットを相手に対して送ってはならない (MUST NOT)。 D) COOKIE ECHOチャンクの受信に際し、端末"Z"はTCBを構築し ESTABLISHED状態に移行した後でCOOKIE ACKチャンクで返答するだ ろう。COOKIE ACKチャンクは処理待ちのDATAチャンク(および／ま たはSACKチャンク)とバンドルしてもよいが、COOKIE ACKチャンク はパケット内の最初のチャンクでなければならない(MUST)。 実装上の注意: 実装によっては、正当なCOOKIE ECHOチャンク の受信をもってSCTPユーザにCommunication Up通知を送ることを選 択してもよい。 E) COOKIE ACKの受信に際し、端末"A"はCOOKIE-ECHOED状態から ESTABLISHED状態に遷移し、T1-cookieタイマを停止させるだろう。 さらに上位層に対しアソシエーション確立の成功をCommunication Up通知によって知らせてもよい(10節参照)。 INITまたはINIT ACKチャンクは他のチャンクとバンドルしてはなら ない(MUST NOT)。これらはSCTPパケットで運ばれる唯一のチャンク でなければならない(MUST)。 端末はINIT ACKをINITを受けとったIPアドレスに対して送らなけれ ばならない(MUST)。 Note: T1-initタイマとT1-cookieタイマは6.3節で示される同じ ルールに従うであろう。 端末がINIT、INIT ACK、またはCOOKIE ECHOチャンクを受けとった が、INITまたはINIT ACK内に必須パラメータの抜けがあったり、無 効なパラメータ値があったり、手元のリソースが不足していること により新たなアソシエーションを確立しないことを決定した場合、 その端末はABORTチャンクで返答しなければならない(MUST)。また ABORTチャンクにエラー原因パラメータを含めることにより、例え ば必須パラメータの欠落などといった中止の理由を指定するべきで ある(SHOULD)。ABORTチャンクを含む送信SCTPパケットの共通ヘッ ダ内の検証タグフィールドは相手の初期化タグに設定されなければ ならない(MUST)。 Stewart, et al. Standards Track [Page 53] RFC 2960 Stream Control Transmission Protocol October 2000 アソシエーションに所属する最初のDATAチャンクを受けとった後、 端末はDATAの受信確認のためにSACKによりただちに応答しなければ ならない(MUST)。以降の受信確認応答については6.2節で記述され たように行うべきである。 TCBが生成される際、各端末は自身の内部的な累積TSN確認ポイント を最初に送信する初期TSNの値から1を引いた値に設定しなければな らない(MUST)。 実装上の注意: IPアドレスとSCTPポートは一般的に、SCTPの中 でTCBをみつけるための鍵として用いられる。 5.1.1 ストリームパラメータの扱い INITとINIT ACKのチャンクにおいて、チャンクの送信者は他の端末 から受け入れる最大の内向きストリームの数(MIS)だけでなく、ア ソシエーションで利用したい外向きのストリームの数(OS)も指定す るだろう。 相手からのストリーム設定情報を受けとった後、それぞれの端末は 以下のチェックを行うだろう。相手のMISが自分のOSよりも小さい 場合、これは自分が利用したい全ての外向けストリームを相手がサ ポートできるわけではないことを意味するので、当該端末はMIS数 の外向けストリームを利用するか、あるいはアソシエーションを中 止して相手端末のリソース不足を上位層に報告するかのいずれかを 行うべきである(MUST)。 アソシエーションが初期化された後、各端末の外向けストリーム識 別子の正当な範囲は0からmin(自身のOS, 相手のMIS)-1までになる だろう。 5.1.2 アドレスパラメータの取り扱い アソシエーションの初期化を行っている間、端末は以下のルールを 用いて、相手端末に接続するための宛先トランスポートアドレスを 発見し収集するだろう。 A) 受信したINITまたはINIT ACKチャンクにアドレスパラメータ がない場合、端末は届いたチャンクの送信元IPアドレスを取得して 記録し、SCTP送信元ポート番号と組み合わせて、この相手の唯一の 宛先トランスポートアドレスとする。 B) 受信したINITまたはINIT ACKチャンクにHost Nameパラメー タがある場合、端末はこのホスト名を解決してIPアドレスのリスト を取得し、これらのIPアドレスとSCTP送信元ポートを組みあわせて、 この相手のトランスポートアドレスを導出するだろう。 Stewart, et al. Standards Track [Page 54] RFC 2960 Stream Control Transmission Protocol October 2000 端末は受信したINITまたはINIT ACKチャンクに他のIPアドレスパラ メータが含まれていた場合、これらを無視しなければならない (MUST)。 INITの受信者がホスト名を解決する時点において、SCTPには潜在的 にセキュリティの考慮点が存在する。INITの受信者がそのチャンク の受信にあたってホスト名を解決しようとするが、受信者がホスト 名を解決するために用いる機構が潜在的に長い遅延を生じる場合 (例えばDNS検索)、受信者は状態クッキーを生成し手元のリソース を解放するまで、名前解決結果を待っている間にリソース攻撃にさ らされるかもしれない。 従って、名前解決が潜在的に長い遅延を生じ得る場合、INITの受信 者は相手からCOOKIE ECHOを受信するまで、名前の解決を延期しな ければならない(MUST)。この場合、INITの受信者は(宛先トランス ポートアドレスのかわりに)受信したホスト名を用いて状態クッキー を生成し、受信したINITの送信元IPアドレスに対してINIT ACKを送 るべきである(SHOULD)。 INIT ACKの受信者はこのチャンクの受信にあたって、いつも即座に 名前を解決しようとするだろう。 INITやINIT ACKの受信者はホスト名が問題なく解決されるまで、相 手に対してユーザデータを(ピギーバックにしろ単体にしろ)送って はならない(MUST NOT)。 名前解決に失敗した場合、端末は"解決できないアドレス"というエ ラー理由をつけて、即座に相手に対してABORTを送らなければなら ない(MUST)。ABORTは最後に受信した相手のパケットの送信元IP アドレスに送られるだろう。 C) 受信したINITまたはINIT ACKチャンクの中にIPv4/IPv6アド レスしかなければ、受信者は受信したチャンクとINITまたはINIT ACKが送られた送信元のIPアドレスから全てのトランスポートアド レスを導き出し、記録するだろう。トランスポートアドレスは、 SCTP送信元ポート(共通ヘッダから得られる)と、INITまたはINIT ACKチャンクで運ばれてきたIPアドレスパラメータ、およびIPデー タグラムの送信元IPアドレスを組みあわせることによって導き出さ れる。受信者は相手に対して以降のパケットを送る際には、これら のアドレスのみを宛先トランスポートアドレスとして用いるべきで ある。 実装上の注意: ある場合においては(例えば、実装が送出に 使われる送信元IPアドレスを決められないとき)、端末は相手に対 して送出することのできる全てのIPアドレスをINITまたはINIT ACK に含める必要があるかもしれない。 Stewart, et al. Standards Track [Page 55] RFC 2960 Stream Control Transmission Protocol October 2000 上記ルールを用いてINITまたはINIT ACKチャンクから全てのトラン スポートアドレスが導き出された後、端末は1つのトランスポート アドレスを初期プライマリパスとして選ぶだろう。 注意: INIT-ACKはINITの送信元アドレスに送られなければなら ない(MUST)。 INITの送信者は、どんなアドレス型が受け入れ可能かを示すために "サポートするアドレス型"パラメータをINITに含めてよい。このパ ラメータが含まれている場合、INIT(initiatee?)の受信者はINITに 応答する際、サポートするアドレス型パラメータで示されているア ドレス型の一つを用いるか、あるいは相手が示しているどのアドレ ス型も使いたくない、あるいは使えない場合には"解決できないア ドレス"エラー理由とともにアソシエーションを中止しなければな らない(MUST)。 実装上の注意: INIT ACKの受信者が、サポートしていない型で あるためにアドレスパラメータを解決できない場合、端末は初期化 処理を中止してもよい。それから、どのアドレス型が好ましいかを 示すために"サポートするアドレス型"パラメータを新しいINITに含 めて、再初期化を試みることができる。 5.1.3 状態クッキーの生成 INITチャンクへの返答としてINIT ACKを送信する際、INIT ACKの送 信者は状態クッキーを生成しINIT ACKの状態クッキーパラメータの 中に入れて送信する。この状態クッキーの中に送信者は、MAC(例え ば[RFC2104]を参照のこと)、状態クッキーの作られた時刻のタイム スタンプ、状態クッキーの有効期間とともに、アソシエーション確 立のための全ての必要な情報を含めるべきである。 状態クッキーの生成には以下の手順をとるべきである(SHOULD)。 1) 受信したINITチャンクと送出するINIT ACKチャンクの両方から の情報を用いてアソシエーションTCBを生成する。 2) TCBにおいては、現在時刻を生成時刻とし、有効期間をプロトコ ルパラメータ「Valid.Coolie.Life」として設定する。 3) このTCBから、TCBを再生成するために必要な最小限のサブセッ トを収集し、この情報サブセットと秘密鍵を用いてMACを生成する (MAC生成の例は[RFC2104]を参照のこと)。 4) この情報サブセットと結果として得られたMACを組み合わせるこ とによって状態クッキーを生成する。 Stewart, et al. Standards Track [Page 56] RFC 2960 Stream Control Transmission Protocol October 2000 状態クッキーパラメータとともにINIT ACKを送信した後、送信者は リソース攻撃を防ぐために、TCBとこの新しいアソシエーションに 関わるその他のあらゆる手元のリソースを削除するべきである (SHOULD)。 MAC生成に使われるハッシュ法はINITチャンク受信者の事情に完全 に任されている(strictly a private matter)。MACの使用はサービ ス不能攻撃(訳注: DoS攻撃)を防ぐために必須である。秘密鍵はラ ンダムであるべきであり(SHOULD)([RFC1750]はランダム性のガイド ラインについて情報を提供している)、十分に頻繁に変更されるべ きであり(SHOULD)、状態クッキーの中のタイムスタンプはMACを検 証するためにどの鍵を使うべきかを決めるのに参照されるかもしれ ない(MAY)。 5.1.4 状態クッキーの処理 (COOKIE WAIT状態にある)端末が状態クッキーパラメータを含んだ INIT ACKチャンクを受け取った際には、受けとった状態クッキーを 含んだCOOKIE ECHOチャンクを、相手に対し即座に送信しなければ ならない(MUST)。送信者はCOOKIE ECHOチャンクの後に送信待ちの DATAチャンクもパケットに付加して送ってもよい(MAY)。 また端末はCOOKIE ECHOチャンクの送信後にT1-cookieタイマを始動 させるだろう。このタイマが期限切れを迎えた場合、端末はCOOKIE ECHOチャンクを再送し、T1-cookieタイマを再始動させるだろう。 この処理はCOOKIE ACKが受信されるか、あるいは(訳注: 再送回数 が)Max.Init.Retransmitsに達し相手端末が到達不能として記録さ れる(そしてアソシエーションはCLOSED状態に入る)まで繰り返され る。 5.1.5 状態クッキーの認証 端末がアソシエーションを確立していない他の端末からCOOKIE ECHOチャンクを受けとった際、以下のような行動をとるだろう: 1) 状態クッキーに含まれて運ばれているTCBデータと秘密鍵を 用いてMACを計算する(どの秘密鍵を用いるかを決定するために状態 クッキーの中のタイムスタンプを参照してよい(MAY)ことに注意)。 2) 計算したMACと状態クッキーに含まれて運ばれてきたMACを比 較することによって、状態クッキーが確かに自身が以前生成したも のであることを認証する。もしこの計算が合わなければ、このSCTP パケットはその中に含まれるCOOKIE ECHOとDATAチャンクとともに、 メッセージを出すことなく(silently)廃棄されるべきである。 Stewart, et al. Standards Track [Page 57] RFC 2960 Stream Control Transmission Protocol October 2000 3) 状態クッキーの中の生成時刻タイムスタンプと現在時刻を比 べる。経過時間が状態クッキーの中に含まれている有効期間よりも 長い場合、COOKIE ECHOと付随するいかなるDATAチャンクも含むそ のパケットは破棄されるべきであり(SHOUD)、端末は相手の端末に 対して状態クッキーエラー原因とともにERRORチャンクを送らなけ ればならない(MUST)。 4) 状態クッキーが正当だった場合、COOKIE ECHOに含まれてい るTCBデータの情報をもとにCOOKIE ECHOチャンクの送信者に対して アソシエーションを確立し、ESTABLISHED状態に入る。 5) COOKIE ECHOの受信確認応答として相手にCOOKIE ACKチャン クを送る。COOKIE ACKは送信されるDATAチャンクまたはSACKチャン クとバンドルしてもよい(MAY)。しかしながら、COOKIE ACKはその SCTPパケットの中の最初のチャンクでなければならない(MUST)。 6) COOKIE ECHOにバンドルされたどんなDATAチャンクにもSACK でもって即座に受信確認応答する(以降のDATAチャンクへの受信確 認応答は6.2節で定義されたルールに従う)。ステップ5)で述べられ ているように、COOKIE ACKにSACKがバンドルされている場合、 COOKIE ACKはそのSCTPパケットの中で最初になければならない (MUST)。 すでにアソシエーションが存在する相手の端末からCOOKIE ECHOを 受けとった場合、5.2節の手順に従って処理されるべきである。 5.1.6 アソシエーションの通常確立例 下記の例では、"A"が"Z"に対しアソシエーションの初期化を始め、 その後ユーザメッセージを1つ送る。それから"Z"は"A"に対し2つの ユーザメッセージを送る(バンドルや分割は起きないことを仮定す る)。 Stewart, et al. Standards Track [Page 58] RFC 2960 Stream Control Transmission Protocol October 2000 Endpoint A Endpoint Z {app sets association with Z} (build TCB) INIT [I-Tag=Tag_A & other info] --------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z) /--- INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Cancel T1-init timer) <------/ Cookie_Z, & other info] (destroy temp TCB) COOKIE ECHO [Cookie_Z] ------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED state) /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ ... {app sends 2 messages;strm 0} /---- DATA / [TSN=init TSN_Z <--/ Strm=0,Seq=1 & user data 1] SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=2 & user data 2] <------/\ \ \------> Figure 4: INITiation Example "A"においてINITまたはCOOKIE ECHOチャンクの送信後にT1-initタ イマの期限が切れた場合、同一の初期化タグ(すなわちTag_A)また は状態クッキーをもった同一のINITまたはCOOKIE ECHOチャンクが Stewart, et al. Standards Track [Page 59] RFC 2960 Stream Control Transmission Protocol October 2000 再送され、タイマを再始動させるだろう。この再送は"A"が"Z"に到 達できないと判断し上位層にその障害を報告する(そしてアソシエー ションんはCLOSED状態に遷移する)までにMax.Init.Retransmits回 繰り返されるだろう。INITを再送する際には、ふさわしいタイマ値 を決めるために6.3節で定義されたルールに従わなければならない (MUST)。 5.2 重複の、または予想外のINIT、INIT ACK、COOKIE ECHO、およ びCOOKIE ACKの取り扱い アソシエーションが存在する間(ある可能なSCTP状態において)、端 末は相手からアソシエーション確立チャンク(INIT、INIT ACK、 COOKIE ECHO、およびCOOKIE ACK)のひとつを受けとるかもしれない。 受信者はこのようなチャンクを重複として扱い、本節で記述されて いるように処理するだろう。 注意: チャンクが自分のあるトランスポートアドレスに対して 自分がアソシエーションを確立している相手のトランスポートアド レスから送られていない限りは、端末はこのチャンクを受けとらな いだろう。そのため、端末はこうしたチャンク(訳注: 送信元と宛 先は正しいが、想定外のSCTP状態で受けとったアソシーエション確 立チャンク)を現在のアソシエーションの一部として処理する。 以下のシナリオが重複の、あるいは予想外のチャンクを生じ得るだろう: A) 相手端末がこちらが気づかないうちにクラッシュしており、 再始動し、アソシエーションを再確立しようとして新しいINITチャ ンクを送ってくる。 B) 両側からほぼ同時にアソシエーションを初期化しようとする。 C) チャンクが、現在のアソシエーション、またはすでに存在し ない過去のアソシエーションを確立するために使われた、すでに無 効になったパケットに含まれている。 D) チャンクが攻撃者によって生成された偽のパケットである。 E) 相手がCOOKIE ACKを受信できないので、COOKIE ECHOを再送 している。 以降の節にあるルールは、これらの場合を認識し正しく扱うために 適用されるだろう。 5.2.1 COOKIE-WAITまたはCOOKIE-ECHOED状態におけるINITの受信(項目B) これは通常初期化の衝突を示す。すなわち双方がほぼ同じ時刻に相 手とアソシエーションを確立しようとしている。 COOKIE-WAITまたはCOOKIE-ECHOED状態におけるINITの受信にあたっ ては、端末は先程INITチャンクで送信したのと同じパラメータを使っ て(初期化タグも含めて変更せずに)INIT ACKで応答しなければなら Stewart, et al. Standards Track [Page 60] RFC 2960 Stream Control Transmission Protocol October 2000 ない(MUST)。INITで送った元々のパラメータは新しく受けとった INITチャンクのものと組み合わせられる。端末はまたINIT ACKとと もに状態クッキーを生成するだろう。端末はINITで送ったパラメー タを使い状態クッキーを計算する。 その後、端末はその状態を変更してはならず(MUST NOT)、T1-init タイマは動作させたままにしておくだろうが、対応するTCBは破壊 してはならない(MUST NOT)。TCBが存在するときに状態クッキーを 取り扱う通常手順は、重複したINITを一つのアソシエーションとし て解決するだろう。 端末がCOOKIE-ECHOED状態にある場合、タイタグに自身と相手のタ グ情報を含めなければならない(MUST)(タイタグの記述については 5.2.2節を参照)。 5.2.2 CLOSED, COOKIE-ECHOED, COOKIE-WAIT, 及び SHUTDOWN-ACK-SENT以外の状態における予想外のINIT 特にことわらない限り、このアソシエーションにおける予想外の INITの受信に際して、端末は状態クッキーとともにINIT ACKを生成 するだろう。送出するINIT ACKの内容として、端末は自身の現在の 認証タグと相手の認証タグを状態クッキーの中の決められた場所に コピーしなければならない(MUST)。これらの場所をそれぞれピアの タイタグ、ローカルタイタグと呼ぶことにしよう。このINIT ACKを 含む送出SCTPパケットは予想外のINITに含まれていた初期化タグと 等しい認証タグをもたなければならない(MUST)。そしてINIT ACKは 新しい初期化タグ(ランダムに生成された値、5.3.1節参照)を指定 しなければならない(MUST)。この端末に関する他のパラメータはア ソシエーションの既存のパラメータ(例えば送出ストリーム数)から INIT ACKとクッキーにコピーされるべきである(SHOULD)。 INIT ACKの送出後、端末はそれ以上の作業は何もおこなわないだろ う、すなわち、現存のアソシエーションとその現在の状態、および 対応するTCBは変更されてはならない(MUST NOT)。 注意: タイタグが用いられるのは、TCBが存在しアソシエーション がCOOKIE-WAIT状態にない場合だけである。通常のアソシエーショ ン初期化(INIT; すなわち端末がCOOKIE-WAIT状態)については、タ イタグは0(以前のTCBが存在しないことを示す)に設定されなければ ならない(MUST)。INIT ACKと状態クッキーは5.2.1節で規定される ように使われる。 5.2.3 予想外のINIT ACK COOKIE-WAIT状態以外の状態において端末がINIT ACKを受けとった 場合、端末はそのINIT ACKチャンクを破棄すべきである。予想外の INIT ACKは通常、古いINITチャンク、あるいは重複したINITチャン クの処理を示唆する。 Stewart, et al. Standards Track [Page 61] RFC 2960 Stream Control Transmission Protocol October 2000 5.2.4 TCBが存在する際のCOOKIE ECHOの扱い 端末が存在するアソシエーションの任意の状態において(すなわち CLOSED状態ではない)COOKIE ECHOチャンクを受けとった場合、以下 のルールが適用されるだろう: 1) 5.1.5節のステップ1で記述されているようにMACを計算する。 2) 5.1.5節のステップ2で記述されているように状態クッキーを 認証する(上記CまたはDの場合にあたる)。 3) 状態クッキーの中のタイムスタンプと現在時刻を比較する。 状態クッキーがその内部で示している有効期間よりも古く、かつ状 態クッキーの中の検証タグが現在のアソシエーションの検証タグと 一致しない場合、COOKIE ECHOとDATAチャンクを含んだそのパケッ トは破棄されるべきである。端末はまた"状態クッキー"エラー原因 とともにERRORチャンクを相手端末に対して送らなければならない (MUST)(これは5.2節のCまたはDの場合である)。 状態クッキーの中の検証タグすべてが現在のアソシエーションの検 証タグと一致する場合、たとえ有効期間がすぎていても状態クッキー は正当である(これは5.2節のEの場合である)と考える。 4) 状態クッキーが正当と示されれば、TCBを展開して一時的な TCBとする。 5) Table 2を参照して、なすべき正しい処理を決定する。 Stewart, et al. Standards Track [Page 62] RFC 2960 Stream Control Transmission Protocol October 2000 +------------+------------+---------------+--------------+-------------+ | Local Tag | Peer's Tag | Local-Tie-Tag |Peer's-Tie-Tag| Action/ | | | | | | Description | +------------+------------+---------------+--------------+-------------+ | X | X | M | M | (A) | +------------+------------+---------------+--------------+-------------+ | M | X | A | A | (B) | +------------+------------+---------------+--------------+-------------+ | M | 0 | A | A | (B) | +------------+------------+---------------+--------------+-------------+ | X | M | 0 | 0 | (C) | +------------+------------+---------------+--------------+-------------+ | M | M | A | A | (D) | +======================================================================+ | Table 2: Handling of a COOKIE ECHO when a TCB exists | +======================================================================+ 凡例: X - タグが、存在するTCBと一致しない M - タグが、存在するTCBと一致する 0 - クッキーにタイタグがない (わからない). A - 全ての場合、すなわちM、X、または0. 注意: 表2に示されていない場合については全て、クッキーはメッ セージを出すことなく(silently)破棄されるべきである。 Action A) この場合、相手は再起動したかもしれない。端末がこの潜在的な「再起動」に気づいたとき、以下の例外を除いて、存在するセッションはABORTに続いて新しいCOOKIE ECHOを受けとったのと同様に扱われる： - SCTPのDATAチャンクは保持してよい(MAY)(これは実装ごとに選択)。 - 「通信喪失(COMMUNICATION LOST)」通知ではなく再起動(RESTART)通知を上位層に送るべきである(SHOULD)。 この相手に関連する全ての輻輳制御パラメータ(例: cwnd、ssthresh)は、初期値(6.2.1節参照)にリセットしなければならない(MUST)。 この後、端末はESTABLISHED状態に入るだろう。 Stewart, et al. Standards Track [Page 63] RFC 2960 Stream Control Transmission Protocol October 2000 もしこの端末がSHUTDOWN-ACK-SENT状態にあり相手が再起動したと気づいたら(Action A)、新しいアソシエーションを確立してはならず(MUST NOT)、かわりに相手に対しSHUTDOWN ACKを再送し、「シャットダウン中のクッキー受信」というエラー原因とともにERRORチャンクも送信しなければならない(訳注: MUST)。 B) この場合、両側からほぼ同時刻にアソシエーションを開始しようとしているが、相手端末がこちら側の端末からのINITに返答した後でINITを開始した。こうしてこの端末に送られた以前のタグに気づかずに新しい認証タグを採用してしまったのかもしれない(訳注: ?要確認)。この端末はESTABLISHED状態を維持またはこの状態へ移行するが、状態クッキーにある相手の認証タグを更新し、動作しているかもしれないinitまたはcookieのタイマを停止し、COOKIE ACKを送信しなければならない(MUST)。 C) この場合、こちら側の端末のクッキーが遅れて届いている。クッキーが届く前に、こちら側の端末はINITを送信し、INIT-ACKを受信し、最終的に相手の同じタグと自分自身の新しいタグを含めてCOOKIE ECHOを送信した。このクッキーは静かに(silently)破棄されるべきである。端末は状態を遷移させるべきではなく(SHOULD NOT)、動作中のタイマはそのままにするべきである。 D) こちら側と相手側のタグが両方とも一致するならば、端末は常に、まだそうなっていないならESTABLISHED状態に入るべきである。端末は動作しているかもしれないinitまたはcookieタイマを停止するべきであり、COOKIE ACKを送るべきである。 注意: 相手の認証タグとはINITまたはINIT ACKチャンクの初期化タグフィールドによって受信したタグのことである。 5.2.4.1 アソシエーション再始動の一例 以下の例では、再起動後"A"がアソシエーションを初期化するもの とする。端末"Z"はチャンクの交換まで、相手の再起動について何 も知らないとする(すなわち、ハートビートによる相手の障害検出 にはまだ至っていない)。(バンドリングや分割は起こらないものと 仮定): Stewart, et al. Standards Track [Page 64] RFC 2960 Stream Control Transmission Protocol October 2000 Endpoint A Endpoint Z <-------------- Association is established----------------------> Tag=Tag_A Tag=Tag_Z <---------------------------------------------------------------> {A crashes and restarts} {app sets up a association with Z} (build TCB) INIT [I-Tag=Tag_A' & other info] --------\ (Start T1-init timer) \ (Enter COOKIE-WAIT state) \---> (find a existing TCB compose temp TCB and Cookie_Z with Tie-Tags to previous association) /--- INIT ACK [Veri Tag=Tag_A', / I-Tag=Tag_Z', (Cancel T1-init timer) <------/ Cookie_Z[TieTags= Tag_A,Tag_Z & other info] (destroy temp TCB,leave original in place) COOKIE ECHO [Veri=Tag_Z', Cookie_Z Tie=Tag_A, Tag_Z]----------\ (Start T1-init timer) \ (Enter COOKIE-ECHOED state) \---> (Find existing association, Tie-Tags match old tags, Tags do not match i.e. case X X M M above, Announce Restart to ULP and reset association). /---- COOKIE-ACK / (Cancel T1-init timer, <-----/ Enter ESTABLISHED state) {app sends 1st user data; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]--\ (Start T3-rtx timer) \ \-> /----- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ Figure 5: A Restart Example Stewart, et al. Standards Track [Page 65] RFC 2960 Stream Control Transmission Protocol October 2000 5.2.5 重複したCOOKIE-ACKの取り扱い COOKIE-ECHOED以外の状態においては、端末は受信したCOOKIE ACK チャンクをメッセージを送出することなく(silently)破棄すべきで ある。 5.2.6 期限切れクッキーエラーの扱い "期限切れクッキー"エラー原因を含んだERRORチャンクを受けとる ということは、多くの可能性のあるイベントのうち一つを示唆する。 A) 送信者が発行した状態クッキーが処理される前に、アソシエー ションを完全に確立できなかった。(?) B) アソシエーション確立が完了したあとで、古い状態クッキー が処理された。 C) 受信者がアソシエーションを持つつもりがない相手から古い 状態クッキーを受けとり、ABORTチャンクが失われた。(?) "期限切れクッキー"エラー原因を含むERRORチャンクを処理する際、 端末はまずアソシエーションが確立処理中でないか、すなわちアソ シエーションがCOOKIE-ECHOED状態でないかを調べるべきである。 アソシエーションがCOOKIE=ECHOED状態でない全ての場合において、 このERRORチャンクはメッセージを出すことなく(silently)破棄さ れるべきである。 アソシエーションがCOOKIE-ECHOED状態の場合、端末は以下の3つの 選択肢からひとつを選んでよい。 1) 新しいINITチャンクを相手に送って新しい状態クッキーを生 成させ、確立手順を再度試みる。 2) TCBを破棄し、アソシエーションの確立が不可能であったこ とを上位層に報告する。 3) 相手に新しいINITチャンクを送り、状態クッキーの有効期間 の延長を要求するクッキーPrevservativeパラメータを付加する。 期間の延長を計算する際、実装は前回のCOOKIE ECHOとERRORの交換 を基にして計測されたRTTの情報を用いるべきであり(SHOULD)、状 態クッキーの有効期間が長いとリプレイ攻撃に狙われやすいので、 計測されたRTTより1秒を超える長さにはならないようにするべきで ある。 Stewart, et al. Standards Track [Page 66] RFC 2960 Stream Control Transmission Protocol October 2000 5.3 その他の初期化に関する課題 5.3.1 タグ値の選択 初期化タグの値は1から2**32-1の範囲から選択するべきである。 "man in the middle"攻撃および"シーケンス番号"攻撃を防ぐため に、初期化タグの値が乱数となっていることは非常に重要である。 初期化タグの乱数化のために、[RFC1750]で記述されている方法を 使うことができる。古いアソシエーションからの古い重複パケット が、現在のアソシエーションに属するものとして誤って処理されな いためにも、初期化タグの慎重な選択が必要である。 さらに、あるアソシエーションを確立している端末で用いられてい る検証タグ値は、そのアソシエーションが存在している間は変更し てはならない(MUST NOT)。端末がアソシエーションを終了し、再び 同じ相手に対してアソシエーションを再確立したいときには、新し い検証タグ値を用いなければならない(MUST)。 6. ユーザデータの転送 データの転送はESTABLISHED、SHUTDOWN-PENDING、 SHUTDOWN-RECEIVED状態においてしか行ってはならない(MUST)。唯 一の例外は、COOKIE-WAIT状態において送出するCOOKIE-ECHOにDATA チャンクをバンドルすることが許されていることである。 DATAチャンクはESTABLESHED、SHUTODOWN-PENDING、SHUTDOWN-SENT の状態において、下記のルールに沿って受信されなければならない (MUST)。CLOSED状態で受信したDATAチャンクは青天の霹靂(out of the blue)であり、8.4節によって取り扱われるべきである(SHOULD)。 他の状態において受けとったDATAチャンクは破棄されるべきである (SHOULD)。 SACKはESTABLISHED、SHUTDOWN-PENDING、およびSHUTDOWN-RECEIVED において処理されなければならない(MUST)。送られて来るSACKに関 してはCOOKIE-ECHOED状態において処理してもよい。CLOSED状態に おけるSACKは青天の霹靂(out of the blue)であり、8.4節のルール に沿って処理されるべきである(SHOULD)。その他の状態において受 けとったSACKチャンクは破棄されるべきである(SHOULD)。 SCTP受信者は1つのSCTPパケットのために最小でも1500バイトは受 信可能でなければならない(MUST)。これはSCTP端末がINITやINIT ACKにおいて1500バイト未満の初期a_rwndを指定してはならない (MUST NOT)ことを意味する。 転送の効率化のために、SCTPは小さなユーザメッセージのバンドル 機構や大きなユーザメッセージの分割機構を定義している。下図は SCTP層を通りぬけるユーザメッセージの流れを図示している。 Stewart, et al. Standards Track [Page 67] RFC 2960 Stream Control Transmission Protocol October 2000 本節においては「データ送信者」はDATAチャンクの送信する端末を 指し、「データ受信者」はDATAチャンクを受信する端末を指す。デー タ受信者はSACKチャンクを送信することになる。 +--------------------------+ | User Messages | +--------------------------+ SCTP user ^ | ==================|==|======================================= | v (1) +------------------+ +--------------------+ | SCTP DATA Chunks | |SCTP Control Chunks | +------------------+ +--------------------+ ^ | ^ | | v (2) | v (2) +--------------------------+ | SCTP packets | +--------------------------+ SCTP ^ | ===========================|==|=========================== | v Connectionless Packet Transfer Service (e.g., IP) 注意: 1) ユーザメッセージをDATAチャンクに変換する際、端末は 現在のアソシエーションのパスMTUより大きなユーザメッセージを 複数のDATAチャンクに分割するだろう。データの受信者は通常、ユー ザにデータを渡す前にDATAチャンクから分割されたメッセージを再 構成するだろう(詳細は6.9節を参照のこと)。 2) 最終的なパケットのサイズが現在のパスMTUを越えない限 り、複数のDATAや制御チャンクは送信者が送信する際にバンドルさ れるかもしれない。受信者はこのパケットのバンドルを解いて元々 のチャンクを取りだすだろう。制御チャンクはパケット内でDATAチャ ンクより前に来なければならない(MUST)。 Figure 6: Illustration of User Data Transfer 分割とバンドルの機構は6.9節と6.10節で詳細が述べられているが、 データ送信者にとって実装はオプション扱い(OPTIONAL)である。し かしこれらの機構はデータ受信者においては実装されなければなら ない(MUST)。すなわち、端末はバンドルされたデータや分割された データを正しく受信し処理しなければならない(MUST)。 Stewart, et al. Standards Track [Page 68] RFC 2960 Stream Control Transmission Protocol October 2000 6.1 DATAチャンクの送信 この文書は宛先トランスポートアドレスあたり1つの再送タイマが あるかのように書かれているが、実装はDATAチャンクごとに再送タ イマを持つかもしれない。 以下の一般的なルールは、送信者において送出するDATAチャンクの 送信および／または再送の際に適用されなければならない(MUST): A) いかなるタイミングにおいても、相手のrwndがバッファスペー スがないことを示しているなら(すなわちrwndが0、6.2.1節を参照)、 その相手のどの宛先トランスポートアドレスに対しても新しいデー タを送ってはならない(MUST NOT)。しかしながら、rwndの値にかか わらず(0の場合も含む)、データ送信者は輻輳ウインドウで許され ている限り、常に受信者に対して1つの未確認応答のDATAチャンク を存在させることができる。このルールはデータ送信者が、SACKが データ受信者からデータ送信者への転送途中に失われたために見落 したrwndの変更を検出できるようにする。 B) いかなるタイミングにおいても送信者は、与えられたトラン スポートアドレスに対してcwndバイトまたはそれ以上のデータが処 未確認応答となっているならば、そのトランスポートアドレスに新しいデー タを送ってはならない(MUST NOT)。 C) 送信者がデータ送信する時間が来た時点では、新しいDATAチャ ンクを送る前に、送信者は最初に再送対象としてマークされている 未確認応答のDATAチャンク(現在のcwndで制限をうける)を送らなけ ればならない(MUST)。 D) その後、送信者は上記ルールAおよびルールBの許す限りの新 しいDATAチャンクを送出することができる。 送信対象となった複数のDATAチャンクは単一のパケットにバンドル されるかもしれないl(MAY)。さらに、結果としてパケットサイズが パスMTUを越えない限り、再送対象のDATAチャンクも新しいDATAチャ ンクとバンドルされるかもしれない(MAY)。上位層はバンドルしな いように要求するかもしれないが、この要求はSCTP実装がバンドル 効率を増加させるために必要とする遅延のみをなくすようにすべき である。これは全てのバンドルを使わないということではない(す なわち輻輳や再送の場合(は使うかもしれない))。 端末がDATAチャンクを送出する前に、もし受信したDATAチャンクに まだ確認応答を返していなければ(例えば、遅延確認応答のために)、 送信者は最終的なSCTPパケットサイズが現在のMTUを越えない限り、 SACKを生成し送出するDATAチャンクとバンドルするべきである。 6.2節を参照のこと。 Stewart, et al. Standards Track [Page 69] RFC 2960 Stream Control Transmission Protocol October 2000 実装上の注意: ウインドウに空きがないとき(すなわち送信がルー ルAおよび／あるいはルールBによって禁じられている)、送信者は 上位層からの送信要求をさらに受け付けてもよい(MAY)が、いくつ かのあるいは全ての未確認応答のDATAチャンクが確認応答され、ルー ルAとルールBによって再び送信が許可されるまで、DATAチャンクを さらに送ってはならない(MUST)。 任意のアドレスに対して送信や再送が行われるときはいつも、もし そのアドレスについてのT3-rtxタイマが動作していなければ、送信 者はタイマを始動させなければならない(MUST)。もしこのアドレス についてのタイマがすでに動作して、このアドレスに送られようと している最も古い(すなわちTSNの最も低い)未確認応答DATAチャン クが再送されようとしているときに、送信者はタイマを再始動させ なければならない(MUST)。さもなければ、データ送信者はタイマを 再始動させてはならない(MUST NOT)。 T3-rtxタイマを始動や再始動させる際、タイマの値は6.3.2および 6.3.3節で定義されているタイマのルールに従って調節されなけれ ばならない。 注意: データ送信者は現在の送信ウインドウの開始TSNより 2**31-1を越えるTSNを使うべきではない(SHOULD NOT)。 6.2 DATAチャンク受信の確認応答 SCTP端末は常に、それぞれの正当なDATAチャンクの受信について確 認応答しなければならない(MUST)。 [RFC2581]の4.2節で述べられている遅延確認応答アルゴリズムのガ イドラインに従うべきである(SHOULD)。具体的には、少なくとも2 つのパケット(2つのDATAチャンクごとではなく)を受信するごとに 受信確認応答を生成するべきであり(SHOULD)、まだ確認応答をして いないDATAチャンクの到着から200ms以内に生成されるべきである (SHOULD)。ある状況においては、この文書で詳細に述べられている アルゴリズムが許しているよりも保守的になることがSCTP送信者に とって有益なこともあるかもしれない。しかしながら、SCTP送信者 は以下のアルゴリズムが許すよりも急激(aggressive)になってはな らない(MUST NOT)。 SCTP受信者は、受信アプリケーションが新しいデータをとりこんだ ことにより利用可能なウインドウを更新する場合を除いて、受けい れたパケット1つごとに2つ以上のSACKを生成してはならない(MUST NOT)。 実装上の注意: 確認応答を生成するまでの最大遅延は、運ばれ るプロトコルに特有の時間的な要求に合わせるために、SCTP管理者 によって静的にあるいは動的に設定されるかもしれない。 実装は500msを越えた最大遅延を設定できるようにしてはならない (MUST NOT)。いいかえると、実装はこの値を500ms未満にしてもよ いが(MAY)決して500msより大きくしてはならない(MUST NOT)。 Stewart, et al. Standards Track [Page 70] RFC 2960 Stream Control Transmission Protocol October 2000 上位層がシャットダウンを要求する場合は端末はSHUTDOWNチャンク によって受信確認を送信するが、そうでなければ受信確認はSACKチャ ンクによって送信しなければならない(MUST)。1つのSACKチャンク は複数のDATAチャンクの受信を確認できる。SACKチャンクのフォー マットについては3.3.4節を参照のこと。特に、SCTP端末は(正当な DATAチャンクの)順序通り受信した最新のTSNを示すために累積TSN ACKフィールドに値を含めなければならない(MUST)。累積TSN Ackフィー ルドの値よりも大きなTSNをもったDATAチャンクを受信した場合は、 これもギャップAckブロックフィールドによって報告するべきであ る(SHOULD)。 注意: SHUTDOWNチャンクはGap Ackブロックフィールドを持たな い。従って端末が順序通りでないDATAチャンクに確認応答するため には、SHUTDOWNチャンクのかわりにSACKを使うべきである。 新しいDATAチャンクを含まない重複DATAチャンクのみのパケットが 来た場合、端末は遅延なく即座にSACKを送らなければならない (MUST)。重複DATAチャンクが新しいDATAチャンクとバンドルされて 来た場合、端末は即座にSACKを送ってもよい(MAY)。通常、元々の SACKチャンクが失われ相手のRTOが期限切れとなったとき、重複 DATAチャンクを受けとるだろう。重複したTSN番号はSACKチャンク の中の重複フィールドによって報告されるべきである(SHOULD)。 端末がSACKを受けとった際、SACKロスが起きたかどうかを調べるた めに重複TSNの情報を使ってもよい(MAY)。このデータのさらなる利 用は将来の研究課題である。 データ受信者には自身の受信バッファを管理する役割がある。デー タ受信者は自身のデータ受信可能量を、変更するごとにすぐにデー タ送信者に知らせるべきである(SHOULD)。実装がその受信バッファ をどう管理するかは多くの要素(オペレーティングシステム、メモ リ管理システム、メモリ量、等々)に依存する。しかしながら、 6.2.1節で定義されているデータ送信者の戦略は受信者の処理が以 下のようになっているという仮定をもとにしている: A) アソシエーションの初期化時に、端末はINITまたはINIT ACKに置いてそのアソシエーションに割りつけられる受信バッファ 量を相手に通知する。この端末はa_rwndをこの値に設定する。 B) DATAチャンクが受信されバッファされるにつれ、受信さ れバッファされたバイト数だけa_rwndを減らす。これは実効上、デー タ送信者のrwndを閉じ、送信できるデータ量を制限することになる。 C) DATAチャンクがULP(上位層)に送られ受信バッファが解放 されるにつれて、上位層に送られたバイト数だけa_rwndを増加させ る。これは実際上、データ送信者のrwndをひらき、より多くのデー タの送出を許可することになる。受信者は受信バッファからデータ を解放しない限り、a_rwndを増やすべきではない(SHOULD NOT)。例 えば、受信者の再構築キューに分割されたDATAチャンクが残ってい る場合、a_rwndを増加させるべきではない。 Stewart, et al. Standards Track [Page 71] RFC 2960 Stream Control Transmission Protocol October 2000 D) SACK送信の際、データ受信者はa_rwndフィールドに現在 のa_rwnd値を入れるべきである(SHOULD)。データ受信者は、データ 送信者が累積TSN確認応答によって確認されたDATAチャンクを再送 しない(すなわち、再送キューから外される)ことを考慮にいれるべ きである(SHOULD)。 ある状況下では、データ受信者は受信されたがまだ受信バッファか ら解放されていない(すなわち上位層(ULP)に渡されていない)DATA チャンクを落とす必要があるかもしれない。これらのDATAチャンク はGap Ack Blocksにおいてすでに確認応答されているかもしれない。 例えば、データ受信者が受信バッファにデータを持っていて、相手 からの分割されたユーザメッセージを再構成しているときに受信バッ ファスペースを使い切ってしまうかもしれない。この受信者は、た とえこれらのDATAチャンクがGap Ack Blocksにおいて確認応答され ていたとしても、これらを落とすかもしれない。データ受信者が DATAチャンクを落とした場合、再送によって再度それらを受けとる まで、これらのDATAチャンクを後続のSACKのGap Ack Blocksに含め てはならない(MUST NOT)。また、端末はa_rwndを計算する際に、こ の落としたデータを考慮に入れるべきである。 端末は、SACKを取り消してデータを破棄するようなことはするべき ではない(SHOULD NOT)。端末は特別な状況においてのみ、この処理 をするべきである(例えばバッファ容量がなくなったときなど)。デー タ受信者は、Gap Ack Blocksで受信確認応答をすませたデータを破 棄することで、データ送信者が最善とはいえない再送処理を行い、 結果として性能が最善とはいえなくなることを考慮に入れるべきで ある。 以下の例は遅延確認応答の使い方を示す: Stewart, et al. Standards Track [Page 72] RFC 2960 Stream Control Transmission Protocol October 2000 Endpoint A Endpoint Z {App sends 3 messages; strm 0} DATA [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) (Start T3-rtx timer) DATA [TSN=8,Strm=0,Seq=4] ------------> (send ack) /------- SACK [TSN Ack=8,block=0] (cancel T3-rtx timer) <-----/ DATA [TSN=9,Strm=0,Seq=5] ------------> (ack delayed) (Start T3-rtx timer) ... {App sends 1 message; strm 1} (bundle SACK with DATA) /----- SACK [TSN Ack=9,block=0] \ / DATA [TSN=6,Strm=1,Seq=2] (cancel T3-rtx timer) <------/ (Start T3-rtx timer) (ack delayed) (send ack) SACK [TSN Ack=6,block=0] -------------> (cancel T3-rtx timer) Figure 7: Delayed Acknowledgment Example 端末がユーザデータを含まないDATAチャンクを受けとったならば (すなわち、長さフィールドが16)、エラー原因を"No User Data"と してABORTを送らなければならない(MUST)。 端末はユーザデータを含まないDATAチャンクを送るべきではない (SHOULD NOT)。 6.2.1 受信したSACKの処理 端末が受信するSACKにはどれもa_rwnd値が含まれている。この値はこのSACKを送信する時点で、データ受信者において(INIT/INIT ACKチャンクで指定されている)合計の受信バッファスペースのうち残っているバッファスペースの量を示す。a_rwnd、累積TSN確認応答、およびGap Ack Blocksを用いることで、データ送信者は相手の受信バッファスペースの様子をより詳しく知ることができる。 SACKを処理するときにデータ送信者が考慮にいれておかなければならない問題の一つはSACKが順序通りには届かないかもしれないことである。すなわち、データ受信者によって送られたあるSACKが先行するSACKを追いこし、データ送信者に最初に受信されるかもしれない。SACKが順序通りに受信されなかったならば、データ送信者は相手の受信バッファスペースを見積もりそこねてしまうかもしれない。 Stewart, et al. Standards Track [Page 73] RFC 2960 Stream Control Transmission Protocol October 2000 順序通りでないSACKを検出するために使えるような明示可能な識別子はないので、データ送信者はヒューリスティックス(発見的手法)を用いてSACKが新しいものかどうか決定しなければならない。 端末は受信したSACKに含まれるa_rwnd値、累積TSN確認応答、およびGap Ack Blocksを用いてrwndを計算するために、以下のルールを用いるべきである(SHOULD)。 A) アソシエーションの確立時、端末はrwndを相手がINITまたはINIT ACKで指定した広告受信ウインドウクレジット(a_rwnd)に設定する。 B) 相手に対しDATAチャンクを送信した(または再送した)とき、端末はその相手のrwndからチャンクのデータサイズを減じる。 C) DATAチャンクが再送対象としてマークされた(T3-rtxタイマの期限切れ(6.3.3節)あるいは高速再送(7.2.4節)により)とき、チャンクのデータサイズをrwndに加える。 注意: もし実装がDATAチャンクごとにタイマを管理しているならば、タイマの有効期限の切れたDATAチャンクのみ再送対象としてマークされる。 D) SACKが到着したとき、端末は以下を実行する: i) 累積TSN確認応答が累積TSN確認応答ポイントよりも小さい場合、このSACKを破棄する。累積TSN確認応答は単調に増加するため、累積TSN確認応答が累積TSN確認応答ポイントよりも小さいSACKは、順序通りでないSACKであることを示す。 ii) rwndを、新しく受信したa_rwndから、累積TSN確認応答とGap Ack Blocksを処理した後も送信処理中であるバイト数を減じた値に設定する。 iii) 以前Gap Ack Blockにより確認応答されていたTSNがSACKに含まれていなかった(データ受信者がそのデータを破棄した)なら、該当のDATAチャンクを再送可能な対象としてマークする: このチャンクを7.2.4節で記述されているように喪失したとみなし高速再送の対象とし、このDATAチャンクが最初に送信された宛先アドレスに対し再送タイマが動作していなければ、この宛先アドレスに対しT3-rtxを始動する。 Stewart, et al. Standards Track [Page 74] RFC 2960 Stream Control Transmission Protocol October 2000 6.3 再送タイマの管理 相手からのフィードバックがない場合にデータ配送を保証するために、SCTP端末は再送タイマT3-rtxを用いる。このタイマの有効期間をRTO(再送タイムアウト)と呼ぶことにする。 ある端末の相手がマルチホームである場合、この端末は相手端末のそれぞれ異なる宛先トランスポートアドレスに対し別々のRTOを計算するだろう。 SCTPにおいてRTOの計算および管理は、TCPの再送タイマ管理法にほぼ従う。現在のRTOを計算するために、端末は宛先トランスポートアドレスごとに2つの状態変数、SRTT(平滑化往復時間)とRTTVAR(往復時間のばらつき)を管理する。 6.3.1 RTOの計算 SRTT、RTTVARおよびRTOの計算を支配するルールは以下の通りである: C1) 与えられた宛先トランスポートアドレスに送られたパケットによりRTT計測が済むまでは、RTOをプロトコルパラメータ'RTO.Initial'とする。 C2) 最初のRTT計測Rが済めば、SRTT<-R、RTTVAR<=R/2、そしてRTO<-SRTT+4*RTTVARとする。 C3) 新しくRTT計測R'が得られれば、以下のように設定する。 RTTVAR <- (1 - RTO.Beta) * RTTVAR + RTO.Beta * |SRTT - R'| SRTT <- (1 - RTO.Alpha) * SRTT + RTO.Alpha * R' 注意: RTTVARの更新に使われる値SRTTは、2つめの式により自身が更新される前のSRTTである。 計算の後、RTO <- SRTT + 4 * RTTVAR と更新する. C4) データが送信途中(in flight)で下のルールC5で許されているならば、各往復ごとに新しくRTT計測を行わなければならない(MUST)。さらに新しい計測は与えられた宛先トランスポートアドレスに対し往復時間に一回以下の頻度で行うべきである(SHOULD)。この推奨には2つの理由がある: 1. 高頻度の計測は実際上、重要な利益をもたらすわけではなさそうである [ALLMAN99]。 2. より高頻度で計測を行うなら、上のルールC3で用いるRTO.AlphaおよびRTO.Betaという値は、往復時間あたり一回の計測でルールC3で与えられているようにRTO.AlphaとRTO.Betaを用いるのとだいたい同じ速度(rate)(新しい値を反映するまでに何往復要するかという尺度)でSRTTとRTTVARが変動に追随するように調整されるべきである。しかしながら、これらの調整の正確な性質は研究課題として残っている。 Stewart, et al. Standards Track [Page 75] RFC 2960 Stream Control Transmission Protocol October 2000 C5) カーン(Karn)のアルゴリズム: RTTの計測に再送されたパケット(返答が最初のパケットに対するものか再送されたものに対するものかあいまいになる)を用いてはならない(MUST NOT)。 C6) RTOを計算し、それがRTO.Min秒よりも小さければ、RTO.Min秒に丸める。このルールを用いる理由は、RTOの最小値が小さいと不必要なタイムアウトに敏感になってしまうからである [ALLMAN99]。 C7) RTO.Max秒以上ならば、RTOには最大値(訳注: RTO.Max)が設定される。 RTT計測に用いる時計の細粒度G、および他の状態変数には、以下以外に条件はない: G1) RTTVARが計算され、RTTVARが0ならばRTTVAR<-Gと調節する。 ある経験によると[ALLMAN99]、より細密な精度(<= 100 msec)の時計を用いた計測はより粗い精度の時計に比べるといくぶんよい結果をもたらす。 6.3.2 再送タイマのルール 再送タイマを管理するルールは以下の通りである: R1) 任意のアドレスにDATAチャンクが送られるときはいつでも (再送を含む)、そのアドレスのT3-rtxタイマが動作していなければ、 そのアドレスに対してRTO後に切れるようにタイマを始動させる。 ここで使われるRTOは下記のルールE2で議論されるように、該当の 宛先アドレスで期限切れとなったことによるT3-rtxタイマの有効期 間を2倍する作業を経て得られたものである。 R2) あるアドレスへ送られたデータがすべて確認応答されたと きにはいつでも、そのアドレスへのT3-rtxタイマを止める。 R3) そのアドレスへ送信中のDATAチャンクのうち最も若いTSNを 持つものへの確認応答であるSACKを受けとったときはいつでも、現 在のRTO値でもってそのアドレスへのT3-rtxタイマを再始動させる (そのアドレスへの送信中データがまだある場合)。 Stewart, et al. Standards Track [Page 76] RFC 2960 Stream Control Transmission Protocol October 2000 R4) Gap Ackブロックによって以前確認応答されたはずのTSNが 失われたSACKを受けとったときはいつでも、そのDATAチャンクが元々 送られた宛先アドレスに対して、T3-rtxタイマがまだ動作していな いならば動作させる。 以下の例はさまざまなタイマのルールを示す(受信者が遅延確認応答を使うと仮定)。 Endpoint A Endpoint Z {App begins to send} Data [TSN=7,Strm=0,Seq=3] ------------> (ack delayed) (Start T3-rtx timer) {App sends 1 message; strm 1} (bundle ack with data) DATA [TSN=8,Strm=0,Seq=4] ----\ /-- SACK [TSN Ack=7,Block=0] \ / DATA [TSN=6,Strm=1,Seq=2] \ / (Start T3-rtx timer) \ / \ (Re-start T3-rtx timer) <------/ \--> (ack delayed) (ack delayed) {send ack} SACK [TSN Ack=6,Block=0] --------------> (Cancel T3-rtx timer) .. (send ack) (Cancel T3-rtx timer) <-------------- SACK [TSN Ack=8,Block=0] Figure 8 - タイマのルールの例 6.3.3 T3-rtxタイマ切れの取り扱い あるアドレスに対しての再送タイマT3-rtxが切れたときはいつでも、 以下を行う: E1) タイマが切れた宛先アドレスに対して、そのssthreshを 7.2.3節で定義されたルールで調節し、cwndをMTUとする。 E2) タイマが切れた宛先アドレスに対して、RTOを2倍する(タイ マをバックオフする)。上述のルールC7で議論された最大値 (RTO.max)はこの2倍する処理の上限値を決めるために使われる。 E3) T3-rtxが切れたアドレスに対して未解決のDATAチャンクが 古い方から(すなわち最も低いTSNから)いくつ単一のパケットに納 まるかを、再送がなされる宛先トランスポートアドレス(これはタ イマの切れたアドレスとは異なるかもしれない)に対応するパスの MTUの制限に沿うように決める。この納まるDATAチャンクの個数をK と呼ぶ。宛先端末に対し、一つのパケットにこのK個のDATAチャン クをバンドルし再送する。 Stewart, et al. Standards Track [Page 77] RFC 2960 Stream Control Transmission Protocol October 2000 E4) 上述のルールR1がそうするように示唆している場合、再送 が行われる宛先アドレスに対して再送タイマT3-rtxを始動させる。 このT3-rtxタイマの開始に用いられるRTOは再送の行われるアドレ スについてのRTOであるべきで、このアドレスは受信者がマルチホー ム環境の場合、タイマが切れた宛先アドレスとは異なるかもしれな い(以下の6.4節を参照のこと)。 再送後、一旦新しいRTT測定値が得られれば(これはルールC5によっ て新しいデータが送られて確認応答を受けるか、あるいは HEARTBEATによって測定される(8.3節参照)場合のみである)、ルー ルC3の計算が行われ、これはRTOの計算を含んでいるので、2倍操作 の対象となった後(ルールE2)のRTOは縮んでしまう("collapsing") だろう。 注意: T3-rtxタイマの切れたアドレスに送られたがMTUに納まら ない(上記ルールE3)DATAチャンクは、再送用としてマークされcwnd が許すようになったらすぐに送られるべきである(通常はSACKの到 着時に)。 再送タイマを管理する最後のルールはフェイルオーバーに関するも のである(6.4.1節参照): F1) 端末が現在の宛先トランスポートアドレスから別のアドレ スに切り替えるときはいつでも、現在の再送タイマは動作させたま まとする。端末が新しいトランスポートアドレスにDATAチャンクを 含んだパケットを送るとすぐ、ルールR1がそうするように示唆して いる場合、データを送った宛先アドレスのRTO値を用いてそのトラ ンスポートアドレスに対してタイマを始動する。 6.4 マルチホーム環境のSCTP端末 その端末に届けるための宛先アドレスとして使うことのできるトラ ンスポートアドレスが2つ以上ある場合、そのSCTP端末はマルチホー ム環境と考えられる。 さらに、端末の上位層はマルチホーム環境にある相手端末の複数の 宛先アドレスの中から一つをプライマリパスとして選ぶだろう(詳 細は5.1.2および10.1節を参照)。 デフォルトでは、SCTPユーザが使いたい宛先トランスポートアドレ スを(そしておそらくは送信元トランスポートアドレスも)明示指定 しない限り、端末は通常プライマリパスに送信するべきである (SHOULD)。 Stewart, et al. Standards Track [Page 78] RFC 2960 Stream Control Transmission Protocol October 2000 端末は返答チャンク(例えば、SACK、HEARTBEAT ACKなど)を、返答 しようとしている受信したDATAや制御チャンクが送られてきたトラ ンスポートアドレスと同じアドレスを宛先として送信すべきである (SHOULD)。このルールは、端末が返答チャンクとDATAチャンクをバ ンドルする場合にも適用されるべきである。 しかしながら、異なる送信元アドレスからのパケットとして受信し た複数のDATAチャンクに単一のSACKで確認応答する場合、このSACK チャンクは確認応答されるDATAや制御チャンクを受けとった宛先ト ランスポートアドレスのうちの一つに送られてよい。 重複したDATAチャンクの受信者がマルチホーム環境の端末に対して SACKを送る場合、宛先アドレスを変更しDATAチャンクの送信元アド レスを使わないほうがいいかもしれない(MAY)。その理由は、マル チホーム環境の端末からの重複受信は(DATAチャンクの送信元アド レスとして指定されている)SACKの返答パスが壊れていることを示 すかもしれないからである。 さらに、相手がマルチホーム環境の場合、端末はDATAチャンクが送 られた最後のアドレスとは異なるアクティブな宛先トランスポート アドレスへ再送を試みるべきである(SHOULD)。 再送は合計の送信中データの数えあげには影響を与えない。しかし ながら、DATAチャンクが別の宛先アドレスへ再送される場合、新し い宛先アドレスとデータチャンクが最後に送られた古い宛先アドレ スにおける送信中データの合計はともに、状況に合うように調整さ れるだろう。 6.4.1 インアクティブな宛先アドレスからのフェイルオーバ マルチホーム環境にあるSCTP端末のトランスポートアドレスのいく つかは、あるエラー条件の発生(8.2節参照)、あるいはSCTPユーザ からの調節によってインアクティブになるかもしれない。 送出したいデータがあるのにプライマリパスがインアクティブになっ た場合(例えば障害によって)、あるいはSCTPユーザがインアクティ ブな宛先トランスポートアドレスへのデータ送信を明示して要求し てきた場合、SCTPユーザは上位層にエラーを報告する前に、もし存 在するならば代わりのアクティブな宛先トランスポートアドレスへ のデータ送信を試みるべきである。 端末がマルチホーム環境にある場合、データの再送にあたって、そ れぞれの送信元・宛先アドレスの組み合せが再送選択ポリシーに合 致するかを考えるべきである。再送の際に端末は、元々パケットが 送られた送信元・宛先の組み合わせに対して、もっとも経路の共有 部分の少ない(divergent)送信元・宛先の組み合わせを選ぼうとす るべきである。 Stewart, et al. Standards Track [Page 79] RFC 2960 Stream Control Transmission Protocol October 2000 注意: 最も経路の共有部分の少ない送信元・宛先の組み合わせ を選ぶルールは実装の問題であり、本文書では規定しない。 6.5 ストリーム識別子とストリームシーケンス番号 全てのDATAチャンクは正当なストリーム番号を含まなければならな い(MUST)。端末が不正なストリーム識別子を持ったDATAチャンクを 受けとった場合、通常の手順に沿ってDATAチャンクの受信の確認応 答をするだろうが、原因を"不正なストリーム番号"としたERRORチャ ンクを即座に送り、そのDATAチャンクを破棄するだろう。端末は、 ERRORチャンクをSACKの後ろに続ける限りは、ERRORチャンクをSACK チャンクと同じパケットにバンドルしてもよい。 全てのストリームのストリームシーケンス番号はアソシエーション 確立時に0から開始されるだろう。またストリームシーケンス番号 が65535という値に至ったときも、次のストリームシーケンス番号 は0に設定されるだろう。 6.6 順序配送および非順序配送 あるストリームにおいて、端末は受信したDATAチャンクのUフラグ が0となっているならば、それらをストリームシーケンス番号の順 序にのっとって上位層に渡さなければならない(MUST)。DATAチャン クがストリームシーケンス番号とは異なった順で届いた場合、端末 は受信したDATAチャンクを正しく並びかえられるまで上位層にわた してはならない(MUST)。 しかしながら、SCTP端末はDATAチャンクのUフラグを1にすることに よって、ストリーム内の特定のDATAチャンクに順序制御の必要がな いことを示すことができる。 端末がUフラグが1となっているDATAチャンクを受けとった場合、順 序制御機構をバイパスし、即座にデータを上位層に送らなければな らない(ユーザデータが送信者によって分割されていた場合は再構 成してから)。 この仕組はあるストリームにおいて"帯域外(out-of-band)"データ を送信する効率的な方法を提供する。またあるストリームで送られ る全てのDATAチャンクにおいてUフラグを1にするだけで、このスト リームは"順序制御なし"のストリームとして使える。 実装上の注意: 順序制御なしのDATAチャンクを送る際、実装は 可能ならば送出キューの先頭にあるパケットにそのDATAチャンクを 含ませることにしてもよい。 Stewart, et al. Standards Track [Page 80] RFC 2960 Stream Control Transmission Protocol October 2000 Uフラグが1に設定されているDATAチャンクの中のストリームシーケ ンス番号フィールドには意味がない。送信者は任意の値で埋めてよ いが、受信者はこのフィールドを無視しなければならない(MUST)。 注意: 順序データと非順序データを送信する際、端末はUフラグ が1に設定されているDATAチャンクを送るときにストリームシーケ ンス番号をインクリメントしない。 6.7 受信したDATA TSNにおけるギャップの報告 新しいDATAチャンクの受信の際、端末は受信したTSNの連続性を調 べるだろう。端末が受信DATAチャンク列にギャップをみつけたなら ば、即座にGap Ack BlocksとともにSACKを送るべきである(SHOULD)。 データ受信者はこのGapが埋まらない限り、各SCTPパケットの受信 ごとにSACKを送りつづける。 受信したSACKのGap Ack Blockに基づいて、端末は失われたデータ チャンクを計算することができ、それらを再送するかどうかについ て判断することができる(詳しくは6.2.1節参照)。 複数のギャップはひとつのSACKに含めて報告することができる(3.3.4節参照)。 相手がマルチホーム環境にある場合、SCTP端末は常に、受けとった 最新DATAチャンクの送出元にSACKを送るように試みるべきである (SHOULD)。 SACKの受信にあたり、端末はSACKの累積TSN確認応答で受信確認さ れた全てのDATAチャンクをその送信キューから削除しなければなら ない(MUST)。端末はまた、SACKによって報告されたGap Ack Blocks に含まれないTSNをもつDATAチャンクを、全て「紛失(missing)」と して扱わなければならない(MUST)。再送処理の決定のために、デー タ送信者は送信処理中のそれぞれのDATAチャンクについて「紛失」 報告の数を記録しなければならない(MUST)。詳しくは7.2.4節を参 照のこと。 以下の例はギャップを報告するためのSACKの使い方を示す。 Stewart, et al. Standards Track [Page 81] RFC 2960 Stream Control Transmission Protocol October 2000 Endpoint A Endpoint Z {App sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed) (Start T3-rtx timer) DATA [TSN=7,Strm=0,Seq=3] --------> X (lost) DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected, immediately send ack) /----- SACK [TSN Ack=6,Block=1, / Strt=2,End=2] <-----/ (remove 6 from out-queue, and mark 7 as "1" missing report) Figure 9 - Reporting a Gap using SACK ひとつのSACKチャンクで報告できるGap Ack Blocksの最大数は、現 在のパスMTUによって制限される。このMTUによる制限のために、ひ とつのSACKでは報告する必要のある全てのGap Ack Blocksをカバー できない場合、端末はひとつのSACKしか送ってはならず(MUST)、 MTUによって決められるサイズ制限の範囲内で最低のTSNから高い方 へGap Ack Blocksを報告することになる。また残りの最高TSN番号 は未確認のままとしなければならない(MUST)。 6.8 Adler-32チェックサムの計算 (訳注: この内容はすでにRFC3309によって置きかえられている) SCTPパケットの送信の際、端末は以下のようにパケットについて計算されたAdler-32チェックサム値を含むことで送信されるデータの完全性(integrity)を強化しなければならない(MUST)。 パケット(SCTP共通ヘッダと一つ以上の制御またはDATAチャンクを含む)が構成された後、送信者は以下を行うだろう: 1) 正しい認証タグをSCTP共通ヘッダに書きこみ、チェックサムフィールドを0に初期化する。 2) SCTP共通ヘッダとすべてのチャンクを含むパケット全体のAdler-32チェックサムを計算する。 3) 得られた値を共通ヘッダのチェックサムフィールドに書きこみ、残りのビットはそのまま変更しない。 SCTPパケットを受信した際、受信者は最初にAdler-32チェックサムを確認しなければならない(MUST): 1) 受信したAdler-32チェックサム値を別の場所に保存しておく。 Stewart, et al. Standards Track [Page 82] RFC 2960 Stream Control Transmission Protocol October 2000 2) 受信したSCTPパケットの32ビットのチェックサムフィールドを全て'0'で置きかえ、受信パケット全体のAdler-32チェックサム値を計算する。 3) 計算したAdler-32チェックサムと受信したAdler-32チェックサムが同じであるか検証する。同じでなければ、受信者はこのパケットを不正なSCTPパケットとして扱わなければならない(MUST)。 不正なSCTPパケットのデフォルトの処理は静かに(silently)破棄することである。 6.9 分割と再構成 端末はDATAチャンクの送信の際、分割をサポートしていてもよい(MAY)が、DATAチャンクの受信時には再構成をサポートしていなければならない(MUST)。端末が分割をサポートしているなら、送信するユーザメッセージを含む送出対象のSCTPパケットのサイズが現在のMTUを超えるならば、ユーザメッセージを分割しなければならない(MUST)。もし実装が送出するユーザメッセージに対し分割をサポートしていないなら、端末はその上位層に対しエラーを返さなければならず、ユーザメッセージを送ろうとしてはならない(訳注: SCTPパケットのサイズがMTUを超えるなら)。 実装上の注意: このエラーの場合、10.1節で議論される送信(Send)機能は上位層に対しエラーを返す必要があるだろう。 相手がマルチホーム環境であった場合、端末はアソシエーション経路MTU以下のサイズを選ぶだろう。このアソシエーション経路MTUは(訳注: 相手の)全ての宛先アドレスの経路MTUの中で最小の値である。 注意: メッセージは一度分割されたら、再度分割してはいけない。そのかわり、PMTUが減少したならIPフラグメンテーションを用いなければならない。PMTU発見の詳細については7.3節を参照のこと。 いつ分割するかを決めるにあたって、SCTPの実装はDATAチャンクのヘッダはもとよりSCTPのパケットヘッダをも考慮に入れなければならない(MUST)。実装はまた、SACKチャンクをDATAチャンクにバンドルするならばSACKチャンクに必要なスペースも考慮に入れなければならない(MUST)。 分割は以下のステップを踏む: 1) データ送信者は、それぞれのチャンクとSCTPのオーバーヘッドの和がアソシエーション経路MTU以下のサイズのひとつのIPデータグラムにおさまるように、ユーザメッセージをひと続きのDATAチャンクに分解しなければならない(MUST)。 2) 送信者(transmitter)は連続したDATAチャンクのそれぞれに別々のTSNを連続して割り当てなければならない(MUST)。送信者は同じSSNをそれぞれのDATAチャンクに割り当てる。もしユーザがユーザメッセージの非順序(unordered)配送を指定したなら、ユーザメッセージのそれぞれのDATAチャンクのUフラグを1に設定しなければならない(MUST)。 Stewart, et al. Standards Track [Page 83] RFC 2960 Stream Control Transmission Protocol October 2000 3) 送信者(transmitter)はまた、連続データの最初のDATAチャンクのB/Eビットを'10'とし、最後のDATAチャンクのB/Eビットを'01'とし、この連続データに属する他のすべてのDATAチャンクのB/Eビットを'00'に設定しなければならない。 端末は受信したDATAチャンクのそれぞれに含まれるB/Eビットを調べることによって分解されたDATAチャンクを認識し、分解されたDATAチャンクを再構成のためにキューイングしなければならない(MUST)。ユーザメッセージが再構成されると、SCTPは再構成されたユーザメッセージを、おそらく必要となる並べかえや最終ふりわけ(dispatching)のために特定のストリームに渡すだろう。 注意: もしデータ受信者がメッセージの再構成を完了させるためにさらにフラグメントを待っている間にバッファスペースを使い切ってしまったならば、入ってくるメッセージの一部を部分配送API(10節参照)を通して割り当て、残りのメッセージが受信できるように受信バッファの一部を解放するべきである。 6.10 バンドル 端末は1つの送出SCTPパケットに単に複数のチャンクを含ませるこ とでチャンクをバンドルする。結果としてできる、SCTPパケットと IPヘッダを含んだIPデータグラムの合計サイズは、現在のパスMTU 以下でなければならない(MUST)。 相手の端末がマルチホーム環境にある場合、送信端末は現在のプラ イマリパスの最新MTUを超えないサイズを選ぶだろう。 制御チャンクをDATAチャンクとバンドルする際、端末は送出SCTPパ ケットの中でまず始めに制御チャンクを配置しなければならない (MUST)。送信者はDATAチャンクをSCTPパケットの中でTSNの増加順 に送らなければならない(MUST)。 注意: 制御チャンクはパケットの中で最初に配置されなければ ならず、またDATAチャンクはSHUTDOWNやSHUTDOWN ACKチャンクの前 に送られなければならないので、DATAチャンクはSHUTDOWNや SHUTDOWN ACKチャンクとバンドルすることができない。 部分チャンクはSCTPパケットの中に含んではならない(MUST NOT)。 Stewart, et al. Standards Track [Page 84] RFC 2960 Stream Control Transmission Protocol October 2000 端末は受信したチャンクをパケット内の順序通りに処理しなければ ならない(MUST)。受信者はチャンク長フィールドを使い、全てのチャ ンクが4バイトの境界で終了する事実を考慮に入れて、チャンクの 終端と次のチャンクの先頭を決定する。受信者が部分チャンクを検 出した場合、そのチャンクを捨て(drop)なければならない(MUST)。 端末はINIT、INIT ACK、またはSHOUTDOWN COMPLETEチャンクをその 他のチャンクとバンドルしてはならない(MUST NOT)。 7. 輻輳制御 輻輳制御はSCTPの基本機能のひとつである。いくつかのアプリケーションにとっては、時間制約のあるデータの機敏な配送を保証するために妥当な資源がSCTPトラフィックに割りあてられそうであり、通常の操作においてはデータ転送が深刻な輻輳状態に遭遇することはなさそうである。しかしながらSCTPは不利な環境下でも動作しなければならず、このような環境下では部分的なネットワーク障害や予想外のトラフィック集中が起こりうる。このような状況において、SCTPはデータを配送できるようになるべく早く輻輳から復帰するために正しい輻輳制御手順に従わなければならない。ネットワークに輻輳がない場合には、これらの抑制的な輻輳制御アルゴリズムはプロトコルの性能に影響を与えるべきではない。 実装上の注意: 特定の性能要求が満たされる限り、実装は常に、以下で定義されるものよりもっと保守的な輻輳制御アルゴリズムを採用できる。 SCTPが用いる輻輳制御アルゴリズムは[RFC2581]に基づいている。この節はRFC2581で定義されたアルゴリズムがSCTPでの利用のためにいかに修正されているかを述べている。最初にTCPとSCTPのプロトコル設計における違いを列挙し、それからSCTPの輻輳制御方法を記述する。この記述の中でふさわしい場合はいつでも、TCPの輻輳制御で用いられるのと同じ用語を用いるだろう。 SCTPの輻輳制御は常にアソシエーション全体に適用されるのであって、個別のストリームに適用されるのではない。 7.1 TCPの輻輳制御とSCTPの差異 SCTP SACKに含まれるGap Ack BlocksはTCP SACKと同様の意味づけをなされるものである。TCPはSACKで運ばれる情報を参考(advisory)情報としか考えない。SCTPはSACKチャンク内のGap Ack Blocksで運ばれる情報を現状報告(advisory)として考える。SCTPにおいては、SACKによって確認応答されたDATAチャンク、それは受信端末に順序が狂って届いたDATAを含んでいるが、それらを累積TSN確認応答ポイントがそのDATAチャンクのTSNを越える(すなわち、そのDATAチャンクがSACKにおいて累積TSN確認応答フィールドによって確認応答される)までは完全に配送されたとは考えない。したがって、cwndの値は(SACKのないTCPの場合のように)もっとも大きな確認応答された通し番号と輻輳制御ウインドウの中で送られる最後のDATAチャンクの間の上限を制御するものではなく、送信処理中のデータの量を制御するものである。SCTP SACKは高速再送と高速回復についてSACKを用いないTCPとは異なる実装を導く。例として[FALL96]を参照のこと。 Stewart, et al. Standards Track [Page 85] RFC 2960 Stream Control Transmission Protocol October 2000 しかしながらSCTPとTCPの最大の違いはマルチホームである。SCTPは2つ以上のトランスポートアドレスを用いどれかが到達可能となることにより、二つの端末の間で頑健な通信アソシエーションを確立するように設計されている。確かではないが(potentially)異なるアドレスは二つの端末の間で異なる経路につながり、理想的には各経路ごとに異なる輻輳制御パラメータの組が必要になるかもしれない。マルチホームを利用している受信者に対してのSCTPにおける輻輳制御のここでの取り扱いは新たな試みであり、将来的にはもっと洗練する必要があるかもしれない。現状のアルゴリズムは以下の仮定をおく: o 送信者は上位層によって指示されない限りはいつも同じ宛先アドレスを使う。しかしながら、SCTPはアドレスがinactiveにマークされるというイベントによって代替の宛先に変更するかもしれない(8.2節参照)。またSCTPは元々の送信とは異なるトランスポートアドレスに対して再送を行うかもしれない。 o 送信者は送信可能なそれぞれの宛先アドレスごとに別々の輻輳制御パラメータをもつ(送信元-宛先のペアごとではなく宛先ごと)。あるアドレスが十分長い期間使われていなかった場合、そのパラメータは古くなっている(decay)だろう。 o それぞれの宛先アドレスに対し、端末は最初の送信時にスロースタートを用いる。 注意: TCPは上位層プロトコルに対し、一つのTCPセッションの中でデータの順序通りの配送を保証する。これはTCPが受信したシーケンス番号に抜けがあることに気づいた際に、抜けたデータよりも大きなシーケンス番号をもつ受信データを(訳注: 上位層に)配送する前に、この抜けが埋まるのを待つということを意味する。一方SCTPはTSNに抜けがあったとしても、特定のストリームのストリームシーケンス番号が順序通りになっていれば(すなわち抜けているDATAチャンクは他のストリームに属する)、あるいは非順序の配送が指示されているならば、上位層にデータを配送することができる。このことはcwndに影響を与えないが、rwndの計算には影響を与えるかもしれない。 Stewart, et al. Standards Track [Page 86] RFC 2960 Stream Control Transmission Protocol October 2000 7.2 SCTPのスロースタートと輻輳回避 端末はネットワークに射出するデータ量を制御するためにスロースタートおよび輻輳回避アルゴリズムを用いなければならない(MUST)。SCTPにおける輻輳制御はアソシエーションに関して適用されるのであり、個別のストリームに関してのものではない。ある状況下ではアルゴリズムが許可するよりももっと保守的にふるまったほうがSCTP送信者にとって有利かもしれない。しかしながら、SCTP送信者は以下のアルゴリズムが許すよりも積極的に(aggressive)にふるまってはならない(MUST NOT)。 TCPと同様に、SCTP端末は送信レートを調節するために以下の3つの制御変数を用いる。 o 受信者広告ウインドウサイズ(rwnd, 単位はバイト)。これは受信者が流入パケットのために利用可能なバッファスペースに基づいて設定する。 注意: この変数はアソシエーション全体に対して維持する。 o 輻輳制御ウインドウ(cwnd, 単位はバイト)。これは観測されたネットワーク状況に基づいて送信者が調節する。 注意: この変数は宛先アドレスごとに別々に管理する。 o スロースタートしきい値(ssthresh, 単位はバイト)。これは送信者がスロースタートと輻輳制御のフェイズを識別するために用いる。 注意: この変数は宛先アドレスごとに別々に管理する。 SCTPはまた、partial_bytes_ackedという付加的な制御変数を必要とする。これは輻輳回避フェーズにおいてcwndを調節しやすくするために用いる。 TCPとは異なり、SCTP送信者はこれらの制御変数の組、すなわちcwnd、スロースタートしきい値(ssthresh)、およびpartial_bytes_ackedを相手の宛先アドレスごと(EACH)に(相手がマルチホーム環境にある場合は)管理しなければならない(MUST)。またアソシエーション全体に対して一つだけのrwndを管理する(相手がマルチホーム環境であろうと単一のアドレスを持っていようと)。 7.2.1 スロースタート 状態のわからないネットワークに対してデータ送信を開始、あるい は十分長いアイドル時間の後で開始する場合、SCTPは利用可能なネッ トワーク容量を決めるためにネットワークをプローブする必要があ る。スロースタートアルゴリズムは、転送の開始または再送タイマー によって検知されたロスからの回復のあとで、この目的のために用 いられる。 Stewart, et al. Standards Track [Page 87] RFC 2960 Stream Control Transmission Protocol October 2000 o DATA送信開始前あるいは十分長いアイドル期間のあとでの初期cwndは2*MTU以下でなければならない(MUST)。 o 再送タイムアウト後の初期cwndは1*MTUをこえてはならない(MUST)。 o ssthreshの初期値は任意の高さでよい(MAY)(たとえば、実装は受信者の広告ウインドウサイズを用いてもよい(MAY))。 o cwndが0より大きいときはいつでも、端末はそのトランスポートアドレスに対しcwndバイトのデータを処理中(outstanding)としてよい。 o cwndがssthresh以下のとき、SCTP端末は(現在の輻輳ウインドウが完全に利用されていると仮定して)cwndを増加させるためにスロースタートアルゴリズムを用いなければならない(MUST)。受けとったSACKが累積TSN確認応答ポイントを進める場合、cwndを少なくとも以下1)と2)のうち小さい方の量は増やさなければならない(MUST)。1)これまで送信処理中であって今回確認応答されたDATAチャンクの全サイズ。2)その宛先の経路MTU。これは[SAVAGE99]で概説されているACK分割攻撃を防ぐ仕組である。 相手端末がマルチホーム環境にある例においては、端末が累積TSN確認応答ポイントを進めるSACKを受信したならば、確認応答されたデータを送信した宛先アドレスに割りあてられているcwnd(ひとつまたは複数)を更新するべきである。しかしながら受信したSACKが累積TSN確認応答ポイントを進めるものではない場合、端末はどの宛先アドレスについてのcwndも調節してはならない(MUST NOT)。 端末のcwndが自身の累積TSN確認応答ポイントと結びつけられていないため、重複SACKが来るにつれて、それらは累積TSN確認応答ポイントを進めないであろうにもかかわらず、端末はこれらを新しいデータを送り出すためのクロックとして用いることができる。すなわち、SACKにより新しく確認応答されたデータは現在送信中のデータ量を減らしcwnd以下にする。その時点で、cwndの値は変更されていないので、新しいデータを送ることができる。一方で、cwndの増加は上記のように累積TSN確認応答ポイントの前進と結びつけられなければならない。さもなければ重複SACKは新しいデータを送り出すためのクロックとなるだけでなく、おそらく輻輳が生じている時間に、ネットワークから(訳注: 上位層へ)出たばかりのデータよりも多くの新しいデータをかえって送り出してしまうだろう。 o 端末が与えられたトランスポートアドレスにデータを送らないとき、そのトランスポートアドレスのcwndはRTOあたりmax(cwnd/2, 2*MTU)に調整されるべきである。 Stewart, et al. Standards Track [Page 88] RFC 2960 Stream Control Transmission Protocol October 2000 7.2.2 輻輳回避 cwndがssthreshを越えているとき、送信者があるトランスポートアドレスに対し送信処理中のデータがcwnd以上あるなら、cwndはRTTあたり1MTUだけ増加させるべきである。 実際上、実装は以下の方法でこの目標を達成できる: o partial_bytes_ackedを0に初期化する。 o cwndがssthreshより大きいときはいつでも、累積TSN確認応答ポイントを進めるSACKが到着するごとに、そのACKで新しく確認応答されるすべてのチャンク -- 新しい累積TSN確認応答とGap Ack Blocksで確認されるチャンクを含む -- の合計分だけpartial_bytes_ackedを増加させる。 o partial_bytes_ackedがcwnd以上であり、また送信者がSACKの到着前にcwnd以上のバイトのデータを送信処理中であったとき(すなわち、SACKの到着前に飛行中サイズがcwnd以上であったとき)、cwndをMTUだけ増加させ、partial_bytes_ackedを(partial_bytes_acked - cwnd)に設定しなおす。 o スロースタートと同様に、送信者が与えられたトランスポートアドレスにDATAを送信しないときは、このトランスポートアドレスについてのcwndをRTOあたりmax(cwnd / 2, 2*MTU)に調節すべきである。 o 送信者が送信したデータがすべて受信者によって確認応答されたとき、partial_bytes_ackedは0に初期化される。 7.2.3 輻輳制御 SACKによりパケットロスが検知されると(7.2.4節参照)、端末は以下を行うべきである: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh 基本的に一つのパケットロスによりcwndを半分にする。 あるアドレスについてのT3-rtxタイマが期限切れとなったとき、SCTPは以下によりスロースタートを行うべきであり: ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU Stewart, et al. Standards Track [Page 89] RFC 2960 Stream Control Transmission Protocol October 2000 また端末がこのアドレスへのデータ配送の成功を示す確認応答を受けとるまでは、このアドレスに送信中のパケットが高々1個となることを確実にしなければならない。 7.2.4 Gap報告を受けての高速再送 データロスのない場合、端末は遅延確認応答を行う。しかしながら、端末が到着するTSN列に抜けをみつけたときはいつでも、その抜けが埋まるまでの間はデータを運ぶパケットが一個到着するごとにSACKを送り返すべきである(SHOULD)。 端末がいくつかのTSNが抜けていることを示すSACKを受けとったときはいつでも、高速再送に関する動作を起こす前に、同じTSNに対しての抜けが(後続のSACKによって)さらに3回示されるまで待つべきである(SHOULD)。 連続する4番目のSACKにおいて、あるTSNが抜けていると報告されたとき、データ送信者は以下の動作を行うだろう: 1) 抜けているDATAチャンクを再送のためにマークする。 2) 抜けているDATAチャンクを最後に送った宛先アドレスについてのssthreshとcwndを、7.2.3節に記述されている式によって調節する。 3) パケットを送信する宛先トランスポートアドレスの経路MTUの制約に合うように、再送対象としてマークされた最初(最も低いTSN)のいくつのDATAチャンクが一つのパケットに納まるかを決定する。この値をKと呼ぶ。これらK個のDATAチャンクを一つのパケットに入れて再送する。 4) 最後のSACKがそのアドレスに送られた送信処理中のパケットのうち最も低いTSN番号について確認応答している場合についてのみT3-rtxタイマを再始動し、そうでない場合は端末はそのアドレスに送られた送信処理中の最初のDATAチャンクを再送する。 注意: 受信したSACKが新しいDATAチャンクも確認応答しており累積TSN確認応答ポイントをすすめるならば、上記の調整を行う前に、7.2.1節および7.2.2節で定義されているcwnd調整ルールをまず最初に適用しなければならない。 上記の素直な(straightforward)実装はSACKで報告されたそれぞれのTSNのぬけに対してカウンタを設ける。同じTSNのぬけを報告する連続したSACKがあるごとにそのカウンタを増やす。4になり高速再送手順を開始したあとで、このカウンターは0にリセットする。 Stewart, et al. Standards Track [Page 90] RFC 2960 Stream Control Transmission Protocol October 2000 SCTPのcwndは間接的に送信処理中のTSNの数を制限するため、輻輳制御ウインドウのサイズに調整を加えないことで自動的にTCP高速回復の効果が得られる。 7.3 経路MTU探索 [RFC1191]は"経路MTU探索"を規定している。これを利用することで端末は与えられたインターネット経路に沿って最大転送単位(MTU)の見積りを管理し、経路MTU(PMTU)の変化を調べる特別な試み以外ではこの経路に沿ってMTUを超えるパケットの送信を禁止する。RFC 1191はMTU探索メカニズムについての議論や、この値の変化の検出のための戦略だけでなく現在のエンドツーエンドのMTU設定を決めるための戦略についてもよくまとめている。[RFC1981]はIPv6のための同様のメカニズムを規定している。IPv6を用いるSCTP送信者は、すべてのパケットがIPv6 MTUの最小値[RFC2460]より小さい場合を除いては、経路MTU探索を用いなければならない(MUST)。 端末はこれらの技術を適用するべきであり(SHOULD)、宛先アドレスごとに別々に管理すべきである(SHOULD)。 TCPにMTU探索を適用することについてのRFC1191における記述と異なる方法が4つある: 1) SCTPアソシエーションは複数のアドレスに対して張る(span)ことができる。端末は相手のそれぞれの宛先アドレスに対して別々のMTU見積りを管理しなければならない(MUST)。 2) 用語"MTU"についてこの文書の中のどこで議論するときも、議論の文脈に対応した宛先アドレスに対してのMTUを指す。 3) TCPとは異なり、SCTPは"最大セグメントサイズ"という概念をもたない。したがって、それぞれの宛先アドレスに対するMTUはその宛先アドレスへのパケットが向けられる経路となるローカルインタフェースのリンクMTU以下の値に初期化されるべきである(SHOULD)。 4) SCTPにおけるデータ転送はもともとバイト(TCPの場合)ではなくTSNにより構成されるので、RFC 1191の6.5節の議論を適用する。そのアドレスの経路MTUに比べて大きすぎるIPデータグラムを送ることになりそうな相手アドレスに対しIPデータグラムを再送する際、IPデータグラムはフラグメント(分割)できるようにDFビットを立てないで再送するべきである(SHOULD)。新しいIPデータグラムの転送にはDFを立てなければならない(MUST)。 Stewart, et al. Standards Track [Page 91] RFC 2960 Stream Control Transmission Protocol October 2000 5) 送信者は相手の全て宛先アドレスに対して最小となるPMTUであろうアソシエーションPMTUを追跡すべきである。メッセージを複数の部分に分割する際、このアソシエーションPMTUを各断片のサイズを計算するために使うべきである。これにより、再送を代替のアドレスにIPフラグメンテーションを起こすことなくシームレスに送ることができるだろう。 これらの違いを除けば、RFC1191と1981におけるMTU探索のTCPでの利用に関する議論は、宛先アドレスごとに別々に管理することでSCTPに適用する。 注意: IPv6宛先アドレスについてはDFビットが存在しないので、かわりにIPデータグラムを[RFC2460]で記述されているように分割しなければならない。 8. 障害の管理 8.1 端末障害の検知 端末は相手に対する連続した再送(相手がマルチホーム環境の場合 はその全ての宛先トランスポートアドレスへの再送を含む)の合計 についてのカウンタをもつだろう。このカウンタの値がプロトコル パラメータ'Association.Max.Retrans'で示される限度をこえた場 合、端末は相手端末が到達不可能と考え、相手へのさらなるデータ 転送は中止するだろう(そしてアソシエーションはCLOSED状態に入 る)。さらに端末は障害を上位層に報告するだろうし、オプション として送出キューに残っている全ての送信処理中ユーザデータにつ いて報告する(report back)だろう。相手端末が到達不可能となっ たとき、アソシエーションは自動的に閉じられる。 このカウンタは相手端末に送ったDATAチャンクが確認応答される (SACKの受信により)か、あるいはHEARTBEAT-ACKが相手から受信さ れるごとにリセットされるだろう。 8.2 経路障害の検知 相手端末がマルチホーム環境にあるとき、端末は相手端末の宛先ト ランスポートアドレスごとにエラーカウンタをもつべきである。 任意のアドレスに対してT3-rtxタイマが期限切れになったときはい つでも、またはアイドルのアドレスに送ったハートビートがRTOの 間確認応答されなかったとき、その宛先アドレスへのエラーカウン タはインクリメントされる。エラーカウンタの値がその宛先アドレ スについてのプロトコルパラメータ'Path.Max.Retrans'を超えたと き、端末はその宛先アドレスをインアクティブとマークするべきで あり、上位層に通知されるべきである。 Stewart, et al. Standards Track [Page 92] RFC 2960 Stream Control Transmission Protocol October 2000 送信中のTSNが確認応答されたとき、またはそのアドレスに送られ たHEARTBEATがHEARTBEAT ACKによって確認応答されたとき、端末は 最後にDATAチャンクが送られた(またはHEARTBEATが送られた)宛先 トランスポートアドレスのエラーカウンタをゼロクリアするだろう。 相手端末がマルチホーム環境にあり最後に送られたチャンクが別の アドレスへの再送だった場合、確認応答が最後にチャンクが送られ たアドレスに対してのものであった(credit)かについて曖昧さが存 在する。しかしながら、この曖昧さはSCTPのふるまいになんら重大 な結果をもたらさなさそうである。この曖昧さを望まないなら、送 信者は最後のチャンクが再送だった場合にエラーカウンタをクリア しないことにしてもよい。 注意: SCTP端末設定の際、ユーザは'Association.Max.Retrans' の値が相手端末の全ての宛先アドレスについての' Path.Max.Retrans'の和よりも大きくならないようにするべきであ る。さもなければ、全ての宛先アドレスがインアクティブになろう とも端末が相手端末をまだ到達可能と考えてしまう。この状況が発 生したとき、SCTPがどのように機能するかは実装による。 プライマリパスがインアクティブと判定された際(例えば規定回数 を超えた再送によって)、アクティブな別の宛先アドレスが存在す るならば、送信者は新しいパケットをそのアドレスに自動的に送っ てもよい(MAY)。プライマリパスがインアクティブと判定された際 に2つ以上の代替アドレスがアクティブならば、ひとつのトランス ポートアドレスのみを選んで新しい宛先トランスポートアドレスと して用いるべきである(SHOULD)。 8.3 経路ハートビート デフォルトでは、SCTP端末は宛先トランスポートアドレスに対して 周期的にHEARTBEATチャンクを送ることによって、相手のアイドル となっている宛先トランスポートアドレスへの到達性をモニタリン グするだろう。 宛先トランスポートアドレスは、経路RTTを更新するために用いら れる新しいチャンク(通常、最初のDATAチャンク、INITチャンク、 COOKIE ECHOチャンク、HEARTBEATチャンクなど)、およびHEARTBEAT が、そのアドレスの現在のハートビート間隔にわたっていずれも送 られていないときに、"idle"であるとみなされる。この規則はアク ティブおよびインアクティブの宛先アドレスいずれにも適用される。 上位層はオプションとして、以下の機能をもつことができる: A) 与えられたアソシエーションの特定の宛先トランスポートア ドレスへのハートビートを不可とする B) HB.intervalを変更する Stewart, et al. Standards Track [Page 93] RFC 2960 Stream Control Transmission Protocol October 2000 C) 与えられたアソシエーションの特定の宛先トランスポートアドレスへのハートビートを再び可能とする D) 与えられたアソシエーションの特定の宛先トランスポートアドレスへのオンデマンドのハートビートを要求する 端末は、あるアドレスへのハートビートが送信されRTOの間に確認 応答が得られない現象が起こるごとに、その宛先トランスポートア ドレスに対応するエラーカウンタを1増加させるべきである。 このカウンタ値がプロトコルパラメータ'Path.Max.Retrans'に達し たとき、端末はこの宛先アドレスがinactiveとマークされていなけ ればマークするべきであり、またオプションとしてこの宛先アドレ スへの到達性の変化を上位層へ報告してもよい。この後、端末はこ の宛先アドレスに対してHEARTBEATを続行すべきだが、カウンタの 加算は停止すべきである。 HEARTBEATチャンクの送信者は、このパケットが送出される現在時 刻と送られる宛先アドレスを、チャンクのハートビート情報フィー ルドに含めなければならない。 実装上の注意: 使用可能なハートビートメカニズムの他の実装 として、ある宛先にHEARTBEATが送られるごとにエラーカウンタ変 数をインクリメントする方法がある。HEARTBEAT ACKが届いたなら ば、送信者はHEARTBEATが送られた宛先のエラーカウンタをクリア するべきである(SHOULD)。この方法は実質、以前に起きたエラー (および他のエラーカウント)をクリアしてしまうだろう。 HEARTBEATの受信者は、受信したHEARTBEATチャンクからコピーした ハートビート情報フィールドを含むHEARTBEAT ACKでもって即座に 返答しなければならない。 HEARTBEAT ACKの受信に際し、HEARTBEATの送信者はHEARTBEATが送 られた宛先トランスポートアドレスのエラーカウンタをクリアし、 もしまだマークされていないならその宛先トランスポートアドレス をアクティブとしてマークするべきである。端末は最新の HEARTBEAT ACKの受信により非アクティブな宛先アドレスがアクティ ブとしてマークされたとき、上位層に任意に(optionally)報告して よい。HEARTBEAT ACKの受信者はアソシエーション全体のエラーカ ウントもクリアしなければならない(8.1節で定義されているように)。 HEARTBEAT ACKの受信者はまたHEARTBEAT ACKチャンクに含まれる時 刻の値を用いて、その宛先トランスポートアドレスに対するRTT計 測をおこなうべきである。 Stewart, et al. Standards Track [Page 94] RFC 2960 Stream Control Transmission Protocol October 2000 ハートビートが許されているアイドルの宛先アドレスに対し、一つ のHEARTBEATチャンクはその宛先アドレスのRTOにプロトコルパラメー タ'HB.interval'を加えた間隔ごとに送ることが推奨される。また この間隔は±50%のジッタとし、前回のHEARTBEATに応答がなかった 場合はRTOに指数的バックオフを適用する。 SCTPユーザは基本機能として、HB.intervalを変更したり、与えら れた宛先アドレスに対しハートビートを発したり止めたりすること ができる。SCTPユーザが設定したハートビート間隔は、その宛先の RTO(指数バックオフのすべてを含む)を加えて用いられる。ハート ビートタイマが切れるごとに(もし複数の宛先がアイドルならば)一 つのハートビートしか送るべきではない。アイドルな宛先候補のう ち、(二つ以上の宛先がアイドルならば)どのようにしてハートビー トを打つ相手を選ぶかは実装に任される。 注意: ハートビート間隔の調整(tuning)にあたっては、考慮に 入れておくべき(SHOULD)副作用がある。この値が増えると、すなわ ちHEARTBEAT間隔が長くなると、ABORTメッセージの喪失を検出する のにかかる時間も同様に長くなる。もし相手端末がなんらかの理由 でアソシエーションを中断(ABORT)し、そのABORTチャンクが喪失し たならば、こちら側の端末はDATAチャンクかHEARTBEATチャンクを 送ること(こうして相手にもう一度ABORTを送信させる)によってし かABORTチャンクを発見できないだろう。このことはHEARTBEATタイ マを調整する際にも考慮しなければならない。HEARTBEATを無効に したならば、そのアソシエーションにDATAを送ることによってしか、 相手からのABORTを発見することはできない。 8.4 "青天の霹靂(Out of the blue)"パケットの扱い あるSCTPパケットが正しく構成されている、すなわち受信者のAdler-32チェックを通る(6.8節参照)にもかかわらず、このパケットがどのアソシエーションに属しているのか識別できないならば、このパケットを"青天の霹靂"(OOTB)パケットと呼ぶ。 OOTBパケットの受信者は以下の処理をしなければならない(MUST): 1) OOTBパケットがユニキャストでないアドレス宛、またはユニキャストでないアドレスが送信元となっていれば、このパケットを静かに(silently)破棄する。 2) 1)に該当せず、OOBがABORTチャンクを含んでいる場合、受信者はこのOOTBパケットを静かに(silently)破棄し、それ以上の処理は何もしてはならない(MUST)。 3) 2)に該当せず、このパケットが認証タグを0としたINITチャンクを含んでいる場合、5.1節で記述されているように処理する。 4) 3)に該当せず、パケットの最初のチャンクがCOOKIE ECHOの場合、5.1節で記述されているように処理する。 Stewart, et al. Standards Track [Page 95] RFC 2960 Stream Control Transmission Protocol October 2000 5) 4)に該当せず、このパケットがSHOUTDOWN ACKチャンクを含んでいた場合、受信者はOOTBパケットの送信者に対しSHUTDOWN COMPLETEで返答するべきである。SHUTDOWN COMPLETEの送信の際、OOTBパケットの受信者は送出パケットの認証タグフィールドにSHUTDOWN ACKで受けとった認証タグを入れ、TCBがみつからなかったことを示すためにチャンクフラグのTビットを立てなければならない。 6) 5)に該当せず、このパケットがSHUTDOWN COMPLETEチャンクを含んでいた場合、受信者はこのパケットを静かに(silently)破棄するべきであり、それ以上の処理は行うべきではない。 7) 6)に該当せず、このパケットが"Stale cookie" ERRORまたはCOOKIE ACKを含んでいた場合、このパケットは静かに(silently)破棄するべきである。 8) 7)に該当しないならば、受信者はこのOOTBパケットに対してABORTで返答するべきである。ABORT送信の際、OOTBパケットの受信者は送出パケットの認証タグフィールドにOOTBパケットの認証タグフィールドの値を入れ、TCBがみつからないことを示すためにチャンクフラグのTビットを立てなければならない(MUST)。このABORTの送信後、OOTBパケットの受信者はOOTBパケットを破棄し、それ以上の処理は何も行わないだろう。 8.5 認証タグ この節で定義する認証タグのルールはINIT、SHUTDOWN COMPLETE、COOKIE ECHO (5.1節参照)、ABORT、またはSHUTDOWN ACKチャンクを含まないSCTPパケットの送受信時に適用される。上記のチャンク型を含むSCTPパケットの送受信に適用されるルールは8.5.1節に分けて議論する。 SCTPパケットの送信に際し、端末は送出パケットの認証タグフィールドに、相手から受けとったINITまたはINIT ACKの初期化タグパラメータの値を入れなければならない(MUST)。 SCTPパケットの受信に際し、端末は受信したSCTPパケットの認証タグフィールドの値が自分自身のタグと一致することを確認しなければならない(MUST)。受信した認証タグの値が受信者自身のタグ値と一致しなかった場合、受信者は静かにこのパケットを(silently)破棄し、以下の8.5.1節に挙げた場合を除いてそれ以上の処理は行わないだろう。 Stewart, et al. Standards Track [Page 96] RFC 2960 Stream Control Transmission Protocol October 2000 8.5.1 認証タグルールの例外 A) INITを含むパケットについてのルール: - 送信者はパケットの認証タグを0にしなければならない(MUST)。 - 端末が認証タグが0となっているSCTPパケットを受けとった場合、このパケットがINITチャンクだけを含んでいるか検証するべきである。ほかのチャンクも含んでいたなら、受信者はこのパケットを静かに(silently)破棄しなければならない(MUST)。 B) ABORTを含むパケットについてのルール: - 端末は常に送出パケットの認証タグフィールドに、もし知っているならば宛先端末のタグ値を入れる。 - OOTBパケットへの返答としてABORTが送られる場合、端末は8.4節に記述された手順に従わなければならない(MUST)。 - 認証タグが自分自身のタグか(OR)相手のタグに一致するならば、受信者はこのパケットを受けつけなければならない(MUST)。さもなければ、受信者はこのパケットを静かに(silently)破棄し、それ以上の処理は行ってはならない(MUST)。 C) SHUTDOWN COMPLETEを含むパケットについてのルール: - SHUTDOWN COMPLETEの送信にあたり、SHUTDOWN ACKの受信者がTCBを保持しているなら宛先端末のタグを使わなければならない(MUST)。TCBを保持していない場合に限り送信者はSHUTDOWN ACKの認証タグを用いるべきである。 - SHOTDOWN COMPLETEの受信者は、そのパケットの認証タグフィールドが自分自身のタグと一致するかまたは(OR)相手のタグが設定されており、かつチャンクフラグにおいてTビットが立ててあれば、このパケットを受けいれるだろう。そうでなければ、受信者はこのパケットを静かに(silently)破棄し、それ以上の処理は行ってはならない(MUST)。端末がSHUTDOWN-ACK-SENT状態でない場合はSHUTDOWN COMPLETEを無視しなければならない(MUST)。 D) COOKIE ECHOを含むパケットについてのルール - COOKIE ECHOの送信にあたり、端末はINIT ACKで受けとった初期化タグの値を用いなければならない(MUST)。 - COOKIE ECHOの受信者は5節の手順に従う。 Stewart, et al. Standards Track [Page 97] RFC 2960 Stream Control Transmission Protocol October 2000 E) SHUTDOWN ACKを含むパケットについてのルール - 受信者がCOOKIE-ECHOEDまたはCOOKIE-WAIT状態にある場合、8.4節の手順に従うべきである(SHOULD)。すなわち青天の霹靂(Out Of The Blue)パケットとして扱うべきである。 9. アソシエーションの終了 端末がサービスを終了するとき、そのアソシエーションを終了させ るべきである。アソシエーションはabortかshutdownによって終了 できる。アソシエーションのabortはその言葉通り処理が未完結と なり、アソシエーションのいずれの端末に送信を待っているデータ が残っていてもそれは破棄され、相手に配送されることはない。ア ソシエーションのshutdownは上品な(graceful)closeと考えられ、 各端末にあるキュー内の全てのデータは相手端末に配送される。し かしながら、shutdownの場合、SCTPは一端が閉じているのに対しも う一端がデータを送りつづけてもよいという(TCPのような)ハーフ オープン状態をサポートしていない。いずれかの端末がshutdownを 実行すると、各端末のアソシエーションはユーザからの新しいデー タの受け入れを停止し、SHUTDOWNチャンクの送受信に際し、キュー に残ったデータを配送するのみとなる。 9.1 アソシエーションのabort 端末が現在存在するアソシエーションをabortしようと決めたとき、 相手端末に対してABORTチャンクを送信するだろう。送信者は送出 パケットの相手のVerification Tagを設定せねばならず(MUST)、 ABORTチャンクにはDATAチャンクをバンドルしてはならない(MUST NOT)。 端末はABORTチャンクを含む受信パケットに対して応答してはなら ない(MUST NOT)(8.4節も参照のこと)。 ABORTを受けとった端末は8.5.1節で記述されている特別な Verification Tagチェックルールを適用するだろう。 Verification Tagのチェック後、受信端末はそのアソシエーション を記録から消去し、その終了を上位層に報告するだろう。 9.2 アソシエーションのshutdown SHUTDOWN要素(10.1節参照)を用いることにより、アソシエーション を確立している端末の上位層は上品に(gracefully)アソシエーショ ンを閉じることができる。これにより、shutdownを発行する端末の 相手が送信処理中の全てのDATAチャンクがアソシエーションの終了 までに配送できるだろう。 上位層からSHUTDOWN要素を受けとると、端末はSHUTDOWN-PENDING状 態に入り、全ての送信処理中のデータが相手によって確認応答され るまでその状態を維持する。端末は上位層から新しいデータを受け つけないが、gapを埋める必要があれば相手に再送する。 Stewart, et al. Standards Track [Page 98] RFC 2960 Stream Control Transmission Protocol October 2000 すべての送信処理中のデータについて確認応答が得られれば、その 端末は相手から連続で最後に受信したTSNを累積TSN確認応答フィー ルドに含めてSHUTDOWNチャンクを相手に送信するだろう。それから T2-shutdownタイマを開始し、SHUTDOWN-SENT状態に入るだろう。も しこのタイマが切れたら、端末は相手から連続で最後に受信した TSNを最新のものとして含めSHUTDOWNを再送しなければならない。 T2-shutdownに適したタイマ値をきめるために、6.3節のルールに従 わなくてはならない(MUST)。TSNのgapを示すために、端末は同一の SCTPパケットにSHUTDOWNチャンクとともにSACKをバンドルしてもよ い。 端末はSHUTDOWNチャンクの再送回数をプロトコルパラメータである' Association.Max.Retrans'に制限するべきである。もしこのしきい 値を過ぎたなら、端末はTCBを破棄するべきであり、相手端末が到 達できなくなったことを上位層に報告しなければならない(MUST) (こうしてこのアソシエーションはCLOSED状態に入る)。相手からの パケットをなにか(すなわち、相手がキューにあるDATAチャンクを すべて送ってくるので)受信したら、端末の再送カウントをクリア するべきであり、T2-shutdowntタイマを再起動するべきである。こ れは相手にまだ送信されていないキュー内のDATAチャンクを全て送 信する十分な機会を与えるためである。 SHUTDOWNの受信にあたっては、端末は以下のように動作するだろう。 - SHUTDOWN-RECEIVED状態に入る。 - SCTPユーザからの新しいデータの受けつけを停止する。 - チャンクの累積TSN確認応答フィールドをチェックすることに より、自分が送信処理中のDATAチャンクが全てSHUTDOWN送信者に受 信されているかを検証する。 端末が一旦SHUTDOWN-RECEIVED状態に入ると、上位層からの要求に 応じてSHUTDOWNを送ってはならず(MUST NOT)、後続のSHUTDOWNチャ ンクを破棄するべきである。 まだ送信処理中のDATAチャンクが残っている場合、SHUTDOWNの受信 者は全ての送信処理中のDATAチャンクが確認応答されるまで、6節 で定義されている通常のデータ転送手順にのっとっり続けるだろう。 しかしながら、SHUTDOWNの受信者はその(上位層である)SCTPユーザ からの新しいデータを受けつけてはならない(MUST NOT)。 SHUTDOWN-SENT状態においては、SHUTDOWN送信者はSACKやSHUTDOWN がつけられたひとつまたはそれ以上のDATAチャンクを含む各パケッ トに対し、即座に応答しなければならない(MUST)。送信処理中の DATAチャンクがない場合、SHUTDOWN受信者はSHUTDOWN ACKチャンク を送り、自身のT2-shutdownタイマを始動させることにより、 SHUTDOWN-ACK-SENT状態に入るだろう。タイマが切れた場合、端末 はSHUTDOWN ACKを再送しなければならない。 Stewart, et al. Standards Track [Page 99] RFC 2960 Stream Control Transmission Protocol October 2000 SHUTDOWN ACKの送信者はSHUTDOWN ACKチャンクの再送回数をプロト コルパラメータである'Association.Max.Retrans'に制限するべき である。このしきい値をこえてしまった場合、端末はTCBを破棄す るべきであり、相手端末が到達不可能になったことを上位層に報告 してよい(こうしてこのアソシエーションはCLOSED状態に入る)。 SHUTDOWN ACKの受信に際し、SHUTDOWN送信者はT2-shutdownタイマ を停止し、SHUTDOWN COMPLETEチャンクを相手に送信し、このアソ シエーションの全ての記録を削除するだろう。 SHUTDOWN COMPLETEチャンクの受信に際し、端末は SHUTDOWN-ACK-SENT状態にいることを確かめ、破棄対象のチャンク でないことを確認するだろう。SHUTDOWN-ACK-SENT状態にあるなら ば、端末はT2-shutdownタイマを停止させこのアソシエーションに 関する全ての情報を削除するだろう(こうしてこのアソシエーショ ンはCLOSED状態に入る)。 端末は、shutdown手続きを始める前に全ての送信処理中のDATAチャ ンクが確認応答されたことを保証するべきである(SHOULD)。 端末はSHUTDOWN-PENDING、SHUTDOWN-SENT、SHUTDOWN-RECEIVED、ま たはSHUTDOWN-ACK-SENTのいずれかの状態にあるならば、上位層か らの新しいデータの送信要求は拒否すべきである。 端末がSHUTDOWN-ACK-SENT状態にあり、このアソシエーションに属 する送信元と送信先のトランスポートアドレス(パケットのIPアド レスまたはINITチャンク内のアドレス)をもったINITチャンクを受 けとった(例えば、SHUTDOWN COMPLETEが喪失したとき)ならば、こ のINITチャンクを破棄し、SHUTDOWN ACKチャンクを再送するべきで ある。 注意: その端末に割り当てられているトランスポートアドレス と同じ送信元と送信先のIPアドレスながら異なるポート番号をもっ ているINITの受信は、別のアソシエーションの初期化を示す。 INITまたはCOOKIE ECHOの送信者はSHUTDOWN-ACKの受信に対し、単 一のSHUTDOWN COMPLETEを一つのSCTPパケットとしその共通ヘッダ の中の認証タグフィールドをSHUTDOWN ACKパケットで受信されたの と同じタグとして応答するべきである。これは8.4節で定義されて いるようにOut of the Blueパケットだと考えられる。INITの送信 者はT1-initタイマを動作させたままとしCOOKIE-WAITまたは COOKIE-ECHOED状態を維持する。通常のT1-initタイマ切れにより INITまたはCOOKIEチャンクが再送され、このようにして新しいアソ シエーションが始められる。 Stewart, et al. Standards Track [Page 100] RFC 2960 Stream Control Transmission Protocol October 2000 COOKIE WAITまたはCOOKIE ECHOED状態においてSHUTDOWNを受けとっ たとき、このSHUTDOWNチャンクは静かに(silently)破棄されるべき である(SHOULD)。 端末がSHUTDOWN-SENT状態において相手からSHUTDOWNチャンクを受 けとったなら、その端末は相手に対しSHUTDOWN ACKで即座に応答し、 SHUTDOWN-ACK-SENT状態に移行しT2-shutdownタイマを再始動させる だろう。 端末がSHUTDOWN-ACK-SENT状態においてSHUTDOWN ACKを受けとった なら、その端末はT2-shutdownタイマを停止し、SHUTDOWN COMPLETE チャンクを相手に送り、このアソシエーションの記録を全て削除す るだろう。 10. 上位層とのインタフェース(境界) 上位層プロトコル(ULP)はSCTPに対して基本要素を渡すことでサービスを要求し、さまざまなイベントについてSCTPから通知をうけるだろう。 本節で記述される基本要素や通知は、SCTPを実装するためのガイドラインとして使われるべきである。以下のULPインタフェースの基本要素についての機能記述は実例を示すためのものである。異なるSCTPの実装は異なるULPインタフェースをもつかもしれない。しかしながら、すべてのSCTP実装が同じプロトコル階層をサポートできることを保証するために、すべてのSCTPはサービスのある程度の最小セットを提供しなければならない。 10.1 ULPからSCTPへ 以降の節はULP/SCTPインタフェースを機能的に特徴づける。使用する書法は多くの高級言語のプロシージャまたは関数呼び出しに類似したものである。 以下に記述するULPの基本要素は、SCTPがプロセス間通信をサポートするために必須の基本機能を指定する。個別の実装はそれぞれの厳密なフォーマットを定めるにちがいないし、基本機能の組み合わせまたはその一部を単一の呼び出しとして提供するかもしれない。 A) 初期化 (Initialize) Format: INITIALIZE ([local port], [local eligible address list]) -> local SCTP instance name Stewart, et al. Standards Track [Page 101] RFC 2960 Stream Control Transmission Protocol October 2000 この基本要素はSCTPがその操作環境を整えるために、内部のデータ構造を初期化し必要な資源を割り当てることを可能にする。SCTPが一旦初期化されれば、ULPはこの基本要素を再度使用することなく他の端末と直接通信することができる。 SCTPはローカルのSCTPインスタンス名をULPに返すだろう。 必須属性: なし. オプション属性: 以下の属性型がこの要素と共に渡されるかもしれない: o ローカルのポート - もしULPが指定したいならばSCTPのポート番号。 o ローカルの候補アドレスリスト - ローカルのSCTP端末が結びつけるべきアドレスのリスト。デフォルトでは、アドレスリストが含まれていなかった場合、ローカルの端末はこのホストに割り当てられている全てのIPアドレスを用いるべきである。 実装上の注意: 実装がこのオプション属性をサポートしている場合、この端末から送出されるすべてのSCTPパケットのIP送信元アドレスフィールドにローカルの候補アドレスリストで示されたIPアドレスのうち一つを含むことを確実にするのは実装の責任である。 B) アソシエーション確立 (Associate) Format: ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count] この基本要素は上位層が特定の相手端末に対してアソシエーションを開始できるようにする。 相手端末の指定には、相手端末を定義するトランスポートアドレスのうち一つを用いる(1.4節参照)。ローカルのSCTPインスタンスがまだ初期化されていない場合は、このASSOCIATEはエラーとみなされる。 アソシエーションの確立に成功すれば、SCTPアソシエーションをとりあつかうためのハンドルとなるアソシエーションIDが返されるだろう。SCTPが相手端末との間にSCTPアソシエーションを開くことができなかった場合はエラーが返される。 Stewart, et al. Standards Track [Page 102] RFC 2960 Stream Control Transmission Protocol October 2000 ローカル端末の送出ストリーム数だけでなく相手の宛先トランスポートアドレス一式など、その他のアソシエーションパラメータも返されるかもしれない。ローカルの端末は返された宛先アドレスの中からひとつのトランスポートアドレスを選び、この相手にSCTPパケットを送るためのデフォルトのプライマリパスとするだろう。返された"destination transport addr list(宛先トランスポートアドレスリスト)"はULPがデフォルトのプライマリパスを変更する際、あるいは特定のトランスポートアドレスにパケットを送る場合に使うことができる。 実装上の注意: ASSOCIATE基本要素がブロッキング関数呼び出しとして実装されていた場合(訳注: 呼び出し側は処理がおわるまで待たされる)、このASSOCIATE基本要素は確立に成功したときにアソシエーションIDに加えてアソシエーションのパラメータを返すことができる。ASSOCIATE基本要素がノンブロッキング関数呼び出しとして実装されていた場合、アソシエーションIDだけが返され、アソシエーションのパラメータはCOMMUNICATION UP通知を用いて渡されるだろう。 必須属性: o ローカルのSCTPインスタンス名 - INITIALIZE操作で得られたもの。 o 宛先トランスポートアドレス - アソシエーションを確立する相手端末のトランスポートアドレスのうち一つを指定。 o 出力ストリーム数 - この相手端末に対しULPが開きたい出力ストリームの数。 オプション属性: なし. C) シャットダウン (Shutdown) Format: SHUTDOWN(association id) -> result アソシエーションを上品に(gracefully)閉じる。ローカルにキューイングされているユーザデータは全て相手に配送されるだろう。アソシエーションは相手が全ての送信したSCTPパケットに確認応答したあとで終了するだろう。アソシエーションの終了が成功した際には成功コードが返るだろう。アソシエーションを閉じる試みが失敗した場合はエラーコードが返るだろう。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うためのローカルのハンドル Stewart, et al. Standards Track [Page 103] RFC 2960 Stream Control Transmission Protocol October 2000 オプション属性: なし. D) 中止 (Abort) Format: ABORT(association id [, cause code]) -> result アソシエーションを粗野に(ungracefully)閉じる。ローカルにキューイングされているユーザデータは破棄されるだろう。またABORTチャンクが相手に送られる。アソシエーションの中止が成功した際には成功コードが返るだろう。アソシエーションを中止する試みが失敗した場合、エラーコードが返るだろう。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル オプション属性: o 原因コード - 相手に渡される中止の理由 None. (? 消し忘れ) E) 送信 (Send) Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unorder flag] [,no-bundle flag] [,payload protocol-id] ) -> result これはSCTPを介してユーザデータを送る主要メソッドである。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o バッファのアドレス - 送信対象のユーザメッセージが保存されている場所 o バイト数 - バイト単位で示すユーザデータの大きさ オプション属性: o コンテキスト - このユーザメッセージの送信に失敗した場合、ULPへの送信失敗通知に入れられるであろうオプションの32ビット整数 Stewart, et al. Standards Track [Page 104] RFC 2960 Stream Control Transmission Protocol October 2000 o ストリームID - このデータを送るストリームを示す。指定がなければストリーム0が使われるであろう。 o 有効期間 - ユーザデータの有効期間を指定する。ユーザデータは有効期間が切れたあとには送信されないだろう。このパラメータは期限の切れたユーザメッセージを送信しようとする試みを避けるために使える。SCTPはデータが有効期限内に送信する(すなわち、SCTPのsend基本要素によって宛先に送信する)ことができなかった場合にULPに通知する。しかしながら、SCTPが有効期間の切れる前にチャンクの送信を試みていた場合は、ユーザデータは送信されるだろう。 実装上の注意: データ有効期間オプションをよりよくサポートするため、送信者は送出DATAチャンクへのTSN番号の割り当てを最後の瞬間まで控えるかもしれない。そして実装の簡単化のために、一旦TSN番号が割り当てられれば、送信者はこのDATAチャンクの送信を委ねられたものとみなし、このDATAチャンクにつけられた有効期間オプションを上書きすべきである。 o 宛先トランスポートアドレス - このパケットを送るべき相手端末の宛先トランスポートアドレスのうち一つを指定する。可能ならばいつでも、SCTPはパケット送信のために、現在のプライマリパスのかわりにこの宛先トランスポートアドレスを用いるべきである。 o 非順序フラグ - このフラグが存在する場合、このユーザはデータを相手に非順序の方式で届けたい(すなわち、このメッセージを送信するすべてのDATAチャンクのUフラグを1に設定する)ということを示す。 o バンドルなしフラグ - SCTPがこのユーザデータを他の送出DATAチャンクとバンドルしないように指示する。ネットワーク輻輳時には、SCTPはこのフラグがあってもバンドルしてよい(MAY)。 o ペイロードプロトコルID - 相手に送信されるペイロードプロトコルデータの型を示すために相手にわたされる32ビット符号なし整数。この値は不透明なデータとしてSCTPにより渡される。 F) プライマリの設定 Format: SETPRIMARY(association id, destination transport address, [source transport address] ) -> result 指定した宛先トランスポートアドレスをパケット送信のためのプライマリパスとして用いるように、ローカルのSCTPに指示する。 Stewart, et al. Standards Track [Page 105] RFC 2960 Stream Control Transmission Protocol October 2000 この操作を試みたことによる結果が返されるだろう。指定された宛先トランスポートアドレスがassociateコマンドやcommunication up通知ですでに返された"宛先トランスポートアドレスリスト"に存在しなかった場合、エラーが返るだろう。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 宛先トランスポートアドレス - パケット送信のためのプライマリアドレスとして使うためのもので、相手端末のトランスポートアドレスの一つを指定する。これはローカルのSCTP端末が管理している現在のプライマリアドレスの情報を上書きする。 オプション属性: o 送信元トランスポートアドレス - 実装にはオプションとして、全ての送出IPデータグラムにつけるデフォルトの送信元アドレスを設定できるようにするものもあるかもしれない。 G) 受信 (Receive) Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id] この基本要素はSCTP入力キューに利用可能なメッセージがあれば、その最初のユーザメッセージをULPで指定されたバッファに読みこむだろう。読みこまれたメッセージのバイト単位のサイズが返されるだろう。特定の実装に依存するが、送信者のアドレス、受信したストリームのID、まだ取得可能なメッセージが残っているか、などの情報も返すかもしれない。順序メッセージについては、そのストリームシーケンス番号も返されるかもしれない。 実装にもよるが、利用可能なメッセージが来ていなかったときにこの基本要素が実行された場合、実装はこの状況を示す戻り値を返すか、あるいはデータが利用可能になるまでこのプロセスをブロックするべきである。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o バッファアドレス - ULPが示す、受信したメッセージを保存するためのメモリ上の位置 Stewart, et al. Standards Track [Page 106] RFC 2960 Stream Control Transmission Protocol October 2000 o バッファサイズ - バイト単位で示す受信データの最大サイズ オプション属性: o ストリームID - どのストリームに属するデータを受けとるかを示す o ストリームシーケンス番号 - 送信SCTPピアによってわりあてられたストリームのシーケンス番号 o 部分フラグ - この戻り値フラグが1の場合、このReceiveは全体のメッセージのうち部分的に送られたデータを含んでいる。このフラグが立っているとき、ストリームIDとストリームシーケンス番号はこのreceiveに付随しなければならない(MUST)。このフラグが0のとき、このストリームシーケンス番号についてこれ以上受けとる配送はないことを示す。 o ペイロードプロトコルID - 32ビットの符号なし整数であり、受信データのペイロードのプロトコルの型を示すために相手から送られる。この値はSCTPにとって不透明なデータとして渡される。 H) 状態 (Status) Format: STATUS(association id) -> status data この基本要素は以下の情報を含んだデータブロックを返すべきである: アソシエーションの接続状態 宛先トランスポートアドレスのリスト 宛先トランスポートアドレスの到達性の状態 現在の受信ウインドウサイズ 現在の輻輳ウインドウサイズ 確認応答されていないDATAチャンクの数 受信待ち(? pending receipt)になっているDATAチャンクの数 プライマリパス プライマリパスにおける最新のSRTT プライマリパスにおけるRTO その他の宛先アドレスにおけるSRTTとRTO、など 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル オプション属性: None. Stewart, et al. Standards Track [Page 107] RFC 2960 Stream Control Transmission Protocol October 2000 I) ハートビートの変更 (Change Heartbeat) Format: CHANGEHEARTBEAT(association id, destination transport address, new state [,interval]) -> result 指定した宛先トランスポートアドレスへのハートビートを有効にしたり無効にしたりするようローカル端末に指示する。 この操作を試みた結果が返されることだろう。 注意: 有効化されたときでも、宛先トランスポートアドレスがアイドルでない場合はハートビートは実行されない。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 宛先トランスポートアドレス - 相手端末のトランスポートアドレスのうちひとつを指定する o 新しい状態 - この宛先トランスポートアドレスに対するハートビートの新しい状態(有効かあるいは無効) オプション属性: o 間隔 - この属性が存在するとき、この基本要素がある宛先トランスポートアドレスに対してハートビートを有効化するものであれば、ハートビートの頻度を指定する。この値をこの宛先トランスポートアドレスのRTOに足して用いる。この値が存在する場合、全ての宛先に影響を与える。 J) ハートビート要求 (Request HeartBeat) Format: REQUESTHEARTBEAT(association id, destination transport address) -> result ローカル端末に、与えられたアソシエーションを構成する指定した宛先トランスポートアドレスに対してハートビートを実行するよう指示する。返ってくる結果はその宛先アドレスに対するHEARTBEATチャンクの送信が成功したかどうかを示すべきである。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 宛先トランスポートアドレス - このアソシエーションを構成するトランスポートアドレスのうちハートビートを発行すべき宛先アドレス Stewart, et al. Standards Track [Page 108] RFC 2960 Stream Control Transmission Protocol October 2000 K) SRTT報告の取得 (Get SRTT Report) Format: GETSRTTREPORT(association id, destination transport address) -> srtt result ローカルSCTPに、与えられたアソシエーションの指定された宛先トランスポートアドレスについての現在のSRTT計測値を報告するよう指示する。返ってくる結果は最も新しいSRTTをミリ秒単位で示した整数かもしれない。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 宛先トランスポートアドレス - このアソシエーションを構成するトランスポートアドレスのうちSRTT計測値を報告すべき宛先アドレス L) 障害とみなすしきい値の設定 (Set Failure Threshold) Format: SETFAILURETHRESHOLD(association id, destination transport address, failure threshold) -> result この基本要素はローカルのSCTPが指定した宛先アドレスについて到達性障害検知しきい値 'Path.Max.Retrans' を調整できるようにする。 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 宛先トランスポートアドレス - このアソシエーションを構成するトランスポートアドレスのうち障害検知しきい値を設定すべき宛先アドレス o 障害しきい値 - この宛先アドレスに対する 'Path.Max.Retrans' の新しい値 M) プロトコルパラメータの設定 (Set Protocol Parameters) Format: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) -> result この基本要素はローカルのSCTPをプロトコルパラメータの設定ができるようにする。 Stewart, et al. Standards Track [Page 109] RFC 2960 Stream Control Transmission Protocol October 2000 必須属性: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o プロトコルパラメータのリスト - SCTPユーザが設定したいプロトコルパラメータの名前と値(例えば, Association.Max.Retrans [14節参照]) オプション属性: o 宛先トランスポートアドレス - プロトコルパラメータのいくつかは宛先トランスポートアドレスごとに別々に設定されるかもしれない。 N) 未発送メッセージの受けとり (Receive unsent message) Format: RECEIVE_UNSENT(data retrieval id, buffer address, buffer size [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id]) o データ取得ID - 失敗通知の際に上位層にわたされる識別子 o バッファアドレス - 受けとるメッセージの保存のために上位層が指定するメモリ上の位置 o バッファサイズ - 受けとるデータの最大サイズをバイト単位で オプション属性: o ストリームID - データがどのストリームに送られようとしていたかを示す戻り値 o ストリームシーケンス番号 - メッセージにつけられていたストリームシーケンス番号を示す戻り値 o 部分フラグ - この戻り値が1に設定されていた場合、このメッセージは全体のメッセージの中で部分的に配送されるものである。このフラグが設定されているとき、ストリームIDとストリームシーケンス番号をこの受信につけなければならない(MUST)。このフラグが0に設定されているとき、このストリームシーケンス番号についてこれ以上の配送を受信することはないであろうということを示す。 o ペイロードのプロトコルID - 相手に送られた符号なし32ビット整数で、受信データのペイロードのプロトコルの型を示す Stewart, et al. Standards Track [Page 110] RFC 2960 Stream Control Transmission Protocol October 2000 O) 確認応答を受けていないメッセージの受けとり (Receive unacknowledged message) Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id]) o データ取得ID - 失敗通知の際に上位層にわたされる識別子 o バッファアドレス - 受けとるメッセージの保存のために上位層が指定するメモリ上の位置 o バッファサイズ - 受けとるデータの最大サイズをバイト単位で オプション属性: o ストリームID - データがどのストリームに送られようとしていたかを示す戻り値 o ストリームシーケンス番号 - メッセージにつけられていたストリームシーケンス番号を示す戻り値 o 部分フラグ - この戻り値が1に設定されていた場合、このメッセージは全体のメッセージの中で部分的に配送されるものである。このフラグが設定されているとき、ストリームIDとストリームシーケンス番号をこの受信につけなければならない(MUST)。このフラグが0に設定されているとき、このストリームシーケンス番号についてこれ以上の配送を受信することはないであろうということを示す。 o ペイロードのプロトコルID - 相手に送られた符号なし32ビット整数で、受信データのペイロードのプロトコルの型を示す P) SCTPインスタンスの破棄 (DESTROY) Format: DESTROY(local SCTP instance name) o ローカルのSCTPインスタンス名 - initialize基本要素においてアプリケーションに渡された値であり、どのSCTPインスタンスを破棄するかを示す。 10.2 SCTPからULPへ ここではオペレーティングシステムまたはアプリケーション環境がSCTPに上位層(ULP)プロセスに対し非同期的にシグナルを送れる手段を提供しているものと仮定する。SCTPがULPプロセスにシグナルを送る際、なんらかの情報がULPに渡される。 Stewart, et al. Standards Track [Page 111] RFC 2960 Stream Control Transmission Protocol October 2000 実装上の注意: ある場合においてはこの処理が別のソケットやエラーチャンネルを通して行われるかもしれない。 A) データ到着通知 (DATA ARRIVE notification) ユーザメッセージを問題なく受信し取得可能になった際にSCTPはこの通知をULPに対して実施するだろう。 以下の項目もオプションとしてこの通知とともに渡されるかもしれない: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o ストリームID - 受信したデータがどのストリームに属しているかを示す B) 送信失敗通知 (SEND FAILURE notification) メッセージが送信できなかった場合、SCTPはこの通知をULPに対して実施するだろう。 以下の項目もオプションとしてこの通知とともに渡されるかもしれない: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o データ取得ID - 送信されなかったデータと確認応答を受けなかったデータを取得するために使うID o 原因コード - 失敗した原因を示す。例：サイズ超過、メッセージ有効期限切れなど。 o コンテキスト - このメッセージに付随するオプションの情報 (10.1節D参照)。 C) ネットワーク状態変化通知 (NETWORK STATUS CHANGE notification) ある宛先トランスポートアドレスがinactiveとマークされたとき(例えばSCTPが障害を検知したとき)、またはactiveとマークされたとき(例えばSCTPが回復を検知したとき)、SCTPはULPに対してこの通知を実施するだろう。 以下の項目もこの通知とともに渡されるだろう: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 宛先トランスポートアドレス - これはこの変化によって影響を受ける相手端末の宛先トランスポートアドレスを示す o 新状態 - これは新しい状態を示す Stewart, et al. Standards Track [Page 112] RFC 2960 Stream Control Transmission Protocol October 2000 D) 通信可能通知 (COMMUNICATION UP notification) この通知はSCTPがユーザメッセージを送信または受信可能になったとき、あるいはある端末への途絶えていた通信が回復したときに用いる。 実装上の注意: ASSOCIATE基本要素がブロッキング関数呼び出しとして実装されている場合、ASSOCIATE基本要素そのものの結果としてアソシエーションのパラメータが返される。この場合、アソシエーションを初期化開始する側においては通信可能通知はオプションである。 以下の項目もこの通知とともに渡されるだろう: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 状態 - これはどの型のイベントが発生したかを示す o 宛先トランスポートアドレスのリスト - 相手のトランスポートアドレスの完全なセット o 送出ストリーム数 - ULPがこのアソシエーションに用いてよい最大のストリーム数 o 受入ストリーム数 - 相手端末がこのアソシエーションについて要求したストリーム数(これは「送出ストリーム数」と同じ数ではないかもしれない) E) 通信喪失通知 (COMMUNICATION LOST notification) SCTPがある端末への通信を完全に失ったとき(例えばハートビートによって検出)、あるいは端末が中止(abort)操作を実行したことを検出したとき、この通知を上位層(ULP)に対して実施するだろう。 以下の項目もこの通知とともに渡されるだろう: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o 状態 - これはどんな型のイベントが発生したかを示す。この状態は障害(failure)かまたは(OR)シャットダウンや中止の要求への対応として発生した通常の終了イベントを示すかもしれない。 以下の項目もこの通知とともに渡されるかもしれない: o データ取得ID - 送信されなかったデータと確認応答を受けなかったデータを取得するために使うID o 最終確認応答 - 相手端末によって最後に確認応答されたTSN Stewart, et al. Standards Track [Page 113] RFC 2960 Stream Control Transmission Protocol October 2000 o 最終送信 - この相手端末に対して最後に送られたTSN F) 通信エラー通知 (COMMUNICATION ERROR notification) SCTPが相手からERRORチャンクをうけとりそのULPに通知することに決めたとき、ULPに対してこの通知を実施できる。 以下の項目もこの通知とともに渡すことができる: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル o エラー情報 - これはエラーの型と、オプションとしてこのERRORチャンクで得られた追加情報を示す G) 再起動通知 (RESTART notification) SCTPが相手の再起動を検出したとき、ULPに対してこの通知を送るかもしれない。 以下の項目もこの通知とともに渡すことができる: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル H) シャットダウン完了通知 (SHUTDOWN COMPLETE notification) SCTPがシャットダウン処理(9.2節)を完了したとき、この通知が上位層に渡される。 以下の項目もこの通知とともに渡すことができる: o アソシエーションID - SCTPアソシエーションを取り扱うローカルのハンドル 11. セキュリティの考慮 11.1 セキュリティ目標 二つのネットワーク接続された端末の間で、例えば電話サービスの料金請求やシグナルのメッセージのような時間に関係するユーザメッセージを信頼性高く運ぶように設計されている共通のトランスポートプロトコルとして、SCTPは以下のセキュリティ目標を満たしたい。 - 高信頼で即時性のあるデータトランスポートサービスの可用性(availability) - SCTPによって運ばれるユーザ・ユーザ間の情報の完全性(integrity) Stewart, et al. Standards Track [Page 114] RFC 2960 Stream Control Transmission Protocol October 2000 11.2 潜在的な脅威に対するSCTPの対応 SCTPは多様なリスクのある状況で潜在的に使われるかもしれない。SCTPを動作させるシステム管理者にとって、特定の状況を解析し適切な対策を決定することが重要である。 SCTPを動作させるシステムの管理者は自身のサイトを安全にするためのガイダンスとして[RFC2196]を参照するべきである。 11.2.1 内部攻撃への対処 [RFC2196]の原理は内部者による情報窃盗や破壊行動のリスクを最小化するために適用できるはずである。これらの手続きはセキュリティポリシーの周知、物理層、ソフトウェア層およびネットワーク層でのアクセス制御、およびサービスの分離などである。 11.2.2 ネットワークにおけるデータ損傷に対する防御 下位層のトランスポートサービスが配送したデータグラムにおいて検出されないエラーのリスクが非常に大きいならば、追加の完全性防御が必要である。この追加の防御がアプリケーション層で提供される場合、SCTPヘッダは完全性への意図的攻撃に対して弱いままである。現状のSCTPがもっているパケットリプレイの検出メカニズムは通常操作に対しては十分だと考えられているが、操作環境に高度な技術をもった敵対者からの意図的な攻撃の重大なリスクがあるときには、SCTPを守るためにより強い防御が必要である。 ソフトウェアコードの再利用を促進し、車輪の再発明を避け、SCTPに余計な複雑さをもたらさないようにするため、強い完全性防御を必要とするが機密性は必要としないときにはIP認証ヘッダ[RFC2402]を用いるべきである(SHOULD)。 オペレーティングシステムのカーネルからAHやESPといったようなIPセキュリティサービスをアプリケーションが要求するために、広く実装されたBSDソケットAPI拡張がある。アプリケーションはAHの使用がふさわしいときはいつでも、AHを要求するためにこのようなAPIを用いることができる。 11.2.3 機密性の保護 ほとんどの場合、機密性がもれるリスクは信号のデータペイロードに対して適用され、SCTPやその下の層のプロトコルオーバーヘッドに対しては適用されない。これが真ならば、SCTPユーザデータの暗号化のみが考慮に入れられるかもしれない。補足的なチェックサムサービスと同様に、ユーザデータの暗号化はSCTPユーザアプリケーションが実施するかもしれない(MAY)。 Stewart, et al. Standards Track [Page 115] RFC 2960 Stream Control Transmission Protocol October 2000 別の手段として、ユーザアプリケーションは機密性や完全性を提供するためにIPカプセル化セキュリティペイロード(ESP)[RFC2406]の使用を要請するために、実装固有のAPIを用いるかもしれない(MAY)。 特にモバイルユーザにとっては、機密性の要求にはIPアドレスとポートの隠蔽を含むかもしれない。この場合にはアプリケーションレベルの機密性ではなくESPを使うべきである(SHOULD)。SCTPトラフィックの機密性保護のためにESPを用いる場合、暗号化完全性保護を含む暗号化変換を用いなければならない(MUST)。というのは機密性への脅威がある場合は完全性への強い脅威もまたあるだろうからである。 ESPを使う場合はいつも、アプリケーションレベルの暗号化は一般的に必要ではない。 どこで機密性が提供されるかにかかわらず、ISAKMP [RFC2408]およびインターネット鍵交換(IKE) [RFC2409]を鍵交換のために使うべきである(SHOULD)。 管理者はインターネットプロトコル層およびその上で利用可能なセキュリティサービスについてさらなる情報を得るためには[RFC2401]を参照すべきである。 11.2.4 ブラインドサービス不能攻撃の防御 ブラインド攻撃とは、攻撃者がターゲットとなるSCTPノードへの流入データフロー、および流出データフローの内容を途中で得ることができない、またはみることができない攻撃である。ブラインドサービス不能攻撃はフラッディング、マスカレード、または不適当なサービス独占という形をとるだろう。 11.2.4.1 フラッディング フラッディングの目的はリソースの浪費によるターゲットシステム のサービス遮断や不正なふるまいをひきおこすこと、正当なトラン ザクションに干渉すること、およびバッファに関連するソフトウェ アのバグにつけこむことである。フラッディングはSCTPノード、あ るいは中間にあるIPアクセスリンクまたはインターネットにおける リソース(資源)に向けて行われるだろう。後者のエンティティがター ゲットになる場合、フラッディングそのものがネットワークサービ スの消失を意味し、これにはファイアウォールの欠陥を潜在的に含 む。 一般的にフラッディングへの対策は機器の設計レベルから始まり、そこでは以下のような尺度が考えられる: - サービス要求が正当なものであるかを決める前における限られたリソースのわりあてを避けること Stewart, et al. Standards Track [Page 116] RFC 2960 Stream Control Transmission Protocol October 2000 - 新しい仕事を受け入れることより実行中の処理を終了させることを優先すること - 待ち行列に入っているサービス要求のうち重複または期限切れのものを同定し削除すること - ユニキャストでないアドレスに送られた予想外のパケットに応答しないこと ネットワーク機器はトラフィックに疑わしい増加が発生した場合、警告やログを生成できるべきである。ログはネットワーク、またはSCTPシステムの管理者が防御対策をとるのを手助けできるような、例えば流入リンクの識別や用いられている送信元アドレスといった情報を提供するべきである。不正利用の明らかなパターンがみえる場合、こうした警告に対応して管理者が対策を講じるような手続きがとられるべきである。 SCTPの設計は、特に4ウェイスタートアップハンドシェイクの使用によって、ハンドシェイクが完了するまで応答側のSCTPノードにおける資源の確保を延期するためのクッキーの使用によって、そして確率したアソシエーションのフローの中に異質のパケットを挿入されることを防ぐための認証タグの使用によって、フラッディング攻撃に対して抵抗力がある。 IP認証ヘッダ(訳注: AH)およびカプセル化セキュリティペイロード(訳注: ESP)はある種のサービス不能攻撃のリスクを低減するのに役立つかもしれない。 INITチャンクのホスト名機能はターゲットのDNSサーバにフラッディングをしかけるのに使われるかもしれない。あるドメインの複数のホストにINITを送りつけることによって、受けとったINITチャンクの中のホスト名をIPアドレスとして解決するためのDNS問いあわせの大きなバックログができてしまうだろう。さらに、攻撃者はランダムなホストにターゲットのホスト名を含む膨大な数のINITを送信するといった第三者による間接攻撃の中でホスト名機能を使うかもしれない。この攻撃はDNS資源への負荷に加え、ターゲットに対して大量のINIT ACKが送られるという結果となる。このタイプの攻撃への一つの防御策は、DNSから受けとったIPアドレスがオリジナルのINITの送信元IPアドレスを含んでいるかを検証することである。DNSから受けとったIPアドレスのリストにINITの送信元アドレスが含まれていなかった場合、端末はINITを静かに(silently)破棄してよい(MAY)。この最後のオプションはDNSに対する攻撃は防げないだろう。 Stewart, et al. Standards Track [Page 117] RFC 2960 Stream Control Transmission Protocol October 2000 11.2.4.2 ブラインドマスカレード マスカレードはいくつかの方法でサービスを不能にするために使われる可能性がある。 - 限定されたアクセス権をもつターゲットSCTPノードの資源を擬装したノードが独占する方法。例えば、ターゲットノードはポリシーにより擬装されたSCTPノードに対して一つのSCTPアソシエーションしか許可しないかもしれない。マスカレード攻撃者は擬装したノードが必要な時にアソシエーションを確立できないように、擬装したノードから来たと偽ってアソシエーションの確立を試みるかもしれない。 - 故意に擬装がみつかるようにする方法。これにより擬装対策が起動され、ターゲットSCTPノードから擬装されたノードが閉めだされてしまう。 - 確立されたアソシエーションを、SHUTDOWNリクエストのような異質な内容を挿入することにより邪魔する方法。 SCTPは4ウェイスタートアップハンドシェイクの使用により、IPスプーフィングを利用したブラインドマスカレード攻撃のリスクを軽減している。介在型(Man-in-the-middle)マスカレード攻撃については以下の11.3節で議論する。コネクション確立時の最初の情報交換がメモリを消費しないので、ブラインドマスカレード攻撃によってはロックアウトメカニズムは起動されない。さらに、状態クッキーを含むINIT ACKが受信したINITの送信元のIPアドレスに対して送り返される。このように、攻撃者は状態クッキーを含んだINIT ACKを受けとれないだろう。SCTPは認証タグの使用により、確立されたアソシエーションのフローに異質なパケットを挿入されることを防いでいる。 受信したINITリクエストと予想外のINIT ACKのような異常をログに記録しておくのも、悪意をもった活動のパターンを検出するための一つの方法かもしれない。しかしながら、このようなログ記録の潜在的な有用性がSCTPのスタートアップ処理を増加させることよりも、すなわちSCTPノードをフラッディング攻撃に対して弱くしてしまうことよりも重視される環境でなければならない。ログ記録は、ルーチンワークとしてログを読み解析する運用手順の確立なくしては無意味である。 11.2.4.3 サービスの不適切な占有 この項目に分類される攻撃は攻撃者がオープンかつ正規に行うものである。これはターゲットとなるSCTPノードのユーザ、または攻撃者とターゲットノードの間の共有資源のユーザに向けられた攻撃である。考えられる攻撃は、攻撃者のノードとターゲットの間に数多くのアソシエーションを開く方法や、正規に確立されたアソシエーションで大量の情報を転送する方法などがある。 Stewart, et al. Standards Track [Page 118] RFC 2960 Stream Control Transmission Protocol October 2000 接続するSCTPノードごとのアソシエーションの数には、ポリシーによる制限を課すべきである。SCTPユーザアプリケーションは、与えられたアソシエーションの中で正規でない、あるいは無意味な("no-op")メッセージの大量送信を検出し、ローカルポリシーに基いてこのアソシエーションをログに記録するかあるいは結果的に終了させることができるべきである。 11.3 詐取と否認に対する防御 詐取(fraud)の目的は認証なしに、具体的には代金を支払うことな くサービス提供をうけることである。この目的を達するために、攻 撃者はターゲットSCTPノードのSCTPユーザアプリケーションに、不 正な請求データを受けいれるか請求データの収集に失敗しているに もかかわらず、欲しいサービスを提供させるようにしむけなければ ならない。否認(repudiation)も関連する問題である。というのは 詐取の故意の行動として起こるからであり、あるいは単に否認者が 受けたサービスに対して不適切な記録を保持するからである(?)。 考えられる詐取攻撃としては、クレジットカード番号のような認証情報の横取りおよび不正利用、ブラインドマスカレードやリプレイ、およびターゲットとなるSCTPアソシエーションを流れるパケットをリアルタイムに変更する介在型(man-in-the-middle)攻撃がある。 横取り攻撃への対策としては、上の11.2.3節で議論した機密性保護手段がある。 SCTPが4ウェイスタートアップハンドシェイクや認証タグ導入の結果としてブラインドマスカレード攻撃に対して抵抗力があるということを、11.2.4.2節で述べた。認証タグとTSNの組み合わせは、既存のアソシエーションに対して行われるブラインドリプレイ攻撃への防御策となる。 しかしながら、SCTPは攻撃者があるアソシエーションで送受されるパケットを横取りして変更できるような介在型(man-in-the-middle)攻撃に対する防御の機能はもたない。例えば、INIT ACKは中間にいる敵が既存のSCTPアソシエーションをハイジャックするのに十分な情報をワイヤ上に送ってしまう。このような攻撃が存在する深刻な可能性がある場合、または否認の可能性が課題となっている場合は、渡されるSCTPパケットの完全性と認証の両方を保証するために、IPSEC AHサービスの使用が推奨される。 SCTPはまた、SCTPノードからのまたはそのノードを越えての攻撃に対する防御手段は提供しておらず、既存のアソシエーションのコンテキストの中で起こす攻撃についても防御手段は提供していない。このような攻撃の防御は11.2.1節で議論されているようにホストサイトの適切なセキュリティポリシーによってカバーされるべきである。 Stewart, et al. Standards Track [Page 119] RFC 2960 Stream Control Transmission Protocol October 2000 12. 推奨されるTransmission Control Block (TCB)のパラメータ この節は実装がTCBの中に含むべきと推奨されるパラメータのセットについて詳述する。本節は説明用の実例にすぎず、実装の必須事項、あるいはSCTP TCBの中の全てのパラメータを網羅したリストなどとは考えないでいただきたい。各実装は最適化のために独自の追加のパラメータを必要とするかもしれない。 12.1 SCTPインスタンスに必要なパラメータ Associations: 現在のアソシエーションとそれぞれのアソシエーションについてノデータ消費者との対応のリスト。これはハッシュ表か、あるいは実装依存のデータ構造の形になるかもしれない。データ消費者とは、SCTPの実装によるがファイルディスクリプタ、名前つきパイプのポインタ、または表へのポインタなどのプロセスを識別できる情報である。 Secret Key: この端末がMACを計算するための秘密鍵。これは十分な長さで暗号学的な品質を持ったランダムな数であるべきである(SHOULD)。[RFC1750]の議論が鍵の選択に役立つだろう。 Address List: このインスタンスが結びつけられているIPアドレスのリスト。この情報はINITとINIT ACKチャンクの中に入れて相手に渡される。 SCTP Port: 端末が結びつけられている端末のローカルのSCTPポート番号。 12.2 アソシエーションごとに必要なパラメータ (すなわち TCB) Peer : 全ての送出パケットに含まれるタグ値であり、 Verification: INITやINIT ACKチャンクによって受信もする。 Tag : My : 全ての流入パケットに含まれていることを期待するタグであり、 Verification: またINITあるいはINIT ACKチャンクで送られるタグ Tag : State : アソシエーションがどの状態にあるかを示す状態変数 : すなわち状態とは COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, : SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, : SHUTDOWN-ACK-SENT. 注意: アソシエーションが"CLOSED"の場合はそのTCBも削除されるべき(SHOULD)なので"CLOSED"状態は示されていない。 Stewart, et al. Standards Track [Page 120] RFC 2960 Stream Control Transmission Protocol October 2000 Peer : 相手が結びつけられているSCTPトランスポートアドレスの Transport : リスト。この情報はINITまたはINIT ACKから導かれ、流入する Address : パケットを与えられたアソシエーションに対応づけるために List : 使われる。通常この情報はTCBのすばやい検索とアクセスの : ためにハッシュされるか鍵がつけられる(keyed?)。 Primary : これは相手端末の現在のプライマリ宛先トランスポート Path : アドレスである。またこの端末の送信元トランスポート : アドレスも一つ指定するかもしれない。 Overall : アソシエーション全体のエラーカウント。 Error Count : Overall : このアソシエーションを落とすために達すべき全体の Error : エラーカウントのしきい値。 Threshold : Peer Rwnd : 相手のrwndの現在の計算値。 Next TSN : 新しいDATAチャンクに割当てられる次のTSN番号。 : これはINITまたはINIT ACKチャンクに入れて相手に送られ、 : DATAチャンクにTSNが割当てられるごとに1増える : (通常は送信の直前またはパケット分割時)。 : Last Rcvd : これは順序通りに受けとった最後のTSNである。この値は最初、 TSN : INITまたはINIT ACKチャンクにより受信した相手の初期TSNから : 1を引いて設定する。 : Mapping : 順序通りでないTSNのどれを受けとったかを(Last Rcvd TSN Array : からの相対位置で)示すビットまたはバイト列。ギャップが : 存在しない場合、すなわち順序通りでない受信パケットがない : 場合、この列は全て0に設定されるだろう。このデータ構造は : 循環バッファまたはビット列の形をとるかもしれない。 : Ack State : このフラグは次に受信したパケットにSACKで返答するべきか : どうかを示す。この値の初期値は0である。パケットを一つ : 受けとると1増やす。この値が2以上になると、SACKが送信され : この値は0に再設定される。 : 注意： これは順序通りでない受信DATAチャンクがない場合 : にのみ用いられる。DATAチャンクが順序通りでないときは : SACKの送信に遅延を設けない(6節参照)。 : Stewart, et al. Standards Track [Page 121] RFC 2960 Stream Control Transmission Protocol October 2000 Inbound : 流入ストリームを管理するための配列構造。通常は次に Streams : 期待されるシーケンス番号とおそらくはストリーム番号を : 含む。 Outbound : 出力ストリームを管理するための配列構造。通常はその Streams : ストリームに送られる次のシーケンス番号を含んでいる。 : Reasm Queue : 再構成のためのキュー。 Local : このアソシエーションに結びつけられているローカルの Transport : IPアドレスのリスト Address : List : Association : 相手の全てのトランスポートアドレスの中で、観測された PMTU : 最小のPMTU(経路MTU)。 12.3 トランスポートアドレスごとのデータ INITまたはINIT ACKチャンクから導かれた相手のアドレスリストに含まれるそれぞれの宛先トランスポートアドレスに対して、以下のような多くのデータ要素を管理する必要がある: Error count : この宛先についての現在のエラーカウント(回数)。 Error : この宛先についての現在のエラーしきい値、すなわち Threshold : エラーカウントがこの値に達した場合にこの宛先を : ダウンとマークする。 cwnd : 現在の輻輳ウインドウ。 ssthresh : 現在のssthresh値。 RTO : 現在の再送タイムアウト値。 SRTT : 現在の平滑化往復時間(RTT) RTTVAR : 現在のRTT分散 partial : 輻輳回避モードにおけるcwndの増加を追跡する手段 bytes acked : (6.2.2節参照) state : この宛先の現在の状態、すなわち DOWN, UP, : ALLOW-HB, NO-HEARTBEAT, など。 PMTU : 現在わかっている経路MTU Stewart, et al. Standards Track [Page 122] RFC 2960 Stream Control Transmission Protocol October 2000 Per : 宛先ごとに用いられるタイマ Destination : Timer : RTO-Pending : このアドレスに送られたDATAチャンクの一つが現在RTTの計算に使われていることを示すために使うフラグ。このフラグが0の場合、この宛先に送られる次のDATAチャンクはRTTの計算に使われるべきであり、このフラグを1に設定するべきである。RTTの計算が完了した(すなわち、DATAチャンクがSACKされた)ときはいつでも、このフラグをクリアする。 last-time : この宛先に最後に送られた時刻。これはHEARTBEATが必要 used : かどうかを決めるのに使うことができる。 12.4 必要な一般パラメータ Out Queue : 送出DATAチャンクのためのキュー。 In Queue : 流入DATAチャンクのためのキュー。 13. IANAに関する考慮 このプロトコルはインターネットにおいて「よく知られた(well known)」サーバを使用するために、TCPのようにポートの予約を必要とするだろう。現在のすべてのTCPポートは自動的にSCTPのポートアドレス空間においても予約されるだろう。新しい要求はTCPについて行われているIANAの現在のメカニズムに従うべきである。 このプロトコルはまた、3つの方法によってIANAを通して拡張されるかもしれない。 -- 追加のチャンク型の定義によって、 -- 追加のパラメータ型の定義によって、または -- ERRORチャンクの中の追加の原因コードの定義によって。 SCTPを用いる特定の上位層が独自ポートを使いたい場合、その上位層がポートわりあてを受けるため、IANAに登録する役割を負うべきである(訳注: SCTPは関知しない)。 13.1 IETFの定義するチャンクの拡張 新しいチャンク型の定義と使用法はSCTP全体にかかわるものである。したがって、新しいチャンク型はIANAによって[RFC2434]で定義されるIETF合意(Consensus)を通して割り当てられる。 新しいチャンクコード型についての文書記述は以下の情報を含まなければならない: Stewart, et al. Standards Track [Page 123] RFC 2960 Stream Control Transmission Protocol October 2000 a) 新しいチャンク型のための長い名前と短い名前。 b) チャンクの構造についての詳細な記述。これは3.2節で定義されている基本構造に沿っていなければならない(MUST)。 c) 存在するならチャンクフラグも含めて、チャンク内のそれぞれのフィールドの詳細な定義と意図する使われ方についての記述。 d) プロトコル動作における新しいチャンク型の使われ方についての詳しい手続き的記述。 最後のチャンク型(255)は必要ならば使えるよう将来の拡張のために予約されている。 13.2 IETFが定義するチャンクパラメータの拡張 新しいチャンクパラメータ型コードのわりあては[RFC2434]で定義されているようにIETFConsensusアクションを通して行われる。チャンクパラメータについての説明書きは以下の情報を含まなければならない(MUST): a) パラメータ型の名前 b) パラメータフィールドの構造についての詳細な記述。この構造は3.2.1節で記述されている一般的な「型−長さ−値」(type-length-value)フォーマットに従わなければならない(MUST)。 c) パラメータ値の成分それぞれについての詳細な定義 d) このパラメータ型の想定する使い方についての詳細な記述、および同じチャンク内にこのパラメータ型が複数あらわれるかどうかとあらわれるならどのような状況においてかについての示唆。 13.3 IETFが定義する追加のエラー原因 追加の原因コードは[RFC2434]で定義されたSpecification Requiredアクションを通して11から65535の範囲でわりあてられるかもしれない。提出される文書は以下の情報を含んでいなければならない: a) エラー条件の名前 b) SCTP端末がこの原因コードとともにERROR(またはABORT)を発行するべき状況条件についての詳細な記述 c) この原因コードを含むERROR(またはABORT)チャンクを受けとったSCTP端末に期待される動作 Stewart, et al. Standards Track [Page 124] RFC 2960 Stream Control Transmission Protocol October 2000 d) この原因コードに付随するデータフィールドの構造と内容についての詳細な記述 原因コードパラメータの最初の1ワード(32ビット)は3.3.10節で示されるフォーマットに従わなければならない(MUST)。すなわち: -- 最初の2バイトに原因コード値を含む -- 最後の2バイトに原因パラメータの長さを含む 13.4 ペイロードプロトコル識別子 DATAチャンクにおいてペイロードプロトコル識別子が指定されていないことを示すためにSCTPが予約している0という値を除いて、SCTPはペイロードプロトコル識別子を標準化したり検証したりする責は負わないだろう。SCTPは上位層から識別子を単に受けとり、対応するペイロードデータとともに運ぶだけである。 上位層、すなわちSCTPユーザは希望するならば、特定のプロトコル識別子をIANAとともに標準化するべきである(SHOULD)。ある特定のペイロードプロトコル識別子の使い方はSCTPの規格範囲外である。 14. 推奨されるSCTPプロトコルパラメータ値 以下のプロトコルパラメータが推奨される(RECOMMENDED): RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (宛先アドレスあたり) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds 実装上の注意: SCTPの実装は上位層がこれらのプロトコルパラメータのうちいくつかを設定可能とするかもしれない(10節参照)。 注意: RTO.Minは上記で推奨された値にするべきである(SHOULD)。 Stewart, et al. Standards Track [Page 125] RFC 2960 Stream Control Transmission Protocol October 2000 15. Acknowledgements The authors wish to thank Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll, and many others for their invaluable comments. 16. Authors' Addresses Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA Phone: +1-815-477-2127 EMail: rrs@cisco.com Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, #2309 Arlington Heights, IL 60004 USA Phone: +1-847-632-3028 EMail: qxie1@email.mot.com Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA Phone: +1-703-484-3323 EMail: kmorneau@cisco.com Stewart, et al. Standards Track [Page 126] RFC 2960 Stream Control Transmission Protocol October 2000 Chip Sharp Cisco Systems Inc. 7025 Kit Creek Road Research Triangle Park, NC 27709 USA Phone: +1-919-392-3121 EMail: chsharp@cisco.com Hanns Juergen Schwarzbauer SIEMENS AG Hofmannstr. 51 81359 Munich Germany Phone: +49-89-722-24236 EMail: HannsJuergen.Schwarzbauer@icn.siemens.de Tom Taylor Nortel Networks 1852 Lorraine Ave. Ottawa, Ontario Canada K1H 6Z8 Phone: +1-613-736-0961 EMail: taylor@nortelnetworks.com Ian Rytina Ericsson Australia 37/360 Elizabeth Street Melbourne, Victoria 3000 Australia Phone: +61-3-9301-6164 EMail: ian.rytina@ericsson.com Stewart, et al. Standards Track [Page 127] RFC 2960 Stream Control Transmission Protocol October 2000 Malleswar Kalla Telcordia Technologies 3 Corporate Place PYA-2J-341 Piscataway, NJ 08854 USA Phone: +1-732-699-3728 EMail: mkalla@telcordia.com Lixia Zhang UCLA Computer Science Department 4531G Boelter Hall Los Angeles, CA 90095-1596 USA Phone: +1-310-825-2695 EMail: lixia@cs.ucla.edu Vern Paxson ACIRI 1947 Center St., Suite 600, Berkeley, CA 94704-1198 USA Phone: +1-510-666-2882 EMail: vern@aciri.org 17. References [RFC768] Postel, J. (ed.), "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1123] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. Stewart, et al. Standards Track [Page 128] RFC 2960 Stream Control Transmission Protocol October 2000 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. 18. Bibliography [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999. [FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21. [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994. Stewart, et al. Standards Track [Page 129] RFC 2960 Stream Control Transmission Protocol October 2000 [RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996. [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, March 1997. [RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. [SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999. Stewart, et al. Standards Track [Page 130] RFC 2960 Stream Control Transmission Protocol October 2000 Appendix A: Explicit Congestion Notification ECN (Ramakrishnan, K., Floyd, S., "Explicit Congestion Notification", RFC 2481, January 1999) describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss. This is an optional feature that an implementation MAY choose to add to SCTP. This appendix details the minor differences implementers will need to be aware of if they choose to implement this feature. In general RFC 2481 should be followed with the following exceptions. Negotiation: RFC2481 details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection. The sender of the SYN sets two bits in the TCP flags, and the sender of the SYN-ACK sets only 1 bit. The reasoning behind this is to assure both sides are truly ECN capable. For SCTP this is not necessary. To indicate that an endpoint is ECN capable an endpoint SHOULD add to the INIT and or INIT ACK chunk the TLV reserved for ECN. This TLV contains no parameters, and thus has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 32768 | Parameter Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ECN-Echo: RFC 2481 details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network. For SCTP this same indication is made by including the ECNE chunk. This chunk contains one data element, i.e. the lowest TSN associated with the IP datagram marked with the CE bit, and looks as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=12 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The ECNE is considered a Control chunk. Stewart, et al. Standards Track [Page 131] RFC 2960 Stream Control Transmission Protocol October 2000 CWR: RFC 2481 details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window. This is termed the CWR bit. For SCTP the same indication is made by including the CWR chunk. This chunk contains one data element, i.e. the TSN number that was sent in the ECNE chunk. This element represents the lowest TSN number in the datagram that was originally marked with the CE bit. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=13 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The CWR is considered a Control chunk. Appendix B Alder 32 bit checksum calculation The Adler-32 checksum calculation given in this appendix is copied from [RFC1950]. Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in network byte order. The following C code computes the Adler-32 checksum of a data buffer. It is written for clarity, not for speed. The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints: Stewart, et al. Standards Track [Page 132] RFC 2960 Stream Control Transmission Protocol October 2000 & Bitwise AND operator. >> Bitwise right shift operator. When applied to an unsigned quantity, as here, right shift inserts zero bit(s) at the left. << Bitwise left shift operator. Left shift inserts zero bit(s) at the right. ++ "n++" increments the variable n. % modulo operator: a % b is the remainder of a divided by b. #define BASE 65521 /* largest prime smaller than 65536 */ /* Update a running Adler-32 checksum with the bytes buf[0..len-1] and return the updated checksum. The Adler-32 checksum should be initialized to 1. Usage example: unsigned long adler = 1L; while (read_buffer(buffer, length) != EOF) { adler = update_adler32(adler, buffer, length); } if (adler != original_adler) error(); */ unsigned long update_adler32(unsigned long adler, unsigned char *buf, int len) { unsigned long s1 = adler & 0xffff; unsigned long s2 = (adler >> 16) & 0xffff; int n; for (n = 0; n < len; n++) { s1 = (s1 + buf[n]) % BASE; s2 = (s2 + s1) % BASE; } return (s2 << 16) + s1; } /* Return the adler32 of the bytes buf[0..len-1] */ unsigned long adler32(unsigned char *buf, int len) { return update_adler32(1L, buf, len); } Stewart, et al. Standards Track [Page 133] RFC 2960 Stream Control Transmission Protocol October 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). 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. 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. Stewart, et al. Standards Track [Page 134]