MPLS JAPAN 2014

通信事業者におけるSDN/NFV技術に対する期待と課題
原 翔一郎 桑原 世輝
NTTコミュニケーションズ株式会社
技術開発部
2014.11.6

Copyright © NTT Communications Corporation. All rights reserved.

SDN/NFVアーキテクチャ
拡張性を持って迅速にサービス開発するため統一されたアーキテクチャが必要<ゴール> 迅速なサービス開発
 効率的なソフトウェア開発
Customer/Productmanagement
オーケストレーションレイヤオーケストレータ
Open API

Copyright © NTT Communications Corporation. All rights reserved.

1

APコントローラNFV Controler

OFC

SDNコントローラ
NW Cntroller

技術の進展に伴い様々なコントローラをデプロイ

Cloud Cntroller

Cloudコントローラ
Virtual
リソース
コントロールシステム連携API

BSS /OSSSDN (Software Defined Networking)Copyright © NTT Communications Corporation. All rights reserved.

2

SDNに対する取り組み
キャリアとして実現したいこと• Time to Market短縮• オペレーションの自動化• OPEX/CAPEXの削減

SDNの取り組み
Cloud/Virtualized DC

最近の主な取り組みをご紹介• DCとVPNの接続自動化の取り組み

DCGW

接続自動化

3DCGW

Service NW

PTN/
OXC

Copyright © NTT Communications Corporation. All rights reserved.

DCGW

PTN/
OXC
PTN/
OXC

PTN/
OXC
PTN/
OXC

Transport

DCとVPNとの接続自動化 [接続自動化前]• クラウド内ではテナントネットワークを自由に作成可能• VPNと接続する場合はVLAN/VRF等の設計が必要• クラウド側でネットワークが追加・削除される度にPEルータのコンフィグアップデートが必要

Data center
Network

MPLS-VPN
VLAN

VLAN

Copyright © NTT Communications Corporation. All rights reserved.

MPLS
4

DCとVPNとの接続自動化 [SDNによる接続自動化]••••

クラウド内ではテナントネットワークを自由に作成可能
ポータルサイトからAPIを介して自動的にVPNと接続
SDNコントローラでテナントネットワークとVPNをマッピング
経路のアップデートはBGPで広告されるためVPN側のASBRのコンフィグが不要
API

オーケスト
レータ
APISDN
コントローラOpenFlow
Data center
Network

mp-eBGP
MPLS-VPNMPLSInter-AS option B

VLAN

Copyright © NTT Communications Corporation. All rights reserved.

MPLS
5

接続自動化におけるSDNのアーキテクチャ
API

オーケストレータ※DC側とVPN側とのシステム連携機能を提供

カスタマーポータル

VPN
管理システムAPI

SDNコントローラ
DB

接続自動化
Application

RIB

ConfigOF-wire(Ryu)
OpenFlow
Data center
Network
Copyright © NTT Communications Corporation. All rights reserved.

BGP
Speaker
mp-eBGP

FIB

DCGW
6

MPLS
VPN

接続自動化実現に向けた主な課題
SDNコントローラDBAPI

接続自動化
Application

OF-wire(Ryu)

課題1.
様々なD-plane要件の実現
Data center
Network
Copyright © NTT Communications Corporation. All rights reserved.

課題2.
高性能・高信頼なアーキテクチャの実現

OpenFlow

BGP
Speaker

mp-eBGP

課題3.
利用状況を設備計画へ反映する方法
MPLS
VPN

DCGW
7

課題1：様々なD-plane要件の実現• 異なるNW間(DCとVPN)をつなぐ際に必要となるD-planeの要件をSDNでどう実現するか？
 効率的なFlow Table管理
 MPLS <-> VLAN変換
 QoS処理 収容数向上Data center
NetworkMPLS
VPN

DCGW

SDNでどのようにD-plane処理するか？
MPLS

VLAN

Copyright © NTT Communications Corporation. All rights reserved.

8

課題1の解決：OpenFlow機能の活用• 以下のようなOpenFlow機能を利用することで実現
 効率的なFlow Table管理 Multi-tableを利用したフロー処理
Table
0Table1Tablen MPLS <-> VLAN変換
 Match & Action(pop & push)
DirectionVLAN

MPLS LabelDC to VPN

Match & PopPush

VPN to DCPush

Match & Pop

 QoS処理 Meter tableの利用 OF-configによるQueue作成
今後に向けたポイント

Copyright © NTT Communications Corporation. All rights reserved.

収容数向上のためには保持できるFlow数が多いほどよいが、Hardware側のMemoryに依存⇒ 短期的にはHardware性能向上
9課題2：高性能・高信頼なアーキテクチャの実現• 様々な障害時にも極力ユーザ通信に影響を与えないようにするにはどのようなアーキテクチャにすべきか？
SDNコントローラ
接続自動化
Application
OtherFunctions••

OpenFlow

ノードを跨いだ形でOpenFlowや
mp-eBGP通信が発生するアーキテク
チャだと、その通信用に高信頼なNWを準備する必要があるノード間でOpenFlowやmp-eBGPの通信が増えることで性能がでない

Copyright © NTT Communications Corporation. All rights reserved.

OF-wire
(Ryu)

DCGW

10

BGP
Speaker

mp-eBGP課題2の解決：コントローラ機能配備の工夫••

SDNコントローラの機能のうち、D-plane処理に関わる機能をDCGW側に配備することでノード間通信の結合度を下げ、ノード間NW障害やController機能
側筐体故障等の際のD-plane影響度を減少
OpenFlow等の通信を筐体内で処理することにより性能を向上

集中モデル

分散モデル

サーバ

サーバ

接続自動化Application

Controller機能•••

OF-wire(Ryu)
ノード間NW

OpenFlow(packet-in/out)

ノード間NW

API提供
Config管理
DCGW管理REST

Application
OpenFlow(packet-in/out)

OpenFlow AgentDCGW

Copyright © NTT Communications Corporation. All rights reserved.

OF-wire(Ryu)
OpenFlow Agent

11

DCGW

課題3：利用状況を設備計画へ反映する方法• 設備計画に利用状況を反映するため、トラフィックやFlow数等の情報を効率的に取得し、管理する方法は？
 SNMP MIBを利用する場合、機能実装が必要(時間とコストがかかる) 一般的には、コントローラにトラフィックやFlow数等の情報を保存する場合、利用するユーザが増えるに従ってこれらの情報も増え、コントローラのスケーラビリティに影響

Copyright © NTT Communications Corporation. All rights reserved.

12課題3の解決：情報収集ソフトウェアの利用• SNMP MIBを利用せず、Applicationによって生成された情報を収集し管理するソフトウェアを利用することで実現

SDNコントローラ

APIAPI

統計情報管理機能

Controller機能
情報表示機能生成される統計情報を取得

統計情報転送機能

各種D-plane機能

DCGW
Copyright © NTT Communications Corporation. All rights reserved.

13

DCとVPNとの接続自動化の取り組み
今回の取り組みで実現できたこと• Time to Market短縮 Software化することで迅速な開発を実現• オペレーションの自動化
 手動で実行していたNW機器の設定変更を自動化することで大幅に削減• OPEX/CAPEXの削減
 OPEXの削減を実現

今後に向けたポイント

Copyright © NTT Communications Corporation. All rights reserved.

SDNの事例増加により、Hard/Soft Switchの流通・導入量増加⇒ Hardware Switchの低価格化⇒ Software Switchの高度化
14

SDNの今後の取り組みに向けた課題と期待全体 Applicationが必要とするNWを利用・管理できる仕組み
 高性能・高信頼・拡張容易なアーキテクチャの検討
 ユーザやオペレータに必要な情報を提供できる仕組みの検討
 ユーザビリティ向上のための検討
SDNコントローラ
 カスタマイズ可能なコントローラ
 Northbound-APIの開示レベル(抽象化の仕方) 保守等で必要となる基本機能の搭載(library提供など)Forwarding Hardware Switchの性能向上
 Software Switchの高度化(性能向上や運用上必要な機能の追加等)

Copyright © NTT Communications Corporation. All rights reserved.

15

(参考) Transport SDNの取り組み
1. NW可視化

２. 仮想リソース管理

3. 自動経路計算

4. マルチドメイン復旧

目的に応じた仮想リソースを生成

ネットワーク全体の構成を考慮して経路を自動計算

マルチドメインの自動切替で信頼性を向上

オペレータ

NW全体の構成を可視化

Step1 (2014年度上期)① ユースケースを設定② 実機を利用したプロトタイプを開発③ 課題を抽出

Step2 (2014年度下期～)• 抽出した課題の解決• 導入へのシナリオ検討
Copyright © NTT Communications Corporation. All rights reserved.

Visualization

Resource
Path
FailureSlicing
Computation Handling
Network Orchestrator

OpenFlow
Controller

Cloud

GMPLS
MPLS-TP
Optical SWController Controller Controller

DC Domain - VLAN
Aggregation Domain - MPLS
Core Domain - OTN
Connectivity Domain - Physical
16Admin&Management

NFV (Network Functions Virtualisation)

Copyright © NTT Communications Corporation. All rights reserved.

17

NFVとは？
・ Network Functions Virtualisation
・仮想化技術を使ってネットワーク機能を汎用サーバ上で実現

・ETSI ISGで2012年から提唱しているネットワーク機能の仮想化技術
・要件定義が主で実際の標準化はリエゾンの各標準化団体が実施
Os-Ma

OSS/BSS

Orchestrator
Se-Ma

Service, VNF and Infrastructure
Description

EMS 1

EMS 2

EMS 3

Or-Vnfm

Ve-Vnfm

VNF
Manager(s)
VNF 1

Or-Vi

VNF 3

VNF 2
Vn-Nf

Vi-Vnfm

NFVI
VirtualStorage

VirtualComputing

VirtualNetwork
Nf-Vi

Virtualisation Layer
Vl-HaComputing
Hardware

Storage
HardwareExecution reference points

Copyright © NTT Communications Corporation. All rights reserved.

Virtualised
InfrastructureManager(s)Hardware resources
NetworkHardware
Other reference points

18

Main NFV reference points

ETSI ISG NFV End-End Framework

NFVは何が新しいのか？
Network functions Virtualisation
ApproachClassical Network ApplianceApproach

専用ハードウェア(ASIC)から汎用サーバ(IA)へ
Independent
フレームワークが重要Software Vendors
Message
RouterCDN

WAN
Session Border
Controller Acceleration

Independent

SoftwareVendors

DPI

FirewallCarrier
Grade NAT

Tester/QoE
monitor

Orchestrated,automatic & remote install.

High volume standard servers
SGSN/GGSNPE Router

BRAS

Copyright © NTT Communications Corporation. All rights reserved.

Radio/Fixed AccessNetwork Nodes

19

High volume standard storageなぜNFVが注目されているのか？
通信事業者の悩み• 機能ごとに専用のハードウェアアプライアンスを利用 様々なハードウェアの管理・運用が必要• バックアップや予備を確保しておく場所・手間• 各ハードウェアの特性の把握• ベンダロックイン

 アプライアンスの管理はベンダ独自システムで実施
 技術革新のスピードが比較的遅く、コスト高に直結

NFVのメリット• 汎用サーバによる設備の統一

 調達および保守コストの低減• 設備の流用が容易

CAPEX / OPEXの削減• ベンダロックインの回避 様々なベンダの参入によるコスト低下

Time-to-Marketの短縮• サービス提供の迅速化 ソフトウェアの導入のみで実現

Copyright © NTT Communications Corporation. All rights reserved.

20

NFVの利用イメージ
Cloud/DC

Cloud/DC

設備の一元化により保守コストの削減
柔軟・迅速な構成変更を実現

現状はサーバ設
備のみ仮想化

仮想化基盤

仮想化基盤
ユーザは機器の設置、管理が面倒
キャリアは機器の設定、アップグ
レードが大変

CPE

端末

サーバ

ユーザ拠点内に機器設置不要
Cloud/DCに機能をデプロイすればOK

終端箱

仮想化技術を使ってネットワーク機能を汎用サーバ上で実現するだけでは不十分
Copyright © NTT Communications Corporation. All rights reserved.

NFVController

21

キャリアへの導入に向けて リソースの最適配置
 デプロイからconfigまで自動化
 サービスチェイニング
 複数の異なるベンダのアプライアンスを一元管理 仮想アプライアンスと物理アプライアンスの融合 軽い・高性能なハイパーバイザ&仮想スイッチ
 様々な仮想NWアプラアイアンス
 NFV対応のコントローラ＆オーケストレータ

実際に市中製品(含むOSS)を触ってみた
Copyright © NTT Communications Corporation. All rights reserved.

検証ターゲット
openstackopencontrail
・・・

CSR1000V
Firefly
Steelhead・・・

Os-Ma

OSS/BSS

Orchestrator
Se-Ma

Service, VNF and Infrastructure
Description

Openvswitch
Nexus1000v
Lagopus switch
・・・

EMS 1

EMS 2

EMS 3

Or-Vnfm
Ve-Vnfm

VNF
Manager(s)
VNF 1

Or-Vi

VNF 3

VNF 2
Vn-Nf

Vi-Vnfm

NFVI

KVM
ESXi
・・・
DELL
HP
Cisco・・・
Copyright © NTT Communications Corporation. All rights reserved.

VirtualStorage

VirtualComputing

VirtualNetwork
Nf-Vi

Virtualisation Layer
Vl-Ha

ComputingHardware

Storage
Hardware

Virtualised
InfrastructureManager(s)Hardware resources
NetworkHardware

Execution reference points

Other reference points

23

Main NFV reference points仮想アプライアンス
 Router (CSR1000V，Firefly，vyatta)
 Firewall (Firefly，Fortigate-VM)
 WAN acceleration (SteelHead，VX)
 Load balancer (softAX，BIG-IP，SteelApp traffic manager) 導入・操作性• ovaの場合はインストールが簡単• CLI・GUIともにハードウェアと同等

 機能・性能• ハードウェアと同じ機能は網羅し切れていない• スペック表通りの性能を出すにはチューニング必要

 その他• ハイパーバイザが限定されていたり• ライセンス管理が複雑なものもあり
Copyright © NTT Communications Corporation. All rights reserved.

コントローラ/オーケストレータ Openstack OpenContrail CloudBand ACI 導入・操作性• 情報が少ない• 環境構築に一苦労• GUIはよくできている 機能• Cloud/DC内は良いが、拠点が分散している場合は…？
• アプライアンスの管理が限定的か その他• OSSは自由度が高いが、クオリティは未知数
Copyright © NTT Communications Corporation. All rights reserved.

実際に触ってみて分かったこと
 ベンダロックインの回避？

• IF、APIの公開
 他のベンダが追随しなければロックインと変わらない• マルチベンダ対応
 複数のベンダに対応していても1社、2社程度• IAサーバで動作 自社サーバであれば保障

 導入コストの削減？

• ソフトウェア単体はハードウェアアプライアンスよりは安価 ハイスペックなサーバが必要なアプライアンスが多い

 OPEXの削減？

• オペレーションの遠隔化と自動化
 既存ネットワークとの併用時はコスト増
 トータルの管理・運用ができるものはまだない 切り分けとチューニング？

• ハイパーバイザやアプライアンス同士の組み合わせ
 検証と切り分けに膨大なリソースがかかる

Copyright © NTT Communications Corporation. All rights reserved.

NFV製品への要望
 APIの公開・IFの標準化、相互運用性の実現• サードパーティやキャリアの開発が容易に• 他社製品との連携が可能に

 箱物と同じ使い勝手• 使い勝手が変わるのは導入障壁

 仮想アプライアンスの高性能化• ソフトウェア処理でも箱物と同程度の性能が欲しい• サーバを占有するのはなるべく避けたい 低スペックで動く手頃な仮想アプラアイアンスの実現• 機能の細分化• 柔軟な組合せを可能に

 運用現場が楽になる方法の検討• 実際のオペレーションを考慮した技術が必要• サービスチェイニングをどうやって簡単に実現するか
Copyright © NTT Communications Corporation. All rights reserved.

今後の展望 NWのどこから当てはめるのが良いかの見極め• 例えばCPEがやりやすそう？

 NFVの早期導入• 小さいNWや新規NWをNFVのみを使って作る

 現用と合わせて利用・共存させる方法の検討• 一時的にでもOPEXを(なるべく)上げないように

 仮想アプラアイアンスの動作検証の迅速化• 検証の自動化を目指す
 デプロイや組合せを動的に

Copyright © NTT Communications Corporation. All rights reserved.

ご清聴ありがとうございました

Copyright © NTT Communications Corporation. All rights reserved.

29