要約

  • 同じISDN設備の複数サービスからPPPを選ぶために着番号情報を使えたが、それはローカル交換機の情報であり、端点を開放する命令ではなかった。
  • LCPに管理上のOpenがなければ着信を拒否しなければならず、受け入れた後で切断したりパケットを無視したりする処理は禁止された。
  • 受け入れ後にも符号化、フレーミング、下位層Up、LCP Opened、認証、NCP、アプリケーション結果が別々に残った。

受け入れてから拒むのでは遅い

1994年5月のRFC 1618は、ISDN交換回線上でPPPを扱う共通点を定めた。世界を一つの均質なISDNにできるとは考えず、交換機、加入条件、端末の多様性の中から少数の既定値を選んだ。相互運用のための出発点は、配備全体が同一だという宣言ではない。

BチャネルはPPPに適したポイントツーポイントのベアラで、PRIは多数を同時に提供できた。Dチャネルも適切なフレームならPPPを運べたが、容量が小さく、ローカル交換機までに制限される場合が多かった。回線が存在するという事実は、そこでPPPを受け入れるという決定を含まない。

一つの物理設備に複数の電話番号を結び、それぞれを別サービスに割り当てることもできた。ローカル交換機が渡す着番号識別子は、発信者がどの入口を選んだかを示す。しかし、発信者の身元、遠隔側の権限、端点の現在の許可までは示さない。

帯域外フィールドは途中で意味を失った

LLC Information Elementなら、データ交換より前に符号化やフレーミングを知らせられそうだった。ところがRFCが記録した経験では、対応交換機が少なく、事業者ごとの加入方針も異なり、LLC-IEはエンドツーエンドで確実に届かなかった。

PPP用の値はまだ割り当てられておらず、別の値をPPPリンクの根拠にはできなかった。RFCは、この情報要素にフレーミングや符号化の決定を依存させてはならないとした。

問題はフィールド形式ではなく、その意味を運ぶ制度的な経路だった。中間交換機や契約条件の一つが情報を落とせば、送信側の宣言は受信側の事実にならない。そこで文書は、より狭いが所在の明確な着番号情報と、端点自身の判断を組み合わせた。

Openを出すのは人またはローカルプログラム

着番号情報を使う場合、あるいは将来PPP用LLC値を受け取る場合でも、LCPに管理上のOpenがなければ着信は拒否される。いったん回線を受けてから閉じることも、パケットだけを無視することも認められなかった。

同時期のRFC 1548と後継のRFC 1661では、Openはネットワーク管理者、すなわち人またはプログラムがリンクの開放を許した外部イベントである。下位層が利用可能と伝えるUpとは違う。LCPの設定交換後に達するOpenedとも違う。

交換機、ローカル管理、対向端点という三つの主体が、それぞれ回線提示、利用許可、設定合意を担当した。名前が似ているからといって、一つの状態表示にまとめればよいわけではない。

早い拒否は資源だけでなく説明責任も守った。受け入れ後の無応答は、符号化不一致、相手の故障、損失、管理方針のどれにも見える。入口で拒否すれば、既に存在していた「使わせない」という決定を故障に変換せずに済む。

検出は推測ではなく、期限付きの試行だった

管理上開いていても、ビット表現は未確定だった。PPPから見たISDNチャネルは全二重の同期リンクだが、符号化とスクランブルはDTE/DCE装置の責任で、PPPの範囲外である。RFC 1618はT点でNRZを既定とし、NRZIを設定可能な代替として認め、古い反転NRZを非推奨にした。

複数の単純な符号化に対応する装置は、モードを順に切り替えるしかなかった。各モードでLCP Configure-Requestを二度送り、応答時間を確保して次へ進む。全試行は59秒未満、できれば通常の30秒以内で終える必要があった。

つまり自動検出は、隠れたラベルを読む処理ではない。時間とチャネルを消費する実験である。無応答は次の試行を許すだけで、原因を確定しない。そのため回数と終了条件が制御面になった。

事前設定がなければBチャネルはビット同期HDLCから始め、オクテット境界を利用できる場合だけ設定済みのオクテット同期HDLCを使った。複数のフレーミングを一つのチャネルで同時に走らせることも推奨されなかった。RFC 1549はNRZIと16ビットFCSの検出性低下を結び付け、32ビットFCSの交渉を勧めている。キャリアが上がっただけでは、完全性条件まで一致しない。

この用途のV.120は、フレームリレーとの識別が難しくなり得るため非推奨とされ、代わりにフレームリレー内でPPPを運ぶ方法が勧められた。これは相互運用の選択であり、特定の着信でどちらかが使われた証拠ではない。

待ち行列が次の発呼を作る

ネットワーク層MTUは1500以下が推奨され、例外は対向との明示的な交渉で少なくとも2048のMRUを得た場合だった。再起動タイマは250ミリ秒から3秒まで指数バックオフすることが勧められた。デマンドダイヤルや再発呼には持続上限が必要で、確立失敗後に送信キューを捨てれば、再発呼を刺激していたパケットを一時的に除けた。

パケットが発呼を起こし、失敗後も残り、また発呼を起こす。上限がなければ一つの要求が回線利用を繰り返す。一方、記録せずにキューを消せば原因も消える。試行を止める権限と、止めた理由を残す責任は同じではない。

RFC 1618は独自の初期化を持つBONDINGよりPPP Multilinkを勧めた。RFC 1990は後に複数ISDNチャネルを束ねる仕組みを規定したが、物理リンクの並存だけではbundleにならない。LCPオプションの合意が必要だった。

着信後に続く証拠

回線を受けても、適切な符号化とフレーム、下位層Up、LCP Opened、必要なら認証成功、対象NCP Openedが順に必要だった。その後のデータグラム通過もアプリケーション完了とは別である。

RFC Editorの記録が証明するのは出版、著者、現在のProposed Standard表示であり、製品実装や現在の利用ではない。RFC 1618はセキュリティを論じていないので、着番号情報を発信者認証に読み替えてはならない。

Heng LuのRunning-Code Primacyに従えば、フィールドと設定は入力で、実際の拒否と稼働結果は別の現実層である。Minimum Initial Specificationは、共通規則を狭く保ちつつ採用判断をローカルに残す理由を示す。

交換機はサービスを示せた。しかし、端点の管理者に代わってそれを開くことはできなかった。RFC 1618は沈黙より先に拒否を置き、判断の所在を見えるままにした。

出典