Network Working Group M. Rose Request for Comments: 3081 Invisible Worlds, Inc. Category: Standards Track March 2001 TCP 上における BEEP コアの対応 この文書の状態 本文書はインターネットコミュニティにおけるインターネット標準化過程プ ロトコルを定義している。本文書の内容を発展させるための議論および提案 を求める。本プロトコルの標準化段階と状態については、最新版の『インタ ーネット公式プロトコル標準』（STD 1）を参照していただきたい。本文書 の配布は制限されない。 著作権情報 Copyright (C) The Internet Society (2001). All Rights Reserved. あらまし この文書は、どのように BEEP(Blocks Extensible Exchange Protocol: ブ ロック拡張可能プロトコル) セッションが、単一の TCP(Transmission Control Protocol) コネクションに対応するかを述べる。 1. はじめに この文書は、どのように BEEP [1] セッションが、単一の TCP [2] コネク ションに対応するかを述べる。対応付けに必要な物の説明として、[1] の 2.5 章を参照して欲しい。 2. セッション管理 TCP サービス上における BEEP セッション管理は、単純である。 双方の BEEP ピアの間で TCP コネクションが確立した時に、BEEP セッショ ンが確立する。 ・消極的な TCP OPEN を発行した BEEP ピアはリスナーと称する。 ・積極的な TCP OPEN を発行した BEEP ピアはイニシエータと称する。 同時に起こる TCP OPEN は、双方のピアに自分がイニシエータだと思いこま せ、どちらのピアもチャンネルを開始出来なくなる結果となる。この為 、BEEP を基にしたサービスは、同時に起こる TCP OPEN が起こり得ないよ う設計しなければならない。 両方のピアが BEEP セッション ([1] の 2.4 章参照) の解放に合意した場 Rose Standards Track [Page 1] RFC 3081 Mapping the BEEP Core onto TCP March 2001 合、"ok" 応答を送るピアは直接 TCP CLOSE を発行する。応答を受け取る時 、他方のピアは直接 TCP CLOSE を発行する。 BEEP セッションはどちらか一方のピアが TCP ABORT を発行した時に終了し 、続いて TCP コネクションが中断する。 3. メッセージ交換 TCP サービス上における BEEP セッション管理は、若干単純である。 メッセージは、TCP の SEND や RECEIVE の呼び出しを使って確実に送られ 、受け取られる (これは同一チャンネル上におけるメッセージの順序通りの 配送も提供する) 。 とはいえ、TCP はコネクション毎のフロー制御を強要する。もし複数のチャ ンネルが BEEP セッション上で 同時に使用中になるならば、BEEP は飢餓や デッドロックを避けるメカニズムを提供しなければならない。これを実現す る為に、BEEP は TCP が用いている「ウィンドウベースのフロー制御」のメ カニズムを、BEEP でも再び導入する。個々のチャンネルは、ピアが許可を 受ける前に送る可能性があるペイロードのオクテットの数を示すスライドウ ィンドウを持つ。 3.1 フロー制御 [1] の 2.2.1.2 章を思い出してみると、チャンネル上のそれぞれの方向に 送られた全てのペイロードのオクテットは、シークエンス番号を割り当てら れる。データフレーム中のペイロードのオクテットの番号付けは、最初のペ イロードのオクテットに最も小さい数が付けられ、その次のペイロードのオ クテットは連続的に番号付けされる。 実際のシークエンス番号の範囲は有限であるが、とても大きく 、0..4294967295 (2**32 - 1) の範囲の数を取る。範囲が有限なので、全て のシークエンス番号を取り扱う演算は 2**32 を法とする。この無符号の計 算は、シーケンス番号が 2**32 - 1 から 0 に循環するという関係を維持し ている。シーケンス番号の演算の特性の議論は、[3] のセクション 2 から 5 を参照の事。 3.1.1 チャンネルの作成 チャンネルを作成すると、最初のフレームの最初のペイロードのオクテット のシーケンス番号として 0 を割り当てる。また、チャンネルの最初のウィ ンドウサイズを 4096 オクテットとする。チャンネルを作成した後、BEEP ピアは SEQ フレームを送る事によってウィンドウサイズを更新してもよい (セクション 3.1.3)。 BEEP ピアがチャンネルの作成を求められたが、最低 4096 オクテットのウ ィンドウサイズを確保出来ない場合、[1] のセクション 2.3.1.2 に書かれ ている通りチャンネルの作成を辞退しなければならない。同様に、BEEP セ Rose Standards Track [Page 2] RFC 3081 Mapping the BEEP Core onto TCP March 2001 ッションを確立している最中に、リスニングロールで活動しているピアがチ ャンネル 0 に最低 4096 オクテットのウィンドウサイズを確保出来ないな らば、[1] のセクション 2.4 に書かれている通り挨拶の代わりに否定的な 応答を返さなければならない。 3.1.2 メッセージの送信 メッセージが送られる前に、送信側の BEEP ピアはペイロードのサイズが、 受信側の BEEP ピアが通知したウィンドウの範囲内である事を保証しなけれ ばならない。そうでないならば、3 つの選択肢がある。 ・ウィンドウが最低でも 1 オクテットのペイロードが送れるなら、BEEP ピアはメッセージを分割して小さなデータフレームを送ってもよい(残 りのウィンドウのサイズの上限まで)。 ・BEEP ピアはウィンドウが大きくなるまでメッセージの送信を遅らせて もよい。 ・BEEP ピアはメッセージを送信出来ない事を BEEP で通信しようとする アプリケーションに示し、アプリケーションに後で再試行する事を許可 する (あるいは、大きなウィンドウが利用可能になった時にアプリケー ションに示すかもしれない)。 選択は実装依存であるが、BEEP を使用するアプリケーションに与えられた メカニズムが決定に影響を及ぼす事が望ましい。 3.1.3 SEQ フレームの処理 アプリケーションが、到着するデータフレームを責任を持って受け入れる為 に、アプリケーションの BEEP ピアは新しいウィンドウを通知する為に 、SEQ フレームを送るべきである。 SEQ フレームの ABNF [4] は以下の様になる。 seq = "SEQ" SP channel SP ackno SP window CR LF ackno = seqno window = size ; channel, seqno, size は [1] のセクション 2.2.1 に定義されてい る。 SEQ フレームは 3 つのパラメータを持つ。 ・チャンネル番号 Rose Standards Track [Page 3] RFC 3081 Mapping the BEEP Core onto TCP March 2001 ・認識番号。これは、送信者がこのチャンネル上で受け取る事を期待して いる、次のシークエンス番号を示す。 ・ウィンドウサイズ。これは、送信者がこのチャンネル上で受け取る事を 期待している認識番号が示す、 1 から始まるペイロードのオクテット 数を示す。 単一のスペース(10 進数で 32, " ")はそれぞれの要素を分割する。 SEQ フ レームは CRLF で終わる。 SEQ フレームを受け取った時、チャンネル番号か、認識番号か、ウィンドウ サイズが決定出来ない、あるいは無効な場合、BEEP セッションは応答を生 成せずに終了し、さらに診断事項をログに記録する事を推奨する。 3.1.4 フロー制御の使用 BEEP 内でフロー制御の使用の成功の鍵は、バランス性能と公正性である。 ・大きなメッセージは、TCP がネゴシエートしたセグメントサイズの最 大値の2/3より大きくない大きさのフレームに分割すべきである。 ・送信準備が出来ている異なるチャンネルへのフレームは、ラウンドロ ビン形式で送られるべきである。 ・フレームが受信される際に、このチャンネルの送信ウィンドウサイズ が少なくともバッファの1/2以上ある時はいつでも SEQ フレームが送ら れるべきである。 ・通信サービスが BEEP ピアに一斉に複数のフレームを与えたなら、単 一の SEQ フレームが送られるかもしれない。 通信サービスとの病的な相互作用を避ける為に、BEEP ピアが使用可能なバ ッファ領域に基づいたウィンドウを通知する事は重要である。さらにまた、 チャンネルへの SEQ フレームはメッセージより高い優先性を持たなければ ならない。 実装は、 BEEP を使うアプリケーションにキュー管理機能を提供する事を望 んでもよい。例えば、チャンネルの優先順位、(相対的な)バッファ確保など である。とりわけ、実装は与えられたチャンネルに、根底の通信ウィンドウ を独占する事を許可すべきでない(例えば、低速の読み手は小さなウィンド ウを確保すべきである)。 加えて、可能ならば、実装は輻輳情報を伝える通信レイヤーの API をサポ ートすべきである。これらの API は、実装に利用可能な帯域の割り当てを 決定する事を可能にする。ここで留意すべきは、BEEP セッションが同時に 巨大なメッセージを交換する複数のチャンネルを持っている時、情報を入手 する手段を持たない実装は、ネットワークの混雑時中に不確かな公平性や進 Rose Standards Track [Page 4] RFC 3081 Mapping the BEEP Core onto TCP March 2001 捗情報を持つかもしれない。 最後に、実装者は RFC1122 [5] のフロー制御に関連する箇所に示されてい る指針に従うべきである (また、TCP においてフロー制御と互いに影響しあ う、再送処理のような点も心に留めるべきである)。例えば、RFC1122 [5] の 4.2.2.16 章は「受信者はウィンドウを縮小する *べきでない* 、すなわ ち、ウィンドウの右端を左に動かす *べきでない* 。」と示唆し、その後、 応答されていないデータにおけるこの規則の効果について議論している。単 一の TCP コネクション上に BEEP を対応づけるという状況において、フロ ー制御に関する箇所のみ実装されるべきである。 Rose Standards Track [Page 5] RFC 3081 Mapping the BEEP Core onto TCP March 2001 4. セキュリティに関する考察 [1] の 9 章のセキュリティに関する問題点の議論を参考にせよ。 参考文献 [1] Rose, M., 「ブロック拡張可能プロトコル"」, RFC 3080, 2001年3月。 [2] Postel, J., 「転送制御プロトコル」, STD 7, RFC 793, 1981年9月。 [3] Elz, R. and R. Bush, 「シリアル番号演算」, RFC 1982, 1996年8月。 [4] Crocker, D. and P. Overell, 「文法仕様書の為の増強されたBNF」, RFC 2234, 1997年11月。 [5] Braden, R., 「インターネットのホストの必要条件 ― 通信層」, STD 3, RFC 1122, 1989年10月。 著者連絡先 Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US 電話番号: +1 707 789 3700 電子メール: mrose@invisible.net URI: http://invisible.net/ Rose Standards Track [Page 6] RFC 3081 Mapping the BEEP Core onto TCP March 2001 附記A. 謝辞 著者は以下の貢献者に感謝の念を示す: Dave Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge, Vernon Schryver, and, Joe Touch. とりわけ、Dave Crocker は、割り当てにおけるフロー制御の 性質について、有用な提案を提供してくれた。 Rose Standards Track [Page 7] RFC 3081 Mapping the BEEP Core onto TCP March 2001 著作権表記全文 Copyright (C) The Internet Society (2001). 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. 謝辞 RFCの編集者の為の資金は現在Internet Societyによって提供されている。 Rose Standards Track [Page 8]