要約

  • RFC 2024 のディレクトリ行は、MAC アドレスや NetBIOS 名にどこから到達できると DLSw ノードが考えているかを示す。端末間回線の開通宣言ではない。
  • トランスポート、回線、ペーシング、切断情報は、それぞれ異なる問いに答える証拠だった。

「この資源には到達できるか」という問いは一つに見える。だが RFC 2024 は、答えを複数の表に分けた。ディレクトリは所在地を示す。トランスポート表は DLSw ピア同士が能力交換を終えたかを示す。回線表は特定の端末間経路を追う。ペーシング項目は、送信側が待機するまでに許された SSP メッセージ数を表す。一つの緑色表示でこれらを代用することはできない。

所在地はローカルな判断だった

MAC と NetBIOS のディレクトリには、資源ごとの所在地ポインタがあった。ローカルインターフェース、設定済みトランスポート接続、稼働中の接続、null、実装固有の表のいずれかを指す。状態は unknown、reachable、notReachable だが、文書が表すのは、その場所からアクセスできると DLSw がその時点で考えているかどうかである。

静的ディレクトリの例にも留保がある。初期状態は unknown になり得る。同じ遠隔資源を複数のピア経由で登録できる。候補の順序は保証されず、同じ具体性を持つ静的情報と動的情報の衝突は実装依存で決められる場合がある。検索失敗後の notReachable は、同じ検索をすぐ繰り返さないために残されることもあった。

つまり、ディレクトリは探索先を絞る。選ばれたピアの接続、回線確立の開始、端末の応答までは証明しない。

トランスポートには別の時計があった

トランスポートの運用状態は、接続中、初期能力交換、接続済み、休止化、切断中、切断済みなどに分かれる。ここで接続済みとは、両ピアが互いの能力を確認し、回線確立メッセージを扱えるという意味だった。端末サービスの成功とは異なる。

設定との結び付きも固定ではない。dlswTConnOperConfigIndex は接続を支配した設定行を指すが、その行が削除されればゼロになる。接続後に設定を変更しても、稼働中の接続には以前の交渉条件が残り得る。このため接続時刻と設定の最終変更時刻を合わせて読む必要がある。

切断後も、統計や理由を残すため運用行を保持でき、保持期間は定められていなかった。ピアから受信した能力情報も履歴行に残り得る。項目が読めることと、相手が現在利用可能であることは同じではない。

回線は探索の後に始まった

RFC 2024 は回線起動を二段階に分ける。最初に explorer が MAC アドレスまたは NetBIOS 名を探し、その後で回線確立が始まる。回線表の行が作られるのは後者が始まった時点であり、所在地が見つかった時点ではない。

回線には独自の詳細な状態遷移がある。設定可能なのは disconnectPending だけで、管理側から再確立する命令はない。回線確立は端末が主導するためだ。切断理由や下位の LLC、SDLC MIB へのポインタは原因を絞る手掛かりになる。トラフィック統計の一部も、そのポインタをたどらなければ得られない。単独の行が根本原因を断定するわけではない。

ペーシングの単位も狭い意味を持つ。送信側が停止して待つまでに、現在いくつのペーシング対象 SSP メッセージを送ってよいかという許可枠である。ペーシングを使わない場合もゼロになり得る。現在または最大の窓は、配信済みメッセージ数でも、処理完了の証拠でもない。

trap は遷移を報告した

トランスポートや回線が接続済みに入った際、trap を送れる。ただし送信は設定で無効にできる。受信した trap が立証するのは、ローカルなエージェントが遷移を報告し、その通知が届いたことまでだ。状態の継続、相手側との一致、その後の切断がないことまでは保証しない。trap がないことも、遷移がなかった証明にはならない。

切断時刻、理由、アクティブ回線の有無は障害像を絞る。アクティブ回線の存在は利用者に影響した可能性を示すだけで、人数や事業損失は示さない。後の RFC 2166 は RFC 1795 に、端末からの切断、DLC エラー、回線プロトコルのエラー、運用者操作などの大まかな HALT 理由を加えた。旧ピアは理由を省略でき、ベンダー固有の詳細も異なる。手掛かりは増えても、最終原因の保証にはならない。

全体像は両方のノードにまたがった

RFC 2024 は、完全な状況把握には複数の DLSw ノードから情報を取得する必要があると述べる。重複を減らすため、双方に存在する情報の一部は「相手から受信した情報」として定義された。さらに、相手の管理対象トランスポートアドレスと管理プロトコルのアドレスを対応させる方法も DLSw 自体にはなかった。

各行は、範囲の定まったローカルな証言である。Lu Heng が論じる「記録と、それが記述する現実の層は同一ではない」という区別は、この設計を読む現代的な視点になる。記録は正確でも、運用状態の全体とは限らない。これは分析上の応用であり、RFC 著者の意図を推測するものではない。

表を疑う必要はない。索引、時刻、ローカルな範囲を失わずに結合すればよい。ディレクトリは所在地判断、トランスポート表はピア接続と交渉時点、回線表は端末経路、下位 MIB はリンク層の証拠を支える。両端を比較すれば説明力を持つが、一色のランプに圧縮すれば境界が消える。

出典