要約

  • RFC 1307 は1992年3月に発表された Experimental の研究用プロトコル記述で、インターネット標準ではない。高価な回線を必要な期間だけ接続するため、トランスポート提供者と別のリンク・コントローラーの間を DSLCP が仲介した。
  • 提供者が見る状態は up と down の二つだけだが、DSLCP は Down、Coming Up、Up、Going Down、Bring Down、Bring Up を使い、処理中の要求と後から反転した利用意図を同時に保持した。
  • Up から release を受けると、DSLCP は teardown を送り、Going Down に移り、コントローラーの完了応答を待たずに提供者へ down を通知する。この down はローカルな抽象であり、物理回線の撤去証明ではない。
  • teardown は提供者に常に成功として返され、コントローラーに該当トランザクションがない場合も成功したものとして処理を続け得る。成功表示とコントローラーの同意、物理状態、容量、課金は別の記録である。
  • 信頼性を保証しない制御配送は、タイムアウト、再送、重複、順序逆転を生み得る。応答の新旧は、識別子だけでなく両端点、未完了機能、内部状態、時刻と結び付けて判断する必要がある。

六状態を二枚に折り畳む

RFC 1307 は Dynamically Switched Link Control Protocol、DSLCP を、Cray Research のプロジェクトから生まれた仕組みとして記述した。対象は、ホストから見える下流のネットワーク・リンクを必要時に制御しつつ、スイッチ固有の差をトランスポート提供者から隠すことだった。

利用者側の境界は意図的に狭い。トランスポート提供者が知るリンク状態は up または down だけでよく、特定リンクの細かな状態を自分で追跡しないよう RFC は求める。DSLCP が状態を持ち、提供者には見えないリダイレクトその他の処理も行い得るからだ。

ところが内部には、Down、Coming Up、Up、Going Down、Bring Down、Bring Up の六状態がある。前半の四つだけでも、停止、起動途中、稼働、停止途中という時間差が現れる。残る Bring Down と Bring Up は、作業中に要求が反転したことを忘れないための折り目である。

二状態は六状態の粗雑な代用品ではない。提供者が扱う責任を限定する公開面であり、六状態は DSLCP が引き受けた順序制御の面である。公開面に down と書かれた時点で、内部面から Going Down が消えるわけではない。この二つを同一のログ列に上書きすれば、抽象が成立するために誰かが保持していた途中経過まで失われる。

まず Up から release を一つ

状態機械の性格は、通常の解放要求だけで明瞭になる。DSLCP が Up のとき、トランスポート提供者から teardown 要求を受ける。DSLCP はコントローラーへ teardown を送り、Going Down に移る。そして、その場で提供者にリンクは down だと知らせる。

まだコントローラーの teardown succeeded は到着していない。送信済みの命令と、完了済みの効果の間に時間があるからこそ、内部状態は Going Down と名付けられている。それでも上位の提供者には down を返す。これは、解放後の待ち時間とコントローラー差異を上位から隔離する設計である。

ここで記録できるのは三つだ。提供者が release を要求したこと、DSLCP が teardown を送ったこと、DSLCP がローカル表示を down にしたこと。物理回線がいつ切れたか、コントローラーがいつ処理を終えたか、容量がいつ再利用可能になったかは、その三つのどれからも自動的には出てこない。

さらに RFC は、teardown について提供者は成功を仮定できるとする。DSLCP は teardown 要求に常に成功応答を返すからだ。setup の成功・失敗は提供者へ知らせるのに、teardown は安定した成功として見せる。この非対称性が、使いやすい公開面を作ると同時に、成功という語の証拠範囲を狭くしている。

費用を止めたいという要求と、止まったという証拠

この抽象には経済上の理由があった。回線交換リンクを接続したままにすると費用がかかるため、通常は切断しておく。トランスポート提供者はセッションの始まりと終わりを把握でき、必要になればリンクを起動し、利用が終われば解放を求められる。ハードウェアや管理上の設定は、別のリンク・コントローラーが扱う。

役割を分けることで、提供者はスイッチごとの操作を知らずに済む。ただし「費用がかかるから解放する」という動機と、「特定時刻に課金が止まった」という結果は別だ。同様に、release 要求は容量を空けたいという意図であり、容量管理系が再割り当てを完了した記録ではない。

データ用リンクを準備する前に、ホストからコントローラーへのネットワーク経路がすでに存在しなければならない点も重要である。制御メッセージは IP または UDP データグラムとして運べ、RFC は信頼できる転送を必須にしなかった。制御経路と制御対象のリンクは、役割も存続条件も異なる。

この構造では、提供者の release、DSLCP の送信、コントローラーの受信、物理操作、応答の配送が別々の時刻を持つ。コストを抑える設計判断があっても、どの段階を課金や容量の境界に採るかは DSLCP の状態名だけでは決められない。

反対向きの要求を捨てない

Coming Up は setup を送り、応答を待っている状態である。その最中に release が来た場合、DSLCP は直ちに過去の setup をなかったことにはできない。データグラムはすでにコントローラーへ届き、回線の起動が進んでいるかもしれない。そこで Bring Down に移り、setup の結果を受けた後、成功なら teardown を送る。

現在の利用意図は down、未完了の制御命令は up。Bring Down は、この矛盾を故障として消すのではなく、順序として保存する。setup succeeded が届いた瞬間も、それは無意味な偽通知ではない。古い要求への正しい返事かもしれないが、現在の意図には合わないため、補償する teardown が必要になる。

逆も起きる。Going Down で新しい connect が来れば Bring Up へ移る。まず進行中の teardown を受け止め、その後 setup を送る。現在の意図が up に戻ったからといって、既送の teardown を時間から消すことはできない。Bring Up は、解放完了と再起動を正しい順序でつなぐための状態である。

最終的な up/down だけを残した記録から、この二つの反転を復元するのは難しい。up、down、up と表示されたとしても、それが三つの独立セッションなのか、一つの未完了操作中に意図が往復したのかは分からない。六状態には、表示値よりも多くの因果順序が保存されている。

応答は「最後の要求」に対して意味を持つ

DSLCP のメッセージには、16ビットの識別子、二つの32ビット端点アドレス、機能、イベント状態、コントローラーが解釈する任意の本文が入る。トランザクションは識別子を二端点と組み合わせて識別する。番号一つを回線、セッション、人物、あるいは世界で一意の権限印として扱う根拠はない。

機能は bring up と bring down。イベント状態には setup succeeded、setup failed、teardown succeeded、teardown failed、そして asynchronous network down がある。RFC はイベント状態を、最後の機能要求に対する制御リンクの状態として位置付ける。つまり、success という単語だけを抜き出しても、何に対する返答かが欠けている。

照合には、識別子、両端点、直前の機能要求、未完了か否か、送信時と受信時の内部状態、タイムスタンプが要る。利用者の意図が途中で反転すれば、応答が正しくても現在の目的からは古い。イベント状態は物理回線についての永続的なラベルではなく、トランザクション文脈を持つ返事である。

また、RFC の Security Considerations はセキュリティ問題を議論していない。端点アドレス、識別子、コントローラー本文、応答を、この文書だけから認証、認可、完全性、機密性の証明へ昇格させることはできない。メッセージ形式が識別に使えることと、送信主体が安全に確認されたことは異なる。

古い成功が、いまの失敗になるわけではない

制御配送が信頼できるとは限らないため、DSLCP はタイムアウトと再送を使う。著者らのローカル環境では五秒のタイムアウトと三回の再送を採用していたが、環境ごとに調整が必要だと RFC は明記した。この数値は普遍的な運用基準ではなく、再送を前提にした設計の具体例である。

再送は冗長な要求を生み、コントローラーから予期しない応答が返ることがある。ネットワークで順序が入れ替われば、古い setup succeeded が新しい release の後に到着する。到着時刻が新しいからといって、応答が表す意図まで新しいとは限らない。

ローカル状態がすでに Down なのに setup succeeded を受けた場合、RFC は重複要求やパケットの順序逆転を可能性として扱い、teardown を送る。成功は捨てられるのではなく、現在の down と整合させるための補償操作へ変換される。Bring Down で setup success が届いた場合も、teardown を送り Going Down へ進む。

この動きは、成功と望ましさを分ける。コントローラーにとって過去の setup が成功でも、現在の利用者はすでに release を望んでいる。監視が success の件数だけを数えれば、不要になった成功と現行意図に沿う成功を区別できない。必要なのはメッセージの評価ではなく、どの要求に応え、到着時にどの状態だったかという履歴である。

「該当なし」でも、状態機械は先へ進む

Up で teardown failed を受ける場面は、抽象と履歴の差がさらに大きい。RFC によれば、DSLCP が無効なトランザクションに teardown を送り、コントローラー側にその識別子と端点に対応する記録がないことを意味する。この場合、DSLCP は要求が成功したかのように処理を続ける。

コントローラーの「該当記録なし」と、DSLCP の「成功したものとして続行」は矛盾した報告ではなく、異なる責任面の判断である。前者はコントローラーが現在保持するトランザクション記録について述べ、後者はローカル状態機械を停止させない収束規則を述べる。

しかし、continue as if succeeded は過去を確定しない。コントローラーが記録を持たない理由、以前に物理操作が起きたか、記録が失われたかは、この一件から決められない。監査で teardown success に正規化してしまえば、失同期を示す唯一の痕跡を消すことになる。

別の方向の警告もある。Up のとき teardown succeeded が届けば、RFC は何らかのエラーが起きたとする。保守的には接続を down にして再同期することを勧める一方、メッセージを無視してもよい場合があると述べる。選択肢が残されていること自体、意外な成功一件から唯一の物理状態を導けない証拠である。

同じ down に異なる起点がある

コントローラーは asynchronous network down も報告できる。DSLCP は Coming Up、Bring Up、Up の各状態から Down へ移り、提供者へ通知する。このイベントはホスト利用者の release ではなく、teardown succeeded でもない。最終表示が down で一致しても、原因を述べる記録は別にある。

したがって、down を時系列の終点としてだけ保存してはならない。Up から release を受けた直後の先行 down、ネットワーク側から来た非同期 down、失同期に対する保守的な再収束は、公開面では同じ札を使える。しかし、インシデントの意味、未完了命令、コントローラー記録は異なる。

データ面もこの札からは分からない。down 通知の前にどのデータが移動したか、受信されたか、アプリケーションが処理したかは、トランスポートやアプリケーション側の証拠を要する。反対に、データが見えないことだけで物理 teardown の完了時刻を特定することもできない。

容量、課金、認可もそれぞれ独立している。DSLCP が上位に down を返す時刻を運用上の境界として採用する設計はあり得るが、RFC 1307 は特定の容量解放や請求停止を記録していない。ローカルな契約を外部結果の証明として読み替えてはいけない。

二値を守り、履歴を六値以上で残す

検証可能な一件を作るには、利用者の connect/release、提供者のアクティブ・セッション数と二値表示、識別子と二端点、送信した機能、遷移前後の六状態、タイムアウトと再送、コントローラーのトランザクション記録、応答イベントと時刻、物理リンクの独立観測、データ面の結果を結合する必要がある。

それぞれの記録は、別の問いに答える。要求は利用意図を、二値表示は提供者とのインターフェースを、内部状態は未完了制御を、コントローラー記録は相手側の認識を、物理観測は回線現象を、データ記録は送受信を表す。一つが欠けたとき、ほかの記録で空欄を埋めるのではなく、何が未観測かを残す。

RFC 1307 の設計は、複雑さを隠すことと、複雑さが存在しないことをきれいに分けた。提供者には二枚の札で十分だった。それでも状態機械は、未完了、反転、重複、順序逆転、未知のトランザクションを覚えていた。使いやすい抽象を維持しながら、証拠まで二値に圧縮しない。その違いが、論理 down を物理的な終幕と誤読しないための条件である。

情報源と証拠の限界

本稿の唯一の情報源は、RFC Editor の RFC 1307 である。Jeff Young と Andy Nicholson が1992年3月に発表した Experimental 文書であり、オンデマンド回線、既存の制御経路、トランザクション項目、二値公開面と六状態、要求反転、setup/teardown の報告非対称、タイムアウトと再送、遅延成功、再同期、未知トランザクション、非同期 network down を裏付ける。現在の導入、実在回線、物理切断、容量解放、課金停止、配送、アプリケーション結果、セキュリティ特性は裏付けない。既刊の RFC 1306 論考が扱った経路検索、外部起動、未完成回線でのデータ禁止、経路別名、最初のバイト以前の独立タイマーとは論点を分けている。