NFV#38(2022年5月)とO-RAN WG6 F2F Denver(2022年5月)の会合サマリ

 今回のNFV#38(5/30〜6/3)は久しぶりの現地(ETSI本部＠フランス・ニース近郊)となった。今回はOpenStack TackerもIFA/SEC/SOLもEnh01.01 Certificate Managementが一つの大きなトピックではあったが、それ意外もRelease4/5ともに仕様検討が大きく進んだ。やはりFace To Faceの会議は、各社の意向を擦り合わせるのが難しい議論の進展には重要なのもかもしれない。最新のNFV仕様の全体像はこちら(ETSI-NFVのOpen area)で、現在のNFVのリリース機能の状況はNFV中間会合(10月)サマリ、前々回のNFV会合の説明はNFV#36サマリ(NFV#37 2022年2月会合は筆者の執筆漏れ)を確認して頂きたい。

NFV#38のサマリ

NFV#36やNFV#37と比較した重要な活動結果としては、
  • Release2はETSI-NFVとしてはv2.8.1を最終バージョンとしメンテナンスも終了
  • Release3はSOL019を除き、v3.6.1で既存仕様(Stage2/Stage3/Stage4)のReleae3対応は全て終了
    • Stage3/Stage4はv3.7.1のメンテナンスは継続
    • 残仕様はFEAT10 (Multi-Site Connectivity Service)のSOL019 (MSCS Stage3) WIM向けIFの追加(v3.7.1(7月) or v3.8.1(12月)予定)
  • Release4はdrop3としてv4.3.1のIFA/SOLの仕様が完成(Finalize中)
    • Enh02.01 (SDN integration): Layer3のvRouter相当の記述をできるようにSOL001(NFV Descriptor)へRoutingResourceDataの追加
    • Enh02.02 (NS feasibility check): 時間のかかるNSのInstantiateの処理の前にInstantiateNSの事前チェック/リソース予約のためにSOL005(Os-Ma-Nfvo)へFeasibility Check/Reserveの追加
    • Enh02.03 (Data flow mirroring): VNFのTroubleshootingのための通信ミラーポート作成のためにSOL001＆SOL005へDataFlowMirroringの追加
    • Enh02.04 (Invariant identification): VNF等のバージョンUP時にVNFD以外の他Descriptorへの影響を与えないようVNFD IDとは別の一貫性を保持するためにIDSOL001へExtInvariantIdを追加
    • Enh02.05 (Scalable VNF instantiation): InstantiationLevelとScaleVnfInfoのどちらでもInstantiationできるようにSOL001やSOL003(Or-Vnfm)の記述修正
    • FEAT17 (Cloud-Native): 同一VNFDやSOL APIでContainer対応できるように既存仕様SOL001/SOL002/SOL003/SOL005へのコンテナ関連パラメータの追加
    • FEAT21 (5G): SBAベースのVNFをInstantiateできるようにNSDにおけるVNF間の依存関係を記述できるように変更
    • TST010 (API Conformance test)は2023年1月完了予定
  • Release4の残仕様が整理された (v4.4.1(2022年12月) or v4.5.1(2023年7月))
      • Enh01.01 (Certificate Mgmt): 証明書の配布をするためにIFA033 (Sec-Mano Stage2)にOCMF向けIFの追加と証明書LCMのために必要な情報要素の既存仕様への追加(予定)
      • FEAT13 (License Mgmt): IFA007 (Or-Vnfm)や IFA013 (Os-Ma-Nfvo)などの既存IFの拡張
      • FEAT17 (Cloud-Native): IFA036 (CCM)がほぼ完了し、Consumer〜CCM、Consumer〜VIM/PIM、CIS Cluster〜CCM、CCD/CCNDのStage2/3レベルの仕様とアーキテクチャ図NFV006の更新
      • FEAT18 (Security Mgmt): SEC024 (Security Mgmt)、SEC025 (Secure E2E VNF&NS Mgmt)、SEC026 (trust domain)の作成
      • FEAT19 (Container networking): 既存仕様の拡張(？)
      • FEAT20 (Autonomous networks): IFA047 (MDAF)、IFA050 (Intent Mgmt)の作成
      • FEAT21 (NFV for 5G): 既存IFの拡張
      • FEAT24 (VNF Generic OAM): IFA049 (VNF G-OAM)の作成と既存IFの拡張
      • FEAT25 (VNF Continuous Integration): CICD実現のためのDescriptorや既存IFの拡張(？)
      • FEAT26 (Policy Mgmt Model): IFA048 (Policy model)
    • Release5のUsecaseが概ね完成しStableに近づいてきた (Report 2022年12月/Stage1&2 v5.1.1 (2023年6月)/Stage3(2023年12月))
      • FEAT27 (NFV for vRAN): IFA046においてO-RANのUsecaseが収集からKey Issues4つ (アーキテクチャ、Accelerator、Descriptor＆Package、Transport Nework)の分析がほぼ完了し、Recommendationのフェーズ
      • FEAT28 (Fault Model): IFA045においてUsecaseやFaultの考え方が完了し、具体的なFaultの情報要素やKPIの仕様化開始
      • FEAT29 (GreenNFV): EVE021においてUsecase収集中
      • FEAT30 (VNF Config): EVE022においてNFV仕様においてConfig可能な仕様の範囲の分析が完了し、Solutionの検討中
      • FEAT31 (Flexible VNF): IFA044においてUsecaseを収集し、仮想リソースをVNFDではなくNFV-MANO内で最適値を判断するようにGAP分析中
      • FEAT32 (Reliability for cloud-native): REL014でUsecase収集中
      • FEAT19 (Enhanced container networking): IFA043にてUsecase収集中
      • FEAT24 (VNF G-OAM): EVE019のRel5の再オープン(WI承認済み)
      • FEAT22 (Multi-tenancy): EVE018において分析中
      • FEAT23 (SBA): IFA039においてほぼStable
      • GAP収集中New Work ItemのVNF Configuration、NFV for vRAN、Fault ModelのUsecaseが概ねで揃ってきた。
    今回はEnh01.01 Cetificate MgmtがIFA-SEC-SOL & OpenStack Tacker Joint Sessionで議論され、証明書管理をどのように推進するかの議論となった。標準化において仕様が定められないというSECのメンバーの発言は残念だが、mTLSやOAuthとの証明書のバインドでは必要な基本機能なので必ず仕様の推進は必要になるであろう。

    また、NOCの方でRelease6のブレストや、White Paperの作成を始める可能性について言及されたことも興味無深い

    O-RAN WG6 F2F Denver

    O-RANも今回はFace To Faceの議論となった。今回は使用面での大きな進展はなかったが、AALを中心に仕様の方向性について議論があった。また、新しい機能についてはFeature Packageという単位でWIを立ち上げ検討していくような進め方となり、電力消費削減やTest仕様などが提案された。

    • Usecase： 細かいUsecaseの拡張中
      • FM: 災害モードやLogなど、応用編的なUsecaseなどをJuly trainに向けて検討中。
      • LCM: HealingやOverlay NWについてJuly trainに向けて検討中。
    • O2:
      • O2ims: FMのDM(Stage3)とPMのIM(Stage2)の設計中
      • O2dms: stage2の検討開始: 基本的な機能についてはNative K8s Profileとも重複する部分がありそうなので、Usecase＆GAPを拡張することで共通機能のStage2化する方向
        • ETSI profile: stage2レベル（Heal LCM）の提案済
        • Native K8s Profile: (初版は代表的なAPIを参照しただけなので)ドキュメント品質向上検討中
    • AAL: MarchのGAPをベースにStage2設計中
      • Common API: LPUのLCMについてO1経由とO2経由で議論 → 原則O1経由
      • Transport API: run-timeのinformationとしてBuffer関連のチューニングAPIを検討中
    • 電力消費抑制
      • RICによるNFやO-Cloudの制御とNF Deploymentを差し替える方法等のいくつかのSolutionを含めてScope議論中。
    • Test仕様
      • Test仕様についてIOTとAPIレベルのテストや、ETSIとの連携について議論開始
    • ASD vs VNFD
      • ASDがHelmChart等の特定のSolutionと密結合になっている(ベンダーロックイン)であることから、オペレータ連合(AT&T/Verizon/DOCOMOなど) vs ベンダ(Ericsson/Nokia)で大きな議論あり

    グローバルにおいては段々Face To Faceの流れになり、現地参加者もかなりの人数がいた。今後は標準化活動もコロナ前の状況に戻り、検討も再加速し始めていくことを期待したい。

    コメント

    コメントを投稿

    このブログの人気の投稿

    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を導入し...
    続きを読む

    VNFMとは？

    仮想化された交換機等のテレコム設備(VNF: Virtualised Network Function)の管理機能部としてETSI-NFVではVNFM(VNF Manager)が定義されている。VNFMの主な役目として VNF LCM を行うというものがあるが、VNFMが入ることでNFVOやVIMとの機能的な違いが分かりにくくなっている。VNFMの役割とは何だろう？ ETSI-NFVにおけるVNFMの役割 ETSI GS NFV-MAN 001 の過去の提案資料(寄書)や議論状況を見ていると、どうやら以下のような考え方で機能部を検討してきたようだ。 テレコム設備(Network Function)の仮想化(VNF) Compute/Storage/Networkの仮想リソースプール化(NFVI: NFV Infrastructure) 複数のNFVIの管理/クラウド化(VIM: Virtual Infrastructure Manager) 複数のVIMのキャパシティ管理と既存保守機能部(OSS: Operation Support System)の接続と自動化(NFVO: NFV Orchestrator) 既存のNFのOAM部(EM: Element Manager)やVNFの仮想化に伴う不足機能の補完(VNFM) MAN001の議論状況だけ見ると、上記の通りNFVOとVIMしかなかったようだ。MAN001の発行直前に、既存のVNF/EM/OSSと新機能部であるNFVO/VIMの不足機能を補完するためにVNFMが定義されている。 問題はこの“不足機能“とは何かが不明瞭なため、VNFMは様々な機能部との境界ラインが曖昧になってしまっている。 VNFMの機能 ETSI GS NFV-IFA 010 を確認すると、VNFMが保持する機能としてはVirtualised Resource (VR) Mgmt、VNF  LCM、VNF Config Mgmt、VNF Info、VNF FM、VNF PM、VNF Indicator、Policy Mgmt、Snapshot Mgmt、VNF workload Mgmtがある。VNF LCMやVNF workload Mgmtは NFV-Tacker workshopのレポート「NFV＃34会合サマリとNFV-Work...
    続きを読む