要約

  • RFC 3472 は GMPLS の機能を CR-LDP の REQUEST、MAPPING、TLV に具体化し、上り方向は下りラベルの帰着前に利用可能になり得た。
  • 転送済み REQUEST、有効な Upstream Label、片方向の最初の通信は部分的な証拠であり、双方向経路やサービスの完成証明ではなかった。

「双方向」という語は、一つのものが同時に完成する印象を与える。RFC 3472 の手順では、二つの方向が異なる時刻に現実になった。

2003年1月に標準化過程の文書として公開された RFC 3472 は、RFC 3471 の一般機能を CR-LDP のメッセージと TLV へ落とし込んだ。要求、汎用ラベル、波長帯、候補、集合、保護、管理状態、インターフェースを具体的に符号化した。RSVP-TE 版は RFC 3473 である。

双方向 LSP の REQUEST には Upstream Label が入った。そのラベルは送信時点で転送に有効でなければならない。受信ノードは受入可能性を検査する。中間ノードは REQUEST を先へ送る前に、上り用の出力ラベルを割り当て、ローカル区間を結ぶ内部データ経路を確立しなければならなかった。

これは将来の設定予約ではない。通過済みノードは、自分の上り部分を先に利用可能にした。REQUEST が終端へ届くと、終端は Upstream Label を使い、発信側へ直ちに通信を送ることができた。

反対方向は別の時間軸を進む。下り用 Generalized Label は MAPPING で発信側へ戻り、各ホップで受容・設置される。したがって、上り通信が存在する一方、最後の下り MAPPING がまだ入口へ届いていない状態は、正当な途中状態だった。

「双方向要求が終端へ届いた」という記録は、上りチェーンを示しても、二方向の完了を示さない。下りラベルの設置、物理的連続性、往復を必要とするアプリケーションの成功は別の証拠である。

Generalized Label Request の検査も分散していた。入口が Encoding Type と G-PID を置き、Switching Type はホップごとに変わり得る。各ノードは入力、自身、出力またはトンネルを検証した。Forwarding Adjacency を作るか使うかはローカル方針だった。REQUEST が進んだ事実は、全ノードで同じ検査が終わったことを意味しない。

G-PID は通常、出口で初めて本格的に調べられた。PSC/PHP では直前ホップに例外がある。途中でエラーがなかったことを、顧客ペイロードの最終承認に置き換えてはならない。

Suggested Label の誤りは無視された。下流が別ラベルを返せば、上流は再設定するか拒否する。入口は対応する下流ラベルが戻るまで、候補値だけでデータを送るべきではなかった。先行準備と割り当て権限は違う。

Label Set は許容性と在庫を分けた。個別値や範囲を追加・除外でき、TLV がない場合は全値が許容されるだけで、空きとは限らない。各ノードは受信集合と下流インターフェースの利用可能資源を交差させ、空集合なら要求を終了した。

交差は物理波長を基準にした。同じ物理資源にリンクごとで異なる論理値が付くため、ノードは一貫した物理意味へ変換し、できなければ値を落とした。変換可能なノードは Label Set を外して転送でき、最終メッセージには過去の制約がすべて残らない。

波長帯が鏡像変換される場合、開始と終了のラベルを入れ替えた。双方向トンネルでは両方向に必要だった。論理的に同じ幅でも、物理的な波長対応が同じとは限らない。

Explicit Label Control は Label ER-Hop を直前のアドレスまたは IF_ID に結び付けた。順序や方向ビットの矛盾は経路エラーになる。ただし先頭ノードが必要情報を得る方法は範囲外だった。

制御とデータが分離されると、IF_ID が実データチャネルを示し MAPPING で返された。帯域外制御の障害は既存光接続へ影響させるべきではない。逆に制御セッションの復旧は古い交差接続の正しさを証明しない。

CR-LDP には RSVP 固有の高速障害通知がなく、RELEASE と WITHDRAW が障害点から外へ進んで資源を解放した。削除時は上下両ラベルが無効になる。その後の転送は承認済み継続ではなく、残留状態である。

RFC 3468 は後に、IETF が CR-LDP の標準化作業を止め RSVP-TE を選ぶ決定を記録した。制度上の結末は重要だが、技術上の途中状態を消したり、全実装の即時撤去を証明したりはしない。

Heng Lu の running-code 原則は、メッセージと効果を分ける。最小仕様はローカル方針を残し、現実の層は受入、割当、内部接続、MAPPING、方向別通信、アプリケーション結果を別々に保つ。

誠実な記録は REQUEST、各ホップの判断と上り割当、終端受入、上り最初の通信、各下り MAPPING、両方向の観測、最後の解放を保存する。これらがそろって初めて「双方向」は要求の属性からサービスの事実になる。

情報源