要約

  • RFC 3476 は OIF の光 UNI 用フィールドを LDP と RSVP の公開名前空間へ置いた一方、内容と使用法の多くを OIF UNI 仕様へ委ねた。
  • 経路分離やサービスレベルの不足、未知の接続 ID、権限のない送信者・受信者という拒否理由は、正しく解釈された番号がサービス完了の証拠ではないことを物語る。

プロトコル登録簿が扱うのは、ごく小さな資源である。名前と数値、それを説明する仕様への参照だ。しかし同じ値を二つの実装が異なる意味に読めば、同一のビット列から異なる行動が生まれる。登録はこの衝突を防ぐ。光路を作ることまではできない。

2003 年 3 月に公開された RFC 3476 は Informational であり、Internet Standard ではなかった。Optical Internetworking Forum は光 User Network Interface、すなわち UNI のシグナリングを設計していた。LDP、RSVP、RSVP-TE、GMPLS を最大限再利用し、UNI 固有の部分だけを追加する方針だった。その追加部分が既存プロトコルを通るには、IANA が管理する空間で一意の値を持つ必要があった。

LDP 側では、IPv4、IPv6、NSAP に対応する三種ずつの Source ID と Destination ID TLV が示された。さらに Egress Label、Local Connection ID、Diversity、Contract ID、UNI Service Level が 0x0960 から 0x0970 の範囲に割り当てられた。RSVP 側には class number 229、C-Type 1 の GENERALIZED_UNI と、class 1、C-Type 11 の UNI_IPv4_SESSION が加わった。前者のサブオブジェクトは、送信元・宛先 TNA、経路分離、出口ラベル、サービスレベルを運べた。

ただし、RFC は数値表をサービス仕様として扱わなかった。各 TLV の内容と使用法は OIF UNI 仕様にある、と繰り返した。公開番号は安定した参照点を作る。外部仕様が意味を与える。実際のネットワークは、その後で主体を確認し、権限を判断し、資源を探し、要求を受け入れるか拒む。

ここには組織間の境界がある。OIF はサービス側の合意を作り、IETF は再利用可能なプロトコルを整え、IANA は数値空間の衝突を防ぎ、ベンダーは状態機械を実装し、運用者は物理設備と容量を支配する。RFC に載ったからといって OIF サービスが IETF 標準になるわけではない。IANA 登録が運用者の承認を代行することもない。

公開値だけが歴史ではなかった。UNI 固有の LDP status code は 0x3Fxxxxxx の Private Use 空間を使い、IANA 管理を必要としなかった。Status Enquiry と Status Response はすでに廃止され、番号申請の対象外となった。登録簿は全ての構想を保存した一覧ではなく、公開登録するもの、私用に残すもの、採用前に捨てるものを選んだ結果だった。

もっとも雄弁なのは RSVP のエラーである。Diversity not available、Service level not available、Invalid/Unknown connection ID が Routing Problem の下に置かれた。Unauthorized sender と Unauthorized receiver は Policy Control Failure の下に置かれた。いずれも番号が理解されなかったというエラーではない。番号を理解した後に、資源や政策の層が「できない」「許さない」と答えたのである。

正しい GENERALIZED_UNI オブジェクトを考えよう。class、C-Type、長さ、サブオブジェクトがすべて妥当で、TNA も読める。それでも送信者に契約上の権限があるとは限らず、受信者が同意しているとも限らない。独立した二経路が本当に存在するか、空き容量があるかも分からない。構文の妥当性と運用上の実現可能性は別の証拠である。

コードポイントが述べるのは「このビットをこの種類のオブジェクトとして解釈せよ」という一点だ。「この主体に従え」「この契約を受け入れよ」「この波長を確保せよ」「顧客への提供が完了した」とは述べない。最初の命題を後の命題とまとめると、登録照合という弱い受領記録が、運用判断全体の権威を借りてしまう。

基礎 RFC も層を分けていた。RSVP は予約状態を扱い、RSVP-TE はトンネルシグナリングを加え、LDP はラベルを配布し、GMPLS はラベルをパケット以外の交換資源へ広げた。RFC 3471 から 3475 は、識別子、メッセージ往復、通知、Call、Connection を区別している。RFC 3476 は UNI の語彙を名前空間へ接続したのであって、これらを一つの完了へ短絡しなかった。

後年の RFC 3936 は RSVP 値の割当方針を整理し、RFC 8126 は IANA への指示と技術説明を分離する考え方を明確にした。後世の文書を 2003 年へそのまま投影してはならないが、RFC 3476 が行っていた作業の輪郭は見えやすくなる。登録は参照を固定する行政作業であり、参照先の機能を実行する作業ではない。

現在の IANA 登録簿は、値が割り当てられ RFC 3476 に結び付くことを示す。そこに運用テレメトリはない。経路計算が分離経路を発見したか、容量が予約されたか、光クロスコネクトが設定されたか、光が出たか、トラフィックが通ったかは分からない。

Heng Lu の現実レイヤーの規律に従えば、監査は生のメッセージから始まる。値、長さ、U/F ビットまたは class/C-Type、解析結果を保存し、当時の日付を持つ登録簿で解決する。適用された RFC と OIF 仕様の版を固定する。その後、主体、認証、認可、受付、経路計算、資源予約、装置設定、光信号、トラフィック、サービス結果を別々に結合する。

読める Source ID は認証済み権限ではない。Diversity サブオブジェクトは独立経路の実在を示さない。Service Level は履行済み SLA ではない。Egress Label は光回線の受領書ではない。エラーが来なかったことも、後続作業が成功した積極的証拠にはならない。

拒否記録も残す必要がある。エラーオブジェクト、code、subcode、発信ノード、時刻、対応する要求を一組にする。「Diversity not available」は一般的な失敗より具体的だが、隠れたトポロジー全体が正しいことや、全ての代替案が不可能だったことまでは証明しない。

RFC 3476 が示したのは、限定された調整権の価値である。公共登録簿は、所属の異なる実装に同じ対象を語らせる。その機能は不可欠だが、サービスへの主権でも、サービスの実在証明でもない。番号は調査の入口であり、結論は各レイヤーの受領記録から作らなければならない。

情報源