要約

  • 通常のPPP/HDLCフレーミングは非番号制のUIを用いる。RFC 1663のNumbered Modeは、必要な二者だけがLCPで選択する任意機能として、単一リンクに受信窓、確認応答、再送タイマー、失敗時の復帰手順を加えた。
  • 両端の窓サイズは違ってよいが、8未満ならmodulo 8、8以上ならmodulo 128という系列を共有しなければならない。Magic-Numberは開始役を決める材料であり、身元証明ではない。
  • SABM/SABMEとUAが閉じるのは番号制リンクの確立だけである。その後の認証、リンク品質判定、NCP、経路制御、アプリケーション処理は、それぞれ別の記録を必要とする。

信頼性は既定値ではなかった

HDLC風の伝送路を使う通常のPPPでは、AddressはAll-Stations、ControlはUnnumbered Informationの値を取る。各パケットはデータグラムとして扱われ、FCSが合わないフレームは破棄される。リンク層が必ず欠落を埋める、という約束はない。

それで十分な通信は多い。しかし、隣り合うデータグラムが状態を共有すると事情が変わる。RFC 1663は圧縮辞書を例に挙げた。一つの圧縮データグラムが失われると、受信側の辞書が送信側からずれ、後続フレームが壊れていなくても展開できなくなる場合がある。容易にリセットできる方式なら再送は不要かもしれない。状態回復の費用が高い方式では、リンク内の順序付き配送に価値が生まれる。

IETFのPPP Working Groupは、この必要性を全リンクの義務にはしなかった。1994年7月のRFC 1663は、LCP Configuration Option 11、Numbered-Modeを提示した。Link Establishment中に一方が要求し、相手が受け入れたときだけ有効になる。既定のUI方式は残った。

この任意性は単なる互換性配慮ではない。共通仕様が判断すべき範囲を狭くしたのである。状態を共有する二者は信頼性の費用を選べる。そうでない実装まで窓や再送を抱える必要はない。

AddressとControlが状態を運んだ

Numbered Modeになっても、PPPのProtocol、Information、Padding、FCS、Flagの役割は変わらない。番号と制御を担うのはAddressとControlであり、手続きはISO 7776 LAPBの番号制を利用する。モード成立後は、リンク上の全フレームが番号制でなければならない。都合に応じてUIと混ぜる設計ではない。

ここでAddress-and-Control-Field Compressionとの衝突が生じる。通常の ff 03 は一定なので省略できるが、番号制ではその二つのフィールドがアドレスやシーケンス情報を運ぶ。RFC 1663はACFCを交渉してはならないとした。RFC 1662の一般則も、標準外のAddressやControlを使うなら事前合意が必要で、既定値のように圧縮できないとする。

FCSは変更後のAddressとControlを含めて計算される。したがって正しいFCSは、受信ビット列に対する強い局所証拠になる。しかし、そのフレームが今の交渉時点に属するか、双方が同じ状態機械にいるかまでは示さない。整合したビット列と整合した状態は別物である。

窓は容量だけでなく文法を選んだ

Numbered-ModeオプションのWindowは1から127までである。受信側が保持できるフレーム数を伝えると同時に、送信側が確認なしに送ってよい未確認フレーム数の上限となる。窓は速度のための数字であると同時に、不確実な作業量の上限でもあった。

値が8未満ならmodulo 8、8以上ならmodulo 128を用いる。両端が異なる窓を示すことは許される。メモリ容量は対称とは限らないからだ。しかしmodulusが違ってはならない。三ビットで巡回する番号と七ビットで読む番号は、性能設定の差ではなくプロトコル文法の不一致になる。

Configure-Nakが示せるのは、提示値以下の窓である。受信側は自分が支えられない容量を約束せずに済み、応答によって相手をより大きな系列へ押し上げることもない。番号空間を広げるには、明示した提案が必要だった。

同じオプションにはHDLC Addressも含まれる。ゼロは最終値にできず、適切な値を添えてNakされる。衝突時には窓とアドレスの比較による規則があり、それでも決まらない限定的な場合だけ乱数に頼る。ここで得られるのはリンク形成のための役割分担であり、企業名や装置所有者の証明ではない。

先に話す者をMagic-Numberで決めた

Numbered ModeではMagic-Numberの交渉が必須である。LCPが構成を受理した後、数値の小さいMagic-Numberを持つ側が、modulo 8ならSABM、modulo 128ならSABMEを送り、相手がUAで応答する。この規則により、二者は別の調停者なしで開始役を選べた。

確立メッセージやUAが失われた場合は、LCPのRestart Timerとカウンターが再試行を制御する。UAは重要だが、意味を膨らませてはならない。それは隣接相手が番号制リンクの確立に応じたことを示す。PPPでは、その後に認証、Link Quality Determination、NCP構成が続く。UAだけでは資格情報の受理、品質基準の達成、IP設定、経路到達性、遠隔サービスの処理完了を証明できない。

Magic-Numberも認証情報ではない。リンクのループ検出や開始役の選択に役立つが、署名でも権限でもない。RFC 1663はセキュリティ問題を論じていない。順序付き配送と相手への信頼は、別の機構で確立する必要がある。

共有状態を失ったときの出口

再送機構は、双方が同じ状態を失ったときに止まれなければ危険である。RFC 1663は、片側だけが番号制を信じ続ける事態に具体的な応答を与えた。

再交渉は番号制のまま進めるが、Numbered-Modeオプションが成立しなければ、認証や品質判定、NCPへ移る前にUIへ戻る。番号制を実装していても現在UI状態の装置が、正しいFCSを持つ非UIフレームを受けた場合はDMを返し、直ちにLCP交渉を再開する。番号制の装置がDMを受けた場合もUIへ戻り、新しいConfigure-Requestを送る。

これにより、FCSが正しいという事実だけで古い制御状態が復活することはない。不一致はDMとLCP再開という観測可能な遷移になる。

個々の再送も無限ではない。T1はIフレームへの応答を待つ最大時間で、経過すれば再送する。LAPBの実測往復時間から動的に決めることが推奨され、測れない場合にはフレーム長、ビットレート、処理時間に基づく式が用意された。T3はアイドル状態を示し、T1より大きくなければならない。N2は一フレームの最大試行回数で、超えればリンクを終了すべきとされ、既定の推奨値は3だった。

この「3」はサービス全体の再試行方針ではない。リンク手続きの局所的な打ち切り線である。N2超過は無応答の原因を語らず、アプリケーションの要求が実行されたかどうかも語らない。

複数リンクには別の合意が要る

同じ装置間に複数のPPPリンクがあっても、既定では各リンクが独立に確立、構成、終了される。順序に依存する圧縮状態も、別の結合手続きがなければリンクごとに保たれる。

RFC 1663はISO Multi-Link方式に触れたが、その実装を非推奨とし、後にRFC 1990となるPPP Multilinkを推した。Numbered Modeは一つのメンバーリンク内の配送を整える。Multilinkは複数リンクを束ね、断片を組み戻す共通シーケンスを作る。似た語彙があっても同じ契約ではない。

したがって、番号制の確認応答は一つのリンク、一組のアドレス、一つのmodulus、一回の交渉状態に結び付く。他の物理リンクやルーターの向こう側へ、その証拠を持ち越すことはできない。

小さな証拠を小さいまま使う

IANA台帳でLCPオプション11がNumbered-Modeに割り当てられていることは、共通の語彙を保証する。Configure-Ackは特定時点の提案受理を示す。SABM/SABMEとUAは番号制手続きの確立を示す。シーケンス、確認、再送の記録は一つのリンク内で何が進んだかを支える。DM、LCP再開、N2超過は、その状態が失われたことを示す。

だが、認証には認証記録、品質には測定と局所基準、ネットワーク層にはNCP、到達性には経路情報、アプリケーション完了にはアプリケーション固有の応答が要る。下位層の証拠を上位層の結論へ昇格させると、観測は増えたのに説明能力が下がる。

RFC 1663が残した教訓は、信頼性を大きな一語で約束することではない。二つの隣接実装が必要な場合に限り、序号の文法、未確認量、再送、状態喪失からの復帰を共有することだった。確認応答はリンクで止まったからこそ、何を確認したかが明確だった。

情報源