SDN
SDN は Software Defined Networking の略称で、ネットワークをソフトウェアで定義するもの全般を指す概念です。これだけだと本当に幅広い意味に取れるので、スイッチに SSH で入ってコマンドを叩くプログラムも SDN だし、そうなると当然 TeraTerm マクロでスイッチの設定するものも SDN です、と言い張れるわけですが、この記事では OpenFlow プロトコルの登場から現在までのネットワーク周りのソフトウェアを中心とした話題を取り上げます。
OpenFlow
OpenFlow は 2008 年にスタンフォード大学の学生の研究から生まれたもので、従来のコントロールプレーンとデータプレーンを同じ物理スイッチ上で動作させていたモデルから、コントロールプレーンを切り出し、このコントロールプレーンを実装したコントローラからデータプレーンを提供する複数のスイッチを集中制御するモデルと各スイッチでのパケット処理に使用されるテーブル定義やこのテーブルをプログラマブルに設定可能なプロトコルなどを含む OpenFlow 技術の総称です。
このスタンフォード大学の研究室の一部の学生が Nicira Networks という会社を起ち上げて、現在のクラウドネットワーク技術の礎を作り上げました。
OpenFlow 技術を用いたコントロールプレーンを実装したコントローラを OpenFlow コントローラ、データプレーンを実装したスイッチを OpenFlow スイッチ、コントローラとスイッチ間の通信プロトコルを OpenFlow プロトコルと呼称します。
上記の図のように、従来のネットワーク装置はコントロールプレーンとデータブレーンを実装し、コントロールプレーンで OSPF や BGP などのプロトコルを用いて機器同士が自律分散型で制御されており、パケットをどのスイッチにフォワーディングするのかを決定していました。OpenFlow ではコントロールプレーンをコントローラとして切り出し、各 OpenFlow スイッチを集中制御します。OpenFlow スイッチは OpenFlow テーブルを実装しており、どのようなパケットがきたら何の処理をしてどこへ転送するかをプログラマブルに定義することができ、このテーブルの設定を OpenFlow プロトコルを用いて設定可能なため、コントローラをソフトウェアとして実装することで SDN の定義を満たすことになります。つまり、従来 CLI 等で設定していたネットワーク装置にネットワーク越しに設定を入力できる API を定義できたと言ったほうがわかりやすいかもしれません。ただ、そういう意味では netconf というネットワーク装置をネットワーク越しに設定可能な技術が 2006 年にRFCとして定義されていますが、こちらはネットワーク装置ごとに異なる設定項目を抽象化する概念を持っておらず、装置ごとにそれに特化したソフトウェアの作り込みが必要でした。その点 OpenFlow はどのようなベンダが開発した OpenFlow スイッチでも同じ設定で装置をコントロールすることができる点が新しかったです。
この OpenFlow をきっかけとした技術革新が今日の SDN の礎を築いたことは間違いありません。例えば Nicira 社が開発をリードした OpenFlow 準拠のソフトウェアスイッチ OpenvSwitch(OVS) は OSS の IaaS 基盤である OpenStack におけるハイパーバイザースイッチのデファクトと呼べる存在になっています。また OpenFlow のインターフェースをオープンにし、その策定を進めることをきっかけとして誕生した Open Networking Foundation(ONF) は広く SDN のアーキテクチャやフレームワークの標準を決定する団体として、現在もその強い影響力で世界をリードしています。
OpenFlow の話題で特に衝撃的だったのは 2012 年に Google が発表した OpenFlow で構築された WAN 網である B4 です。
Google のような世界一のデータセンターとコンテンツを持つ企業が OpenFlow を用いてデータセンター間ネットワークを制御し、なおかつトラヒックエンジニアリングまでしていると聞いて、とても興奮したことを覚えています。
ただ、現在 OpenFlow がネットワーク装置において主流になっているかと言うとそうではありません。様々な理由があるとは思いますが、個人的に思っているのはフローテーブルの限界値と初期の実装の欠点であるコントローラへの問い合わせ問題があると思っています。
OpenStack Neutron
OpenStack は IaaS 基盤を提供する OSS です。わかりやすく言うと VMware の OSS 版と思って頂いても構いません。ネットワークと関係ないのでは？と思う方もいるかもしれませんが SDN を語る上で欠かせない存在が OpenStack です（若干のポジショントークを含みます）。OpenStack 自体の話をするととても長くなってしまうので、ここでは OpenStack のネットワーク機能 (Neutron) のみに着目します。
OpenStack Neutron (旧名称: Quantum) はマルチテナント環境において仮想計算機に仮想ネットワークを提供するソフトウェアです。主にネットワークの機能として L2 スイッチやルータ、ロードバランサ や ファイアウォール、VPN といったものを提供しています。Neutron はこれらのネットワークの機能を API によって設定できるため、当然 SDN と言えるでしょう。以降、SDN はクラウドにおける仮想計算機の仮想ネットワークをどのように提供するか、というテーマと共に発展していきました。Neutron が登場した際に7つのプラグインが実装されていました。そのプラグインの1つが nicira プラグインです。先にも述べたとおり、 nicira は OpenFlow を作ったメンバーが設立したベンチャー企業です。当時、nicira は OpenStack に仮想ネットワークを提供するためのコントローラとして Network Virtualization Platform(NVP) を開発し、また仮想計算機のトラヒックを転送するためのデータプレーンを OpenvSwitch で実現しました。NVP の特徴は従来ユーザのネットワークの Isolation に用いていた VLAN を使うのではなく、トンネリングプロトコル（GRE, STT）を用いたことにあります。この技術により IaaS を利用するユーザは自分の好きなネットワークアドレスを自由に仮想計算機に設定できるようになりました。このような仮想ネットワークの提供方法を確立した nicira は後に VMware に買収され、現在も VMware NSX と名前を変えて VMware や OpenStack の製品でネットワーク機能を提供しています。現在まで Neutron ではたくさんのプラグインが開発されてきましたが、そのすべてにおいて Neutron が定義したネットワーク設定用の API を用いて、物理スイッチ、仮想スイッチ、その他ルータなどのネットワークアプライアンスを設定できるという点で SDN を実現しています。単一の API で多くのベンダの様々な製品を設定可能なプロダクトは Neutron が初めてだったのではないかと思っています。
ただし Neutron の役割はあくまで仮想計算機に仮想ネットワークを提供するものであって、データセンター内のネットワーク全体の管理ができるわけではありません。そこで各ベンダやOSSコミュニティは様々な SDN Controller の実装をはじめます。
SDN Controller
SDN Controller は SDN におけるコントロールプレーンを実装し、ネットワーク装置を設定可能な API を提供するコントローラとここでは定義します。この章では特に筆者の経験則をもとにした感想という側面が大きいため、参考情報程度に読み進めてください。
OpenDayLight
OpenDayLight(ODL) は Linux Foundation 傘下で開発が進められているオープンソースの SDN コントローラです。基本は OpenFlow コントローラをベースとしていましたが、現在は様々なプロトコルに対応しており、またネットワークの管理に必要な多くの機能が実装されているため、汎用的な SDN コントローラと呼べると思います。
良いアーキテクチャの絵がなかったので少し古いリリースのアーキテクチャ図
オープンソースコミュニティとしても開発が活発で、Cisco や Intel, Redhat などベンダやディストリビュータの開発者が多く投入されました。ただ、個人的な感想を言うと ODL は OpenStack Neutron(+OVS) と組み合わせたときは、それなりに動作しますが、物理ネットワーク機器を制御しようとすると、辛い目に合います。まず、どのネットワーク機器となら接続できるのかが不明確でマニュアルも全くありません、かろうじて各ベンダの最新のネットワーク OS とは接続できて設定などは可能でしたが、操作をしている中でエラーが出たとしてもエラーログが簡潔すぎて全くデバッグできませんでした。これは仕方のない面もあって、ODL に限らず OSS コミュニティ開発で保障できるのはコミュニティで回している CI 環境の範囲だけで、多くの場合はリファレンス実装でその CI を回しています。ODL は OVS との組み合わせはきちんと CI が回っているので信頼できましたが、それ以外については OSS 版だと不明確でした。また ODL は Restful API を提供していますが URI にネットワーク装置のコンフィグの階層構造が羅列してあるような定義になっていたり、Body として送る JSON もコンフィグの階層構造をそのまま記述したような定義になっており、全く抽象化されている気がしませんでした。また一時期、唯一の利点と思っていた OpenStack インテグレーション部分も死んでいて、いったいこいつは何のために存在するのか？と思うこともありましたが、Intel のエンジニアの尽力もあり、持ち直しました。今では、ODL は OPNFV や ONAP のデフォルト SDN コントローラとして使われるなど、その地位を回復してきていると思っています。
Ryu
Ryu は OSS の OpenFlow コントローラです。特徴としては Python として実装されていること、最新の OpenFlow プロトコルを常に追従し、Nicira Extension 等にも対応していて OpenFlow コントローラとしての機能を十分に備えているだけではなく、BGP や MPLS, EVPN などのプロトコルを提供するソフトウェアライブラリとしても使われています。また Ryu は Neutron が最初に実装していたプラグインの1つでもあり、現在では Neutron のデファクトドライバである OVS Driver の中で OVS と通信するためのコントローラとして用いられていたり、Neutron において BGP 機能を提供する neutron-dynamic-routing プロジェクトではデフォルト BGP Speaker として Ryu が使われています。このように現在は、Neutron の中の重要な機能の一部として活躍しています。しかも Ryu は武蔵野ととても縁が深いプロダクトでもあります。しかし、ODL とは違い SDN コントローラ単体で使うことは想定されておらず、SDN コントローラとして使うためには自分で頑張ってアプリケーションを実装する必要があります。そのためコントローラというよりは SDN 機能のソフトウェアライブラリと考えるのが一番正しいかもしれません。本当は Neutron の中で Ryu ベースのコントローラプラグイン ofagent として覇権争いをしていた時期もあったんですが、誰も使わなかったので消えてなくなりました。
OpenContrail
OpenContrailは Juniper が開発を進めている SDN コントローラです。OpenContrail の特徴は L3 に特化した作りになっており、コントロールプレーンのプロトコルに BGP を使っている点にあります。また MPLS VPN の機能を提供しており、AT&T や Orange, NTT などのキャリアが好んで使っています。このようにデータセンターネットワークを L3 をベースとして組み上げ、BGP をコントロールプレーンのプロトコルとして用いるモデルは CLOS ネットワークに代表されるように 2014 年ごろから増えてきていた印象があります。
従来、ネットワークは L2 レイヤで ARP プロトコルなどを用いて接続しているネットワークの宛先ノードの MAC を学習する必要がありましたが、仮想計算機、仮想ネットワークの世界ではクラウドコントローラがすべての情報を保持しており、ネットワークのレガシーなプロトコルで近隣ノードの情報の学習を必要としません。OpenContrail はその点においては ARP プロキシを各ハイパーバイザー上で提供することで VM からの ARP 問い合わせを処理しています。これはトンネリングプロトコルで問題になりがちな BUM トラヒック対策でも用いられている手法ですが、しばしば ARP テーブル更新タイミング問題でネットワークエンジニアを苦しめることになります。かくいう私も SDN コントローラにおける ARP 処理問題でネットワーク通信が1パケットだけ落ちるという問題を泣きながらデバッグした記憶があります。話が逸れましたが、OpenContrail は非常に実績のあるプロダクトですが、個人の感想としては開発のオープンさに課題があると思っています。AT&T が ONS 2017 のセッションで話していたことですが OpenContrail はプロダクト自体は OSS ですが、そのコミュニティはオープンではなく Juniper が完全に主導権を握っています。そのような場合、ユーザが真に欲しい機能であっても Juniper のビジネスの都合で実装が見送られるといったことが起こりえます。AT&T はそういった懸念から Contrail ベースの SDN から ODL へ乗り換えを検討していると宣言しており、今後どうなっていくのか注目しています。また OpenStack Neutron の観点から言うと OpenContrail は Neutron とのインテグレーション機能を持っていますが、そのモデルは Neutron から乖離が激しく、実際に Neutron のデータベースすら一切使っていませんでした。当然 Neutron 結合周りはいつもガタガタで不安定だったのですが、今年の夏頃に OpenStack のリポジトリ配下に networking-opencontrail が作られ、現在の Neutron 実装に合った開発が進められており、とても期待しています。
2017/12/14 追記: 2017/12/12 に OpenContrail が Linux Foundation 配下で管理されることが決まりました。 これは Contrail を利用している多くのユーザが待ち望んでいたことではないでしょうか。まだオープンコミュニティとしてどのような姿になるのかはわかっていませんが、コミュニティでは Juniper が主導権を握りつつも、全体での比率は下げて様々な企業の開発者がコミッタとして参加する形になることを期待しています。また、現在実装が進められている ONAP の SDN コントローラは ODL がベースになっていますが、今後は OpenContrail を使った実装も検討されていくと面白くなってきます。もちろん、そのためには現状で OpenContrail 側に足りない機能はたくさんあるので、そういった開発も活発になっていくと面白くなると思います。ところで、これは完全に AT&T の思惑通りという感じもあり、改めてその力の強さとプロダクトのユーザとして声をあげる重要性、他の OSS コミュニティを巻き込んでいくやり方や既存の方法を捨てて新しいことに挑むチャレンジ精神の強さを感じました。歴史のあるキャリアでこれが出来るのは本当に凄いです。
Nuage Networks
Nuage Networks はアルカテル・ルーセントのベンチャー小会社として設立された会社で、現在はアルカテル・ルーセントとともにノキアに買収され、ノキア配下で Nuage の SDN ソリューションを提供しています。Nuage も OpenContrail と同様に L3 中心の考え方で設計された SDN コントローラで、コントローラ間で MP-BGP を使っています。OpenContrail と大きく異る点の1つがハイパーバイザースイッチとの通信プロトコルが OpenFlow を用いている点があります。
Nuage Networks は知名度はありましたが、あまり導入事例を聞くこともなく、このまま消えていくような印象を持っていましたが、China Mobile での導入など中国の企業で導入され、大きな話題となりました。China Mobile での導入だけでも軽く 1000 ノード以上のハイパーバイザー、数万 VM は接続しているはずで、そのネットワークを支えている SDN コントローラというだけでもその実力をうかがい知ることができます。
OVN
OVN は OVS コミュニティで開発が始まった OVS に特化した SDN コントローラです。目標としては OVS 単体では実現が難しい L2, L3, ACL などのネットワーク機能や Neutron の新しい機能に追従したインテグレーションに必要なものを提供することです。
図を見てわかる通り OVN のコントローラ自体はハイパーバイザー側に分散して提供されており、では API はどうやって提供するのかと言うと ovn-northd というプロセスが OVSDB 経由で外部からの命令を受付けています。正直、プロダクションで OVN を使っている話は一切聞いたことがありませんし、その実力も未知数ですが、Redhat が主導しており開発はとても活発で、OpenStack の開発者の中でもかなりの知名度があります。現在最も Neutron と SDN コントローラのインテグレーションで信頼感があるのは OVN だと思います。その理由の1つが、そもそも OVN の成り立ちからして Neutron のコントロールプレーンを置き換えることも目的に Neutron の一部のエンジニアが作ったのが OVN だからです。現在、Neutron のデファクトの実装は ML2 Plugin の OVS Driver ですが、これはコミュニティとしてはリファレンス実装であり、この Driver にプロダクションレベルの機能を作り込んでいくには限界がありますし OVS の機能をフルに使えているわけでもありませんでした。そこで OVS コミュニティの中で OVS の機能追加に合わせて、その機能をフルに活用でき Neutron のコントロールプレーンを置き換えることを目指した OVN が作られたという背景があります。完全に OpenStack に特化しているという部分で、初期の nicira の NVP を思い出しますが、面白いのは、OVN には VMware のエンジニアも何人かが参加しており、いつかのサミットで「お前たちは VMware NSX があるのに何で OVN をやっているんだ？」という質問に VMware 所属の OVN 開発者が「趣味だよ」と返していたのが印象的でした。
VMware NSX
VMware NSX は前述の通り元々は nicira が提供していた NVP が VMware に買収されて名前を変えたものです。OpenStack Neutron が作られた当初、そのアーキテクチャ設計にこの nicira のメンバーが深く関わっていたこと、また OVS の開発にも nicira メンバーが関わっていたこと、加えて Neutron が作られてから現在まで継続して（VMware に買収された後も）プロジェクトに貢献し続けていることから OpenStack との連携の安定度はずば抜けて高いです。個人的な意見ですが、私は度々「一番良いと思う SDN コントローラは何？」という質問を受けますが、そのときには NSX と答えています。ちなみに現在は VMware との統合が進んでおり vSphere 用の NSX とそれ以外のプラットフォーム用の NSX と区別されてプロダクトがリリースされており OpenStack 用には VMware NSX-T という名称になっています。
The Future of Cloud Networking is VMware NSX
上記の図のように NSX は元々は OpenStack の SDN コントローラとしてリリースされていましたが VMware に買収されてからは vSphere への最適化が進められ、ハイパーバイザー以外にも L2 gateway を介してベアメタルサーバへの接続にも対応しています。NSX の特徴としては、L3 や FW などの機能を物理アプライアンスや VM を利用した仮想アプライアンスで実現するのではなく、ハイパーバイザースイッチで実現しているところです。これにより、負荷分散や耐障害性の向上を実現しています。OVN も似たようなアーキテクチャとなっていますが、OVN を開発した中心メンバーの中には VMware のエンジニアもいるので納得できます。思い出話ですが 2013 年の OpenStack Summit Hong Kong で VMware のエンジニアが OpenvSwitch を改造して Stateful ACL を実装した、というセッションを聴講したことをよく覚えています。当時はそんな機能以前に OVS が安定してなくて、そんなことしてる場合か？という感想を持ちましたが、現在では OVS 本体に実装されて Neutron のリファレンスモデルでもデフォルトで利用されるようになりました。
Cisco APIC
Cisco APIC(Application Policy Infrastructure Controller) は Cisco の ACI(Application Centric Infrastructure) という SDN プロダクトの SDN コントローラです。
OpenStack において、今まで紹介した SDN コントローラは VM に仮想ネットワークを提供することを主眼において発展してきたものが多かったですが、ACI は物理的なデータセンターネットワークの設計や構築を主眼において発展してきている印象を受けます。その分、他の SDN コントローラよりも物理ネットワーク装置との連携に関しては一日の長があるのではないかと思います。
上記のグラフは OpenStack Foundation が実施している最新(2017 Jun-Dec)のユーザサーベイの結果ですが、商用の SDN プラグインでは Cisco UCS/Nexus と並んで Cisco APIC がシェアトップになっています（ただ、確実にユーザがいる Contrail が入ってないので、このサーベイ結果は完全に鵜呑みにしないほうが良さそうですが）。このように、実績もある Cisco APIC ですが、前述の通り ToR より上のネットワークでは信頼できそうですが OpenStack 連携機能に関して、いくつかのコード(networking-cisco, group-based-policy, apic-ml2-driver, python-opflex-agent)やマニュアルを読んでみましたが、ハイパーバイザースイッチとして OVS を使うモデルはかなり複雑です。Cisco のクラウドアーキテクチャは独自色が強く Cisco プロダクトのキーコンセプトである Policy や EGP(End Point Group) などの概念を取り入れているためだと思いますが、慣れていない運用者はしんどい思いをするのではないでしょうか（GBP や OpFlex などは特につらそう）。また、データプレーンを OVS に任せるのではなく、今売り出し中の VPP が使えるようになれば、もう少しシンプルになるかもしれません。
データプレーン高速化
前章では SDN におけるコントロールプレーンの話を主にしましたが、次にデータプレーンの近年の話題の中でも、その高速化についてこの章で触れたいと思います。先に紹介したとおり SDN の歴史は仮想計算機に提供する仮想ネットワークをいかに管理するかという課題とともにありました。仮想計算機は多くの場合は x86 サーバの上で稼働することになるため、従来ネットワーク装置が持っていた転送専用のチップというものは持っておらず、ソフトウェアとして実装し、CPU でパケットの処理を行っていました。しかし、ネットワークの帯域幅が大容量化するにつれて、普通のサーバにも 10GbE, 40GbE のような NIC が挿さる世界になり、CPU でのパケット処理は限界を迎えています。そこで、従来のカーネルのネットワークスタックをバイパスする技術や様々なパケット処理をハードウェア側にオフロードする技術が誕生しました。
DPDK
DPDK(Data Plane Development Kit) は Intel が開発した技術で現在は Linux Foundation 配下で開発が進められています。
上記の図のように Linux 上で動作するアプリケーションが通信をする場合、Linux カーネルのネットワークスタックにおいてパケット処理が実施されて、アプリケーションに渡されます。通常のアプリケーションならば、自前でパケット処理を実装する手間がなくなり非常に楽なのですが、例えばこのアプリケーションをネットワークアプライアンスに置き換えたとすると、ネットワークアプライアンスでは大量のパケットを転送する必要があり、ネットワークスタックでの処理がボトルネックとなってしまいます。そこでカーネル部分の処理をバイパスして、アプリケーション側で必要なパケット処理をして転送するモデルになっています。この技術によって、従来は困難であった IA サーバでショートパケット 40 Gbps ワイヤーレートも達成できるようになりました。この DPDK を使ったソフトウェアスイッチの実装として有名所は OVS, VPP, Lagopus などがあります。DPDK のメリットは大きいですが、逆に欠点もいくつかあります。まず、DPDK アプリケーションで高い転送速度を確保しようと CPU リソースをかなり割り当てる必要があります。また、従来ネットワークスタックで提供されていたパケット処理機能を再実装する必要があります。他にも DPDK に対応した NIC を用意するなど様々な欠点がありますが、現状ネットワークアプライアンスを仮想計算機で提供する際には、必須の機能だと思っています。
XDP
XDP(eXpress Data Path)は DPDK のようなカーネルをバイパスする技術とは異なり、カーネルの中で動作し、ボトルネックになっていたカーネルのネットワークスタックの前に任意のパケット処理を eBPF という技術を使って実行できるものです。XDP を用いたデータプレーン実装として IOVisor が有名ですが、これは単体で使用するというよりも PLUMgrid の SDN コントローラとセットで使うことを想定したものになります。
XDP Packet Processing Overview
2016 年に開催された netdev1.2 での発表を聴きに行きましたが、発表者は「DPDK はカーネルじゃない！」と連呼していたのを覚えています。しかし、まだ性能は DPDK ほど出ていないようですし、こちらも対応した NIC が必須になります。これは個人的な感想になりますが、カーネルは OSS コミュニティとしてはかなり参入障壁が高く、この機能をがっつり使ってカーネルの中でごちゃごちゃするよりも DPDK のようにユーザランドで好きなように実装するほうが楽なのではないかと思います。もちろんカーネルのエコシステムの中で高速なネットワーク処理が可能という点は魅力ではあります。
SR-IOV
SR-IOV(Single Root I/O Virtualization) はハイパーバイザーのホスト OS 上で行われていたパケット処理をパススルーすることが出来る機能で、従来のPCIパススルー技術と異なる点として、SR-IOV の NIC 上で仮想的なスイッチ機能を持ち、このスイッチ機能で複数の仮想計算機に対してパケットを振り分けることが可能になります。
この技術もネットワークアプライアンスを仮想計算機で提供する際には必須の技術と言って良く、実際に様々な環境で使われています。DPDK を用いたソフトウェアスイッチと違い、スイッチングの処理がハードウェアで実行されるためホストの CPU を使用せず エコ な技術となっています。ただし、ハードウェアであるがゆえの制限もあり、ソフトウェアで実装できる DPDK ほど柔軟ではありません。
SmartNIC
SmartNIC は従来の NIC に NPU や FPGA などのプロセッサが合体したもののことを指します。Microsoft の Azure クラウドを保持するデータセンターでこの技術が使われていることが公表されて話題になりました。従来の高性能な NIC の中にもパケット処理を NIC にオフロードする機能はいくつか存在しましたが、それらの機能はハードウェアとして固定の機能となっていて一度製造されて出荷されてしまえば、その機能を変更することは不可能でした。その点、この SmartNIC は搭載されている FPGA ボードに必要な処理をプログラミングしてやることで、柔軟なパケット処理を実現することができます。Microsoft では SmartNIC 上で NAT, ACL, QoS などの処理を実施し、ホストやゲスト OS 上の CPU リソースの消費を避けているそうです。
SR-IOV を更に進化させた非常に期待が持てる技術ですが、現状では全く枯れていないため、まだまだ実運用をしているとハマることが多いそうです。また FPGA のプログラムを書くこと自体がかなりコストが高いと思っています。ただ、SmartNIC には FPGA の他に、 NPU を搭載し、 P4 と呼ばれるプログラミング言語で書いたプログラムを動作させることが出来る Netronome という SmartNIC もあります。P4 のほうが FPGA で用いられるハードウェア記述言語よりもはるかに導入が優しいため、ネットワーク業界では期待されています。このように SmartNIC は、まだまだこれから発展していくところだと思いますので、実運用で SmartNIC が使われだすのはもうしばらく後になると思います。
WhiteBox Switch
2015 年頃からよく話を聞くようになったのがホワイトボックススイッチで、これはソフトウェアを含まない、ODM ベンダ製スイッチのことを指します。従来の物理スイッチのようにベンダが独自に開発したソフトウェアが載ったスイッチではなく、スイッチ機能を持ったハードウェアだけを販売しソフトウェアをユーザが選択できるというものです。
Google や OCP(Open Compute Project) を推進する Facebook など大規模なデータセンターを持っている企業では、自社向けのネットワークに特化したネットワーク OS を自分たちで開発し、このホワイトボックスに載せて、データセンターネットワークを構築しているようです。このホワイトボックス業界の中でも特に Cumulus Linux が提供する debian ベースのネットワーク OS の知名度が高いです。例えば、ユーザが欲しいコントロールプレーンを Linux ベースで開発し、そのままホワイトボックススイッチで動かすことが可能です。ホワイトボックススイッチは ASIC を搭載していますので、パケットの転送速度は従来の物理スイッチと遜色ありません。ただし、ホワイトボックススイッチに搭載されている CPU はサーバ向け CPU ほどのパワーがない物が多く、当然メモリやその他の LinuxOS が使えるハードウェアは非力なため、マシンパワーを必要とするソフトウェアを動かすのには向いていないという注意点があります。
NFV
NFV(Network Functions Virtualization) は従来、物理機器として提供されていたネットワークアプライアンスを仮想計算機上のソフトウェアで実現するものです。よく SDN/NFV という表記で書かれるため SDN とは違うものという印象を持つかもしれませんが、私は NFV は SDN にとって重要な要素の1つだと思っています。今まで紹介してきたのは、あくまでネットワーク装置がすでにあって、そのネットワーク装置をソフトウェアでコントロールする話でしたが、本来はこのネットワーク装置自体を準備するところまでソフトウェアで可能になるべきなので NFV はそのための重要な概念になります。
NFV は ETSI 配下の組織で標準化の策定が行われています。まだ議論が行われている最中ですが、標準化と並行して NFV を実現するための具体的な実装の検討が OSS コミュニティでは行われてきました。例えば、上記図における VIM は仮想資源（仮想計算機、仮想ネットワーク、仮想ストレージ）をマネジメントする機能ですが、多くの NFV PoC では OpenStack がデファクトになっています。実際に OpenStack には ETSI NFV のユースケースに基づいた様々な提案が持ち込まれて、実装が進められてきました。また、図における NFV Management and Orchestration(MANO) についてはどのような実装がふさわしいか近年注目を集めているトピックの1つとなっています。
OPNFV
OPNFV(Open Platform for NFV) はオープンソース実装で NFV を実現することを目的とした団体です。OPNFV は新たな OSS を作るわけではなく、あくまで既存の OSS を組合せて NFV を実現することを目的としており、既存の OSS では足りない機能を整理し、OSS コミュニティにその仕様を提供することで実装を促すという活動を行っています。また NFV の機能に必要な OSS を組合せた環境で動作させるための NFV 要件に合わせたテストセットを作りこんでおり、従来の OSS コミュニティでも標準化団体でもない、その中間の立ち位置で標準化団体と OSS コミュニティの間にあるギャップを埋める活動を行っています。
ONAP
ONAP(Open Network Automation Platform) は先に紹介した MANO の実装になります。2016 年台に MANO モデルを実現する OSS として AT&T が主導する OpenSourceECOMP、中華系企業が主導する OpenO、ヨーロッパ系企業が主導する OpenSourceMano, OpenBaton などのプロジェクトが立ち上がりました。この中の OpenSourceECOMP と OpenO が 2017 年初頭に Linux Foundation 配下で合併して出来たのが ONAP になります。MANO 実装の覇権争いの中で、このビッグプロジェクトの合併は衝撃的なニュースとなり、以後多くの企業が ONAP に参画することになりました。世界中から期待を一身に背負う ONAP ですが、その実装の実体は ECOMP と OpenO のキメラ合体であり、現状まだまだまともに動くものとは言い難いです。ただ、期待できる面は色々あり、例えば ONAP の VNF Requirements Project は VNF の要件について定義するプロジェクトで、従来ベンダごとに機能がバラバラだった VNF の仕様を統一できる可能性があります。またこのプロジェクトの中で VNF が仕様に沿ったものかをチェックするツールや VNF をコントロールするための SDK なども提供する予定とのことで、NFV の大きな課題の1つを解決できる可能性があります。
SDN の将来
ここまで、SDN のトピックをいくつか紹介してきましたが、どのトピックでも共通して言えることが、コントロールプレーンとデータプレーンを分離して、それぞれをソフトウェアの力で発展させていく試みだということです。この流れは冒頭で紹介した OpenFlow の考え方が基本となっており、今後も続いていくのではないかと思います。
今後特に注目しているのは物理ネットワーク装置のマネジメントの抽象化です。多種多様なベンダのネットワーク装置を単一の API で管理することは現時点において困難です。中にはそれを力ずくで解決している Cisco NSO という製品や OSS で近いことを目指しているものとして Ansible のネットワークモジュールや NAPALM もありますが、私が注目しているのは OpenConfig yang です。OpenConfig はベンダ間で同じコンフィグフォーマットを使用して機器の設定を実現しようとしている団体で、実際に Juniper や Cisco, Arista などは対応を開始しています。ベンダのネットワーク装置の管理をうまく抽象化できれば、MANO の実装である ONAP から、OpenStack, SDN コントローラ、プログラマブルで高速なデータプレーン、ホワイトボックススイッチとベンダのネットワーク装置を操作し、完全にソフトウェアでコントロール可能な巨大なネットワークインフラを即座に、また柔軟に、構築可能になる未来がやってくると考えています。