Viptela SD-WANのオンプレ展開

Viptelaのコントローラコンポーネント(vBond, vSmart, vManage)は通常Viptelaが運用管理しているクラウド(これは現状AWS上にあります)にデプロイして利用するのが一般的です。コントローラのインフラストラクチャの運用管理をViptelaに任せることができるので、サービスを素早く立ち上げることができます。しかし、何かしらの理由でこれらのコントローラコンポーネントを自社設備(オンプレ)に立てたい、または、サービスプロバイダーなどが自前のパブリッククラウド上にデプロイして使いたい、という場合もあるかと思います。Viptelaのソリューションはオンプレ環境でもまったく問題なく利用をすることができます。

コントローラコンポーネントを動作させるハイパーバイザとしては、現在VMware ESXi及びKVMがサポートされており、それぞれOVA形式、QCOW2形式のイメージがが提供されています。2016年末にはこれらに加え、Hyper-V用のサポートが加わる予定です。

これらのコントローラコンポーネントはvEdgeからIP的な到達性さえあれば、パブリッククラウド、プライベートクラウド、オンプレ、どこにデプロイしても構いません。コントローラをオンプレにデプロイした際でも、Viptelaソリューションの持つすべての機能を利用することができます。このようにオンプレ環境にコントローラを置くことができますので、インターネット接続のない環境(完全クローズドなネットワーク環境)でもViptela SD-WANソリューションを使うことができます。

オンプレ環境でコントローラを立てる際には、vBond、vSmart、vManageで以下のようなスペックを満たす仮想マシン環境を用意する必要があります。

  • vBond
サイト数 vCPUs RAM OS用ボリューム 帯域 vNICS
1-50 2 4 GB 8 GB 1 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
51-250 2 4 GB 8 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
251-1000 2 4 GB 8 GB 5 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
1001- 4 8 GB 8 GB 10 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
  • vSmart
サイト数 vCPUs RAM OS用ボリューム 帯域 vNICS
1-50 2 4 GB 16 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
51-250 4 8 GB 16 GB 2 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
251-1000 4 16 GB 16 GB 7 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
1001- 8 16 GB 16 GB 10 Mbps 2 (トンネルI/F*1、マネージメントI/F*1)
  • vManage
サイト数 vCPUs RAM OS用ボリューム DB用ボリューム 帯域 vNICS
1-250 16 32 GB 16 GB 500 GB, 1500 IOPS 25 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)
251-1000 32 64 GB 16 GB 1TB, 3072 IOPS 100 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)
1001- 32 64 GB 16 GB 1TB, 3072 IOPS GB 150 Mbps 3 (トンネルI/F*1、マネージメントI/F*1、クラスタ用メッセージバスI/F*1)

SD-WANのスケーラビリティ

ViptelaのSD-WANはIPsecによるオーバーレイネットワークです。今回はこのオーバーレイネットワークのスケーラビリティについて少し考えてみたいと思います。

オーバーレイネットワークの進化の方向性

オーバーレイ技術の歴史を振り返ると、その技術の進化の方向性としては、私は3つほどあるのではないかと思っています。

オーバーレイネットワークの進化の方向性
オーバーレイネットワークの進化の方向性

一つはカプセル化技術の進化です。古くはGREから、そしてその後もさまざまなカプセル化技術(IP in IP、MPLS、L2TP、VXLANなど)が生まれてきました。オーバーレイの二つ目の進化の軸はシグナリングです。こちらも過去さまざまな方式が生まれましたが、歴史的に振り返ってみると、勝者はBGP(あるいはその拡張)ということになるのではないかと思います。MPLS/BGP VPNの成功や最近のEVPNなどがそれを証明しているように思います。3つ目の進化の軸はスケーラビリティです。今回はここに注目してみたいと思います。

なぜフルメッシュが困難なのか?

一般的に大規模なフルメッシュのオーバーレイネットワークを構築するのは大変困難です。大きく分けると2つ理由あります。一つは設定(プロビジョニング)の困難さです。初期設定時に多くの工数がかかるものもちろんですが、むしろ大変なのはサイトを追加する時です。フルメッシュを維持するためには、対向の全てのノードにも再設定をしなければいけません。初期構築時は仮に頑張れても、運用に入った後に全てのノードの再設定をしなければいけないのは大きな苦痛を伴います。もう一つの困難さはステート維持です。使用するオーバーレイ技術が何かしらのステートを持つ場合、nノードからなるフルメッシュなネットワークでは、全体としてn^2のオーダー(O(n^2))のステートを維持管理していかなければいけません。IPsecの鍵もこのようなステートの一種です。IPsecのフルメッシュネットワークが難しいのは上記の二つの理由に依るところが大きいと言えます。

サイト追加時のプロビジョニングの苦痛を解決する策としては、過去にも提案がありました。例えばRFC6224です。提案者の名前から通称「Kompella方式」とも呼ばれる方法です。

Kompella方式
Kompella方式

この方式のポイントは「オーバー・プロビジョニング」をする、という点にあります。この方式では、例えばFrame RelayのネットワークであればDLCIをあらかじめ余計に割り当てておき、サイトが追加になった際にローカルの設定変更だけで残りのリモートサイトには変更が必要ないように工夫されています。

また、CoSine CommunicationsのIPSXは仮想ルータをIPsecで結んでオーバレイネットワーク(VPN)を作ることができました。

CoSine IPSX
CoSine IPSX

CoSineのInVisonというNMSには自由にハブ&スポークやフルメッシュのIPsecを構成する機能がありましたので、ある意味プロビジョニング上の問題は解決することができていたとも言えます。2000年当時、1仮想ルータで1000のIPsecトンネルを終端することができた(ハブ&スポーク)を構成することができた)のはかなり頑張っていたのではないかと思いますが、では1000個の仮想ルータでフルメッシュのIPsecトンネルを作れたかというと、それは全くもって不可能な話でした。

IPsecをスケールさせるのが難しい理由

IPsecをスケールさせるのが難しいのには二つの理由があります。IPsecの鍵交換プロトコルであるIKEで使われる処理(Diffie Hellmanの鍵交換)が非常に重たい処理であるという点。Diffie Hellmanの鍵交換がどれくらい重いのか、少し考えて見ましょう。

https://www.cryptopp.com/benchmarks.html を見ると様々な暗号化アルゴリズムのベンチマーク結果が出ています。この中からAES-CBC-256bitとDiffie Hellmanの鍵交換の結果を以下に掲載します。

Diffie Hellman鍵交換とAESによる暗号化処理の比較
Diffie Hellman鍵交換とAESによる暗号化処理の比較

AESなどの暗号化アルゴリズムの性能はスループット(MiB/s)で測るのに対し、Diffie Hellmanの鍵交換は1オペレーションの実行時間(msec/operation)で測りますので単純に比較はできませんが、仮に1500バイトのデータをAES-CBC-256bitで暗号化するのを1オペレーションとみなしてそれにかかる時間を計算して見ると上記のようになります。Diffie Hellmanの鍵交換はAES-CBC-256bitに比べると二桁ほど重い処理であることがわかります。このようにDiffie Hellmanの鍵交換処理は非常に重たい処理なのです。

IPsecのフルメッシュネットワークが難しいもう一つの理由が、IKEによって作られる鍵が “pair-wise” である、という点です。鍵がpair-wiseであるというのは、相手が異なれば異なる鍵を使う、すなわちペアごとに異なる鍵が存在するということです。nノードのフルメッシュのネットワークの場合にはO(n^2)の個の鍵が存在することになります。暗号鍵があるということは、必ず鍵の更新(Rekey)をしなければいけないということを意味します。どんな暗号化システムでも、同じ鍵を使い続けていけば暗号強度は必ず低下してくるからです。上記のように重たい処理であるDiffie Hellmanの鍵交換を全体としてO(n^2)回やらなければいけないのでとても大変です。O(n^2)問題を甘く見てはいけません。例えば1,000ノードのフルメッシュを構成するとおよそ500,000のペアが存在することになります。仮にIKEのPhase 1のRekey時間を24時間としましょう。24時間はたった86,400秒しかありません。この間に500,000回の鍵交換をしなければいけないわけですから、毎秒5〜6回のペースで鍵交換をし続けなければいけないことになります。3,000ノードのフルメッシュなら毎秒50回以上になります。

このように非常に重たい処理のIKEですが、IPsecにとって本当に必須のものなのでしょうか? 実際、多くの場合IPsecを使う際にはIKEが使われます。しかし、IPsecにとってIKEが唯一無二の鍵交換プロトコルというわけではありません。実は、IPsecにはKINKやPhoturisといった別の鍵交換プロトコルもあります。極端な話、手動で鍵を設定することもできるわけです(もちろん鍵の更新をしなければセキュアとは言い難いですが・・)。つまりIPsecにとってIKEは必須ではないのです。

IKEはセキュアなチャネルがないところにセキュアなチャネルを開設するプロトコルです。従ってすでにセキュアなチャネルがあれば、必ずしもIKEを使う必要はないという点に注意してください。「Viptelaのアーキテクチャー」の回で、コントローラとvEdgeの間のコントロールチャネルはTLSもしくはDTLSが使われているというご説明をしました。すでにそこにセキュアなチャネルがあるわけですから、それを使えば良いのです!

Viptelaによるスケーラブルなオーバーレイネットワーク

ViptelaのコントローラであるvSmartはBGPをベースに拡張をされたOMP (Overlay Management Protocol)というプロトコルを使って経路の配布を行っており、OMPはTLS/DTLSによるセキュアなチャネルの上で動いています。vSmartはBGPのルートリフレクタと同様の役割を果たしていて、経路情報をすべてのvEdgeに配布するようになっています。実はこのOMPは、経路だけではなくIPsecで使う鍵の配布も行えるように拡張をされているのです。このためOMPでの鍵交換は非常にシンプルなものになっています。

統合されたルーティングとセキュリティ
統合されたルーティングとセキュリティ

vEdgeは自分宛に送るパケットの暗号化に使う鍵を自らランダムに生成し、それをvSmartに送ります。すると、vSmartは他のすべてのvEdgeにその鍵を配布してくれます。これだけで鍵を更新することができるわけです。

各vEdgeがやらなければいけないのはランダムな鍵を自ら生成するだけです。これは非常に軽い処理ですので、例えば極端に短い時間(例えば30秒)で鍵更新をするということも可能です。IPsec/IKEのフルメッシュネットワークで30秒で鍵更新をするのはほぼ不可能だと思いますが、Viptelaではそれが可能です。Viptelaのアーキテクチャでは鍵の更新は経路のアップデートとほぼ同程度の処理です。BGPの環境で30秒に一度程度の経路アップデートをさばくのはさほど大変なことではないのはみなさん肌でご理解いただいていると思います。ViptelaのIPecの鍵更新は経路の更新と本質的に同じ処理ですので、BGPと同様のスケーラビリティをIPsecについても実現できる、と考えていただければいいかと思います。

また、鍵はvEdge毎に1つしかないことも注目すべき点です。したがって鍵はpair-wiseにはならず、IKEの時のような鍵の個数をO(n^2)からO(n)に大幅に減らすことができるのでスケーラビリティを確保することができます。

今日の多くのSD-WANソリューションは、IPsecによるオーバーレイネットワークを使ったものが多いです。SD-WANソリューションには通常何かしらのコントローラがありますので、プロビジョニングに関する問題は多くの場合解決されていると考えて良いと思います。しかし、維持しなければいけないステートの問題、特にIPsecの鍵交換のスケーラビリティに関して未解決のものが多いです。ViptelaのSD-WANソリューションのオーバーレイネットワークは、IKEを使わず鍵もpair-wiseに作らないので、他のIPsec/IKEベースのオーバーレイネットワークに比べると遥かにスケールする仕組みになっています。

Viptelaのオーバーレイネットワーク
Viptelaのオーバーレイネットワーク

実際に、ViptelaのSD-WANを使っているお客様の中には3,000拠点のIPsecフルメッシュなネットワークを実現されているされているお客様がおられます。そのお客様の利用事例についてはまた日を改めてご紹介をしたいと思います。

Viptela SD-WANソリューションの基本用語

明日からViptelaのSD-WANソリューションの具体的なユースケースをご紹介していきます。その前に、今日はViptelaの詳細をご紹介する際によくご質問をいただくViptela独自の用語について簡単にご説明したいと思います。

トランスポートサイド/サービスサイド

ViptelaのSD-WANソリューションでは、vEdgeのWAN側をトランスポートサイド、LAN側をサービスサイドと呼んで区別します。トランスポートサイドに設定されたインターフェースでは、コントローラーとのDTLS/TLSトンネル(コントロールコネクション)やvEdge同士のIPsecトンネルが構成されます。サービスサイドに設定されたインターフェースから受信したトラフィックは、トランスポートサイドのインターフェースからIPsecトンネルを通って、他サイトのvEdgeに運ばれます。

VPN (Virtual Private Network)

ViptelaのSD-WANソリューションにおいて、VPNは論理的に分離されたルーティングドメインを意味しています。トランスポートサイドの物理ネットワーク(WAN)と、サービスサイドのトラフィックを通すオーバーレイネットワークはルーティングドメインが異なります。このため、トランスポートサイドネットワークはVPN 0として区別されます。また、アウトオブバンドの管理ネットワークにはVPN 512が割り当てられています。サービスサイドのネットワークには0および512以外の任意の番号(1〜65530)を割り当てます。セグメンテーション機能を使用する場合、各セグメントにユニークなVPN番号を割り当てます。

VPNの識別にはIPsecカプセル化の際に付与されるラベルが使われます。このため、VPN(セグメント)を複数定義しても、vEdge間のIPsecトンネルは送受信で1対で変わりません。「VPN = IPsecトンネル」ではないことに注意が必要です。

Overlay Management Protocol (OMP)

vEdgeとコントローラーの間には、DTLSもしくはTLSで暗号化されたコントロールプレーンが構成されます。このコントロールプレーンの中ではSNMPやNetconfといったプロトコルのほかに、OMPと呼ばれるViptela独自のプロトコルが使われ、非常に重要な役割をはたしています。「Viptelaのアーキテクチャ」の回にもあったように、vSmartの主要な役割は、経路情報と暗号化鍵の配布、およびポリシーの配布です。OMPはこの経路情報や暗号化鍵、およびポリシーの配布を行うために開発された、BGPを拡張した独自のルーティングプロトコルです。OMPによって、ViptelaのSD-WANソリューションはポリシーによるトポロジーや経路の柔軟な制御と非常に高いスケーラビリティを実現しています。

ポリシー

ポリシーはオーバーレイネットワーク上でのvEdge間でのトラフィックのフローを柔軟に制御するための仕組みです。ViptelaのSD-WANソリューションは、コントロールプレーンとデータプレーンを完全に分離しており、ポリシーもそれぞれに対して適用することができます。コントロールプレーンに対して適用するポリシーでは、OMPで学習もしくは配布される経路情報を制御し、トポロジーを変化させたり、サービスチェイニングを実装できます。データプレーンに対して適用するポリシーでは、IPヘッダなどにもとづいて、各vEdge上でのトラフィックの扱いを制御できます。ポリシーの詳細については、今後くわしくご紹介していきたいと思います。

Site ID

Site IDはViptela SD-WANソリューションのオーバーレイネットワークの中で、物理的なロケーションを識別するための識別子です。同一のデータセンターや支店などのロケーションに複数のvEdgeを配置する場合、それらのvEdgeには同じSite IDを割り当てます。デフォルトの設定では、Site IDが異なるvEdge間のみIPsecトンネルが形成され、同一のSite IDのvEdge間では形成されません。通常、同一の物理ロケーションに複数のvEdgeを配置するのは、冗長化や負荷分散のためであり、vEdge同士でユーザデータをやり取りする目的ではないためです。Site IDは、ポリシーの定義や適用の際にも使われ、同一のポリシーを簡単に複数のvEdgeに関連づけることができます。

System IP Address

System IP Address(以下System IP)はIPv4アドレスの形式をした識別子で、vEdgeルータや、vSmart、vBondに必ず1つ割り当てられます。IPv4アドレス形式ですが、実際にそのノードに外部から疎通可能なIPアドレスである必要性はありません。Viptela SD-WANのオーバーレイの中で一意である必要があり、1.1.<site-id>.<siteの中での一意の番号>といった命名規則がよく使われます。

いったんコントロールプレーンが形成されると、System IPでのもともとのIP到達性の有無によらず、System IPはコントロールプレーン上で相互に疎通可能になります。実際にコントロールプレーンの通信はこのSystem IPを使って行われ、物理ネットワークのIPアドレス等が変更になった場合の影響が最小化されています。

Color

ColorはvEdgeルータがもつ複数のWAN回線(トランスポート)を識別するためのラベルです。mplsやmetro-ethernet、biz-internetといったサービス品目にもとづく名称や、gold、silver、bronzeといったサービスレベルにもとづく名称など、あらかじめ使えるラベルが決められていて、WAN回線につながる物理ポートの設定の中で指定します。

Colorは、vEdgeがもつ複数のIPsecトンネルを識別する際などに使われます。ge0/4のようなインターフェース名を使わず、抽象化したラベルであるColorを使うことで、設定やポリシーの定義の柔軟性や管理性を高めています。例えば、音声トラフィックはmplsというColorが指定されたWAN回線を優先的に使用するというポリシーを定義した場合、各vEdgeの物理インターフェースの構成やIPアドレスを意識することなく、ポリシーをvEdgeに適用することができます。

Transport Location (TLOC)

TLOCはOMPの中で使われる概念で、BGPにおけるNext Hopに相当しますが、単純なIPアドレスではなく、System IPとColorの組み合わせで表現します。物理インターフェースのIPアドレスではなくSystem IPを使うため、WAN回線につながる物理インターフェースにDHCPのようにIPアドレスの変更がある場合でも、影響をうけません。また、ViptelaのSD-WANソリューションでは、あるvEdgeにデータを送る場合に、複数のWAN回線(トランスポート)があれば、ECMPやポリシーによって、それらのWAN回線をアクティブ・アクティブで適切に使い分けます。このため、Colorを組み合わせることで、宛先vEdgeだけでなく経由するWAN回線もNext Hopとして特定できます。なお、厳密には、TLOCはSystem IPとColorに加えて、カプセル化方式によっても区別されますが、カプセル化方式は基本的にIPsecですので、ここでは無視して説明しています。

Viptelaのアーキテクチャ

ViptelaのSD-WANソリューションは大きく分けると二つの構成要素から成り立っています。

Viptela Architecture

一つ目の構成要素は「vEdge」と呼ばれるルータで、データセンター、キャンパス、支店やリモート拠点などに置かれます。vEdgeにはいくつかのモデルがありますが、基本機能はどのモデルでも共通です。

もう一つの構成要素がコントローラです。コントローラが拠点にあるvEdgeをソフトウェア的にコントロールすることでSD-WANが実現されています。コントローラはさらにいくつかの構成要素から成り立っています。一つ目が「vSmart」と呼ばれるもので、主に経路情報と暗号化鍵の配布、及びポリシーの配布などを行っています。「vBond」はオーケストレータ的な役割をするもので、vEdgeのブートストラップ時やNATトラバーサルする際に重要な役割を果たします。「vManage」はいわゆるNMS (Network Management Station)で、ユーザはvManageを使って機器の設定、モニタリング、トラブルシュートなどを行います。North-bound APIを提供しているのもこのvManageです。

コントローラは通常はViptela社が維持管理を行っているクラウド環境状にデプロイされますが、何かしらの理由でコントローラを自社環境(オンプレミス)に立てたい場合にはそのような構成も可能です。

コントローラとvEdge間の通信(いわゆるコントロールプレーン)はDTLSもしくはTLSで暗号化されています。証明書を使って認証を行いますが、vEdgeのハードウェアには証明書が耐タンパー性を備えたチップ(TPMチップ)に埋め込まれており、この情報を使って機器をセキュアに認証するようになっています。

一方、データプレーンは標準的なIPsecを使って暗号化を行なっています。vEdge同士は直接通信しますので、全てのvEdgeが1ホップで繋がるいわゆる「フルメッシュ」なIPsec構成を構成できます。一部のSD-WANソリューションの中にはクラウド上にゲートウェイをデプロイし、それを介してデータプレーンを構成するケースも見受けられますが、Viptelaはデータプレーンのトラフィックがクラウド側を流れることは一切ありません。

このようにコントロールプレーン、データプレーン共に完全に暗号化されていますので、下の回線の種類の特性(例えばインターネットはセキュアではない、など)を意識することなく、全ての回線を同時に使うハイブリッドなWANを実現することができます。

Full Stack Enterprise SD-WANとは何か

ヴィプテラ・ジャパン株式会社の進藤です。小松とともにSD-WAN市場の立ち上げと、Viptelaのソリューションに関する技術的支援などを行なっています。

さて、今回はSD-WANの要件について少し考えてみたいと思います。

現在、SD-WANを標榜する会社はゆうに30を超えています。ちょっとしたSD-WANフィーバー状態です。何を持ってそのソリューションが「SD-WAN」呼べるのかについてはっきりとした規定・規格はありませんが、一般的にはONUG (Open Networking USER GROUP)による「SD-WANのビジネス的要件」が引き合いに出されることが多いと思います。以下に簡単に要約します。

  •  拠点からパブリックなWANとプライベートなWANをハイブリッドに使うことができること。
  • 安価で汎用的なハードウェア上に物理的または仮想的なCPEを作れること。
  • ネットワークの可用性やパフォーマンスを損なうことなく、アプリケーションのポリシーに基づき、プライベートまたはパブリックなWAN上に動的にトラフィックエンジニアリングできるセキュアなアーキテクチャになっていること。
  • 企業のガバナンスやポリシーに準拠した形で、ビジネスにとって重要なトラフィックやリアルタイム性の高いアプリケーショントラフィックの可視化および優先付けができること。
  • 高い可用性と耐障害性を持ち、ユーザやアプリケーションに最適なハイブリッドWANを提供できること。
  • 既存のルータ・スイッチに直接接続して、L2およびL3での相互接続性が確保できること。
  • 拠点、アプリケーション、またはVPNのパフォーマンスを確認できるダッシュボード画面を持つこと。
  • オープンなNorth-bound APIを持ち、特定のログイベントをログ解析やセキュリティー監視装置(SEIM)に転送できること。
  • 接続されるネットワークの設定変更を要求せず、ゼロタッチで拠点を迅速に開設することができること。
  • 自動化された証明書の世代管理とレポート機能を備え、FIPS 140-2に準拠した暗号化モジュールもしくは暗号化方式を使っていること。

これを見て分かる通り、かなり曖昧な定義になっていますので、どのSD-WANベンダーも「うちのソリューションはこれらを全部満たしている」と胸を張っている状況です。

一方、Viptelaが考えるSD-WANソリューションが備えているべき機能要件は以下の通りです。

  • MPLS、インターネット、4G/LTEなど様々な回線をハイブリッドに使え、かつ全て”アクティブ”で使えること。
  • 完全なゼロタッチ(電源とネットワークケーブルを接続するだけ)で拠点を開設することができ、その際にTPM機能を使って機器をセキュアに認証する仕組みを持つこと。
  • コントロールプレーン、データプレーン共に完全に暗号化されていること。
  • オーバーレイでWANを実現することにより、回線の種類がプライベートであるかパブリックであるかを問わないこと。
  • 一つのオーバーレイWANの中に論理的に複数のネットワークの面(セグメント)を作ることができ、セグメント毎に任意のトポロジー(フルメッシュ、ハブ&スポーク、等)を定義できること。
  • WAN側、LAN側ともにOSPFおよびBGPをサポートし、既存のネットワークとシームレスに統合できること。
  • DPI技術でアプリケーションを特定し、トラフィックを可視化できること。
  • 複数あるWAN回線をさまざまなポリシー(アプリケーション種別や回線品質、など)によって選択できること。
  • 一般的なルータが持つQoS機能(キューイング、スケジューリング、ポリーシング、シェーピング、DSCPマーキング、など)を備えていること。
  • 大規模なサイトに対して一元的にポリシーを適用することのできるコントローラを持ち、ビジネスロジックやコンプライアンスを担保できる仕組みがあること。
  • トラフィックをリアルタイムあるいは過去に遡って可視化することができ、異常がある場合にはそれを検知し通知できる仕組みがあること。
  • RESTfulなNorth-bound APIを持ち、自動化や他のシステムとの連携が容易に行えること。
SD-WAN Requirement
SD-WANソリューションが備えるべき要件

ONUGの要件に比べるとかなり具体的だと思います。これらを全て満たして初めて「Full StackなSD-WANソリューション」と言えるのではないかと思っています。このようなFull StackなSD-WANソリューションはあまりありませんが、ViptelaのSEN (Secure Extensible Network)はこれらを全て満たすことのできるFull StackなEnterprise向けSD-WANソリューションになっています。Viptelaがこれらの要件を具体的にどのように実現しているかは、このBlogで追って詳しくお伝えしていこうと思います。