NFV#39(2022年9月)会合サマリ

 今回のNFV#39では、旧議長陣が引退し選挙が行われたり、次期NFVのコンセプトについてWorkshopがあったりと、ETSI NFVが大きく飛躍する期待を受けた。

NFV#39のサマリ

NFVの各Releaseの概要はNFV IFA＆SOL(2021年10月)会合サマリとETSI NFV仕様の各リリース機能、詳細はReleaseDocumentを参照して頂きたいが、前回NFV#38からの更新は

  • Release2 (VNF LCMの基本機能): v2.8.1を最終バージョンとして終了(変化なし)
  • Release3 (自動化やNWの制御): v3.7.1を最終バージョンとして最終メンテナンス中(WIM  IFを除く)
    • SOL APIで参照しているREST系のRFCについて、RFC 9110 “HTTP Semantics”とRFC 8446 “TLS Version 1.3”によりいくつかの仕様が変更になった
      • RFC 7231、RFC 7232、RFC 7233、RFC 7235が廃止(Obsoleted)されたことで、“payload body” -> “message content”、”422 Unprocessable Entity” -> “422 Unprocessable Content”と名称が変わった
      • HTTP conditional requestsが導入され、GETやPatchでの”E-tag”や”Last-Modified”によるキャッシュの仕様が明確になった(既存仕様でも考慮はされていたが不透明な仕様だった)
      • RFC 8446ではRFC 5246 “TLS Version 1.2”は廃止(Obsolted)になっているが、SOL  API Rel3はTLS 1.2を継続利用することになった
    • SOL005 Os-Ma-NfvoにおけるImageのUpload/Download時にBASIC認証も利用できたが、OAuth2.0のみとなった
    • SOL002 Ve-VnfmにおけるVNF/VNFC Configuration Dataにおいて、DHCP ServerのIP Addressは不要(DHCP DISCOVER/DHCP REQUESTはBroadcast)のため、dhcpServer attributeの削除
    • SOL001 VNFDで指定可能な仮想リソースが拡張された
      • Virtual MemoryにメモリサイズやNUMAに追加してHuge Pagesも指定できるようになった
      • VipCpについてもScaleが対応し、ScalingAspectsDeltaやInstantiaionLevelにVNFC数に追加して、Vipも指定できるようになった
    • SOL001 VNFDにおいてtosca.datatype.nfv.SwImage(Rel2で利用)が廃止され、tosca.artifacts.nfv.SwImageのみとなった
    • SOL014 Virtual Resource Descriptorにおいて、Reservationが導入され、HOT::Blazarを利用できるようになった
    • SOL016 MANO Procedureにおいて、VNF SnapshotとVNF Snapshot Packageのシーケンスが追加となった
  • Release4 (コンテナ対応): v4.3.1として初版リリース
    • NFV006 Rel4のアーキテクチャ図によると、CIS (Container Infrastructure Service)、CISM (CIS Management)、CIR (Container Image Repository)、CCM(Container Cluster Management)が追加されている
    • FEAT17 SOL018 CISM(Container Infrastructure Service Management) IFがPublishされた
      • 7or8月にリリースされたSOL001/002/003/004/005/006/007/009/014と合わせて、コンテナ制御の基本仕様は完成
      • コンテナベースのVNFもSOL001/SOL004のVNFD&Packageで提供され、SOL002/003のVNF LCM APIにてVMベースと同じように制御可能
      • VM用のInfrastructureであるVIMと同様に、Container用のInfrastructureであるCISM/CIRが定義され、VNFM/NFVO⇔CISM間IFがSOL018にて制定
    • FEAT17 IFA036 CCM(CIS Cluster Manamgent) IFのStage2がFinalizeされ、Kubernetes Cluster API (CAPI)がStage3として提案中
      • CIS Cluster＝CIS ＋ CISMとして、CIS  Cluster自体のLCMを管理する機能部としてCCMが追加
      • NFVI＋VIMの構築は現行のNFV仕様には存在しない(pre-configure)であるため、IFA036はインフラ自体を構築/削除する新しい試み
      • Pod単位の制御はIFA040/SOL018 CISM APIで提供され、CIS Cluster全体の制御(Cluster wideな制御)であるPrimary/Secondary Container Networkの構築やCRDのインストールはIFA036で行う
    • FEAT13 “Licensing”: 仕様リソースやインスタンス数ベースのVNFのライセンス管理
      • 既存NFV仕様とGAP分析したReportはIFA034として2021年10月に発行済みだが、Stage2以降の予定は未定 (進展なし)
    • FEAT19 “NFV Connectivity”: Container NetworkのNFVへの取り込み
      • IFA038をベースにContainer Networkの仕様(Primary Container Network/Secondary Container Network)はv4.3.1のStage2/3に盛り込み済
    • FEAT20 “Autonomous: LCMの自動化
      • IFA041をベースにIFA047にてMDAF (Management Data Analytics Function)のStage2作業中 (進展なし)
      • IntentのStage2は未
    • FEAT21 “NFV for 5G”: 5GCのNFVへの要件分析とその取り込み
      • IFA037をベースに既存IFの拡張中(進展なし)
    • FEAT23 “SBA”: NFVをSBAベースにすべきかどうかの検討
      • IFA039がFinal Reviewとなり、NFVのSBA化のRecommendationがほぼ完成
      • Step1: 重複仕様を削除し、NFV-S (NFV-MANO Service)とNFV-P(NFV-MANO Producer)の概念のみ導入 (ドキュメントの修正のみで実質的な仕様の変更はなし)
      • Step2: Rel5においてFunctional Blocks (NFVO/VNFM/VIM/WIM/CISM/CIR/CCM/NFVIなど)を廃止し、NFVの仕様はNFV-Sの定義のみとするが、既存仕様そのものは変更しない (アーキテクチャ図からFBが消えるので機能分担は変わるがAPIそのものは大きな変更はしない)
      • Step3: Common APIを導入し、類似のAPIはリファクタリングすることでMANOをFull SBA化する (既存仕様との互換性なし)
    • FEAT24 “Generic OAM”: Cloud-native時代のVNFの共通的なOAMの機能定義
      • EVE019をベースにIFA049にてStage2作業中
      • 機能部の定義とGeneric OAM APIの制定中
      • 今後Information Element、Descriptorも制定予定
      • Generic OAM ⇔ VNF間IFもIFA049のScopeのため、今後制定されるかも？
    • FEAT26 “Policy Models”: NFVにおけるECAベースの自動化 (仮想化と監視運用自動化を参照)
      • IFA023 (PolicyのUsecase)、IFA042 (既存仕様とIFA023のGAP分析)をベースにIFA048でPolicyの記述ルールのStage2制定中(Final Review中)
      • ONAP APEXのState-Taskの記述ベースに、Event(Policy起動のtrigger)-Condition(どのアクションを実行するか選択ための分析)-Action(実際に自動実行する処理)が実行可能なように仕様制定
      • Context (ConditionやActionでLogicで各種判断できるようにPolicyが起動された時の状況を保存)として、既存のAPIやDescriptorで取得可能なものは全てContextに入れる方針
      • Logicには各種プログラミング言語で記述可能な演算子やループなどが記述可能
  • Release5 (NFV対象ドメインの拡張): UsecaseのGAP分析が完了しRecommendation抽出中
    • FEAT27 “NFV for vRAN”: IFA046においてvRANのNFVへの要件分析とその取り込み
      • GAP分析、Solution、Recommendationまでほぼ完了しStable化
      • O-RAN WG6とNFVの対応づけはVNFM/VIM/CISM/WIMをO-Cloud、NFVO/OSS/EMをSMO
      • O2ims実現に向けて、PIM (Physical Infrastructure Manager)の導入が必要
      • S-Plane実現に向けて、WIMはTime Synchronization対応の拡張が必要
      • Near-RT RICのML(Machine Learning) ModelのPackage化のために、VNF  Packageの拡張が必要
      • AAL(Acceleration Abstraction Layer)の実現はO-RAN WG6の動向を踏まえて継続分析が必要
    • FEAT28 “Fault Model”: Alarmのアイテムの定義(Stage2)
      • NFVIの障害パターンからVirtual Resource (VR) Fault Management (FM)、VNF FMと通知されるUsecaseはAnnexに記述済み
      • Performance Management(PM)についてはIFA027で規定されていたが、FMはこれまでなかった
      • FaultType=Alarm Definition IdentifierとそのDescriptironはIFA045で規定し、Probable CauseやFault DetailsについてはIFA045でどこまで規定し、どこからRegistryで記載するか検討中
    • FEAT29 “Green NFV”: NFVにおける省電力の実現
      • 省電力モードやそのリカバリのUsecase (事前検討)
      • SolutionやGAP分析はこれから
    • FEAT30 “VNF Configuration”: VNF Configurationのリファクタリング
      • SOL002 Ve-VnfmによるVNF Configurationや、SOL014 VR DescriptorによるUser  Data (cloud-init)、EMからVNFのVNF Configuration、EVE019のVNF Configuration Management/Network Configuration Managementなどの多様なVNF向けConfigurationのリファクタリング
      • EVE022でDay-0/1/2 ConfigurationのUsecaseと各ルートでのVNF Configurationの仕様のGAP分析, Solution, 評価を実施しほぼStable
      • Configuration ServerをGeneric OAMに導入し、EMやNFV-MANOからVNF Configurationを格納する方向

Release 6

Release 6の仕様が利用される時代のETSI NFVを取り巻く世界についてWorkshopを実施した。具体的な仕様についてはRelease 5までかなり拡張されたことから、NFV仕様と周辺機関(Open Source、Cloud技術、他標準化団体)との関連について議論された。

  • Open SourceやCloud技術を”as is(=そのまま)”使うべきか、NFV標準仕様として規定すべきか？
  • VM -> Container -> Server less -> ..とインフラやVNFの実装形態が変化する中で、NFV仕様は何を決めるべきか？
  • 参加企業が減っているのにトータル寄書数は変わらない中で、本当にNFV仕様は品質を維持できているか？
  • MEC, ZSM, ENI, 3GPP, O-RAN, CNCFなどとJoint Workなどでしっかり連携し、NFVはそれらを“どう使うか=Profiling”に専念すべきではないか？
  • もっとTackerやOSMなどのOpen Sourceが即NFV仕様を利用できるように、それらが利用しやすい形態(Open APIやRobot FrameworkやSimulator)はないか？
また、具体的なRel6のNew Work Itemについても提案があった
  • 様々なタイプのData Center (High-Altitude Platform Station (HAPS), Unmanned Aerial Vehicles (UAV), Non-Terrestrial-Networks (NTN), Hyperscaler、metasurfaces など)
  • 新しいタイプのVNF (unikernel, serverless, Function as a Service (FaaS), sandbox, eBPFの集合体 など)
  • End To EndでのTime Sensitive Network (TSN)の管理
  • 原因切り分け/大規模災害時の復旧/新規サービスの正常性確認などのためのDigital Twin Networks
  • Block Chainなどを活用したConfigやFaultの管理

2016年にIFA029として開始したContainerの仕様は今回のSOL018のPublishによってやっと初版が完成した。早急にContainerの仕様をNFVがサポートできないとNFVは廃れると言われ続けながら仕様一式が完成するまで非常に長かった。テレコムの装置は単純にコンテナをDeployすれば良いというわけではなく、Networkや既存装置との接続、長期間安定的に利用するインフラなど、Kubernetesのコンセプトだけでは不足し追加すべき仕様が多々あった。今後はSOL016にContainerをDeployするときのProcedureを記載していきたい。

また今回はIFA046 NFV for vRANやEVE022 VNF Configurationなど、NFVを利用していく上で興味深い仕様検討も大きく推進し、間もなくFinalize＆Publishされる。是非とも確認して頂きたい。

コメント

コメントを投稿

このブログの人気の投稿

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