NFV IFA&SOL (2021年10月)中間会合サマリとETSI-NFV仕様の各Release機能

 今回はIFA＆SOLの中間会合(10/25〜11/4)もコロナの影響でeMeeting (電話会議)となった。今回は標準仕様としてはあまり目立った進展はなかったが、Release4とRelease5のゴールが少しずつ見えてきた。最新のNFV仕様の全体像はこちら(ETSI-NFVのOpen area)で、前回NFV会合の説明はNFV#35の会合サマリを確認して頂きたい。

ETSI-NFV仕様の各Release機能

ETSI-NFVはテレコムAPLをクラウド上に載せる技術と仕様であり、各Releaseによって制御範囲や制御内容の拡張が行われている。

  • 非仮想化： ETSI-NFV仕様導入前は、テレコム装置であるNF (Network Function)と、それを制御するEM (Element Manager)、そしてそれら複数のEMを運用する支援するOSS (Operating Support System)によって構成されている
  • Release2: VNF LCMとは？の通りVNFやNSの基本ライフサイクルがサポートされている
    • 仮想化されたNF(VNF)と VNFが動作するクラウド環境NFVI (NFV Infrastructure)＋VIM (Virtual Infrastructure Manager ≒ OpenStack/vCenter)が導入された
    • 複数のVIMとVNFを統合管理するNFVO (NFV Orchestrator)と、NFを仮想化するにあたってNFVOやVIMだけで不足するVNFM(VNF Manager)がNFV-MANOとして新規追加された
    • NFV-MANO動作させるNS Package(NSD) (SOL007)とVNF Package(VNFD, VM image, Artifact) (SOL004) 、そしてTOSCA-baseのNSD/VNFD (SOL001)とYang-model baseのNSD/VNFD (SOL006)が定義された
    • 各機能部を接続するRESTベースのAPI (SOL005, SOL002, SOL003)とVIMを制御するVirtual Resource Descriptor (≒HOT)が定義された
  • Release3: VNF/NS LCMの高度化のためにNWとVNFの統合管理がサポートされた
    • ETSI-NFVではFeatureという単位で管理されFeature Trackingで仕様規定状況が分かるようになった
    • VNF Software modification(FEAT02)により、VNF LCM API(SOL002)とVNFD(SOL001)が拡張され、動作中のVNFを更新できるようなChange Current VNF Package Operationが追加された。
    • Multi-Site Multi Connectivity (FEAT10)により、WAN (Wide Area Network)とそれを制御するWIM (WAN infrastructure Manaegr)が導入された。現在IETF  ACTN (RFC8453)ベースのAPI (SOL019)が定義中である (2022年中旬完成予定)
    • Network Slicing (FEAT05)やService Availability Level (FEAT16)により、NS毎にQoS制御がLCMの優先度が制御できるようにNS LCM API(SOL005)が拡張された。
    • NFV-MANO Mgmt (FEAT11)やVNF Snapshotting (FEAT15)により、NFV-MANO自体のOAM用API (SOL009)や、VNF LCM API(SOL002/003)とVNFD(SOL001)の拡張によるVNFのSnapshot取得機能が追加された。
    • NSのMulti-domain (FEAT08)により、NFVOを論理分割し、それらのNFVOを接続するSOL005ベースのSOL011が定義された。
    • Policy mgmt (FEAT07)もRelease3で追加されているが、肝心のPolicy Content(IFA042)がRelease4以降のため、現時点で利用することは難しいだろう。
    • MEC対応 (FEAT012)もRelease3で追加され、SOL004のVNF PackageにMEC関連の資材投入のための拡張とSOL002にCoordinate LCM operationの追加が行われた。ETSI Plugtest 2021においてNFVとMECの接続が行われるので、仕様とプロダクトの両方の観点でどの程度NFVとMECが接続可能か近日中に分かるだろう。
  • Release4: VNF自体がクラウド向けに進化(クラウドネイティブ化)を想定し、NFV-MANOのクラウドネイティブ支援機能が追加されている
    • Release3までと比較するとAgileを意識しているせいか、半年単位(Drop)で新機能対応のAPIをリリースする方式になっている。初版はコンテナ対応であり、その順次Release4の拡張機能がリリースされる見込みである。
    • FEAT17により、Kubernetesベースのコンテナ環境のサポートのために、コンテナ実行環境であるCIS (Container Infrastructure Service)とCISの管理機能であるCISM (CIS Manager)、コンテナのイメージレポジトリであるCIR (Container Imager Registry) が導入された。現在 Helmchart/Kubernetes API/Docker Registry APIベースのAPI (SOL018)とMCIOP (Managed Container Infrastructure Object Package)の管理方法(MCIOP自体はETSI-NFVのScope外)を定義中である(2022年初旬完成予定)
    • VNFが動的に変更することに合わせ、VNFのライセンスの動的管理(FEAT13/IFA034)、VNFのリソースをインテントベースで管理できるようなAIの導入(FEAT20/IFA041)、PaaS(FEAT24/EVE019)、VNFへの証明書を動的に配布できるOCMF (Operator Certificate Management Function)を導入予定である。
  • Release5: RANとCOREの統合管理
    • 現在RAN対応のためのNFV for vRAN(FEAT27/IFA046)やGreen NFV(FEAT029)のStudyが始まっている。
    • また、従来のコンテナやネットワーク、FMなどの拡張も実施予定である

中間会合のサマリ

NFV#35と比較すると今回大きな進展はなかったようだ。
  • Release3はed361(11月完成予定)に向けBug Fixの提案が何件か議論中(解決には至らず)。
  • Release4はed431(2月完成予定)に向け、SOL018を中心にVNFDとのMappingやSOL018のInput/Output parameterが少し進捗したようだ。
  • Release5は初版のStudyがスタートし、まずはScopeや最初のUsecaseの検討が始まった。

Release3：LCMの高度化

IFA&SOLの第3版(ed361)にむけFEAT03の完了とBug Fixを優先して議論されたが、完成には至らなかった。
  • Grant関連の仕様における不明瞭な記述の修正提案
    • Affitinity/Anti-Affinity ruleの責任範囲の明確化。
    • SR-IOVのネットワーク設定情報の受け渡し方法の明確化。
    • NsChangeNotificationの通知Triggerにおいて、VNF LCMだけのオペレーションを含むかの議論
  • FEAT03 NFVI Modificationの実現のために、更新対象のNFVI上で動作されているVNFを同制御するかについて議論
    • NFV-MANOトリガーでCoordinate LCM operationでVMを安全に停止しNFV-MANOで該当VMを移動する vs NFV-MANOはMaintenanceの通知のみ送信しEMで対処する、で議論中
    • NFV-MANOはMaintenance通知のみの方向で検討中。

Release 4：コンテナ対応

Helmchartの記述や、NFV-MANOから渡すrun-time情報(NW情報や現在のリソース状況等)としてのValue.yamlの記述レベルについて議論中。
  • SOL001は概ね完了したため、残りはSOL018。
    • Input Parameterについて概ね最低限必要なrun-time情報が揃ってきたので、これからはOutput Parameterが議論の中心。
  • Slicingの実現に向けて、ZSMと連携して“Feasibility Check“という新しいフェーズの導入を議論中。
    • 現在のSOL003の設計ポリシーで実現しようとするとRESTっぽくないので再検討
  • SEC005のOCEFが改名され、Operator Certificate Management Function (OCMF)として仕様規定開始。
    • Release4からはmTLSベースでの認証になるためroot証明書が必要。
    • SOL009のIFを利用してroot証明書を配布する方向で検討中

Release5: NFV適応ドメイン拡張

各WIについて最初のUsecaseの提案開始。
  • IFA043 Enhanced container network: Workplanのみ共有。
  • IFA044 Flexible deployment:進展なし。
  • IFA045 Fault Model: HWの故障が最終的にどのようにVNFMやNFVOに届くのかのUsease提案。
  • IFA046 NFV for RAN: 進展なし。
中間会合とは直接関係ないが
  • EVE021 Green NFV:電力問題の背景を記載。
  • EVE022 VNF Configuration: 現仕様におけるConfigurationのルートについて分析。


ETSI-NFVは参加者がアジア、ヨーロッパ、アメリカ・・・と世界中から参加しているため、どうしてもオンラインだと議論可能な時間が限られてしまう。現在は日本時間の22〜24時がゴールデンタイムと言われており、この時間のみ世界中の参加者が(ギリギリ)会議に参加し議論できる。そのため、どうしても活動時間が減り、難しい案件ほど仕様策定の進捗が遅れてしまっているようだ。
11月からはヨーロッパのサマータイムが終わってしまったため、日本は23〜25時がゴールデンタイムになってしまった。筆者も深夜の会議参加が辛く感じるようになってきたので、日本を含むアジアの方々もかなり大変だと思う。

コメント

コメントを投稿

このブログの人気の投稿

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