2.11. SCTPヘッダ

この節は SCTP ヘッダの非常に手短な紹介だ。SCTP には沢山のタイプのパケットがあるのだが、RFC に示されているものはできるだけすべて網羅するようにし、それらの中で各ヘッダの果たす役割を説明してみようと思う。まずは SCTP パケット全般に共通するヘッダについての概論から始めることにしよう。

2.11.1. SCTP共通ヘッダフォーマット

これが SCTP パケット全般のレイアウトだ。基本としてまず最初にくるのは、パケット全体についての情報と送信元および宛先のポートなどを伝える一般ヘッダ (common header) だ。一般ヘッダに関しては以降で詳しく述べる。

一般ヘッダの後ろには任意の数の チャンク がくる。 チャンク の最大数は MTU の許す範囲内だ。 チャンク はこのように「束」にできるわけだが、 INIT, INIT ACK, SHUTDOWN COMPLETE は束には入れられない。 DATA チャンクは、パケットの MTU 内に収めるために分割することもできる。

2.11.2. SCTPの一般ヘッダと共通ヘッダ

すべての SCTP パケットは上記に見る一般ヘッダを備えている。ヘッダには 4つのフィールドがあり、 SCTP パケット毎にそれぞれの値がセットされる。

送信元ポート (Source port) - ビット 0-15。そのパケットの送り元となったソースポートを伝える。 TCPUDP のソースポートと同じだ。

宛先ポート (Destination port) - ビット 16-31。パケットの宛先ポート、つまりパケットの行こうとしているポート。TCPUDP の宛先ポートと同じだ。

検証タグ (Verification Tag) - ビット 32-63。検証タグは、そのパケットがどの相手から送られてきたのかを検証するために使われる。この値は、アソシエーションのイニシャライズの段階で対向のピアから Initiate タグ で受け取った値がずっと使われる。ただし以下のような少数の例外もある:

チェックサム (Checksum) - ビット 64-95。Adler-32 アルゴリズムによって計算した、その SCTP パケット全体のチェックサム。アルゴリズムについては RFC 2960 - Stream Control Transmission Protocol の appendix B を参照されたし。

すべての SCTP チャンクは、上図に示した決まったレイアウトに則っている。ただし、これらはヘッダそのものではなく、「チャンク はおしなべてこういうフォーマットになっている」という定型を示したものに過ぎない。

タイプ (Type) - ビット 0-7。そのパケットの チャンクタイプを指定する。例えば INIT チャンクなのか SHUTDOWN チャンクなのかそれとも... といった具合。チャンク には、下表に示したようにそれぞれ決まったナンバーが割り当てられている。すべてのチャンク タイプをリストアップしたのが次の表だ:

Table 2-1. SCTPタイプ

チャンクナンバーチャンク名
0ペイロードデータ (Payload Data) (DATA)
1イニシエーション (Initiation) (INIT)
2イニシエーション承認 (Initiation Acknowledgement) (INIT ACK)
3選択的承認 (Selective Acknowledgement) (SACK)
4ハートビート要求 (Heartbeat Request) (HEARTBEAT)
5ハートビート承認 (Heartbeat Acknowledgement) (HEARTBEAT ACK)
6中止 (Abort) (ABORT)
7シャットダウン (Shutdown) (SHUTDOWN)
8シャットダウン承認 (Shutdown Acknowledgement) (SHUTDOWN ACK)
9オペレーションエラー (Operation Error) (ERROR)
10ステートクッキー (State Cookie) (COOKIE ECHO)
11クッキー承認 (Cookie Acknowledgement) (COOKIE ACK)
12明示的輻輳通知エコー用の予約域 (Reserved for Explicit Congestion Notification Echo) (ECNE)
13輻輳ウィンドウ縮小用の予約域 (Reserved for Congestion Window Reduced) (CWR)
14シャットダウン完了 (Shutdown Complete) (SHUTDOWN COMPLETE)
15-62IETFによる予約域 (Reserved for IETF)
63IETFによって定義済みのチャンク拡張 (IETF-defined chunk extensions)
64-126IETFによる予約域 (reserved to IETF)
127IETFによって定義済みのチャンク拡張 (IETF-defined chunk extensions)
128-190IETFによる予約域 (reserved to IETF)
191IETFによって定義済みのチャンク拡張 (IETF-defined chunk extensions)
192-254IETFによる予約域 (reserved to IETF)
255IETFによって定義済みのチャンク拡張 (IETF-defined chunk extensions)

チャンクフラグ (Chunk Flags) - ビット 8-15。 チャンクフラグ はほとんど使われることはないが、他の用途に明け渡す必要が生じない限り、将来の活用に備えて確保されている。フラグチャンク 毎に特有のフラグやビットで、対向のピアに必要な情報を格納する。現時点での規格によれば、これらのフラグDATA, ABORT, SHUTDOWN COMPLETE パケットでのみ使うことになっている。ただし将来変更になる可能性もある。

Important

RFC を読んでいると、前にも踏んだはずの危険な轍がそこここに転がっていることに気づかされる。 RFC 2960 - Stream Control Transmission Protocol の文書もそのひとつ。チャンクフラグ は必ず 0 でなくてはならないが、特に用途のない限りは無視される、という規定だ。いたるところに見られるこのような規定は、将来、問題になる危険性をはらんでいる。これには目を光らせておかなくてはならない。というのも、こういったフィールド規定は将来変更となる可能性があり、その時には、道理のいかない理由であなたのファイヤーウォールが爆弾を抱えることになってしまうのだ。同じことは、過去に IP ヘッダECN が取り入れられた時にも起こっている。詳しくはこのチャプターの IPヘッダ セクションを読んでいただきたい。

チャンク長 (Chunk Length) - ビット 16-31。バイト単位で数えたチャンク の長さ。チャンクタイプ, チャンクフラグ, チャンク長, チャンク値 を含めたヘッダすべてを含めた長さだ。チャンク値 がひとつもない場合の長さは 4 (バイト) となる。

チャンク値 (Chunk Value) - ビット 32-n。ここはチャンク 毎に固有で、チャンクタイプ に応じた追加のフラグ およびデータを格納できる。空の場合もあり、その時のチャンク長 は 4 に設定される。

2.11.3. SCTP ABORTチャンク

ABORT チャンクは、当チャプターの シャットダウンと中止 で述べたようにアソシエーションを断ち切る時に使用する。 ABORT は、データやヘッダの異常など、アソシエーションの中で回復不能の問題が発生した際に発行される。

タイプ (Type) - ビット 0-7。このチャンクタイプ では常に 6。

予約域 (Reserved) - ビット 8-14。将来のチャンクフラグ 拡張用に予約されているが、投稿執筆時点ではまだ使われていない。チャンクフラグ フィールドについては SCTPの一般ヘッダと共通ヘッダ を参照のこと。

T-bit - ビット 15。このビットが 0 だとすれば、このパケットには送信元で TCB が関連付け (associated) されていて、そのパケットがそれを無効化した (destroyed) ということを示している。送信元で TCB を使っていない時には、T-bit は 1 にすることになっている。

全長 (Length) - ビット 16-31。エラーの原因も含めたチャンク の長さのバイト表記。

2.11.4. SCTP COOKIE ACKチャンク

COOKIE ACK チャンクはコネクションのイニシャライズの際にのみ使用され、コネクション中の他の場面で使われることはない。必ず DATA および SACK チャンクよりも前に送らなければならないが、そうした中の最初のパケットをこれに兼用してもよいことになっている。

タイプ (Type) - ビット 0-7。このタイプでは常に 11。

チャンクフラグ (Chunk flags) - ビット 8-15。今のところ未使用。RFC 2960 - Stream Control Transmission Protocol によれば常に 0 にすることになっている。こういった旨を記した RFC には常に目を光らせておかなければならない。というのは、将来変更される可能性があり、それによってあなたのファイヤーウォールにヒビが入ることになるからだ。 IPECN で起きたことの二の舞である。詳しくは SCTPの一般ヘッダと共通ヘッダ のセクションを参照していただきたい。

全長 (Length) - ビット 16-31。このタイプのチャンク では常に 4 (バイト)。

2.11.5. SCTP COOKIE ECHOチャンク

COOKIE ECHO チャンクが使われるのは SCTP コネクションのイニシャライズの過程で、接続の申し出を受けた側が INIT ACK パケットの State クッキー フィールドで送ってきたクッキーに対して、接続を申し出た側が回答する時だ。 COOKIE ECHO チャンクは DATA チャンクを乗せたパケット内で一緒に送ってもよいが、その場合には DATA チャンクよりも前に置かなければならない。

タイプ (Type) - ビット 0-7。このチャンクでは常に 10。

チャンクフラグ (Chunk flags) - ビット 8-15。今日ではまだ使用されていない。 RFC はこのフラグを必ず 0 にせよとしているが、このことは SCTPの一般ヘッダと共通ヘッダ のセクション (特にチャンクフラグの説明部分) で述べたようなトラブルを引き起こす可能性がある。

全長 (Length) - ビット 16-31。チャンク の長さ。タイプ, チャンクフラグ, 全長 および クッキーフィールド を含んだ長さで、バイト表記。

クッキー (Cookie) - ビット 32-n。このフィールドは、これに先立つ INIT ACK チャンクで送信されたクッキーと同じものを持つ。返答をよこした側の送ってきたクッキーと正確に一致していないと、コネクションはオープンできない。 RFC 2960 - Stream Control Transmission Protocol は、互換性を損なわないためにクッキーは可能な限り小さくせよと述べているが、曖昧で、多くを語ろうとしない。

2.11.6. SCTP DATAチャンク

DATA チャンクはストリームの中で実際のデータを送るためのもので、見方によってはかなり込み入っているように思えるかもしれないが、実際のところは TCP ヘッダの一般フォーマットとどっこいどっこいだ。 ひとつのパケットの中に同居していたとしても、各 DATA チャンクは別のストリームに属するものかもしれない。なぜなら、 SCTP はひとつのコネクションで複数のストリームを扱うことができるからだ。

タイプ (Type) - ビット 0-7。DATA チャンクでは常に 0 に設定される。

予約域 (Reserved) - ビット 8-12。今日では未使用。将来の変更のために確保されている。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

U-bit - ビット 13。 U-bit は、その DATA チャンクが順不同で構わないものかどうかを表す。順不同であれば、ストリームシーケンスナンバー は無視する決まりになっており、 DATA を並べ直そう (re-order) とはせずにいち早く上位レイヤーに渡さなくてはならない。

B-bit - ビット 14。 B-bit は、フラグメントされた DATA チャンクの存在を示す。このビットが正で E (ending) ビットが正でない場合、このチャンクがいくつかにフラグメントされた DATA チャンクの最初の断片であることを表している。

E-bit - ビット 15。 E-bit は、フラグメントされた DATA チャンクの最終断片を表す。このフラグが正になったものは、 SCTP の受け取り側にとって、フラグメントの再構成を開始し上位レイヤーに渡せという合図になる。また、 B ビットE ビット も 0 であれば、それはこのチャンクがフラグメントの半ばのチャンクであることを表す。両方とも 1 にセットされるのは、パケットはフラグメントされておらず再構成も必要ない場合などだ。

全長 (Length) - ビット 16-31。チャンクタイプ も含めてチャンク終端まで全部をビット単位で計算した DATA チャンクの長さ。

TSN - ビット 32-63。トランスミッションシーケンスナンバー (Transmission Sequence Number = TSN) は DATA チャンクの中で送られ、受信側ホストはこれを受け取ると、チャンクがきちんと届いたと認め (acknowledge)、引き替えに SACK チャンクを送る。値はその SCTP アソシエーション を通じてカウントされていく。

ストリーム識別子 (Stream Identifier) - ビット 64-79。ストリーム識別子DATA に付属して送られ、その DATA チャンクがどのストリームに関連付けられているかを明らかにする。これが存在するのは、 SCTP がひとつのアソシエーションの中で複数のストリームを運ぶ能力を備えているからだ。

ストリームシーケンスナンバー (Stream Sequence Number) - ビット 80-95。 ストリーム識別子 で括られるひとつのストリームの中でのシーケンスナンバー。このシーケンスナンバーは各ストリーム識別子 毎に管理される。チャンクがフラグメントされている場合には、元チャンクが同一ならばすべての断片に同じストリームシーケンスナンバー を付けなければならない。

ペイロードプロトコル識別子 (Payload Protocol Identifier) - ビット 96-127。この値は上位レイヤーまたは、SCTP を使用しているアプリケーションによって入れられ、それらどうしが DATA チャンクの内容を伝え合うために使われる。このフィールドは必ず送信する必要があり、フラグメントしたチャンクもその例外ではない。というのは、フラグメントされたチャンクであっても経路上のルータやファイヤーウォールなどがこの情報を必要とするからだ。値が 0 だった場合、上位レイヤーがセットしなかったと解釈される。

ユーザデータ (User data) - ビット 128-n。そのチャンクの運ぶデータそのもの。可変長だが、偶数オクテットで終わらなければならない。ストリーム S のストリームシーケンスナンバー n 番のデータ。

2.11.7. SCTP ERRORチャンク

ERROR チャンクは、特定のストリームの中で起きた問題を対向のピアに知らせるためにある。ひとつの ERROR チャンクは複数の エラー原因 を格納することもでき、そのことについては RFC 2960 - Stream Control Transmission Protocol で詳説されている。僕がここで述べるのは基本だけで、それ以上詳しく述べるのは控えておく。中身が濃すぎるからだ。 ERROR チャンクは、それ自体が致命的 (fatal) な性格のものというよりも、発生したエラーの詳細内容を知らせるものといえる。とはいえ、 ABORT チャンクと組み合わせると、コネクションを断ち切るぞという知らせにもなりうる。

タイプ (Type) - ビット 0-7。 ERROR チャンクでは常に 9。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更を目してのフィールドだ。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

全長 (Length) - ビット 16-31。すべての エラー原因 フィールドを含めた長さをバイトで指定する。

エラー原因 (Error causes) - ビット 32-n。ひとつの ERROR チャンクはひとつ以上の エラー原因 フィールドを含むことができ、それぞれのフィールドで対向ピアにコネクションに関する問題を知らせる。ひとつの エラー原因 の中にも決まったフォーマットがあり、それは RFC 2960 - Stream Control Transmission Protocol ドキュメントで述べられているが、ここではそれに踏み込むのはやめ、フィールドが 原因コード原因長 (cause length) および、原因毎に特有の情報フィールドから成ると言うだけに留める。指定可能な エラー原因 は下表の通りだ:

Table 2-2. エラー原因コード

Cause ValueChunk Code
1Invalid Stream Identifier (無効なストリーム識別子)
2Missing Mandatory Parameter (必須パラメータの欠如)
3Stale Cookie Error (「失効したクッキー」エラー)
4Out of Resource (リソースの欠乏)
5Unresolvable Address (リゾルブできないアドレス)
6Unrecognized Chunk Type (未知のチャンクタイプ)
7Invalid Mandatory Parameter (必須パラメータの値が無効)
8Unrecognized Parameters (未知のパラメータ)
9No User Data (ユーザデータの欠如)
10Cookie Received While Shutting Down (シャットダウン中にクッキーを受信)

2.11.8. SCTP HEARTBEATチャンク

HEARTBEAT チャンクは、特定の SCTP 端末アドレスが無効になっていないか走査する目的で、ひとつのピアが送信する。これはアソシエーションのイニシャライズの過程で関係を結んだ (negotiated) 複数のアドレスに対して行われ、それらが生存しているかどうかの確認に使われる。

タイプ (Type) - ビット 0-7。 HEARTBEAT チャンクでは、タイプ は常に 4。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更で使用されるようになる可能性がある。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

全長 (Length) - ビット 16-31。Heartbeat Information TLV を含めた、チャンク全体の長さ。

ハートビートインフォメーション TLV (Heartbeat Information TLV) - ビット 32-n。 RFC 2960 - Stream Control Transmission Protocol で定義された可変長のパラメータ。 HEARTBEAT チャンクには必須のパラメータで、infoタイプ=1, info長, 送信元固有の ハートビートインフォメーション パラメータの 3つのフィールドから成る。最後のフィールドは送信元によって内容がかなり異なり、例えば、ハートビートが前回いつ送られたかや送信先の IPアドレスが入ったりする。このパラメータと同じものが HEARTBEAT ACK チャンクで返される。

2.11.9. SCTP HEARTBEAT ACKチャンク

HEARTBEAT ACK は、HEARTBEAT が受理されコネクションは正常に機能しているという了解 (acknowledge) を示すために使われる。 HEARTBEAT ACK は要求のやってきた IPアドレスに対して返される。

タイプ (Type) - ビット 0-7。 HEARTBEAT ACK チャンクでは常に 5。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更に備えて確保されている。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

チャンク長 (Chunk length) - ビット 16-31。 ハートビートインフォメーション TLV を含めた HEARTBEAT ACK チャンクの長さをバイト単位で表したもの。

ハートビートインフォメーション TLV (Heartbeat Information TLV) - ビット 32-n。 ここには必ず、元となった HEARTBEAT チャンクの ハートビートインフォメーション パラメータと同じものを格納する。

2.11.10. SCTP INITチャンク

INIT チャンクは、宛先ホストとの新たなアソシエーションを開始 (initiate) する時に用いられるもので、コネクションを張ろうとするホストの発する一番最初のチャンクがこれだ。 INIT チャンクはいくつかの固定長パラメータと、省略可能な可変長パラメータから成る。固定長の必須パラメータには、既に他のヘッダで述べたものの他に、 イニシエートタグ (Initiate Tag), 受信ウィンドウ保証量広告 (Advertised Receiver Window Credit), 送出ストリーム数 (Number of Outbound Streams), 流入ストリーム数 (Number of Inbound Streams), 初期TSN (Initial TSN) パラメータがある。その後ろに下の「省略可能なパラエータ」の段落で挙げているいくつかのオプションパラメータが続く。

タイプ (Type) - ビット 0-7。INIT チャンクでは常に 1。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更に備えて確保されている。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

チャンク長 (Chunk Length) - ビット 16-31。 チャンク長 は、オプションパラメータも含めたすべてのヘッダを含めたパケットの全長。

イニシエートタグ (Initiate Tag) - ビット 32-63。イニシエートタグINIT チャンクの中で決められ、それが 検証タグ (Verification Tag) に利用されて、このアソシエーション中ずっと受信側によるパケット承認に使用される。 イニシエートタグ は 0 以外ならどんな値でも採ることができる。決まりに反して 0 にされた場合には、受信側は ABORT を発生させなければならない。

受信ウィンドウ保証量広告 (Advertised Receiver Window Credit) (a_rwnd) - ビット 64-95。 INIT チャンクの送り主がこのアソシエーション用に割り当てることにしている受信バッファの最小量。 a_rwnd の受け取り側は、この値によって、どれだけの量のデータが SACK で区切らずに送り出せるかを知る。実際の受信ウィンドウをここで広告したサイズよりも縮小することは推奨されないが、 SACK チャンクで改めて a_rwnd を送ることによってサイズを減らす余地はある。

送出ストリーム数 (Number of Outbound Streams) - ビット 96-111。相手に向かって張りたい、こちらから出て行く方向のストリームの最大数を規定する。この値を 0 とすることは許されておらず、もしもそうすれば相手はアソシエーションを即刻 ABORT しなくてはならない。送出ストリームに関しても流入ストリームに関しても最小数についての折衝はなく、単純に、両ホストがヘッダで指定したうちの小さい方が最小値となる。

流入ストリーム数 (Number of Inbound Streams) - ビット 112-127。このセッションで送り側が受信側ホストに生成を許可する、流入方向のコネクションの最大数。0 にすることは許されておらず、そうすれば受信側ホストはコネクションを ABORT しなければならない。送出ストリームに関しても流入ストリームに関しても最小数についての折衝はなく、単純に、両ホストがヘッダで指定したうちの小さい方が最小値となる。

初期 TSN (Initial TSN) - ビット 128-159。この値は、送り手側がデータの送信に使用する 伝送シーケンスナンバー (Transmit Sequence Number = TSN) の初期値を規定する。イニシエートタグ と同じ値を使用してもよいことになっている。

上記に挙げた固定長の必須ヘッダに加えて、設定してもよい オプショナルな数種の可変長パラメータがある。少なくとも IPv4, IPv6, Hostname のいずれかひとつは指定しなければならない。 Hostname はひとつだけしか指定できず、指定してある時には IPv4IPv6 パラメータはいずれも指定できない。ひとつの INIT チャンクで IPv4IPv6 パラメータを複数指定することは許されている。また、送り手側がひとつのアドレスしか持たずそれをチャンク の送信元として使う場合には、これらのパラメータを 3つとも省略することもできる。これらのパラメータは相手ピアとの接続に使用するアドレスを取り決めるためにある。下記が INIT チャンクで利用可能な全パラメータのリストだ:

Table 2-3. INITの可変長パラメータ

パラメータ名ステータスタイプ値
IPv4 Address省略可5
IPv6 Address省略可6
Cookie Preservative省略可9
Host Name Address省略可11
Supported Address Types省略可12
Reserved for ECN Capable省略可32768

以下に、 INIT チャンクで最も一般的な 3つのパラメータについて述べる。

IPv4 パラメータは INIT チャンクで IPv4 アドレスを送るためにある。これによって指定するのは、そのアソシエーションの中でデータ送信に使用していく IPv4 アドレスだ。ひとつの SCTP アソシエーションに対して IPv4 アドレスや IPv6 アドレスを複数指定することもできる。

パラメータタイプ (Parameter Type) - ビット 0-15。IPv4 アドレスパラメータでは常に 5。

全長 (Length) - ビット 16-31。 IPv4 アドレスパラメータでは常に 8 となる。

IPv4 アドレス - ビット 32-63。送り手側端末の、ひとつの IPv4 アドレス。

このパラメータは INIT チャンクで IPv6 アドレスを送るためにある。ここで指定したアドレスはそのアソシエーションの中での送り手側端末との通信に利用することができる。

タイプ (Type) - ビット 0-15。 IPv6 パラメータでは常に 6。

全長 (Length) - ビット 16-31。 IPv6 パラメータでは常に20となる。

IPv6 アドレス - ビット 32-159。送り手側エンドポイントの、ひとつの IPv6 アドレス。受け手側エンドポイントはこのアドレスと通信することになる。

Hostname パラメータは、アドレスとしてのひとつのホストネームを送るためにある。受信側ホストはここで指定されたホストネームをルックアップし、それによって得られた何れかまたはすべてのアドレスを利用する。Hostname パラメータを送るのであれば、 IPv4IPv6 も、余計な Hostname パラメータも送ることはできない。

タイプ (Type) - ビット 0-15。 Hostname パラメータでは常に 11。

全長 (Length) - ビット 16-31。 タイプ, 全長 をはじめとする全フィールドを含めたパラメータ全体の長さ。 Hostname フィールドは可変長だ。単位はバイト。

Hostname - ビット 32-n。ホストネームを格納する可変長パラメータ。個々で指定したホストネームは受信側エンドポイントでリゾルブが行われ、そこで得られたアドレスが送り手側エンドポイントとの通信に利用される。

2.11.11. SCTP INIT ACKチャンク

INIT ACK チャンクは INIT チャンクへの返事として送られる。ヘッダは基本的に INIT と同じだが、それらの値はこれを送ってきたピア (つまり元の INIT を受けた側) のものに置き換えられる。また、 INIT にはない追加の可変長パラメータ、 ステートクッキー認識不能パラメータ (Unrecognized Parameter) パラメータがある。

タイプ (Type) - ビット 0-7。 INIT ACK チャンクでは常に 2。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更を目して確保されているフィールドだ。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

チャンク長 (Chunk Length) - ビット 16-31。チャンク長 は、省略可能なパラメータも入れたすべてのヘッダを含めたパケット全体の長さ。

イニシエートタグ (Initiate Tag) - ビット 32-63。 INIT ACK チャンクの イニシエートタグ を受け取った端末は、その値を記録した上で、INIT ACK チャンクを送りつけてきた端末へ送り返すすべてのパケットの 検査タグ (Verification Tag) フィールドにそれをコピーしなければならない。 イニシエートタグ は 0 であってはならず、もし 0 であれば、その INIT ACK チャンクを受け取ったピアは ABORT によってコネクションをクローズしなければならない。

受信ウィンドウ保証量広告 (Advertised Receiver Window Credit) (a_rwnd) - ビット 64-95。送り手側が受信トラフィック専用に確保したバッファのサイズ。単位はバイト。専用バッファをこれより小さくしてはならない。

送出ストリーム数 (Number of Outbound Streams) - ビット 96-111。出て行く方向のストリームを送り手側ホストがいくつ生成したいか。0 にしてはならず、もしそうすれば INIT ACK を受信した側はそのアソシエーションを ABORT しなくてはならない。送出ストリームに関しても流入ストリームに関しても最小数についての折衝はなく、単純に、両ホストがヘッダで指定したうちの小さい方が最小値となる。

流入ストリーム数 (Number of Inbound Streams) - ビット 112-127。送信側エンドポイントがすすんで受け入れる流入方向ストリームの最大数。0 にしてはならず、もしそうすれば INIT ACK を受信した側はそのアソシエーションを ABORT しなくてはならない。送出ストリームに関しても流入ストリームに関しても最小数についての折衝はなく、単純に、両ホストがヘッダで指定したうちの小さい方が最小値となる。

初期 TSN (Initial TSN) - ビット 128-159。送信側がそのアソシエーションで最初に使う 伝送シーケンスナンバー初期値 (Initial Transmission Sequence Number = I-TSN)。

この後、 INIT ACK チャンクにはオプションの可変長パラメータが続く。パラメータは基本的には INIT チャンクのものと同じだが、 ステートクッキー パラメータと 認識不能パラメータ パラメータが加わり、対応アドレスタイプ (Supported Address Types) パラメータがなくなる。つまり下表のような塩梅だ:

Table 2-4. INIT ACK の可変長パラメータ

パラメータ名ステータスタイプ値
IPv4 Address省略可5
IPv6 Address省略可6
State Cookie必須7
Unrecognized Parameters省略可8
Cookie Preservative省略可9
Host Name Address省略可11
Reserved for ECN Capable省略可32768

ステートクッキーINIT ACK チャンクで使用され、対向のホストにクッキーを送るためにある。これを受信したホストが COOKIE ECHO チャンクで回答するまでは、そのアソシエーションが正当なものであることは保証されない。 TCP プロトコルでいうところの SYN アタックを防ぐための仕組みだ。

タイプ (Type) - ビット 0-15。ステートクッキー パラメータでは常に 7。

全長 (Length) - ビット 16-31。タイプ, 全長, ステートクッキー フィールドを含めたパラメータ全体のサイズ。バイト表記。

ステートクッキー (State Cookie) - ビット 31-n。任意の長さのクッキーを格納する。クッキーがどのように生成されるかについては RFC 2960 - Stream Control Transmission Protocol を参照。

2.11.12. SCTP SACKチャンク

SACK チャンクの使用目的は、受信した TSN に照らしてどのチャンク が受信済みでストリームのどこにギャップがあったかを DATA チャンクの送信元に伝えることにある。 SACK チャンクの働きは、ざっくり言えば、特定の時点 (累積 TSN Ack パラメータ) までに受け取ったデータを承認し (acknowledges)、その 累積 TSN Ack ポイントまでに受け取った全データに対する ギャップ Ack ブロック を加えていくというものだ。 SACK チャンクの送信は DATA チャンクの受信 1回に対して 1回だけと決められている。

タイプ (Type) - ビット 0-7。 SACK チャンクでは常に 3。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更を目して確保されているフィールドだ。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

チャンク長 (Chunk Length) - ビット 16-31。すべてのヘッダおよびパラメータを含めたチャンク全体の長さ。

累積 TSN Ack (Cumulative TSN Ack) - ビット 32-63。この 累積 TSN Ack パラメータはデータを承認するためにある。その DATA チャンクを受け取ったホストは、アソシエーションにおける現時点までのデータを受信し終えたことをこのフィールドによって送信元ホストに伝える。この時点でまだ明示的に ギャップ Ack ブロック によって承認していないデータは、基本的には喪失扱いになる。

受信ウィンドウ保証量広告 (Advertised Receiver Window Credit) (a_rwnd) - ビット 64-95。この a_rwnd フィールドも基本的には INITINIT ACK チャンクの a_rwnd と同じだが、ここでは a_rwnd 値の増減も可能だ。詳しくは RFC 2960 - Stream Control Transmission Protocol を読んでいただきたい。

ギャップ Ack ブロック数 (Number of Gap Ack Blocks) - ビット 96-111。このチャンクに含まれる ギャップ Ack ブロック の数。 ギャップ Ack ブロック ひとつは チャンク の 32 ビットを占有する。

重複 TSN 数 (Number of Duplicate TSNs) - ビット 112-127。重複していた DATA チャンクの数。重複していたすべての TSN はこの チャンク上の ギャップ Ack ブロック の後ろに並べられる。ひとつの TSN を送るには 32 ビットを消費する。

ギャップ Ack ブロック #1 開始点 (Gap Ack Block #1 Start) - ビット 128-143。ここに来るのが、この SACK チャンクで最初の ギャップ Ack ブロック。受け取った DATA チャンクの TSN ナンバーにギャップがひとつもない時には、 ギャップ Ack ブロック はひとつもない。かたや、 DATA の受信順序が乱れたり、伝送中にいくつかの DATA チャンクが失われた場合には、ギャップありと認められ、 ギャップ Ack ブロック を使って報告される。ギャップ Ack ブロック の開始位置は、 累積 TSN の値に ギャップ Ack ブロック開始点 パラメータを足すことによって求められる。そうして求められたのがブロック開始点だ。

ギャップ Ack ブロック #1 終点 (Gap Ack Block #1 End) - ビット 144-159。そのストリームにおける第1 ギャップ Ack ブロック の終点。 ギャップ Ack ブロック開始点ギャップ Ack ブロック終止点 の間にある TSN を持つすべての DATA チャンクは受信済み扱いになる。開始点同様に、実際に承認するブロックチャンクの最終 TSN を求めるには、ギャップ Ack ブロック終止点 の値を 累積 TSN と足す。

ギャップ Ack ブロック #N 開始点 (Gap Ack Block #N Start) - ビット可変。 ギャップ Ack ブロック数 パラメータがひとつ増える毎に、 ギャップ Ack ブロック がひとつ追加される (最後の第 N ブロックまで)。例えばつまり、ギャップ Ack ブロック数 = 2 だとすれば、その SACK チャンク内にはふたつの ギャップ Ack ブロック があるはずだ。ここは単純に最後の ギャップ Ack ブロック を意味し、ギャップ Ack ブロック #1 開始点 と同様の値が入ることになる。

ギャップ Ack ブロック #N 終点 (Gap Ack Block #N End) - ビット可変。ギャップ Ack ブロック #N 開始点 と同様。ただし、終点である。

重複 TSN #1 (Duplicate TSN #1) - ビット可変。このフィールドは、重複した TSN のことを通知する。つまり、既に受け取った チャンク と同一の TSN を持つ チャンク を、何度も受信した場合だ。ルーターの悪戯 (送信済みデータの再送) によるもの、エンドポイントの再送によるものなどケースは様々だ。重複した TSN は個々について 1回報告され、例えば、最初の該当データを承認してから 2つの重複 TSN を受信した場合、次回送信する SACK メッセージにふたつの重複 TSN それぞれについての報告が乗る。その SACK 送信後にさらに重複 TSN が観測されたら、そのまた次の回の SACK で知らせ、また... といった具合だ。

重複 TSN #X (Duplicate TSN #X) - ビット可変。ここに、最後の重複 TSN パラメータが来る。パラメータは前のものと同様だ。

2.11.13. SCTP SHUTDOWNチャンク

SHUTDOWN チャンクが発行されるのは、或るコネクションの一方のエンドポイントが現行のアソシエーションのクローズを希望する時だ。これを発行するホストは前もって送信バッファを空にしておく必要があり、 SHUTDOWN チャンクを送ったらもう DATA を一切送ってはならない。受信した側は、やはり送信バッファを空にして、 SHUTDOWN ACK チャンクで回答することになっている。

タイプ (Type) - ビット 0-7。 SHUTDOWN チャンクでは常に 8。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更を目して確保されているフィールドだ。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

チャンク長 (Chunk Length) - ビット 16-31。 累積 TSN Ack パラメータも含めたパケット全体の長さ。 SHUTDOWN チャンクでは常に 8 となる。

累積 TSN Ack (Cumulative TSN Ack) - ビット 32-63。この 累積 TSN Ack フィールドも SACK チャンクのものと同様。累積 TSN Ack は、対向エンドポイントからこれまでにシーケンス上最後に受け取った TSN に承認を与える。このパラメータは、 SHUTDOWN チャンク以降のデータはもちろん、ギャップ Ack ブロック の承認も行わない。以前承認したはずの TSNSHUTDOWN チャンクの ギャップ Ack ブロック にないからといって、そのブロックが今になって破棄されたと解釈してはならない。

2.11.14. SCTP SHUTDOWN ACKチャンク

SHUTDOWN ACK チャンクは、受信した SHUTDOWN チャンクを承認するために使用される。 SHUTDOWN ACK を送る前には、送信バッファの中身はすべて絞り出しておかなければならず、アプリケーションから新たなデータを受け取ってもいけない。 SCTP には TCP にあるようなコネクションの半開状態 (half-open) は存在しない。

タイプ (Type) - ビット 0-7。 SHUTDOWN ACK チャンクでは常に 8。

チャンクフラグ (Chunk flags) - ビット 8-15。今日では未使用。将来の変更を目して確保されているフィールドだ。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

チャンク長 (Chunk Length) - ビット 16-31。チャンク全体の長さ。 SHUTDOWN ACK では常に 4 となる。

2.11.15. SCTP SHUTDOWN COMPLETEチャンク

SHUTDOWN COMPLETE チャンクは、SHUTDOWN ACK チャンクへの返答として、 SHUTDOWN を先導したホストによって送信される。アソシエーションのクローズが完了したことを承認するためだ。

タイプ (Type) - ビット 0-7。 SHUTDOWN COMPLETE チャンクでは常に 14。

予約済み (Reserved) - ビット 8-14。今日では未使用。将来の変更を目して確保されているフィールドだ。詳しくは SCTPの一般ヘッダと共通ヘッダ を参照。

T-bit - ビット 15。送信側がこのコネクションに対して 伝送制御ブロック (Transmission Control Block = TCB) を結びつけており、それを無効化したのがその SHUTDOWN チャンクだった場合には、その事実を送信者側に伝えるために T-bit は立てない [訳者註: 0 にする]。 T-bit が立っている [: 1 になっている] とすれば、反故にするような TCB は存在しなかったということになる。

全長 (Length) - ビット 16-31。 SHUTDOWN COMPLETE チャンクでは常に 4。規格が改定でもされない限りは、それより大きくなることはあり得ないからだ。