資料 50-2 ネットワーク仮想化の技術動向 KDDI 総合研究所 コネクティッド NW 部門 2019 年 7 月 10 日

Transcription

1 資料 50-2 ネットワーク仮想化の技術動向 KDDI 総合研究所 コネクティッド NW 部門 2019 年 7 月 10 日

2 アジェンダ NW 仮想化に向けた HW/SW のアーキテクチャ ( 振り返りを含む ) HW 技術の進展 ( アプライアンス ホワイトボックス 汎用サーバ ) SW 技術の進展 (IT 技術の転用とキャリア要求 クラウドネイティブ ) NFV の標準化とオープン化 標準化 :ETSI NFV オープン化 :RAN 光ネットワーク NFV の運用管理 自動化 まとめ 標準化 :ETSI ZSM TM Forum ODA オープン化 :LF ONAP

3 NW 仮想化に向けた HW/SW のアーキテクチャ

4 ( 今一度 )Network Function を実現する手段 Server model Whitebox model Appliance model VNF VNF VNF VNF VNF VNF OSPF LDP IPSec SW Guest OS Guest OS Guest OS Guest OS Guest OS Guest OS BGP IGMP PIM Hypervisor Host OS FlowSW vswitch Hypervisor Host OS FlowSW vswitch Appliance OS (vendor specific) IOS / JUNOS / PANOS NIC FPGA GPU ASIC T-CAM ASIC T-CAM HW CPU Memory Storage CPU Memory Storage CPU Memory Storage Server Whitebox Appliance Router / Switch 汎用 HW こっちへの移行を指向 専用 HW IT 寄り Telco 寄り

5 Appliance HW 進化の変移 D-Plane CPU (Centralized Architecture) ASIC (NP Clustering) Switch Fabric Distributed Architecture 主な機種 Cisco 7200 Cisco 7600 Cisco Catalyst 6500 Cisco CRS-1 ASIC や Switch Fabric による D-Plane offload の結果として高速 広帯域化は実現したが Telco 以外での用途はなく クローズ化がより進んだ Interfaces Interfaces DRAM FP CPU Ctrl Mem Pkt Mem NP TM DRAM RP CPU NP TM NP:Network Processor TM:Traffic Manager FP:Forwarding Processor RP::Route Processor ASIC:Application Specific Integrated Circuit Ctrl Mem Pkt Mem DRAM FP CPU Interfaces Switching Fabric Reference : Anatomy of internet routers jusef ungerman BRKSPG-2772 Cisco systems 5

6 Server HW 進化の変移 I/O PCI(133.3Mb) PCI-E Gen1 (32Gb) PCI-E Gen2 (64Gb) PCI-E Gen3(126Gb) PCI-E Gen4 (252Gb) NIC 100Mb 1Gb 10Gb 40Gb 100Gb D-Plane (I/O controller) MCH IOH CPU Accelerator / NIC (FPGA / ASIC) 主な Processer Harpartwon Nehalem Sandy Bridge 2010 年までは I/O が CPU とは別チップ (MCH/IOH) で提供されていたが CPU が I/O 機能を統合 CPU で計算が難しいもの 帯域幅が必要なものは Accelerator や NIC に offload される QPI C3 C2 C1 C0 MI LLC PCI-E C4 C5 C6 C7 MI QPI QPI C3 C2 C1 C0 MI LLC PCI-E C4 C5 C6 C7 MI Accelerator, NIC vendor への依存が高まる Open 化のメ リットは?Offload の流れは Appliance の歴史の繰り返しでは? PCH DMI2 x8 x8 x8 NIC FPGA PCI-E Accelerator PCI-E PCI-E NIC FPGA PCI-E ASIC ASIC Reference : System Architecture History 6

7 VNF から CNF へ NW Architecture の推移 専用物理機器上に個別の NW 機能を実装 汎用物理サーバ上に仮想化された NW 機能を実装 クラウド環境上にクラウドネイティブ化された NW 機能を実装 PNF VNF CNF インフラレイヤの効率化 NW 機能の仮想化 インフラレイヤの抽象化 NW 機能のクラウドネイティブ化 OSS/BSS Orchestrator VNFs OpenStack / VMware (Bare Metal) Server 仮想レイヤの導入により インフラレイヤの効率的な利用を目的とする 管理対象の増加やカーネルレイヤでの複雑性が上昇 オーケストレータを利用した複雑性への対処が一般的 OSS /BSS Orchestr ator VNFs OpenStack / VMware (Bare Metal) Server クラウドネイティブ管理技術 CNFs Kubernetes Any Cloud クラウドネイティブ管理技 術の活用により インフラ レイヤの抽象を行う事で NW 機能のより効率的なインフラレイヤ利用が検討さ れ始めている 7

8 クラウドネイティブ クラウドネイティブの定義 クラウドネイティブ技術により パブリッククラウド プライベートクラウド ハイブリッドクラウドなどの昨今のダイナミックな環境において スケーラブルなアプリケーションを構築および実行可能とする このアプローチの代表例に コンテナ サービスメッシュ マイクロサービス イミューダブルインフラストラクチャ および宣言型 API がある (CNCF Cloud Native Definition v1.0) 仮想化環境の導入による効果と課題 仮想化環境の導入により インフラ (HW) の共通化による調達時間などサービスインにかかる時間短縮を実現 単なる PNF のコードを移植したため 運用の煩雑さ 大規模化での課題顕在化 プラットフォームの見直しが多数発生 ( と聞いている ) 従来の NFV からクラウドネイティブネットワークへの移行 NFV における課題解決やサービス品質向上を目的とし より早いサイクルでの NW 機能改修 高度な運用管理自動化を実現するため サービスメッシュ マイクロサービスなどクラウドネイティブ技術の適用が検討され始めている 5G コア機能に関して NW 機能開発の効率化を目的の一つとし クラウドネイティブ技術が利用されている テレコム業界におけるクラウドネイティブネットワークの動向 Linux Foundation を代表とするオープンソースコミュニティを中心に検討が活発化している CNCF において Telecom Users Group が発足し オペレータとベンダによるクラウドネイティブ技術を活用した NW アーキテクチャについて議論が始まった ONS KubeCon などオープンソースカンファレンスにて 各オペレータからクラウドネイティブネットワークの検討 要求事項などが共有されている 8

9 NFV の標準化とオープン化

10 ETSI NFV 動向 ETSI NFV は NFV アーキテクチャの検討を初期からリードし 標準リファレンスモデルとしての地位を確立 多くの NFV 製品に加え 近年はオープンソース業界 (LF ONAP) でも参照されている状況 NFVI Release2 例 : OSS/BSS EM1 EM2 EM3 VNF1 VNF2 VNF3 Virtual Computing Computing Hardware Virtual Storage Virtualisation Layer VI-Ha Vn-Nf Storage Hardware Virtual Network Hardware resources Network Hardware IFA013 SOL005 Os-Ma Ve-Vnfm Nf-Vi IFA008 SOL002 NFV Orchestrator NFV Manager(s) Virtualised Infrastructure Manager(s) NFV Management and Orchestration Or-Vnfm Vi-Vnfm Serviece, VNF and Infrastructure Description Or-vi Execution reference points Other reference points Main NFV reference points 発行 Release 発行 Release 発行 Release 3 主にユースケース 及びアーキテクチャ NFVO VNFM VIM の 3 レイヤー構成 機能間インタフェース及び NS/VNF のディスクリプタ ( 設計 ) IFA では インフォメーションモデルを規定 SOL では プロトコルとデータモデルを規定 商用実装に向け より実用的な機能群を策定 例 ) ポリシー ライセンス管理 マルチサイト対応 現在 Release4 に向け議論中 NFVI レイヤの不足機能の仕様化 ライフサイクル管理の自動化 運用面の考慮 10

11 海外キャリア動向 マルチベンダー NFV 環境を構築 ビジネスのための NFV 技術 物理をそのまま仮想化しても上手くいかない スケーリングや Time to Market など提供目的毎に適材適所で NFV を導入する方針 Telco の仮想化は一般 IT と異なるため業界全体で標準化等協調が必要との立場 NFV 技術の導入だけではなく スキルセットやカルチャー等組織的な対応が必要 NFV 導入済み Cost メリットや Delivery 短縮の効果が出せていない キャリア ベンダー等の業界内でオープンな標準化が必要 ONAP や OPNFV に積極的 B2B で大規模に導入済み (24 の VNF 用 DC を構築 ) Delivery 短縮と CAPEX 削減が目的 OTT の参入によってテレコムは仮想化しないと生き残れないとの意識

12 RAN のオープン化 オープン化によるハードウェアの低廉化 仮想化実装の加速化 OTT オペレータ チップベンダがオープン化を主導 2017~18 年にデモが行われる 製品化や導入も徐々に進展する見込み Service Orchestrator Open Cloud Platform CORD led by DT, AT&T, SKT, etc. 目的効果 オペレーターの局舎設備のSDN/NFV/Cloud 化 RAN 含めたネットワークの集中制御 Controller C-Plane U-Plane RAN Protocol Virtualization Open Architecture b/w C/U-planes xran (2016~) led by DT, AT&T, SKT, etc. Open Wireless Access Platform OpenCellular (2016~) led by Facebook 目的効果目的効果 RAN ProtocolのNFV 化 C/U-Plane 分離 U-Planeハードウェアの効率化 RANのプログラマブル化 (RANaaS) RAN Protocolのオープンソースソフトウェアの開発ソフトウェアのエコシステム化 Standard Server Open Hardware OCP Telco Project (2016~) led by Facebook, AT&T, SKT, etc. 目的 効果 Telco 事業者要求を満たしたオープンハードウェアの開発 ハードウェアのエコシステム化 12

13 光ネットワークのオープン化と他社動向 主に DCI/ メトロ領域においてオプティカル NW のオープン化が活発化している 低 NW 柔軟性 実現難易度 Traditional Open Line System Open ROADM Level.2 高 WDM A 社 WDM NW WDM A 社 WDM A 社 WDM NW WDM A 社 WDM A 社 WDM NW WDM A 社 WDM A 社 WDM NW WDM A 社 Transponder B 社 Transponder B 社 Transponder B 社 Transponder B 社 Transponder B 社 Transponder B 社 Transponder B 社 Transponder B 社 異ベンダ接続 / 異ベンダ接続 / 異ベンダ接続 / 異ベンダ接続 / WDM ー WDM WDM ー WDM WDM ー WDM WDM ー WDM Transponder ー Transponder Transponder ー Transponder Transponder ー Transponder Transponder ー Transponder WDM ー Transponder WDM ー Transponder WDM ー Transponder WDM ー Transponder 各社のオープン化志向 ベンダ (Ciena 社 FNC 社 ) からの情報 オープン化団体 (TIP) を推進 オープン化団 (Open Line System) を推進 オープン化団体 (OPEN ROADM MSA) メンバ オープン化団体 (ONF ODTN) を推進 オープン化団体 (OPEN ROADM MSA) を推進 13

14 NFV の運用管理 自動化

15 運用管理 自動化に関する各団体のスコープ Level.2 Realization of E2EO ETSI NFV との整合を図るオープンソースのネットワーク機能仮想化マネジメントとオーケストレーションソフトウエア構想 OSS / BSS 5G や NFV を想定した OSS/BSS の全体フレームワークを策定 AI 活用を想定したサービス 運用 システム間 API(OpenAPI) 等の標準化に注力 また OpenAPI は ONAP の NB インターフェースにも活用されている E2E Service Orchestration オープンソースで作るネットワーク仮想化の NW 設計を含む運用管理システム 最近は他標準化団体との融合を意識している Application Orchestration NFV MANO NFVO ZSM SDN Controller 3GPP ネットワークのプロビ マネジメントや O&M 課金アーキテクチャに関する仕様の標準化 SA5 VNF EMS VNFM VIM NFV 人手を介さない運用を含むネットワーク運用自動化技術の標準化 Infrastructure Resources 15

16 TM Forum 目的 テレコム業界が OTT と対抗するために取るべきティジタル化フレームワーク (Open Digital Framework) を定義 Level.2 Open Digital Framework 従来の OSS や BSS だけでなく ビッグデータ基盤などを考慮した構成要素 AI 活用 全体システム NW 自動化

17 ITU-T FG ML5G (Focus Group on Machine Learning for Future Networks incl.5g) 将来ネットワークにおける ML (Machine Learning) 適用のアーキテクチャ プロトコル アルゴリズム データ形式に関する報告書の作成を目的とする Level.2 ITU FG-ML5G の各 WG のミッションと目標 WG1 Use cases, Services and Requirements WG2 Data formats & ML technologies WG3 ML-aware network architecture チェア SeongbokBAIK(KT 韓国 ) Mostafa ESSA(Vodafone エジプト ) WojciechSAMEK(Fraunhofer ドイツ ) Qi SUN(China Mobile 中国 ) Wei MENG(ZTE Corp. 中国 ) 検討内容 機械学習が必要となるユースケースおよび要求条件は何か? 現状の標準仕様とのギャップは何か? 機械学習に必要となるデータを ネットワークからどのように収集 精査 処理を行うか? プライバシやセキュリティにどのような影響を与えるか? 機械学習の手法を 如何に NW の問題解決に適用するか? 機械学習がネットワークアーキテクチャに与える影響は何か? 計算能力 消費電力 インタフェース 通信資源等の要求条件は何か? 予定成果 重要なユースケースの策定 複数のユースケースに共通する基本機能の仕様策定 ユースケースとビジネスエコシステムにおける技術ギャップの分析 機械学習技術の適用方式やデータ形式に関する分析 ネットワークアーキテクチャに与える影響の分析 WG1 が定めるユースケースを想定したデータ形式と収集に関する仕様策定 機械学習機能を実現するネットワークアーキテクチャの策定 WG1 WG2 と連携した機械学習の実現に必要となる機能 インタフェース 資源の仕様策定 今後の検討課題 : 現状ネットワーク構成では収集できない不足情報の明確化や ML で導出可能な情報の明確化

18 ONAP(Open Network Automation Platform) 概要 オープンソースベースで キャリアグレードの次世代運用支援システムを開発し NW 設計 障害対応に係るオペレーションを自動化することを目標にしたプラットフォーム Level.2 ONAP の歴史 NW 設計機能 運用機能 ECOMP 2016 プロジェクトを統合 NW 設計機能 と 運用機能 の 2 つに分かれた構成 VNF の Controller は ETSI 準拠 2

19 ETSI ZSM Zero-touch Service and network Management NFV 更にはモバイル網やトランスポート網を含む End-to-End(E2E) の自動化を目的として設立 19 年 9 月に ユースケース及びアーキテクチャのドキュメントが発行される予定 今後 IF やプロトコル等詳細仕様策定 アーキテクチャの特徴 管理区分に応じ複数のドメイン (MD) を規定し これらを E2E サービス管理ドメイン (E2ESMD) が統合する階層型管理 各ドメインが必要な管理サービスを expose する E2E 管理に必要なデータを蓄積する 各種管理機能 ( オーケストレーション データ収集等 ) をサービスとして規定し これらを組み合わせることによって E2E サービスの運用を自動化する 例えば ETSI NFV で規定される管理機能群が 1 ドメインを構成 19

20 まとめ

21 まとめ NW 仮想化に向けた HW/SW のアーキテクチャ ( 振り返りを含む ) 標準化とオープン化 運用管理 自動化の進展 仮想化は汎用物理サーバのVNFからクラウドをダイナミックに活用したCNFへ NFV の標準化とオープン化 多くの標準化とオープン化の活動が存在 これまで以上にオペレータとしての判断必要 OTT 的に走りながら実施するか キャリア的にきっちり決めて実施するかの判断必要 スピード感と安定性の相反性をどう考えるか オープン化の際の安定性はオペレータの責任 今後に向けて業界内でのコラボレーションを促進する土壌を形成していく仕組みが必要

22