要約

  • RFC 9889 は RFC 9543 のネットワークスライス枠組みを、現行 IP/MPLS 技術で実現するための実務的なモデルとして扱う。S-NSSAI はトランスポートドメインに見えないため、ハンドオフで VLAN、IP、MPLS の識別子へ写像される。
  • 実現には attachment circuit（接続回線）の調整、L2VPN または L3VPN のサービスインスタンス、QoS の写像、PE での細粒度の資源制御、コアでのより粗い資源処理、容量計画と容量管理が必要になる。
  • 対象は一つの Network Resource Partition（NRP）である。複数 NRP への適用は文書の範囲外であり、RFC 9889 は Informational で、BCP でも必須仕様でもない。

ハンドオフで変換されるもの

5G ネットワークスライシングとトランスポートネットワークスライシングは同一ではない。前者は移動ドメインの意図を S-NSSAI で表せるが、後者はエッジクラウド、データセンター、WAN ドメイン間でネットワーク機能を接続する、トランスポートから見える構成を必要とする。したがって移動側オーケストレーターは S-NSSAI を渡すだけでは足りない。移動側とトランスポート側のオーケストレーション境界で、写像と attachment circuit を調整しなければならない。

L2VPN と L3VPN は論理分離に利用できるが、どちらを採用し、どのサービスインスタンスとして構成し、ハンドオフ識別子とどう対応させるかは実装・展開ごとの問題である。識別子だけで自動的にポリシーが実行されるわけではない。QoS マッピングは、スライスの目的をトランスポート側の分類、キュー、スケジューリングの意味へ変換する。PE は attachment circuit と入口に近いため、より細かい資源制御を行いやすい。一方、プロバイダーネットワークのコアでは、より粗い資源処理になり得る。両者を同一精度のエンドツーエンド保証として扱ってはならない。

検証フィクスチャと運用判断

運用者は次の検証フィクスチャを用意できる。ただし、これらは RFC の必須要件ではない。既知の S-NSSAI、許可された VLAN/IP/MPLS 写像、対応する attachment circuit、L2VPN または L3VPN インスタンス、PE のキューとスケジューリング、コアの資源クラス、QoS クラス、容量予算を一組として記録する。S-NSSAI が移動側だけで見えること、ハンドオフ識別子が境界の両側で一致すること、attachment circuit が意図した VPN に接続されること、PE とコアで QoS クラスが失われないこと、資源割り当てと残容量に根拠があること、OAM が同じサービス経路の障害を特定できることを順に確認する。誤った識別子、QoS 不一致、PE 資源枯渇、attachment circuit 断のテストも行い、復旧とロールバックを記録する。

判断経路は明確にできる。まず要求が 5G スライスなのかトランスポートスライスなのかを確認する。次に S-NSSAI を VLAN、IP、MPLS のいずれかへ写像する。続いて移動側とトランスポート側の責任者が attachment circuit、VPN、QoS、PE 資源を共同確認する。その後、コアの粗い資源処理と容量計画を確認し、最後に OAM と設定検証で実施、保留、ロールバックを決める。移動、トランスポート、オーケストレーション間の所有権は展開ごとに異なり、RFC は固定していない。

証拠の境界

RFC 9889 は本番の遅延、損失、可用性、隔離性能を測定していない。特定の事業者、ベンダー実装、商用需要、価格、採用状況も示していない。複数 NRP の実現も範囲外である。識別子だけでスライスが実行可能なポリシーになるという見方は、Theo March の分析であり、RFC の要件ではない。さらに私の分析では、容量計画と承認を結び付けなければ、資源を確保せずに識別子だけをサービスとして見せる誘因が生じる。跨ドメイン変更に検証済みの撤回手順がなければ、誤りが VPN、PE、コアへ広がり、ロールバック不能に近いリスクとなる。これらは説明責任、容量インセンティブ、ロールバックに関する分析であって、標準の強制事項ではない。RFC 9543 はより広い IETF の枠組みを示し、RFC 9889 は既存のサービスプロバイダー構成要素によるトランスポート実現へ対象を絞る。

出典