NFV#52@Tokyo & NFV#53@ニース & NFV#54@Shanghai & NFV#55@Tokyo

NFV#51でRelease 6のStage2が始まってから半年以上あまり進展が見られなかったが、やっと少し進展したのでまとめていきたい。

Release 5はTST010を除く全仕様がed541として完了し、Finalizeされた。Release 6はTelecom装置に対してKubernetesの機能では不足している部分を、Operator Frameworkを利用した拡張部分で仕様化する方向で検討が大きく進捗した。Release 7はAI for CloudとCloud for AIの両面でAI nativeな基盤の仕様化をStudyしている状況である。

NFVの仕様がそのように進捗する一方で、ETSI ISGの再編が起こり、新しくTC NETという団体が設立され、NFV/MEC/ENI/ZSMは今後新しい仕様の検討はTC NETで行われることとなった。

NFVの仕様進捗のサマリ

Release 5はSOL021 (intent mgmt)の仕様が完了した。その他の更新としては、他団体が制定済みの仕様に対してNFVのUsecaseを実現するためのパラメータや使い方を制定するProfiling Approachについて、仕様の参照の仕方が曖昧で実際に実装しにくいというフィードバックから全般的にバージョンを指定しつつ具体的に記述されている仕様の章を参照することでわかりやすさを改善した。また省電力に関する仕様が全体的に追加された。ed541として更新され、既存としてはメンテナンス完了された仕様は以下の通りである。

またSECもRelease 5の仕様は全て検討を終え、IFAのRelease 6の検討を待つ状態となった。


Release 6としては、NFVからTelco Cloudと名前が変更され、TCO (Telco Cloud Orchestration)、TCP (Telco Cloud Platform)、TCI (Telco Cloud Infrastructure)、TCA (Telco Cloud Application)が規定された。TCO/TCP/TCIのStage1はNFV008シリーズとして制定され、NFV009シリーズでDescriptor、NFV010シリーズでIFを定義中である。

Release 6では従来のImperative (APIをコマンドベースで指示し必要な操作を積み上げて理想の状態にする)からDeclarative (あるべき姿をDesired Stateとして定義し、各装置はDesired Stateになるように自動で制御を繰り返す)に発想を変えている。そのため、従来のSOL003のIFもNFV010-2ではDesired State (あるべき姿)とObserved State (現在の状況)の一部としてOperator Framework上のCustom Resourceとして定義される方向である。Operator frameworkとは、Kubernetesの機能にDB (Custom Resource Definition)とController (Operator)を追加する機能である。上位装置からCRDにDesired StateがCustom Resourceとして投入されると、Operatorはその状態に合うようにreconcileしてPodの状態を合わせようとする。その結果、各装置間のIFはシンプルになりつつ、Kubernetesの機能を最大限活用することができる。

NFV008-2では、Telecom特有の要件として、APLの状態を管理する必要がある旨が記載されている。Kubernetesの世界ではlivenessprobe/readinessprobeによってPodの状態をKubernetesが管理し、その状態に応じて依存関係のある装置の起動順序等を制御するが、Telecomの装置はDBのようにリソースレベルでは正常に動作していても冗長系との同期などによって正常に動作できるようになるまで追加のステップが必要なケースがある。TCA LCMではこのようなAPLレベルのステータスを管理して起動制御等を行うことでTelecomの装置をKubernetes上で動作できるようにしている。その他の特徴としては以下のようなものが議論されている。

  • APLレベルのステータス管理
  • 起動順序制御
  • Multusを利用した多数のネットワーク
  • RackレベルのAffinity/Anti-affinity rule
  • APLレベルのステータス管理を継続したTCI (Kubernetes Cluster)の無中断Upgrade対応

一方で、Declarativeな時代のDescriptorとは何か？というところで議論が止まっている。Desired StateとしてAPI上であるべき姿が定義されるのであれば、敢えてデプロイのテンプレートとしてDescriptorが要るのか？という議論が起きている。

また、Profiling Approachによって制定された仕様のテストはどうあるべきか？という議論も起きている。例えばKubernetesやPrometheus等のOpen Sourceは既に開発されているのに、そのテスト仕様を作ったとしてそれは誰が何のために行うテストなのか？という議論である。ProfilingによってこんなユースケースがあるはずだとOpen Sourceに共有し試験してもらうのだろうか？それともオペレータのインテグレーションされた環境で、Consumerが正しくProfilingされた値を指示できるかを試験するのだろうか？

更にドキュメント体系も大幅に見直しされ、Markdown形式での作成となり、Stage2とStage3も統合された。

TC NET

元々ETSI ISG NFVは時限式の団体であり、長期継続する予定は無かったがETSI ISG NFVが始まって10年以上経過してしまった。一方で、AIを中心としてETSI配下のISGの作業領域が重複してきていたり、参加者が激減してContributorだけでは仕様の維持も難しくなってきた。このような中で、ETSIのBoard(役員クラスのグループ)はISGのマージとEU Commissionとの連携強化として恒久的な仕様策定団体であるTC(Technical Committee)化する方向に向かった。

10/7 - 9が初回の会議であり、Chair 1人、Vice Chair 4人の構成で会議はスタートする予定である。また、ETSI ISG NFVの仕様等は今後TC NETで引き受けていくことになるため、なるべく会合はTC NETとETSI ISG NFVを合同開催していく方向で議論されている。筆者もTC NETのVice Chairとして再びMobile Networkの標準化を活性化させていくことに貢献していこうと考えている。

コメント

コメントを投稿

このブログの人気の投稿

CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

イメージ
ETSI-NFV仕様の各Release機能 の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4は IFA039のSBA の影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？については こちら を参照して頂きたい。 Kubernetesによるクラウド管理 Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。 仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。 Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。 Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長...
続きを読む

モバイルネットワークの保守運用の基礎

イメージ
O-RANや Sliceの管理 によって、最近モバイルネットワークの保守運用が脚光を浴びるようになってきた。しかし、運用方法や保守系装置は“オペレータやベンダ毎に異なる領域“というイメージであり、なかなかまとまったドキュメントや資料が見つからない。 保守運用の基本 これまでネットワークの保守運用のデファクトや標準仕様と言えばTM Forumの eTOM 程度しか無かったと思う。eTOMや各種標準化機能やOpen Sourceを踏まえると、大きく以下のような考え方がありそうだ。 保守運用のプロセス strategy： 新サービス導入やユーザの利用状況を踏まえた設備計画 保守運用の観点から見るとfulfillmentのInput情報 fulfilment(fulfillment)：設備計画に基づいたネットワーク装置(NF)や、それらを接続するネットワーク(NW)の設計・工事 assurance：運用しているNFやサービスの監視や復旧、更新作業 4Gまでの保守運用というと、assuranceを指すことが billing：利用状況に基づいた課金 保守運用の観点から見ると運用結果のOutput 保守運用レイヤ Business Management System (BMS)： 顧客の契約情報を管理 一般的にBusiness Support System (BSS)を利用 Service Management System (SMS)： 提供サービスの管理運用 Network Management System (NMS)： (サービスを実現する)NFの接続性の管理運用 4GまでのOperation Support System (OSS)と言うとNMSのことを指すことが多かったようだ Element Management System (EMS)： NF自体の管理運用 NFのFCAPSと言えば、EMSのことを指すことが多い 一般的にネットワークの保守運用というと、EMSまたはNMSのレイヤのfulfilment＋assuranceを指すことが多いように感じる。しかしながら、システムによる実装と人手での運用という観点では、4GまではEMSのassuranceまでを実装し、残りは手作業ということも多かったようだ。規模が大きな企業では、NMSやSMSの一部を取り入れてOSSを導入し...
続きを読む

NFV#50@Shanghai & NFV#51@Bonn

イメージ
 今回のNFV#50はチャイナテレコムがホストし、MWC上海と同日開催だった。またNFV#51はドイツ・テレコムのR&Dセンタ近くの会場だった。今回はオペレータのRoundtableが開催された。 NFV#50 & NFV#51のサマリ NFVの各Releaseの概要は NFV IFA＆SOL(2021年10月)会合サマリとETSI NFV仕様の各リリース機能 、詳細は ETSI GR NFV 007 Release Description 、各仕様の最新状況は Openbox と Feature Wiki を参照して頂きたい。 この半年はRelease6における新しいMANOのアーキテクチャをどうすべきか？が大きな議論ポイントとなっている。 前回 NFV#49 からの更新は Release5: v5.3.1のFinalize FEAT20(Autonomous) : AI技術を利用した自律的なLCMの実現のStage3 IFA047 MDAF のStage3  SOL025  Finalize化 IFA050 Intent のStage3  SOL021 はHuaweiが再開し基本オペレーションの提案開始 FEAT24 (Enhansed Generice OAM):   SOL024  Finalize Component Open Source Interface Name Stage 2 Stage 3 study Stage 3 Normative Traffic Enforcer Istio, Cilium Traffic management interface 機能要件＆ IF要件仕様化済(ed441) 済(ed531) API＆Resource＆Data model 仕様化済(ed531) Network Configuration Manager 調査中 Network configuration management interface 機能要件＆ IF要件仕様化済(ed441) 未(ed541 /2025年12月末？) Upgrade VNF Manager 調査中 (Argo?) Upgrade VNF management interface 機能要件＆ IF要件仕...
続きを読む