NFV#35(2021年9月)会合サマリ

    今回のNFV#35(9/13〜22)もコロナの影響でeMeeting (電話会議による会議)となった。今回はNFV-Workshopのようなイベントは無かったようだが、いくつかの仕様検討は大きく進んだ。最新のNFV仕様の全体像はこちら(ETSI-NFVのOpen area)で、前回NFV会合の説明はNFV34の会合サマリを確認して頂きたい。

    NFV#35のサマリ

    NFV#34と比較した重要な活動結果としては、
    • Release3のed351がPublishになった。
    • Release4のStudyが多数完了フェーズになり、今後Normativeに移行する。
    • Release5のNew Work Itemが承認され、活動が開始された。
    コンテナ関連はあまり進んでいないが、新Usecaseや新機能に関するStudyが多数完了して、これから新しい機能に関するアーキテクチャの検討や機能分担が開始されそうだ。

    Release3：LCMの高度化

    IFA&SOLの第2版(ed351)がPublishされ、サポートするVNF関連の機能について大きな進展があった
    • CoordinateLcmOperationが仕様化され、FEAT02 VNF Upgradeが完了した。ed361に向けた残機能はFEAT03 NFVI UpgradeとWIMのNorth Bound Interface (NBI)のみとなる。
      • SOL017 MSCS (Multi-Site Connectivity Service) stage 3 reportが完了し、IETF ACTNベースでWIM NBIが開始予定。
    • VipCpの導入によりVirtual IP address (VIP)がNFV-MANOでも管理可能となり、NFV-MANOがサポートできるVNFのNWの幅が広がった。
      • Rel2までは主にMAC Address＋VLAN (L2)のLinkのみがNFV-MANOの管理対象であり、IPアドレスはConfiguration(設定情報でありNFV-MANOの管理対象外)だった。そのため、例えばVNFC間で冗長構成になっていた場合も、その数だけExtCpが必要となるような管理方法だった。
      • Rel3からはVipCpを利用することで、複数のVNFCでVIPを共有するVRRPのようなNWも記述可能になった。
      • Rel2/Rel3の制約を見ると、サポート対象のVNFの構成と、サポートされていない構成がある

    Release 4：コンテナ対応

    Release4はいくつかのStudyが完了に向かい、今後各StudyのFBを踏まえてStage2が始まりそうだ。
    • IFA041 Autonomous mgmtが完了し、MDA(Management Data Analytics)とIntent mgmtが追加される。
      • OSSからIntent (= desired state)を貰って、従来のNFV-MANOに仮想リソース制御を行える。
      • MDAはNFVOの中or独立して定義(今後仕様決定)され、OSSからMachine Learningを利用できるようになる。
      • 詳細は「仮想化と監視運用自動化」を参照
    • IFA042 Policy Modelが完了し、ECA(Event Condition Action)モデルでPolicyを記載する方向になる。
      • SOL012 Policy mgmtのInterfaceしかなかったので、やっと中身のStage2が進むことになる。
      • ONAP APEXとPolicy Frameworkがリファレンスになっているようだが、かなり細かいレベルでErro-handlingも記述することを要求しているので、ETSI-NFVで拡張仕様を決めることになるのだろう。
    • SEC005 certificate mgmtが完了し、Operator Certificate Enrollment Function (OCEF ≒ CA局から証明書を配信するPKI相当)が追加される。
      • SOL013で規定されているTLS通信実現ための証明書配信の仕様がやっと制定される。
      • KubernetsはCNFへの証明書配布のために独自のCA局を内包しているようなので、OCEFとKubernetsがどのように接続されるのは継続的な確認が必要になりそう。
    • IFA037 NFV for 5GもFinal Reviewが概ね終盤となり、今後Normativeへ移行する。
      • 大きな機能追加は無いようだが、既存IFはあちこち拡張が入るようだ。
      • 特に大きいのは、NFVOがVNF間の関係を理解し、片方のVNFが変化したら、他の関連するVNFの変更も行なっていくことの拡張だろう。これでやっとNFVOがOrchestoratorらしく、VNFの要件＋NFVIの能力＋現在のNS/VNFのトポロジーから関連するVNFやNWの変更をDynamicに行う土台ができてきたようだ。
    • IFA038 Container  NWもFInal Reviewに入り、NFVO/VNFM/CISM間の機能分担が明確になってきた。
      • Primary Container Network, Secondary Container Network, Cluster Networkの3種類のNWが定義されるようだ。
      • CIS Cluster(CaaS)内はCISMにお任せのようだが、CIS Cluster外の通信はNFVOやVNFMがそれぞれ仮想NWやLB等へ設定変更を行うようだ。
    • EVE019 VNF Common OAMもFinal Reviewに入り、PaaS機能が追加される。
      • IFA029 Cloud NativeのVNF Common/Dedicated Service (Common Function)がDB、LB、CA局などの共通機能を提供
      • EVE019 VNF Common OAMのGeneric  OAM Functionはログ監視、FM、PM、CM、NW制御、VNF Upgrade、時刻管理などの保守機能を提供
    • IFA034 License mgmtもFinal Reivewが概ね終盤となり、今後Normativeに移行していく。
      • VNF-LM (License Mgmt)がEMサイドに追加される(ETSI-NFVのScope外なので、今後どうなるかは要確認)
      • 基本的には既存IFをVNF-LMが利用するだけなので、あまり機能拡張は無さそう。
    • IFA036(Cluster管理)では、CIS Cluster(CaaS)用の新しいDescriptorを使う議論が始まっている。
    • IFA040-SOL018 CISM APIとIFA011-SOL001 VNFDはver4.2.1として仕様化されているようだが、他のSOLもver4.3.1として仕様化が始まったようだ。
      • 4.3.1の終了予定は2022年の3月末らしいので、実質コンテナ関連の仕様が整うはその頃だろう

    Release5: NFV適応ドメイン拡張

    Release5はNew Work Itemが承認され活動計画の議論が始まり、どうやら2022年の6月末頃までStudyする予定のようだ。元々「NFV＃34の会合サマリ」でも記載した通り、Release5はAPLレイヤの制御支援による自動化と、NFVで利用可能なドメインの拡張が主な方向性であった。
    • IFA043 Enhanced container network: IFA038の後継であり、よりテレコムのNW条件に合致したContainer NWを検討するようだ。
    • IFA044 Flexible deployment: 現在のNFV仕様では”Deployment Flavour”によるStaticなScaleの仕様なので、コンテナの特徴を活かしたよりDynamicなScaleを行う方法を検討するようだ。
    • IFA045 Fault Model: 現状どこの標準化団体でもAlarmの中身はあまり規定されていないので、IFA045ではIFA027(PM)のようにAlarmの中身を規定するらしい。
    • IFA046 NFV for RAN: O-RANで検討されているRANの要件と現在のNFV仕様のGAP分析を行うようで、IFA037のRAN版のようだ。
    • EVE021 Green NFV: 省電力に向けた高度なPolicy制御やSmall Setの機能定義をStudyするようだ。
    • EVE022 VNF Configuration: VNFに関するConfigurationが様々な設定ルートがあるので、その課題分析と仕様拡張を行うようだ。

    コメント

    コメントを投稿

    このブログの人気の投稿

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