要約

  • RFC 1434は各Data Link SwitchでLLC Type 2を終端し、WANを横断する一本のリンクではなく、互いに独立した二本のローカル接続を作った。
  • スイッチ間では、TCPの上でCANUREACHからREACH_ACKまでの探索、Circuit IDの交換、CONTACT／CONTACTEDによる端末接触が別途必要だった。
  • 多重化はWAN上の確認トラフィックを減らす一方、一つのTCP障害が、その上に載るすべての回線を両端で切断する共有運命を生んだ。

遅延を調整するのではなく、境界を動かす

LLC Type 2はLANの時間感覚で設計されていた。伝送遅延は小さく、変動も予測できる。固定タイマーが切れればフレーム紛失と判断する。ところが低速の広域回線や混雑をまたぐと、紛失していないフレームまで遅れて到着する。再送が重なり、リンク手順が混乱し、最後には接続そのものが落ちかねない。

RFC 1434は、WAN全体に合う巨大なタイマーを探さなかった。DLSは手前のスイッチでLLC Type 2を終端する。左の端末は左のスイッチとのみLLCを維持し、右の端末は右のスイッチと別のLLCを維持する。スイッチ同士はSwitch-to-Switch Protocol（SSP）で情報を中継する。

したがって、端末が受け取るRRやUAは、隣接スイッチがローカルな責任を引き受けたという証拠である。遠隔端末が受信した証拠ではない。遠隔側のLLCが成立した証拠でも、アプリケーションが処理した証拠でもない。RFC 1434が二つのLLC接続を「完全に独立」と記した意味はここにある。

この切断は欠陥ではなく効用を生んだ。LLCのタイムアウトと確認応答はWANへ出ず、SDLCのポーリングもローカルで完結する。再試行は該当リンクに近いスイッチが処理できる。LAN用の時間制御を、変動する広域遅延から隔離したのである。

TCPが開いても、目的の回線はまだない

二つのDLSがSSPを使う前に、まず信頼できるトランスポート接続を作る。初期実装はTCPだったが、文書は他の信頼性トランスポートも排除していない。その接続の上に複数のDLS回線を設けるのがSSPの役割だった。

この順番を無視すると監視表示が誤る。TCP接続済みという事実は、二つのスイッチがバイト列を運べることだけを示す。目的端末の場所、そこへ到達できるピア、回線識別子の交換、遠隔端末とのリンク接触については何も確定していない。緑色のソケットが、緑色の端末セッションを意味するわけではない。

RFC 1434は対象と実体を別に識別した。Data Link IDは両端のMACアドレスとSAPアドレスを組み合わせ、どの接続関係を求めるかを示す。各スイッチはDLC Port IDとData Link Correlatorからなる64ビットのCircuit IDをローカルに割り当てる。一本のエンドツーエンド回線には両側のCircuit IDが必要で、各DLSはその対を記憶する。

回線成立前は完全なData Link IDで制御し、成立後のINFOFRAMEは相手側Circuit IDだけを含む短いヘッダーを使える。この効率化は、識別子の来歴を保存することを前提とする。片側の番号だけをログに残しても、別のスイッチ上の番号とは照合できない。

探索、選択、接触

SSPのメッセージ名は、成功を一度に宣言しない。CANUREACHは端末に到達できるピアを尋ねる。ICANREACHは肯定と対象側Circuit IDを返す。REACH_ACKが起点側Circuit IDを通知して、初めて識別子の対がそろう。その後のCONTACTとCONTACTEDが、遠隔端末との接触を進める。

ピア生存、場所発見、識別子交換、端末接触は別の出来事である。どこか一つが成功しても後続状態は自動的に成立しない。RFCの状態機械をログへ写す価値は、失敗をこの順序のどこへ置けるかにある。

同じCANUREACHに複数のICANREACHが返る場合、起点DLSは最初の応答を選び、その相手へREACH_ACKを送った。つまり「端末の場所」は唯一の静的真実ではない。ある探索に対して複数の候補が観測され、そのうち一つが選択された結果である。後から選択理由を検証するには、採用した答えだけでなく、他の応答と到着順も必要になる。

場所キャッシュは探索の拡散を抑えた。対象を知らなければ、CANUREACHやNetBIOSの質問は既知のDLSピアすべてに送られ得る。キャッシュが古ければ別の問題を生む。探索範囲、時刻、キャッシュの由来は回線状態と同じく重要な観測である。

手前のUAと、向こう側の沈黙

ローカル端末がSABMEを送ると、起点DLSは遠隔端末への接触が終わる前にUAを返せた。これは近端のLLC成立を速やかに見せる。そのままデータを送らせないため、スイッチは一時的にRNRで送信を止め、遠隔DLSからCONTACTEDを受けてからRRで解除した。

UAは遠隔成功の代筆ではない。隣接スイッチが一つの責任を引き取った記録である。RNRは、その先の不確実性を隠さず制御した記録である。この二つを同じ「接続済み」へ潰すと、利用者が待っている場所と監視が成功を宣言した場所が食い違う。

SSP回線成立、遠隔接触、ローカル送信許可、アプリケーション応答は四段階の証拠である。TCPが順序どおりスイッチへ配送しても、遠隔LLCは再試行中かもしれず、端末側プログラムは何も受け付けていないかもしれない。

後継のRFC 1795は、この境界を適応ペーシングとして明示した。能力交換で初期ウィンドウを知り、各方向・各回線の送信者はFCINDで明示的な単位を与えられるまでデータを送れない。これは1995年版の追加であり、RFC 1434の機能ではない。ただし、信頼できるTCPとは別に、論理回線ごとの送信許可が必要だったことをよく示す。

共有による節約、共有による切断

ローカル終端はWAN上のLLC確認を減らし、多重化は端末対ごとのTCPを不要にする。効率の反対側には、共有障害領域がある。

RFC 1434では、二つのDLS間のTCPが失敗すると、その接続へ多重化されていたすべての接続を落とす。両スイッチは影響を受けるローカルシステムへDISCを送る。端末のケーブルもポートもローカルLLCも正常でありながら、中間の共通依存が消えたためにセッションが終わる。

同時刻に十件の端末切断が起きても、根本原因は一件のトランスポート障害かもしれない。逆に一件のTCPアラームだけでは、十回線の影響を隠す。原因の集約と影響の展開を同じイベント関係として保存しなければならない。

通常の切断にはHALT_DLとDL_HALTEDがあり、片側のDLCエラーから切断状態へ移る経路もある。画面上は同じ「切断」でも、ローカルリンク、遠隔リンク、個別回線、共通トランスポートのどこが最初に変化したかで責任は異なる。

改訂は新しい運用面を可視化した

RFC 1795はRFC 1434を大幅に変更し、置き換えた。APPN Implementers WorkshopのDLSwグループは、複数ベンダーが実装できる単一のSSPを作り、旧文書の問題を修正しようとした。トランスポート成立後に能力交換を置き、通常の回線制御へ進む前の準備状態を明確にした。

RFC 2024のMIBでは、トランスポートはconnecting、初期能力交換、connected、quiescing、disconnecting、disconnectedに分けられた。回線作成数、探索、切断理由も管理対象になった。プロトコルが最初から持っていた複数の真実を、運用がようやく別々に観測できるようにしたのである。

RFC 2166は規模の問題を列挙した。多数のピア設定、点対点接続ごとの探索・NetBIOS複製、常設トランスポート、中央での大量LLC2終端が負担になる。v2.0は切断理由、マルチキャスト探索、オンデマンド接続、対応ピア間の単一双方向TCPなどを導入した。

後世の機能を1993年へ持ち込んではならない。改訂史から読めるのは、状態をローカルへ移せば状態が消えるのではなく、新しい交渉、観測、拡張性の責任が生まれるということである。

アプリケーションの手前で証拠を止めない

監査可能な記録には、ピアとトランスポート状態、検索したData Link ID、全ICANREACHと選択結果、両Circuit ID、CONTACT／CONTACTED、両側DLC、送信許可、データ計数、最初の切断理由が要る。アプリケーション応答は別の証拠として結び付ける。

RFC 1434とRFC 1795は、どちらもセキュリティ問題を論じていない。従って本文だけから、ピア認証、端末の権限、機密性、敵対者に対する完全性を導いてはいけない。TCPの信頼性は定められたモデル内の配送特性であり、安全性の判定ではない。

また、RFCは特定ベンダーへの普及、実トラフィック、現代の利用、実事故を証明しない。歴史的な重要性は、一つに見える会話を責任の単位へ戻した点にある。ローカル確認と遠隔接触、回線とトランスポート、送信許可と利用結果は、近く見えても同じ証拠ではない。

出典