要約

  • RFC 2098 は、選ばれたフローを隣接 ATM 仮想回線の連結で複数の Cell Switch Router に通し、各段でのデータグラム再構成と IP ヘッダー処理を省く構想を示した。
  • IP ルーティングはサブネット間の CSR 列と出口を選び続け、ATM ルーティングは隣接ノード間の局所的な VC 経路だけを選んだ。
  • 設置済みの bypass-pipe が示すのは転送状態であり、最適経路、資源予約、認可、主体の同一性、配送、経路変更後の有効性ではない。

セル単位の近道が始まる場所

RFC 2098 が描いた CSR は、通常の IP 転送機能に ATM セル交換を加えた装置だ。セルが入ると、入力インターフェースと VPI/VCI の組を調べる。ATM 表に出力インターフェースと新しい VPI/VCI があれば、そのままスイッチ・モジュールへ送る。なければセルをデータグラムに戻し、IP モジュールで次の出力を決める。

選択済みフローは、中間ルーターごとの再構成とヘッダー処理を避けられる。だが ATM 表のヒットは新たな経路計算ではない。別の層が決めたことを高速に実行する状態である。

文書は 1997 年 2 月に Informational として公開され、Internet Standard ではないと明記する。IETF Datatracker は現在これを Legacy とし、IETF の標準化過程で正式な位置づけを持たないと説明する。RFC Editor の正誤表検索 に該当項目はない。これは構想の一次記録であって、製品、普及、性能測定の証明ではない。

一本に見える管は複数の局所回線だった

Default-VC は通常のホップ単位 IP 転送に使われる。そこから来たセルはデータグラムへ再構成される。専用状態がまだない間も通信を続けられ、近道が崩れたときの通常経路にもなる。

Dedicated-VC は、アドレス、ポート、IPv6 フローラベルなどで選ばれたフローを収容する。同じフロー用の入力 VC と出力 VC がそろえば、CSR は両者を連結できる。複数の CSR が連続してこれを行うと、ATM Bypass-pipe になる。

RFC は、この管を一つの ATM クラウドが提供する単一 VCC と区別した。実体は隣接ノードを結ぶ複数の区間であり、各区間に設定方法、サービスクラス、寿命がある。端から端まで滑らかに見えても、制御点は一つではない。

IP が順序を決め、ATM は区間内を選んだ

RFC の例では、通常転送でも bypass-pipe でも X.1、CSR1、CSR2、Z.1 の順に進む。IP ルーティングが ATM クラウドの出口と、サブネット間で通る CSR の列を決める。ATM ルーティングが扱うのは、隣接ノード間の各 VC がサブネット内をどう進むかだけである。

この分担は最適性にも限界を置く。文書自身が、サブネット境界のルーターを通るため、端から端の ATM 経路は NHRP モデルより最適でない場合があると述べる。高速なセル列が見えても、分かるのは現在の IP 経路に沿って区間が設置されたことまでだ。ATM 全体で最良の経路を選んだ証拠にはならない。

RFC 1932 は、正しい転送判断に必要な情報を交換する routing と、その判断をパケットに適用する forwarding を分ける。RFC 2098 は後者を速めたが、前者の記録を消してはいない。

Classical IP と NHRP は別の境界を選んだ

RFC 1577 の Classical IP は、同じ Logical IP Subnetwork 内では ATM で直接つなぎ、境界を越えるとルーターを使う。RFC 2225 は後に、拡張がない場合や失敗した場合にも使える安定した基礎としてこのモデルを残した。

NHRP は、複数 LIS の向こうにある宛先へ近い NBMA 次ホップを解決する。RFC 2332 により、送信元はより直接的な接続を張れる。CSR モデルはルーター列を保ち、その列に沿ってデータだけを加速する。Classical IP のままでも、クラウド全体を一本で抜く NHRP 接続でもない。

BTW の近接記事も領域が異なる。RFC 1953 は一つのリンク上の拒否可能で期限付きの IFMP ラベル、RFC 1954 は受理済みラベルの ATM 表現、RFC 2022 はマルチキャスト受信者一覧と送信者が作る回線の違いを扱う。本稿の中心は複数 CSR の連結と、その上位に残った IP 経路権限である。

経路が変われば、以前の表は過去の証拠になる

RFC 2098 は bypass-pipe を固定物としない。IP 経路が変われば関係する CSR が区間を変え、ノード、リンク、ルーターの障害でも同様に修復する。必ずしも管全体を最初から作り直す必要はない、という構想だった。

しかし、それは実装の成功を保証しない。現実のフローが妥当な経路を使い続けたと示すには、経路表の版、CSR 列、全隣接 VC、状態の期限、障害通知、修復動作、修復後のトラフィック観測が要る。残っている VPI/VCI エントリーは、現行状態かもしれず、すでに根拠を失った近道かもしれない。

低遅延は予約品質ではなかった

トラフィック量の観測や FTP、NNTP、HTTP の検出から、短期の近道を起動する案があった。目的は中間 IP 処理とバースト転送の遅延を減らすことだ。端末から帯域や QoS の明示要求がないため帯域決定の規則はなく、容易な UBR を使ってもセル損失品質は保証されない。

別の案は RSVP のような明示要求から始まる。RFC 2205 の RSVP は、routing が選んだ経路上で資源を要求する制御プロトコルであり、routing protocol ではない。Dedicated-VC の存在だけで予約を証明できず、RSVP 要求だけで bypass の設置やサービス結果を証明することもできない。

RFC 2098 は security issues を論じていない。フロー分類や VPI/VCI 対応は、利用者、アプリケーション、権限の認証ではない。

高速状態は権限ではなく実行記録である

Lu Heng の Running-Code Primacy は、技術的主張を実際に動くものへ戻す。Minimum Initial Specification は共通層と後の局所判断を分ける。Reality Layers は、記述が実行結果の証拠を借りる危険を示す。

RFC 2098 では、IP routing がサブネット間到達性の共通記録を持ち、ATM 状態が選択済みフローを局所的に加速する。セルが実際に通った事実は重要だが、それが語れるのは一時点の実行までである。経路の正当性や最終結果まで代弁はできない。

情報源