要約

  • RFC 3186 は入口で PPP/POS フレームの先頭 1〜2 オクテットを MAPOS 宛先へ変え、出口で元に戻すことで、追加ヘッダーなしの点対点リンクを CPE に見せた。
  • 実際の経路は二つのポートモード、未使用の MAPOS アドレス対、両方向の安定した転送、経路分離に依存した。OAM データベースは経路を記述しても転送はしなかった。

文書は 2001 年 12 月の Informational RFC である。IESG Note は、IETF ワーキンググループの成果でも Standards Track でもなく、同等の広範な審査を受けたとは限らないと明記した。参照実装と測定は当時の証拠であり、普遍的な採用証明ではない。

仕組みはフレーム形式の近さを利用した。PPP over SONET/SDH の先頭には固定値があり、MAPOS は同じ付近を内部宛先に使った。入口スイッチは固定値を相手側ポートの MAPOS アドレスへ置換し、網内で転送し、出口で PPP の値へ復元した。

CPE からは新しいカプセル化が見えない。だが状態がないわけではない。書き換え先、ポートモード、C2、内部ルート、ポート対応、分離規則がスイッチへ移った。透明性とは、複雑さの削除ではなく観測境界の変更だった。

PPP トンネルモードへの移行は複数操作である。顧客ポートの NSP と SSP を止め、MAPOS の broadcast/multicast を止め、scrambling に応じて C2 を設定し、指定宛先への書き換えを有効にする。MAPOS モードへ戻るときは逆順だった。

管理画面が一つのモード名を示しても、実装は段階を踏む。片側だけ完了した状態、C2 だけ変わった状態、書き換え先が誤った状態を区別しなければならない。

経路確立では、運用者が未使用の MAPOS アドレス対を選んだ。文書の設計ではアドレスとスイッチポートが一対一に対応する。両端を設定し、両方向の route と frame forwarding が安定してから経路を成立とした。それまでは CPE 側リンクを down に保つべきだった。

アドレス対は管理対象の識別子であって、到達性そのものではない。二つの値が登録されたことは、両方向の収束、正しい書き換え、特定フレームの到着を証明しない。

RFC は重複設定を避けるため path database を提案した。例には利用者、速度、モード、アドレス対、状態が並ぶ。ただし database は OAM&P 専用で、frame forwarding には使われないと明記された。

したがって “Up and running” は運用上の主張である。実際の転送は SSP、ポート、書き換え機能に依存する。データベースが正しくても次のフレームが届く保証はなく、転送変更が先で台帳更新が後になることもある。

撤去も別々の行為だった。両側の CPE ポートを無効にし、database を更新し、必要なら MAPOS 既定へ戻す。宛先ポート無効化後のフレームは黙って捨てる。送信者には、どの操作が沈黙を生んだか分からない。

障害通知では観測点が分かれる。近端の CPE 接続が切れると、その CPE と MAPOS edge は SONET/SDH alarm を見る。遠端の光状態は上がったままで、LCP Echo の期限切れ後に “link up, line protocol down” となる。

Echo timeout は期待応答が期限内になかった証拠にすぎない。故障箇所、単方向か全断か、アプリケーション結果までは示さない。網内では SSP が topology change を処理していても、CPE が持つのは端から端の症状だけである。

点対点の見た目は専用容量も意味しなかった。MAPOS に protocol-level QoS はなく、POS に flow control はない。RFC は end-to-end throughput の保証が難しいと認め、十分な inter-switch capacity と oversubscription 時の per-port fairness を求めた。

latency test には範囲がある。指定された機器、OC12c の片方向 30% load、固定された framing、frame size ごとに 150 秒を 25 回という条件だった。その比較で MAPOS switch は router より低遅延だったが、全負荷、全ベンダー、損失や公平性を代表しない。

security section は、CPE が内部 MAPOS を制御できず別 stream の注入も難しいとした。同時に path duplication を避け、per-path isolation を極めて重要とし、全 switch に isolation が入るまで native MAPOS と PPP tunnel の混在を勧めなかった。

MAPOS frame に source address field がないため、混在環境の帰属判定は難しい。CPE に内部が見えないことと、内部で完全に分離されていることは別の主張だった。

RFC 3186 の教訓は、透明な抽象を捨てることではない。抽象の下の権力と証拠を残すことである。service order、address pair、port、各 transition、方向別 convergence、database revision、isolation、alarm、LCP Echo、frame observation を別々に保存して初めて、簡単なリンク表示を説明できる。