要約

  • 5G 制御面の S-NSSAI は転送ドメインから見えない。サービス境界では、VLAN、IP アドレスやプレフィクス、DSCP、MPLS、SRv6 など、その場所で観測できる選択子へ対応付ける必要がある。
  • 対応付けは処理の入口にすぎない。VPN 分離、PE のアドミッション制御、コアの集約、容量、下位経路、実測性能は別々に確かめなければならない。

ネットワークスライスの図には、たいてい端から端まで途切れない色が引かれる。しかし実機は色を読まない。インターフェース、ヘッダー、テーブル、キュー、経路を読む。RFC 9889 は既存の IP/MPLS 技術で 5G スライスの転送を実現する方法を整理し、その間にある翻訳作業を隠さない。

5G 制御面で使われる 32 ビットの S-NSSAI は転送網には見えない。そこで VLAN、アドレス、プレフィクス、DSCP、トンネル、MPLS ラベル、SRv6 の識別子などへ写す。期待した値を持つパケットが来たことは分類材料の存在を示すだけである。正しい VPN、許可されたレート、選択されたキュー、制約を満たす経路、受信側の性能まで証明しない。

境界ごとに意味を結び直す

VLAN は局所性を明確にする。同じ 5G スライスでも拠点ごとに別の VLAN を使い得る。一つの値は特定のアタッチメント回線でしか意味を持たず、各 SDP に対応表が必要になる。顧客側と事業者側は VLAN だけでなく、アドレス、サブネット、方式によっては ASN やトンネルも一致させる。

IP ハンドオフでは、専用アドレス、プール、プレフィクスの一部、DSCP、SRv6 locator などが選択子になる。柔軟である一方、アドレス管理と分類ポリシーが権限面になる。古い対応表や再利用されたアドレスは、正常なパケットを別のスライスへ結び付ける。共有 NF がスライスごとに複数トンネルを持つ場合もある。値だけでなく、場所、版、発行者が必要である。

RFC 2474 の DSCP はホップごとの振る舞いを選ぶもので、端から端の SLA を証明する印ではない。RFC 3270 は DiffServ を MPLS 上で扱う方法を定める。コードポイントが正しくても、各装置のキューや障害時容量は別の事実である。

写像の数も固定されない。一つの 5G スライスを制御面用とユーザー面用の複数転送スライスへ分けられる。複数の 5G スライスが一つを共有することもある。規模が増えれば M 対 N が現実的になる。一対一の台帳は正しさの証明ではなく、多対一も直ちに欠陥ではない。共有後に残る性質が問題となる。

成果は三つの管理領域にまたがる

RFC 9543 は SDP 間の接続とサービス目標を枠組みにする。RFC 9889 の 5G 文脈では、端から端のオーケストレーター、顧客サイトの制御群、事業者の Network Slice Controller が異なる範囲を管理する。RAN とコアの管理が転送網を直接支配するわけではない。

一つの成功応答は他の範囲を代表しない。CE に VLAN があっても PE が VPN に結んでいないかもしれない。VPN が存在しても bearer がない場合がある。識別子が一致してもレートが異なることがある。コントローラーが完了を記録しても、一台の装置が設定を拒否している可能性がある。

アタッチメント回線は両者の契約点である。選択子、アドレス、カプセル化、帯域、安全条件、変更順序を合わせる必要がある。既存の転送スライスを自動再利用するポリシーは開通を速めるが、同時に判断権を委ねる。適用した版、参照した容量、競合、取り消し方を保存すべきである。

PE では細かく、コアではまとめる

論理分離には L2VPN または L3VPN を使える。RFC 4664 は L2VPN の枠組みを、RFC 4364 は BGP/MPLS IP VPN を示す。別のサービスインスタンスと外側ヘッダーは分類境界を作るが、帯域予約や暗号化を自動的に与えない。

PE では入力 policing によりスライス単位、場合によっては 5QI クラス単位の契約を実施できる。出力 scheduler と shaper は保証レートを割り当てる。分類器、CIR/PIR、burst、キュー階層、物理回線容量が同じ契約に一致して初めて、識別子が制御になる。

コアでは粒度を意図的に落とす。このモデルは一つの Network Resource Partition を使い、トランジットルーターはスライスごとの状態を持たない。多数のサービスが通常八つ以下の転送クラスへ集約される。5QI-unaware 方式はスライス全体を一クラスへ写し、コアは内側 DSCP を見ない。5QI-aware 方式は境界で細分できるが、コアではやはり限られたクラスへ束ねる。

したがって、商用メニューが千種類あっても資源が千通りに分離されているとは限らない。共通のキュー、リンク、経路、制御機能への集中を示すことが、実際のリスク台帳になる。

最初のスライスと追加スライスは同じ変更ではない

最初のスライスでは制御面、ユーザー面、それらを運ぶ接続をまとめて用意することがある。追加スライスは既存の制御面を共有し、新しいユーザー面と転送だけを増やす場合がある。どちらも画面では「作成」だが、生成された状態と共通障害点は異なる。

一対一から多対一への移行も単なる台帳整理ではない。VPN、キュー、制御状態を節約する代わりに、障害範囲、輻輳関係、測定粒度、rollback が変わる。旧新の対応表を並行して検証し、実トラフィックと装置状態が移行完了を示すまで、上位の成功だけで終了してはならない。

境界で最小限固定すべきものは、全ドメイン共通の実装ではない。サービス目標、選択子の有効範囲、容量の意味、版、責任者、失敗時動作、測定法である。各ドメインは VPN、TE、OAM を局所的に選べるが、境界の意味を暗黙に変えることはできない。

予約なしでも「保証」と呼ばれる場合

RFC 9889 の最初の容量方式は最短経路と計画に依存し、明示的な端間帯域予約を行わない。それでも需要予測、負荷分散、余裕により顧客へ帯域を保証できる。想定外の需要や故障は前提を崩す。この方式自体が誤りなのではない。予約と計画余裕を同じ言葉で扱うことが問題である。

他の方式は固定または動的制約を持つ TE 経路を利用する。RFC 9522 は Enhanced VPN と TE の関連枠組みを示す。SR-TE では、コントローラーが予約量を管理しても、ネットワーク層が RSVP-TE と同じ形で資源を予約するとは限らない。台帳、計算経路、インストール状態、実測負荷を分けて見る必要がある。

出口回線では、明示的な低優先サービスの preemption がない限り、CIR の合計が物理容量以内でなければならない。正しい識別子は回線を太くしない。アドミッション判断はその時点の容量と障害トポロジーに結び付く。

観測が約束を閉じる

RFC 9889 は、管理面の見方と実設定の不一致を検出し、SLO の指標を報告し、顧客へ運用状態を示すよう求める。意図、装置状態、トラフィック、顧客体験は別の記録である。「provisioned」という一語にまとめると、検証できる部分が失われる。

対応表と分類表はセキュリティ資産でもある。制御通信には安全な転送、相互認証、限定された権限が必要だ。不正変更はトラフィックを別スライスへ移し、他者の資源を消費させ得る。地域制約は underlay 経路の証拠を必要とし、VPN 名だけでは証明できない。

適用範囲も残すべきだ。RFC 9889 は Informational で、一つの NRP を扱い、BCP でも必須実装でもない。特定事業者の導入や性能を記録していない。可能な実現方法であって、実現済みの証明書ではない。

参照資料