Software Defined Network

ルータやスイッチはデータプレーン・コントロールプレーン・マネジメントプレーンの三層に分かれている。 ルーティング、ARP解決等一般的なルータ、スイッチの機能はデータプレーンとコントロールプレーンで完結している。 マネジメントプレーンとはネットワーク機器を管理するためのプロトコル全体を指し、SSH, SNMT, Syslogなどを含んでいる。どれもルーティングやスイッチングといった本来の役割を果たすのに必要な機能ではない。

コントロールプレーンは従来、各機器が独立して自機のデータプレーンを操作するために機能してきた。例えばルーティングプロトコルは各ルータのコントロールプレーンが独自に計算を行ってきた。こうしたコントロールプレーンの役割を一か所に集中させ、各機器のデータプレーンを動かそうとしているのがCentrized Controllである。

Centrilzed Controllではコントロールプレーンに持たせる役割を担うプログラムの実装が容易である。なぜなら全てのデータを中央で集中的に持っているからである。こうした理由からSoftware-Defined ArchitecthureではこのCentrilized Controllが採用されることが多い。

中央に実装された集中型コントロールプレーンから、各データプレーンを制御するのにつかわれるAPIをSouthbound Interfaceと呼ぶ。集中型コントロールプレーンも各データプレーンも所詮はプログラムであり、そのプログラム間の対話を担うAPIということになる。このAPIにはいくつか規格があり、OpenFlowと呼ばれるオープンソースのものやOpFlexと呼ばれるCiscoによる実装もある。このほかSNMPによってデータプレーンを操作したりTelnetによって操作することも可能である。今まではTelnetSNMPはマネジメントプレーンの役割であったが、直接データプレーンの操作にも利用できるようだ。実際APIC-EMなどの従来の機器をそのまま流用したSDNにはこうした既知のプロトコルが利用されるらしい。

既に述べたが集中型コントロールプレーンでは、制御する機器のデータプレーンからの情報を収集して一元的に管理できる。こうした情報を外部のアプリケーションに呼び出して、コントロールプレーンの処理そのものを、より簡単で素早くプログラム化できるようにしたのがNorth bound interfaceである。例えば、Javaのアプリケーションが集中化されたコントロールプレーンから、そのネットワークの情報をNorth-bound APIを通じて収集し、そのデータに即した新しい処理をデータプレーンに指示できる。

このAPIはRESTfulなAPIとして実装されHTTPで対話するので、たとえコントロールプレーンと、Javaプログラムが異なるネットワークにあったとしても対話可能である。

さてSoftware-Defined-Networkには、この集中化されたコントロールプレーンをどこに配置するか、またコントロールプレーンの役割のうちどの程度を中央に集約するのか、という問題によって3つのソリューションが存在し、それぞれコンセプトが大きく異なる。

OpenSDN

OpenNetworkFoundationという機関が考案したSDNの枠組みで、OpenSDNとも呼ばれる。ベンダに拠らない標準プロトコルで企業のSDN推進を助ける目的で開発された。OpenSDNではほとんどのコントロールプレーンの役割を中央に集中させ、加えてNorthbound-APIに提供したい機能も集中型コントロールプレーンが提供する。ここで利用されるsouthbound-APIをOpenFlowと呼ぶ。このOpenFlowに対応した集中型コントロールプレーンは各ベンダによって挙って開発され、各ベンダによる似たような実装が誕生した。結果これを統合しようという動きがあり、コントローラそのものも規格化された。この集中型コントローラこそが、オープンソースのコントローラOpenDayLightである。

このコントローラはオープンソースで開発され、このコント―ローラからデータプレーンを操作するAPIとしてOpenFlow、NetConf等に対応し、またこのコントローラをプログラムにするAPIとしてJAVA等のNorthbound APIにも対応している。

なお、このコントローラはオープンソースであったが、全く同じ機能を持つものをCiscoが独自に開発・提供しており、これをCisco Open SDN Controllerとして提供していた。OpenDayLightに新機能が追加されるたび、OSCも同様の機能を実装して提供した。この開発をCiscoは既に取りやめており、CiscoはOpenSDNの開発そのものに興味を示さなくなっている。ネットワーク自動化について全く新しいアプローチをとることを選択したからである。

Cisco Open SDN Controller - 製品 & サービス - Cisco

Application Centric Infrasracture

OpenFlowがスタンフォード大の研究で生まれたのに対して、Cisco独自のアプローチで生まれたネットワーク自動化のためのコンセプトである。 Ciscoはデータセンターで稼働するアプリケーションに着目し、自動化によってアプリケーションに必要なネットワークを提供するための枠組みを作ることを目指した。

このコンセプトでは、ネットワークの物理的トポロジもスパインアンドリーフに定められており、外部ネットワークに接続するルーターもリーフ側のスイッチに接続する。また、各アプリケーションは仮想スイッチに接続された仮想マシンを稼働させるCsico Unified Computing Sysytemというコンピューターで稼働し、仮想スイッチは複数のリーフスイッチに接続されている。

こうしたネットワーク全体を制御するためにリーフ側にはもう一つApplication Policy Infrastructure Controllerという機器が接続され、これがデータセンターで提供しているアプリケーションに対して、アプリケーション意図するネットワークを提供するよう各コントローラをカスタマイズしていく。このようなアプリケーションの意図するネットワークを構築するモデルをintent-base networkingと呼ぶ。

例えば、ルータはVM上で走るWebサーバーとパケットのやり取りをする必要はあっても、データベースサーバーと直接やり取りはしないはずだ。(外部からの攻撃を避けるためにむしろ接続を禁止された方が良い。)あるいは、アプリケーションサーバーはデータベースとWebサーバーと接続する必要はあるが、ルータと接続する必要はない。

こうしたポリシーをAPICが定義すると、APICはスイッチ、ルータのコントロールプレーンに対し、ポリシーに即した通信を提供するよう指示していく。VLAN、EtherChannel、トランキングの作成などが、North-Bound interfaceであるOpFlexによって各機器のコントロールプレーンに指示される。このとき注意すべきなのは、コントロールプレーンの役割はまだ各機器に残されていることだ。このモデルではコントロールプレーンを完全に集中化するものではない。あくまで、各アプリケーションに対してネットワークを提供するノード同士(EPGと呼ぶ)がどのように接続され、ネットワーク全体がどのようにデザインされるべきかを決定し(Application Centilized Infrastracture)、それを実現することまでがAPICの目的である。

APIC-EM

Open-SDNとACIはSDNの実現のため、全く異なる機器やネットワークトポロジを要求した。Open-SDNでは、OpenDeylightと連携し、自分のデータプレーンをOpenFlowで制御できる新しいスイッチルータが必要だし、ACIはそもそもトポロジを今までのキャンパスネットワークからスパインアンドリーフ型に変更する必要がある。

SDNを既存の機器だけで実現できるように考案されたのがAPIC-EMである。APICはApplication Policy Infrstracture Controllerの略なので、Application Centrilized Networkを実現するための機器に聞こえるが、発想のいきさつ自体は全く別である。

既存の機器を用いるので、OpenFlowのようなそもそもデータプレーンとコントロールプレーンの対話に新しいプロトコルが実現されるわけではない。またNorthbound-APIも各機器のコントローラが対応していないので、OpFlexのような新しいAPIが提供されるわけでもない。Northbound-APIとして、従来通りTelnetSSHSNMPがコントロールプレーンと新しい自動化されたマネジメントプレーンを制御する。新しいマネジメントプレーンでは設定状況の確認や、各機器の情報が集約され、各機器の再設定もできる。

APIC-EM用のマネジメントプレーンのソフトウェアが無料で利用できる。APIC-EMで実現できる新しい機能は限りが合った様で、PathTraceの可視化、簡単なQoS、プラグアンドプレイなどの実現を打ち出していたが、現在APIC-EMはCiscoが提供を終了しているが、次のCisco DNA Centerが既存の機器を用いたSDNの構築を一部サポートしている。

Cisco Application Policy Infrastructure Controller エンタープライズ モジュール - Cisco Application Policy Infrastructure Controller エンタープライズ モジュール - Cisco

SDNまとめ

3つのSDNを見てきて既存のネットワークとの違いについて以下のようなことを述べることが出来る。

  • 接続された機器の初期設定を一括で行うことが出来る
  • 機器の監視、利用されているデータの収集、リポート作成、潜在的な問題の通知をすべて自動化することが出来る。
  • 機器から情報を一括で収集することが出来るので、分析はより高度で役に立つものを提供できる。

Software Defined Access

SDAとは従来のEthernet/IPによるローカルネットワーク以上の接続を新しいソフトウェアによる処理で提供するという、新しいネットワークアーキテクチャCisco Digital Nwtwork Architectureを実現するための具体的な手段である。SDAに対応したスイッチ同士が、VXLANトンネリング(= Overlay)という新しいLAN接続を提供する。VXLANを提供するために、各LANスイッチとルータ、APはrouted access layer designeとういうトポロジで、メッシュ状のネットワークを提供してVXLANトンネリングを実現する。全てのスイッチはレイヤ3スイッチであり、各スイッチではIS-ISルーティングプロトコルが実行され、各ルータはレイヤ3接続で接続される。(既存の機器でのSDAの実現についても言及されていたが一旦省略)レイヤ2冗長性はないのでSTPは不要になり、各スイッチはその下のクライアント機器のデフォルトゲートウェイとして機能するようになる。

SDAノード(クライアントと直接接続するレイヤ3スイッチ)は、クライアントからフレームを受け取るとVXLAN専用のカプセリングを行い、ルーティングプロトコルが目的のSDAノードまでカプセリングされたフレームを運搬する。フレームのスイッチング自体は従来のルーティングやスイッチングと同じく各機器のデータプレーン上のASICで行われるので、処理自体に遅延は発生しない。各SDAノードは、ルーティングプロトコルによって自分以外のSDAノードの存在とルートについては知り得るが、そこに接続された各クライアント(エンドポイント)がどこに接続されているかまではわからない。

(VXLAN間通信を想定すると)受け取り側であるSDAノードIngress tonnel routerと呼ばれクライアントから受け取ったパケットに記載されたIPアドレス(Endpoint IDと呼ぶ )から、直接接続されているSDAノード(Routing LocatorRLOCsという)のアドレスを知る必要がある。SDAノードはLISP-Mapサーバーに対して、宛先EIDに直接接続されているSDAノード(Egress tonnel router)のIPアドレスを尋ねる。LISP MapサーバーはMapテーブルから、該当するSDAノードのIPアドレスを探し出し、宛先SDAノードに対して現在その宛先EIDと通信可能か問い合わせる。

すると、宛先SDAノードは、LISP-Mapサーバーに対してではなく、Ingress tunnel routerに対して直接、自身に対してトンネリングを確立しパケットを送り込むように伝える。

ではこの通信以前にLSIP-Mapサーバーはどのようにして、EIDとそれに該当するSDAノードをRLOCsのエントリーで所持できたのか。各SDAノードは古典的なルーティングプロトコル、サブネット、MACアドレスから自身が接続可能であると確認したクライアントのEIDと他のSDAノードについて事前にLSIP-Mapサーバーに通知しておく。(この確認のタイミングがいつなのかはよくわからない)こうしてLSIPサーバーには各EIDとそれに直接接続されているSDAノードの一覧を生成してRLOCsとして保持しておくことが出来る。

LISPの基本 by Cisco Community

ここまではあまり、Software-Definedな側面について言及した来なかった。このネットワークのSDAノードのデータプレーンをSouthbound Interfaceを用いて直接プログラムするのがCisco DNA Centerである。DNA CenterではSNMP, Telnet, SSHなどの既知のプロトコルの他NETCONF RESTCONFなどのプロトコルもサポートしている。DNA Centerでは、例えば今まで一行づつ具体的なIPアドレスを根拠にネットワーク管理者が操作しなくてはならかったACLについて、より抽象的なポリシーを設定するだけで解決可能になる。このようなアプリケーションやユーザが意図するネットワークを構築するための設定の自動化はIntent-based Networkと呼ばれ、これはSDNの章で扱った「提供されるべきソフトウェアに応じたネットワークを構築する」Application Centric Infrastructureの要素を内包しているとも言えそうだ。

シスコ、新アーキテクチャ「Digital Network Architecture(DNA)」を発表 - ZDNet Japan

これはCisco DNA Centerがスケーラブルグループという「このユーザグループが接続してよいユーザーグループと接続が禁止されたユーザーグループ」が書かれたのリストを保持しており、各ingress Tunnel routerはクライアントから送られてきたパケットのIPアドレスを、DNA Centerに問い合わせてIPアドレスに即したスケーラブルグループエントリを確認させる。DNA Centerはその接続が禁止されていないことを確認したうえで、初めてVXLANによるトンネリングを許可する。

こうしたACLを代替する役割まで提供していることからわかるように、Cisco DNA Centerはただのスイッチ/ルータのマネジメントプレーンとして動作するだけではなく、一部のコントローラプレーンの役割も請け負っている。

注意

SDNとSDAは別物である。 SDAはSDNの方法論のうちの一つである。

DNA-Centerを通してアプリケーションによって通信経路の確立の可否を決定することで、ネットワークを定義していくことをSoftware-Defined Accessと呼んでいる。