要約

  • RFC 2129では、PROPOSE と PROPOSE ACK が隣接する二つの装置のDedicated-VCとVCIDを確かめる。後の OFFER と READY が、特定の送信元・宛先IPv4アドレスのフローをその回線に結び付ける。
  • その対応付けは拒否も失効もあり得るソフトステートだ。一つの応答から全経路の整合性、配送、継続的な容量、QoSを読み取ることはできない。

最初の返答が答えていないこと

上流の装置は、まずDedicated-VCを選ぶ。その回線上でVCIDと下流の宛先IPアドレスを載せた PROPOSE を送る。相手が受け入れれば PROPOSE ACK がDefault-VCを通って返る。通常のIP処理に使うDefault-VCは、ここでは制御の返答経路でもある。この交換で双方は同じ隣接回線を指せるようになり、回線と相手が機能していることを確かめる。しかし、どのフローを流すかはまだ決まっていない。

次の OFFER はDefault-VC上でVCID、flow-ID、READY の更新間隔を示す。下流が同じ経路で READY を返して初めて、そのフローのパケットをDedicated-VCで受け取れるという応答になる。提案を送信した事実と受諾の返答は違う。さらに、返答したのは一つの隣接装置であって、経路上の全装置ではない。RFC 2129 の三台のルーターの例でも、次の区間の手順は独立して行われる。

この文書はInformationalであり、インターネット標準を定めたものではない。FANPが扱うのは、パケットフローとコネクション型データリンクの接続との局所的な対応付けである。Default-VCでは従来どおりIPヘッダーを見て転送できる。一方、適合するセルスイッチルーターは、選ばれたフローに対してデータリンクの接続識別子で転送し、各地点の通常のIP処理を省ける。この一地点の処理短縮を、端から端までの通行証と見なすのは行き過ぎだ。

待ち時間と空き回線の交換

きっかけとなるパケットは、TCP/UDPのポート番号などを材料に各ノードの方針で選ぶ。長寿命または大量のパケットを運ぶセッションが例示されている。専用回線はあらかじめ作った未使用のプールから取り出せるし、必要になってからATMシグナリングで確立することもできる。前者は起動を速くする一方、使わない回線資源を確保しておく。後者は空き資源を節約するが、設定の時間がかかる。RFCが示すのは局所的な費用と応答性の選択であり、実ネットワークの節約実績ではない。

名前にも注意が要る。この文書のflow-IDは送信元と宛先のIPv4アドレスだけで、IPv6のフローラベルとは異なる。VCIDは、両端でVPI/VCI値が一致しない場合にも隣接回線を指すための識別子だ。どちらも送信者の認証にはならない。複数フローの集約、マルチキャスト、IP層のQoSシグナリング、IPv6対応は将来の課題として列挙されている。

消えていく対応付け

下流は方針、未知のVCID種別、資源不足などを理由に最初の提案を拒める。二度目も未知のVCIDやflow-ID種別、フロー方針、更新間隔の不一致で失敗し得る。返答が来なければ再送するが、文書が推奨する五回の再送を経ても確認できない場合は選んだ回線を解放する。無応答を黙認と解釈する仕組みではない。

受け入れ後、下流はDedicated-VCでパケットを受けている間、周期的に READY を送り続ける。パケットが来なくなれば送らず、上流は一定時間更新を受けないとflow-IDとVCIDの対応を消す。上流が通知せず停止しても、下流は無通信が長引けば自分の対応を消す。更新二分、上流の失効六分、下流の除去二十分は推奨例であり、普遍的なサービス保証ではない。回線の種類によって明示的な REMOVE/REMOVE ACK やATMでの解放もある。

したがって、選んだ回線、受け取ったACK、返ってきたREADY、後日の更新は別々の証拠になる。起点の真正性、各区間の一致、宛先への配送、容量やQoS、経済効果を自動的には証明しない。RFC 2098 が示したバイパス構造の隣で、RFC 2129は近道を保つために必要な、隣同士の絶え間ない照合作業を可視化した。

出典