NFV#33 (2021年2月) の会合サマリ

NFV標準仕様は今も日々進化している。このブログでは標準仕様のトレンドや進捗状況についても定期的に共有したい。最新のNFV仕様の全体像はこちらで確認できる。

NFV会合とは

ETSI NFV ISGは複数のWorking  Group(WG)と呼ばれる会議体によって標準仕様を検討・制定している。NFVの主要な仕様を制定しているWGはInterface And  Architecture(IFA)とSolution(SOL)であり、基本的にはIFAとSOLのGS(ETSI NFV ISGの標準仕様として発行しているドキュメント)の更新状況を確認していくことになる。

NFV会合とは、プレナリと呼ばれるETSI  NFV  ISGの最高意思決定会議が開催される期間であり、コロナ以前は1週間特定の場所で集中的に会合を行なっていた。実はNFV#6沖縄とNFV#28福岡の2回ほど日本でも開催されている。基本的にはプレナリによって新しいドキュメント作成の活動(WI)が提案されたり、完成したドキュメントの発行を承認されたりする。

NFV#33のサマリ

Technical Steering Comittee(TSC)が最新のETSI NFVの活動状況をまとめており、NFV#33の時点ではNFVTSC(21)000004r1_Summary_of_NFV_Releases_by_Jan_2021.pdfに記載されている。重要な活動結果としては
  • Release 2のStage3レベルの仕様がVersion 2.8.1として全て揃いCloseされる。これでETSI NFVとしては実質Release2のメンテナンスが終了。
  • 今更感があるがNFVのアーキテクチャ(全体像)を表すNFV006 “Architectural Framework“ Release2が発行された。
  • Release3はFEAT02 NFVI UpgradeのStage2がVersion 3.4.1で完了し、Stage2は全て完了。
  • Release3のStage3も初版は3.4.1として完了し、主なStage3の残仕様は、
    • NFVI Upgradeの取り込み
    • CoordinateLCMoperationの完成
    • SOL017 “Multi-site connectivity service”のプロトコル分析の完了と、それに基づく実際のStage3の作業
    • TST010 “API Conformance test”の完成
  • Relase4はStage2の初版Verzion 4.1.1としてコンテナ制御の一部機能をリリースするものも、新規機能のStudyやコンテナ制御を含む他のインタフェースの拡張が終わっていないため、まだまだStage1やStage2の最中と読める。
今後ETSI NFV  ISGの仕様策定は、Release3のStage3およびTest仕様と、Release4のStage1/2がメインの活動になりそうだ。

コメント

コメントを投稿

このブログの人気の投稿

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

VNF Lifecycle Management (LCM)とは？

イメージ
NFVの登場によりLifecycle Management (LCM)というキーワードが頻繁に登場するようになったが、NFVの用語定義( NFV003 )を見ても”set of functions required to manage the instantiation, maintenance and termination of a VNF or NS“としか書かれておらず、なかなか意味が分からない。NFVの仕様の基本であるLCMについて解説していきたい。 LCMとは？   標準化仕様について①「基本仕様の見分け方」 でも記載した通り、NFVの仕様の基本であり、仮想化されたNetwork Function(VNF)に対してInstantiation/Healing/Scaling/Termination等の制御を行うことである。元々は IT系のLCM  Service という考え方であり、それをNFVでテレコムやモバイル系装置にも同じ概念を適用したようだ。 NFVにおいては、これらの計画・設計 〜 導入・工事 〜 運用・更新 〜 廃止・撤去をそれぞれAPI化し、 モバイルの運用 でも利用可能なように機能を拡充している。 IT系と異なる点 としては 仮想リソース(VMやVirtual Storage)の設定や設計をインフラではなく、Network FunctionのApplication  Provider (VNF Provider)が決めている IT系では、Compute FlavourやGuest OSはインフラ提供者が決め、Cloudの運用効率最大化を指向することが多い NFVでは、性能向上のためにGuest OSの使い方がVNF毎に特殊だったり、そもそも独自OSを利用していたりするため、Guest OSや仮想リソースの設定・設計(Descriptor)はVNF Providerが用意する Cloudのネットワーク機能を利用せず、VNF自身がネットワークを制御する IT系では、CloudのDNSやOverlay Networkingの機能を利用しApplicationはNetworkを意識しない方向で設計や運用をすることが多い NFVでは、VNF自体がRouterのようなものなのでAddressingやTunnelingもVNF...
続きを読む