OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月

© 2017 NTT DOCOMO, INC. All Rights Reserved.

OpenStackを利用したNFVの商用化

２０１7年7月２6日

NTTドコモネットワーク開発部

中島佳宏


自己紹介

•中島佳宏

– 経歴 •2003年 - 2008年筑波大学大学院コンピュータサイエンス専攻

– HPC･分散システムの研究

•2008年 – 2017年 NTT 未来ねっと研究所

– 2008年-2011年 HD映像のIP伝送装置･ネットワークトラヒック測定装置開発

– 2011年-2012年 SDN制御

– 2012年-2017年高速なソフトウエアスイッチ開発 (Lagopus vswitch)

http://www.lagopus.org/

•2017年 - NTTドコモネットワーク開発部

– NFV向け仮想化基盤 (ミドルウエア･HW)担当

– 専門 •高速な○○処理･仮想化技術･システムソフトウエア

– 2012年 DPDK Version 1.1から

2


ネットワーク仮想化への取り組み

3


メリット① 通信混雑時のつながりやすさの向上（オートスケーリング）

メリット② 通信サービスの信頼性向上（オートヒーリング）

メリット③ サービスの早期提供（システム個別HWの構築が不要）

メリット④ ネットワーク設備の経済性向上（COTS、共用化）

上記メリット最大化のためには

複数ベンダー装置の組み合わせが必要

ネットワーク仮想化のメリット

4


専用ハード

ソフト

仮想化レイヤー仮想化管理

システム

・低コストな汎用ハード・自動切替用に共用ハード・統一的なメンテナンス

専用ハード

ソフト

汎用ハード汎用ハード

ソフトソフト

ハード (故障交換用)

ハード (故障交換用)

・汎用ハードが共用可能となり、ネットワーク設備の経済性を向上

ネットワーク仮想化技術の適用後

・高価な専用ハード・故障交換用に専用ハード・専用ハード毎のメンテナンス

汎用ハード

ネットワーク仮想化技術の適用前

メリット① ネットワーク設備の経済性向上

5


・自動的に通信設備の容量を追加し、つながりやすさを向上

イベント・災害発生イベント・

災害発生

容量逼迫

容量追加

ハード

ソフト仮想化レイヤー

ハード

ソフトソフト

ハード

仮想化管理

システム追加指示

輻輳時には規制を実施自動で容量追加し、つながりやすさを向上

ネットワーク仮想化技術の適用後ネットワーク仮想化技術の適用前

輻輳⇒規制

メリット② 通信混雑時のつながりやすさの向上

6


メリット③ 通信サービスの信頼性向上

・ハード故障時に、二重化運転への自動復帰により高い信頼性を実現

稼働中予備

切替後、修理完了まで二重化されていない

ハード

ソフト

ハード

ソフト

故障発生

仮想化レイヤー

ハード

ソフトソフト

ハード

仮想化管理システム

ハード

稼働中

予備


ハード

ソフト

ハード


ハード

稼働中

故障発生

故障

切替指示

ソフト

予備

二重化運転に自動復帰

自動で二重化運転に復帰する → 高い信頼性を実現

ネットワーク仮想化技術の適用後ネットワーク仮想化技術の適用前

ソフト

稼働中

ハードハード

ソフト

7


メリット④ サービスの早期提供・ハードの準備が不要なため、迅速なサービス提供が可能

サービス開始

ハード計画

サービス準備開始

ハード調達

ハード工事

ソフトインストール・設定

試験

サービス開始

ソフトインストール・設定

試験


ハード


ネットワーク仮想化技術の適用後

ハード

ハード

ソフト

ハード

ソフト



ハード

サービス準備開始

ハードの計画・工事が必要共用ハードを用いて、迅速なサービス提供が可能

ネットワーク仮想化技術の適用前

8


複数ベンダー装置の組合せによるメリットの最大化


複数ベンダー組合せ単一ベンダー

・ソフトウェアと仮想的なハードウェアが、異なるベンダーの組み合わせで動作可能とする


仮想化管理

システムハードハード（予備）

ソフト

新サービス

ハード（予備）

仮想化レイヤー仮想化管理

システム

ソフト

ハード



仮想化管理

システム

ソフトベンダーA

ハード輻輳

ベンダーB

ベンダーＸ


仮想化管理

システムハードハード

ソフトソフト輻輳or故障


設備利用の効率化

ベンダーA ベンダーB

ベンダーＢ用に1台の予備ハード

仮想化管理

システムハードハード

ソフトソフト

ベンダーA ベンダーB

全体を追加する必要あり

ベンダーＡ用に1台の予備ハード

ベンダーＸソフト

（新サービス）

ハード

新サービス追加

新サービス追加

故障

9


２．商用化への取り組み

10


ネットワーク仮想化の基礎研究に着手

2005 －

総務省受託研究

※大規模災害時等により発生する通信混雑を緩和する技術研究

2012 －2013

3社との単一ベンダー実証実験

2013年11月－

6社との複数ベンダー

組み合わせ実証実験

2014年4月―

2012年11月～

ETSI ISG NFVで活動

2014年9月～

OPNFVで活動

ドコモの取り組み

•2005年よりネットワーク仮想化の基礎研究を開始

•ETSI ISG NFVにてネットワーク仮想化の検討をリード、 OPNFVにて仮想化プラットフォームの実装を推進

•2度の実証実験を経て、2016年3月にvEPCを商用化

2016年3月 Today

vEPCの商用化

拡大＆拡張

11


ETSI ISG NFVのアーキテクチャフレームワークハードウェアとソフトウェアを分離し、異なるベンダーからの提供を可能とするアーキテクチャ

プラットフォーム：仮想化技術によりハードウェアに依存しないソフトウエア実行環境を提供

アプリケーション：ソフトウェアのみによるネットワーク機能の実装

管理制御：全体を管理制御するオーケストレーション機能

出典：ETSI GS NFV 002 V1.1.1

実行参照点

NFV参照点

NFV対象外

網内全体にわたるインフラとサービスの管理

DC（局舎）内の各種インフラ資源の管理

NFV Management and Orchestration

計算装置記憶装置伝送装置

Hardware resources

仮想化レイヤ（Hypervisor）

仮想インフラマネージャ

（VIM)

仮想NW機能マネージャ（VNFM)

仮想NW機能（VNF 2）

オーケストレータ

OSS/BSS

NFVI

仮想NW機能（VNF

3）

仮想NW機能

（VNF 1）

仮想計算資源

仮想記憶資源

仮想伝送資源

EMS 2

EMS 3

EMS 1

サービス、仮想NW機能等の要件記述

Or-Vi

Or-Vnfm

Vi-Vnfm

Os-Ma

Se-Ma

Ve-Vnfm

Nf-Vi

Vn-Nf

Vl-Ha

仮想NW機能 (IMS, EPC)

汎用機器から構成される物理装置

仮想NW機能（通信APL）のライフサイクル管理

VNFに仮想資源を提供 (ハード非依存)

12


NFV標準アーキテクチャと利用している仮想基盤構成

出典：ETSI GS NFV 002 V1.1.1

NFV Management and

Orchestration

計算装置記憶装置伝送装置

Hardware resources

仮想化レイヤ（Hypervisor）

仮想インフラ

マネージャ（VIM)

仮想NW機能マ

ネージャ

（VNFM)

仮想NW機能

（VNF 2）

オーケスト

レータ

OSS/BSS

NFVI

仮想NW機能

（VNF 3）

仮想NW機能

（VNF 1）

仮想

計算資源

仮想

記憶資源

仮想

伝送資源

EMS 2

EMS 3

EMS 1

サービス、仮想NW機能等の

要件記述

Or-Vi

Or-Vnfm

Vi-Vnfm

Os-Ma

Se-Ma

Ve-Vnfm

Nf-Vi

Vn-Nf

Vl-Ha

13


vEPCのベンダ構成

• 異なるベンダーのソフトウェアとハードウェアを組み合わせてシステムを構築

• VIMとしてOpenStackを採用

• システムインテグレーションはドコモが実施

NFV test bed in DOCOMO

Hypervisor

HW

vEPC

HW

VIM

vEPC

SDN NW

マル

チベ

ンダ

構成

複数ベンダのアプリケーション

FUJITSU NEC

ERICSSON

CISCO

VNFM VNFM

NFVO

14


対象とするキャリア向けのVNF

15


VNFと一般的なアプリケーションとの違い

•リアルタイム処理指向

– モバイル網の規定する遅延時間未満での処理

– 低い処理遅延と低いジッタ

•高いネットワークI/O・パケット処理性能が必要

– Gbps級・sub M PPS級の性能

– 1KB以下パケットサイズ時の高い性能

•VNFのVNFcレベルでHA･Failover機能が動作

– L2/L3レベルでのHA機能あり

16

VNF: Virtual Network Function VNFc: Virtual Network Function Component


0

2,000,000

4,000,000

6,000,000

8,000,000

10,000,000

12,000,000

14,000,000

16,000,000

0 256 512 768 1024 1280

# o

f packets

per se

conds

Packet size (Byte)

Short packet 64Byte 14.88 MPPS, 67.2 ns • 2Ghz: 134 clocks • 3Ghz: 201 clocks

Computer packet 1KByte 1.2MPPS, 835 ns • 2Ghz: 1670 clocks • 3Ghz: 2505 clocks

10Gbpsってどのくらい大変なの?

17


テレコム向けVNFの特徴 (1/5)

VNF

1 function = 1 VNFc = 1 VM

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

1 function = 3 - 10 VNFcs = 10 – 50 VMs

18



NFVI

Compute server

Compute server

Compute server

Compute server

Compute server

Compute server

Compute server

Compute server

Compute server

100-500台

～1000 VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

19



VM App

vNIC

OS

vNIC backend

frontend

VM App

vNIC

OS

vNIC vNIC vNIC vNIC vNIC

management

C-plane (internal)

C-plane (external2)

C-plane (external1)

U-plane (internal)

U-plane (external)

通信用途ごとのQOS要件やセキュリティ要件のためvNIC数が多い

構成がシンプル３vNIC程度

20



NFVI

Compute server

Compute server

Compute server

Compute server

Compute server

Compute server

VIM

VNFM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFの更新

100VMへの同時操作

21



NFVI

Compute server

Compute server

Compute server

Compute server

Compute server

Compute server

VNF

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VNFc

VM

VIM

VNFM

大量のVM全部が正常にInstantiation完了する必要性

22


NFV向けの仮想化環境として求められる機能

要件 OpenStackの機能(期待を含む) 運用の工夫

オーバヘッドの無い環境 - CPU 占有 - NUMA-aware割り当て - 資源のOver commitを防止

性能劣化を防ぐ資源配置 - NUMAを意識した資源割り当て - CPU - Memory - NIC

リアルタイム処理にむけた環境を提供 • 資源のOver commitを防止 • CPU pinning • Memoryの確保

高性能なNetwork I/Oを提供 - DPDK対応OVS - SR-IOV

サーバベンダ差分を吸収 - KVM/HV - NWの命名規則による工夫 - Fencing

保守作業の部分自動化 - ヒーリング機能 - Fencing

高い同時制御命令実行 - OpenStackのスケーラビリティ - Nova - Cinder

23


VNFの高い性能要件を満たすために

24

CPU Socket#0

NIC NIC NIC

RAM RAM RAM RAM

RAM RAM RAM RAM

CPU Socket#1

RAM RAM RAM RAM

RAM RAM RAM RAM

NIC

VM VM VM VM HostOS

vSW

SRIOV SRIOV

仮想CPUはオーバコミットしない（専用割り当て）

仮想メモリーはオーバコミットしない（専用割当て）

単一Numaノードで配置 (同一スロットル上に配置)

SR-IOVを利用 OVS-DPDKを活用


SR-IOVの活用

25


SR-IOVとvSWの使いどころ

SR-IOV (Intel 82599) OVS DPDK

帯域性能 1- 10 Gbps 1 – 1 Gbps

PPS性能 8 MPPS < 1 MPPS

遅延 HWと同等 HWより大きい

Jitter HWと同等 HWより大きい

VLAN数 64 2K

vNICの制限最大64 VF 1 unicast MAC/VF

64 vlan/VF 最大30 multicast MAC

最大100 vNIC vNICの増加に伴い

性能劣化

NWアプリの挙動観点で制限が多い

26


SR-IOVの中身

Intel 82599

VM

OS

VF driver

NIC

PCI Pass-through

VF0 PF VF1

Embedded L2 SW

BUF BUF BUF

VM

OS

VF driver

NIC

単なるL2 SWではない • Source MAC filter • Multicast MAC filter

HWと比較し制限あり VLAN数/VF 1 Unicast MAC addr/VF

27


実際は････

› SR-IOVドライババージョン相性 – VNFベンダの提供するVF driverと基盤ベンダの

提供するPF driverのバージョン相性問題

– 特定パケットがドロップ

› NeutronでPort security = off

› Hostでip vf trusted on

› SR-IOVでのパケットロス – 切り分け、解析が非常に困難

– VF切れば切るほどBufferが削減

Guest OS

Host OS

PF driver

VF driver

NIC

互換性の欠如

• SR-IOVは高スループットを必要とるVMにとっては現実解であるが、インテグレーションの複雑さの増大･問題解析の困難さ増大

• 将来的にOVSの高速化やHardware accelerationの活用も?

VNFベンダ

基盤ベンダ

パケット転送

28


HW差分を隠蔽した上でサーバ内部構成を意識

29


SR-IOV利用時のNFVO, VNFM，VIMの流れ

•NFVO、VNFMが指定したNetwork･Port情報は間接的に特定のCPU Socketを活用するのと同義

VIM （OpenStack)

NFVO

Create Network Network#A Physnet1

Create Port Port#A Network#A

VNFM Create VM VM#A Port#A

IA Server

CPU Socket#0 CPU Socket#1

NIC#1 NIC#0

host

VM#A

Physnet1

Assign Logical Name for Physical NIC NIC#0 = Physnet1

30


SR-IOVのためのIAサーバのバス構造によるホスト設計差分

•CPU Socketごとの差分削減のためCPU Socket毎に直結したNICを搭載

•IAサーバは機種やCPUの違いにより以下のように内部バス構造が異なる

CPU Socket#0

NIC NIC NIC

RAM RAM RAM RAM

CPU Socket#1

RAM RAM RAM RAM

NIC

IAサーバ（機種＃A）

CPU Socket#0

NIC NIC NIC

RAM RAM RAM RAM

CPU Socket#1

RAM RAM RAM RAM

NIC

IAサーバ（機種＃B）

31


DPDK OVSのためのIAサーバのバス構造によるホスト設計差分

•DPDK OVSの性能ために、CPU SocketとNICを考慮しプロセスを固定

•機種差分によって固定配備するCPU Socketが異なる

CPU Socket#0

NIC NIC NIC

RAM RAM RAM RAM

CPU Socket#1

RAM RAM RAM RAM

NIC

IAサーバ（機種＃A）

CPU Socket#0

NIC NIC NIC

RAM RAM RAM RAM

CPU Socket#1

RAM RAM RAM RAM

NIC

IAサーバ（機種＃B）

HostOS vSW

HostOS vSW

32


OpenStack活用＋SR-IOV,ホスト設計差分による課題

•NFVO,VNFMにおいてマルチソケットを考慮したVM生成を制御する必要

•機種毎の設計差分が存在し，Socket#指定では差分を吸収できない

課題① 大規模VMの作成失敗


Host

VM

課題② 収容効率の向上 or VM作成失敗

VM

VM

VM


Host

VM

VNFM VIM VM作成要求 (socket#0)

IAサーバ（機種＃A）：成功

IAサーバ（機種＃B）：失敗


Host


Host

IAサーバ（機種＃A）：６VM

IAサーバ（機種＃B）：４VM（２VM失敗）

VM VM VM VM VM

VM VM VM VM VM VM

VNFM VIM

VM作成×4 (socket#0)

VM作成×2 (socket#1)

33


論理識別子の命名方法の工夫による解決

VIM

NFVO

②Create Network for SR-IOV Create network Large – physnet1 Create network Small – physnet2

③Create Port Create port aaa – Large Create port bbb – Small

VNFM

④Create VM Create server VM#A –port aaa, bbb Create server VM#B –port ccc, ddd

⑤Deploy VM

IA Server 機種A


NIC#1 NIC#0

host

VM#A

Physnet1 Physnet2

①Assign Logical Name for Physical NIC NIC#0 = Physnet1／NIC#1 = Physnet2

VM#B

IA Server 機種B


NIC#1 NIC#0

host

Physnet2

①Assign Logical Name for Physical NIC NIC#0 = Physnet2／NIC#1 = Physnet1

Physnet1

VM#A VM#B

①機種に依らず同じ空リソースのSocketを識別

• Physnet1:空リソース大

• Physneｔ2:空リソース小

②論理デバイスによる識別方法を仮想Network名にも透過適用し、抽象的なSocket指定

• Large：空リソース大

• Small：空リソース小

34


識別の工夫による結果

•VIMによって機種差分は隠ぺいされ、且つVNFMは仮想ネットワーク名をCPU空リソースの識別子として扱うことが可能

課題① 大規模VMの作成失敗


Host

VM

課題② 収容効率の向上 or VM作成失敗

VM


Host

VNFM VIM VM作成要求 (空リソース：大)

IAサーバ（機種＃A）：成功

IAサーバ（機種＃B）：成功


Host


Host

IAサーバ（機種＃A）：６VM

IAサーバ（機種＃B）：６VM

VM VM VM VM VM

VM VM VM VM

VNFM VIM

VM作成×4 (空リソース：大)

VM作成×2 (空リソース：小)

VM VM VM

35


ヒーリング

36


①オートヒーリング（VNFM起動）

②オートヒーリング（VIM起動）

③マニュアルヒーリング

IA Server

VNFc

IA Server

VNFc

OSS

VIM

VNFM

NFVO

IA Server

VNFc

VNFc

IA Server

VNFc

OSS

VIM

VNFM

NFVO

VNFc

VNFc

故障

VNFc

故障

ヒーリング

ヒーリング判断

IA Server

VNFc

VNFc

IA Server

VNFc

OSS

VIM

VNFM

NFVO

故障

ヒーリング判断

故障

37

ヒーリングとは

•VNFc(VM)障害やHW障害時に正常なHW上にVMを再生成し障害から復旧させる機能 – オートヒーリング: 仮想化基盤が障害状況に応じて自動的に実施

– マニュアルヒーリング: 障害監視等を通じて人手によって実施

•HW故障の自動復旧により駆けつけ稼働（OPEX）の削減が可能

37


オートヒーリングの動作

38

サーバ異常を検出 VNFMへ通知

別ServerにVMを配置

IA Server

VNFc

IA Server

VNFc

OSS

VIM

VNFM

NFVO

VNFc

VNFc

故障

ヒーリング

VNFMは障害情報からヒーリング要否を判断

VMを起動通信ソフトを復旧

サーバベンダ毎に故障情報ポリシーが異なる ①障害検知可能な故障部位 ②故障レベル ③故障検出方法

障害情報をNova schedulerを考慮せず • 故障ノードに再配置 • リブートするHWに再配置


STEP1：HW監視装置はNFVI Server障害を検出し, 障害情報の正規化を実施 STEP2：HW監視装置は正規化した障害情報を VIMに送信 STEP3：VIMは正規化された障害情報を元にヒーリング実施判断し, NFVI ServerのIPMIを使いNFVI Serverの停止 (Fencing機能) STEP4：VIM/VNFMはNFVI Serverの停止を検出し他のNFVI ServerにVMを起動する

IA Server

OSS

VIM

VNFM

NFVO

HW監視装置

故障 ①

②

③

キャリアネットワーク観点からの解決法

39


CPU MEM NIC

致命的な障害重度の障害軽度の障害警告情報

DISK PSU FAN Temp

CPU MEM NIC DISK PSU FAN Temp



NFVI(ベンダ:A）テンプレート

NFVI(ベンダ:B）テンプレート

HW監視装置

NFVI(ベンダ:A） NFVI(ベンダ:B）

障害情報障害情報

ハードウエア差分をなくすための障害情報の統一化

• 仮想化基盤システム内で用いる障害情報は統一的な表現とする

– 障害レベルの定義と構成品を定義

– 異なる汎用IAサーバの障害情報を定義した障害情報にマッピングし正規化

– 障害情報のマッピング処理は一元的に実施する必要がある為,HW監視装置での実施

– 正規化はテンプレートを用いる事で汎用IAサーバの追加毎に機能追加なく実現可能

40

オペレータのポリシーを元に定義

障害情報をマッピング

Fault ID Fault severity 1011 CPU 警告

1012 CPU 軽度の障害

1013 CPU 重度の障害


OPNFV Doctor

•ハード故障を即座に検知し切替指示を行う機能を開発

•当初のScopeは開発完了

41


ハード

ソフトソフト

ハード


ハード

稼働中

予備


ハード

ソフト

ハード


ハード

稼働中

故障発生

故障

切替指示

ソフト

予備

ハードウェア等の故障情報をリアルタイム把握し、

VMのSLAを踏まえて切替指示を実施


OPNFV Doctor機能

42

モバイルコアノードの故障対応機能を新たに開発した PJメンバ：NEC, Nokia, Ericsson, NTT SIC, DOCOMO他

ハードウェアサーバ(ホスト)

ハイパーバイザ

NFVI（クラウド基盤)

VNF (ACT)

VNF (SBY)

3rd Party NFVIモニタ

Inspector (Congress/

Vitrage)

AODH NOVA

VNFM

①

②

③

④

OpenStackにて開発した新機能： ①：故障通知（ホスト名） ②：故障通知（ホスト名）－NOVAにて「ホスト利用不可能」と状態変更 ③：VM状態変更 ④：VNFMへ故障通知

ｵﾍﾟﾚｰﾀによる故障項目の動的な定義

オープンソースソフトウェアとして開発することで低コスト化の実現 OpenStackで1秒以下で故障対応可

開発のスコープ


Doctor開発機能一覧

43

OpenStackに７つの新機能を開発した

4. (alt) Notify

Monitor

Notifier

Consumer (VNFM, NFVO)

Alarm Conf.

3. Update State 2. Find Affected

Controller Controller Controller

Resource Map

1. Raw Fault

Inspector

4. Notify all

5. Notify Error 0. Set Alarm

Failure Policy

Monitor Monitor

Nova

Congress

Ceilometer+Aodh

NFVI

（クラウドインフラ）

OpenStack function

6

1

2

3

4

5

Title Status Owner Lead Developer Description Link

Event Alarm Evaluator Code merged in Liberty

Ryota (NEC) Ceilometer: Ryota (NEC) Implementation of new alarm evaluator to immediately notify consumers of fault events

https://blueprints.launchpad.net/ceilometer/+spec/event-alarm-evaluator

New nova API call to mark nova-compute down

Code merged in Liberty

Tomi (NOKIA) Nova: Roman (Intel) API to set compute nodes to down / up https://blueprints.launchpad.net/nova/+spec/mark-host-down

Support forcing service down Code merged in Liberty

Tomi (NOKIA) Nova client: Carlos (NEC) Client-side implementation of above https://blueprints.launchpad.net/python-novaclient/+spec/support-force-down-service

Get valid server state Code merged in Mitaka

Tomi (NOKIA) Nova: Tomi (NOKIA) To get host status information when consumer queries for VM instance detailed information

https://blueprints.launchpad.net/nova/+spec/get-valid-server-state

Add Notification for service status change

Code merged in Mitaka

Balazs (Ericsson) Nova: Balazs (Ericsson) Notification of maintenance actions on e.g. compute nodes to consumers

https://blueprints.launchpad.net/nova/+spec/service-status-notification

Push Type Data Source Driver Code merged in Mitaka

Masahito (NTT)

Congress: Masahito (NTT)

This feature enables Congress to receive data from another service.

https://blueprints.launchpad.net/congress/+spec/push-type-datasource-driver

Doctor Data Source Driver Code merged in Newton

Masahito (NTT)

Congress: Masahito (NTT)

Push Type Data Source Driver adaptation for Doctor

https://review.openstack.org/#/c/314915/

1 2

4 5

6

3

プロジェクト名OPNFV Doctor

7

7


今後

44


SDN(マルチレイヤ連携)

・・・・・・

コアネットワークの進化

[2016年3月9日] vEPCの商用導入

[2016年度以降] ネットワーク仮想化の適用拡大とハードウェア利用の効率化

[2020年度以降] 5G時代の新たなビジネスを実現するネットワークへの発展

vEPCの導入

既存EPC

MME

PGW SGW

PCRF

P-CSCF

HSS TAS

S-CSCF

既存IMS

ビジネス領域の拡大

NFV導入 - スケールアウト/ヒーリング

SGW MME PGW

市販IAサーバ（COTS）

NFV拡張 - 自動化の拡大

- 局舎間リソース共有

適用対象拡大ハードウェア利用効率化

MME SGW PCRF

TAS P-CSCF HSS

…

NFV進化 - ｻｰﾋﾞｽ最適化ﾈｯﾄﾜｰｸ

SDN(局舎内) SDN(局舎間)

・・・・・・・・・

現在 2020年度以降 2017年度以降

4K

S-CSCF

PGW

クラウドネイティブアプリ

45


Reference (1/2)

•OpenStack

– https://www.openstack.org/assets/presentation-media/7688-Achieving-Low-Latency-NFV-With-Openstack.pdf

•DPDK

– http://events.linuxfoundation.org/sites/events/files/slides/Jun_Nakajima_NFV_Container_final.pdf

– https://dpdksummit.com/Archive/pdf/2016USA/Day02-Session02-Steve%20Liang-DPDKUSASummit2016.pdf

– https://01.org/sites/default/files/page/intel_onp_server_release_1.2_benchmark_test_report_v1.0.pdf

46

https://www.openstack.org/assets/presentation-media/7688-Achieving-Low-Latency-NFV-With-Openstack.pdf















http://events.linuxfoundation.org/sites/events/files/slides/Jun_Nakajima_NFV_Container_final.pdf



https://dpdksummit.com/Archive/pdf/2016USA/Day02-Session02-Steve Liang-DPDKUSASummit2016.pdf







https://01.org/sites/default/files/page/intel_onp_server_release_1.2_benchmark_test_report_v1.0.pdf

https://01.org/sites/default/files/page/intel_onp_server_release_1.2_benchmark_test_report_v1.0.pdf


Reference (2/2)

•SR-IOV

– http://events.linuxfoundation.org/sites/events/files/slides/20160715_LinuxCon_sriov_final.pdf

– http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.456.8534&rep=rep1&type=pdf

47

http://events.linuxfoundation.org/sites/events/files/slides/20160715_LinuxCon_sriov_final.pdf

http://events.linuxfoundation.org/sites/events/files/slides/20160715_LinuxCon_sriov_final.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.456.8534&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.456.8534&rep=rep1&type=pdf

OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月

Technology

Transcript of OpenStackを利用したNFVの商用化 - OpenStack最新情報セミナー 2017年7月