Wikipedia

ソフトウェア定義ネットワーク

オープンインターフェイスを用いて、ネットワーク管理者がネットワークの動作を初期化・制御・変更・管理を動的に行えるようにする技術
（Software Defined Networkingから転送）

ソフトウェア定義ネットワーク[1]（ ソフトウェア・デファインド・ネットワーキング、SDN）テクノロジーは、大規模なネットワークを設計・構築・運用する際に、ネットワーク間に中継する通信機器やネットワークデバイスの転送判断を中央のサーバーからソフトウェアでプログラミングする手法[2]。

概要

編集

ネットワークのパフォーマンスと監視を改善して従来のネットワーク管理よりもクラウドコンピューティングのようにするために、動的でプログラム的に効率的なネットワーク構成を可能にするネットワーク管理へのアプローチである。 [3] データ転送と経路制御の機能を論理的に分離し、ソフトウェア制御による動的で柔軟なネットワークを作り上げる技術全般を指す。

Wi-Fiなどの一部の技術分野とは異なり、SDNの開発を担当する単一の標準化団体はない[2]。

コントローラと呼ばれるマシンで動作する制御用ソフトウェアにより、データプレーンを制御する技術のことである。2008年にカリフォルニア大学バークレー校とスタンフォード大学で研究が開始された。SDNは制御プレーンからデータプレーンへのコミュニケーションを必要とし、その通信プロトコルの一つとしてはOpen Flowが存在する。現在は、Open Networking FoundationによってOpenFlow規格の策定とSDNの推進が進められている[4]。

SDNは、従来のネットワークの静的アーキテクチャが分散型で複雑であるのに対し、現在のネットワークにはより柔軟性があり、トラブルシューティングが容易であるという事実に対処することを目的としている。 SDNは、ルーティングプロセス（制御プレーン）からネットワークパケット （データプレーン）の転送プロセスの関連付けを解除することにより、ネットワークインテリジェンスを1つのネットワークコンポーネントに集中させようとする 。 制御プレーンは、インテリジェンス全体が組み込まれているSDNネットワークの頭脳と見なされる1つ以上のコントローラーで構成される。 ただし、セキュリティ、 スケーラビリティ、弾力性に関しては、インテリジェントな集中化には固有の欠点があり、これがSDNの主要な問題である。一般的なSDNコントローラは、ノースバウンドとサウスバウンドインターフェースに加えて、他のSDNコントローラや他のネットワークとの通信を可能にするイースト／ウエストバウンドインターフェースを持っている。データ転送と処理と制御サポートは、リソース層のサブレイヤーである。抽象化、オーケストレーション、およびアプリケーションのサポートは、SDN制御レイヤーのサブレイヤーである[2]。

SDNは、2011年の登場以来、一般にOpenFlowプロトコルに関連付けられていた（ ネットワークスイッチ間のネットワークパケットのパスを決定するためのネットワークプレーンエレメントとのリモート通信用 ）。 しかし、2012年以来[5] [6]多くの企業のためのOpenFlowは、彼らが独自の技術を追加し、もはや排他的なソリューションではない。 これには、 シスコシステムズのオープンネットワーク環境とニシラのネットワーク仮想化プラットフォームが含まれる 。

SD-WANは同様の技術を広域ネットワーク （WAN）に適用する。 [7]

SDNテクノロジーは現在、非常に高速なフェイルオーバーを必要とする産業用制御アプリケーションで利用できる。 1つの企業は、従来のネットワーク管理スイッチに関連する特定のサイバー脆弱性の排除とともに、ミッションクリティカルプロセスの100倍の高速フェイルオーバー（従来のネットワークの10ミリ秒と比較して100μsでフェイルオーバー）を誇っている。

vSDNEmul、 [8] EstiNet、 [9] Mininet [10]など、多くのエミュレータが研究目的で開発されているため、SDNの研究は続いている 。

SDNデータプレーンは、SDN制御プレーンの決定に従って、ネットワーク転送装置がデータの転送や処理を行う場所である。

制御サポート機能は、SDN制御レイヤと相互作用し、リソース制御インターフェースを介してプログラマビリティをサポートする。

データ転送機能は、他のネットワークデバイスやエンドシステムから受信したデータフローを受け取り、SDNアプリケーションで定義されたルールに従って計算・確立されたデータ転送パスに沿って転送する[2]。

歴史

編集

SDNの原理の歴史は、このアーキテクチャがデータネットワークで使用されるようになる前に、プロビジョニングと管理を簡素化する方法として、公衆交換電話網で最初に使用された制御プレーンとデータプレーンの分離に遡ることができる。

インターネット技術特別調査委員会（IETF）は、2004年に公開された "Forwarding and Control Element Separation"（ForCES）という適切なインターフェイス標準の制御機能と転送機能を分離するさまざまな方法を検討し始めた。 [11] ForCESワーキンググループは、コンパニオンSoftRouterアーキテクチャも提案した。 [12] データから制御を分離することを追求したIETFの初期の追加標準には、IPサービスプロトコルとしてのLinux Netlink [13]とパス計算要素（PCE）ベースのアーキテクチャが含まれる。 [14]

これらの初期の試みは、2つの理由で牽引力を得られなかった。 1つは、インターネットコミュニティの多くが、特に制御プレーンで障害が発生する可能性があるため、データからコントロールを分離することはリスクがあると考えていたことである。 2つ目は、制御プレーンとデータプレーンの間に標準のアプリケーションプログラミングインターフェイス（API）を作成すると競争が激化することをベンダーが懸念していたことである。

分割制御/データプレーンアーキテクチャでのオープンソースソフトウェアの使用は、スタンフォード大学のコンピューターサイエンス部門のエタンプロジェクトにそのルーツをたどる。 エタンのシンプルなスイッチ設計により、OpenFlowが誕生した。 [15] OpenFlowのAPIは、2008年に最初に作成された。 [16] その同じ年に、ネットワークのオペレーティングシステムであるNOXが作成された。 [17]

複数のキャンパスを接続するためのバックボーンとしてのWAN全体だけでなく、単一のキャンパスネットワークでのプロトコルの使用を評価するためのテストベッドの作成を含め、OpenFlowでの作業はスタンフォードでも継続された。 [18] アカデミックな環境では、 NECとHewlett-Packardの OpenFlowスイッチに基づくいくつかの研究および生産ネットワークがあった。また、2009年頃から、 Quanta Computerのホワイトボックスに基づいている。 [19]

アカデミアを超えて、最初の展開は2010年にNiciraによって、NTTおよびGoogleと共同開発したOnixからのOVSを制御することだった。 注目すべき展開は、2012年のGoogleのB4展開だった。 [20] [21] その後、Googleは、データセンターにOnixを導入した最初のOpenFlowを同時に認めた。 [22] もう1つの既知の大規模な展開は、 China Mobileである。 [23]

2014 Interop and Tech Field Dayでは、ソフトウェアデファインドネットワーキングがAvayaによって最短パスブリッジング（ IEEE 802.1aq ）とOpenStackを自動化キャンパスとして使用し、データセンターからエンドデバイスに自動化を拡張し、サービス提供から手動プロビジョニングを排除することで実証された。 [24] [25]

概念

編集

SDNアーキテクチャはネットワーク制御と転送機能を分離し、ネットワーク制御を直接プログラム可能にして、基盤となるインフラストラクチャをアプリケーションとネットワークサービスから抽象化できるようにする。 [26]

OpenFlowプロトコルは、SDNテクノロジーで使用できる。 SDNアーキテクチャは次のとおりである。

  • 直接プログラム可能 ：転送機能から切り離されているため、ネットワーク制御は直接プログラム可能である。
  • アジャイル ：転送から制御を抽象化すると、管理者はネットワーク全体のトラフィックフローを動的に調整して、変化するニーズに対応できる。
  • 集中管理 ：ネットワークインテリジェンスは、ソフトウェアベースのSDNコントローラーに（論理的に）集中化され、ネットワークのグローバルビューを維持する。これは、アプリケーションとポリシーエンジンからは単一の論理スイッチとして認識される。
  • プログラムで構成 ：SDNを使用すると、ネットワーク管理者は動的な自動SDNプログラムを介してネットワークリソースを非常に迅速に構成、管理、保護、および最適化できる。
  • オープンスタンダードベースでベンダーニュートラル ：SDNはオープンスタンダードを通じて実装されると、複数のベンダー固有のデバイスやプロトコルではなくSDNコントローラーによって命令が提供されるため、ネットワークの設計と運用が簡素化される。

新しいネットワークアーキテクチャの必要性

編集

モバイルデバイスとコンテンツの急増、サーバーの仮想化、およびクラウドサービスの出現は、ネットワーキング業界が従来のネットワークアーキテクチャを再検討する傾向にあるトレンドの1つである。 [27] 多くの従来のネットワークは階層型であり、ツリー構造に配置されたイーサネットスイッチの層で構築されている。 この設計は、クライアントサーバーコンピューティングが主流だったときに意味をなしたが、このような静的アーキテクチャは、今日のエンタープライズデータセンター、キャンパス、およびキャリア環境の動的コンピューティングとストレージのニーズには適していない。 [28]

Open Networking Foundation（ONF）は、従来のコンピュータや機械をつないだネットワーク構造の4つの一般的な制限を挙げている：外部ソフトからの操作が許可されて複雑、一貫性のないポリシー、スケーリングできないこと、情報通信企業依存。今後の時代はネットワークを仮想化し、抽象的に考える時代である。つまり、時間の経過とともに、ネットワーク仮想化(NFV)とソフトウェア定義ネットワーク(SDN)は緊密に相互運用され、ネットワーク機器とネットワークベースのリソースを抽象化してプログラムで制御するための幅広い統合ソフトウェアベースのネットワーキングアプローチを提供することになる[2]。

新しいネットワークパラダイムの必要性を推進する主要なコンピューティングトレンドには、次のものがある。

交通パターンの変化
エンタープライズデータセンター内では、トラフィックパターンが大幅に変化している。 通信の大部分が1つのクライアントと1つのサーバー間で発生するクライアントサーバーアプリケーションとは対照的に、今日のアプリケーションはさまざまなデータベースとサーバーにアクセスし、データを最後に返す前に一連の「東西」のマシン間トラフィックを発生させる。クラシックな「南北」のトラフィックパターンのユーザーデバイス。 同時に、ユーザーは、あらゆる種類のデバイス（自分のデバイスを含む）から企業のコンテンツやアプリケーションへのアクセスを要求し、いつでもどこからでも接続することで、ネットワークトラフィックのパターンを変えている。 最後に、多くのエンタープライズデータセンターマネージャーは、プライベートクラウド、パブリッククラウド、またはその両方の組み合わせを含むユーティリティコンピューティングモデルを検討しており、ワイドエリアネットワーク全体のトラフィックが増加する。
「ITの消費」
ユーザーは企業のネットワークにアクセスするためにスマートフォン、タブレット、ノートブックなどのモバイルパーソナルデバイスをますます採用している。 ITは、企業データと知的財産を保護し、コンプライアンス要件を満たす一方で、これらの個人用デバイスをきめ細かく対応する必要がある。
クラウドサービスの台頭
企業はパブリッククラウドサービスとプライベートクラウドサービスの両方を熱心に採用しており、これらのサービスの前例のない成長をもたらしている。 エンタープライズビジネスユニットは、アプリケーションやインフラストラクチャ、その他のITリソースにオンデマンドでアラカルトでアクセスする俊敏性を求めている。 複雑さを増すために、ITのクラウドサービスの計画は、セキュリティ、コンプライアンス、監査の要件が強化された環境で、ビジネスの再編成、統合、および一夜で想定を変更する可能性のある合併とともに行われる必要がありる。 プライベートクラウドでもパブリッククラウドでも、セルフサービスプロビジョニングを提供するには、理想的には共通の観点から、共通のツールスイートを使用して、コンピューティング、ストレージ、およびネットワークリソースの柔軟なスケーリングが必要である。
「ビッグデータ」はより広い帯域幅を意味する
今日の「ビッグデータ」またはメガデータセットを処理するには、何千ものサーバー上で大規模な並列処理が必要であり、それらすべてが相互に直接接続する必要がある。 巨大なデータセットの台頭により、データセンターでのネットワーク容量の追加が常に求められている。 ハイパースケールデータセンターネットワークのオペレーターは、ネットワークを以前には想像もできなかったサイズにスケーリングし、破損することなく多対多の接続を維持するという困難な作業に直面している。 [29]

要件

編集

Open Data Center Alliance (ODCA) は、以下のような便利で簡潔な要件を提供している[ODCA14][2]：

適応性
ネットワークは、アプリケーションのニーズ、ビジネスポリシー、およびネットワークの状態に基づいて、動的に調整および対応しなければならない。
自動化
ポリシーの変更が自動的に伝達されることで、手作業やエラーを減らすことができること。
保守性
新機能の導入（ソフトウェアのアップグレードやパッチ）は、業務の中断を最小限に抑えながらシームレスに行われなければならない。
モデル管理
ネットワーク管理ソフトウェアは、個々のネットワーク要素を再構成して概念的な変更を行うのではなく モデル管理：ネットワーク管理ソフトウェアは、個々のネットワーク要素を再構成して概念的な変更を行うのではなく、モデルレベルでネットワークを管理できる必要がある。
モビリティ
制御機能は、モバイル・ユーザー・デバイスや仮想サーバーなどのモビリティに対応する必要がある。
統合されたセキュリティ
ネットワークアプリケーションは、アドオンソリューションとしてではなく、コアサービスとしてシームレスなセキュリティを統合する必要がある。
オンデマンド・スケーリング
オンデマンドの要求に応じて、ネットワークとそのサービスを拡大・縮小できること。

建築コンポーネント

編集
 
ソフトウェアデファインドネットワーキングアーキテクチャの概要

次のリストは、アーキテクチャコンポーネントを定義および説明している： [30]

SDNアプリケーション
SDNアプリケーションは、 ノースバウンドインターフェース （NBI）を介して、ネットワーク要件と望ましいネットワーク動作を明示的、直接的、およびプログラム的にSDNコントローラーに伝達するプログラムである。 さらに、内部の意思決定のために、ネットワークの抽象化されたビューを使用する場合がある。 SDNアプリケーションは、1つのSDNアプリケーションロジックと1つ以上のNBIドライバーで構成される。 SDNアプリケーション自体が、抽象化されたネットワーク制御の別のレイヤーを公開し、それぞれのNBIエージェントを通じて1つ以上の高レベルのNBIを提供する場合がある。SDNアプリケーションレイヤーは、コントロールレイヤーサービス要求を特定のコマンドとディレクティブにデータプレーンスイッチにマップし、アプリケーションにデータプレーンのトポロジとアクティビティに関する情報を提供する。抽象化、オーケストレーション、およびアプリケーションのサポートは、SDNコントロールレイヤーのサブレイヤーである。 アプリケーションプレーンには、ネットワークリソースと動作を定義、監視、制御するアプリケーションとサービスが含まれている[2]。


SDNコントローラー
SDNコントローラーは、（i）要件をSDNアプリケーションレイヤーからSDNデータパスに変換し、（ii）SDNアプリケーションにネットワークの抽象的なビューを提供する（統計やイベントが含まれる場合がある）を担当する論理的に集中化されたエンティティである。 。 SDNコントローラーは、1つ以上のNBIエージェント、SDN制御ロジック、およびコントロールからデータプレーンインターフェース（CDPI）ドライバーで構成される。 論理的に一元化されたエンティティとしての定義は、複数のコントローラーのフェデレーション、コントローラーの階層接続、コントローラー間の通信インターフェース、ネットワークリソースの仮想化やスライスなどの実装の詳細を規定したり妨げたりするものではありない。
SDNデータパス
SDN Datapathは、アドバタイズされた転送機能とデータ処理機能に対する可視性と競合しない制御を公開する論理ネットワークデバイスである。 論理的表現は、物理的基板リソースのすべてまたはサブセットを包含することができる。 SDNデータパスは、CDPIエージェントと、1つ以上のトラフィック転送エンジンと0個以上のトラフィック処理機能のセットで構成される。 これらのエンジンと機能には、データパスの外部インターフェース間の単純な転送、内部トラフィック処理または終了機能が含まれる場合がある。 1つ以上のSDNデータパスは、単一の（物理）ネットワーク要素（通信リソースの統合された物理的な組み合わせ）に含まれ、ユニットとして管理される。 SDNデータパスは、複数の物理ネットワーク要素にわたって定義することもできる。 この論理定義は、論理から物理へのマッピング、共有物理リソースの管理、SDNデータパスの仮想化またはスライス、非SDNネットワーキングとの相互運用性、 OSIレイヤー4-7関数を含むことができるデータ処理機能などの実装の詳細を規定または排除するものではない。
SDN Control to Data-Plane Interface（CDPI）
SDN CDPIは、SDNコントローラーとSDNデータパスの間に定義されたインターフェースであり、少なくとも（i）すべての転送操作のプログラムによる制御、（ii）機能の通知、（iii）統計レポート、および（iv）イベント通知を提供する。 SDNの1つの価値は、CDPIがオープンでベンダー中立で相互運用可能な方法で実装されるという期待にある。
SDNノースバウンドインターフェイス（NBI）
SDN NBIは、SDNアプリケーションとSDNコントローラー間のインターフェースであり、通常、抽象的なネットワークビューを提供し、ネットワークの動作と要件を直接表現できるようにする。 これは、抽象化の任意のレベル（緯度）で、異なる機能セット（経度）で発生する可能性がある。 SDNのもう1つの価値は、これらのインターフェースがオープンでベンダー中立で相互運用可能な方法で実装されるという期待にあるという。

SDN制御プレーン

編集
集中型-階層型-分散型

SDN制御プレーンの実装は、集中型（中央集中型）、階層型、または分散型（自律分散型）の設計に従うことができる。 最初のSDN制御プレーンの提案は、単一の制御エンティティがネットワークのグローバルなビューを持つ集中型ソリューションに焦点を当てた。 これにより、制御ロジックの実装が簡略化されるが、ネットワークのサイズとダイナミクスが増加すると、スケーラビリティに制限がある。 これらの制限を克服するために、文献では、階層的アプローチと完全分散アプローチの2つのカテゴリに分類されるいくつかのアプローチが提案されている。 階層型ソリューションでは、 [31] [32]分散コントローラーは分割されたネットワークビューで動作するが、ネットワーク全体の知識が必要な決定は、論理的に集中化されたルートコントローラーによって行われる。 分散型アプローチでは、 [33] [34]コントローラはローカルビューで動作するか、同期メッセージを交換して知識を強化する。 分散型ソリューションは、アダプティブSDNアプリケーションのサポートにより適している。

結果、コントロールプレーンでは主に以下の機能を有する。

  • ルーティングテーブルの作成
  • MACアドレステーブルの作成
  • ARPによるアドレス解決
コントローラの配置

分散SDN制御プレーンを設計する際の重要な問題は、コントロールエンティティの数と配置を決定することである。 その際に考慮すべき重要なパラメーターは、コントローラーとネットワークデバイス間の伝搬遅延[35]あり、特に大規模ネットワークのコンテキストではそうである。 検討されてきた他の目的には、制御パスの信頼性、 [36]フォールトトレランス、 [37] 、およびアプリケーション要件が含まれる。 [38]

従来型とSDNのネットワーク管理
特徴従来型コントローラベース
コントロールプレーン自律分散型中央集中型
管理単位ネットワーク機器ネットワーク
機器設定各機器にログインし、コンソールから設定を行うネットワーク構成を定義し、コントローラが定義に従って各NW機器に適切な設定を行う
ファームウェア管理各NW機器ごとにファームウェアを管理し、ファームウェアの更新は各機器ごとに行うコントローラーで一括管理。各機器のファームウェアはコントローラーから行う。
セキュリティ各機器のインターフェイスやNWの境界となる機器で監視やフィルタリングを行うNetFlowなどの分析機能を用いて、NW全体で不審な動きを監視し対処する
障害復旧手動でトラブルシューティングを行うAIや機械学習で問題の検出や分析が可能。迅速かつ正確に問題解決を行う

SDNアプリケーションプレーン

編集

SDNアプリケーション層は、制御層のサービス要求をデータプレーンスイッチへの特定のコマンドやディレクティブにマッピングし、アプリケーションにデータプレーンのトポロジーやアクティビティに関する情報を提供する。このアプリケーションプレーンには、ネットワークリソースと動作を定義、監視、制御するためのアプリケーションとサービスが含まれる[2]：

Defense4Allは、OpenDaylightに統合されたオープンなSDNセキュリティアプリケーションである。

断面帯域幅とは、ネットワークの2つの部分を半分に等分した場合に、その間を通過できる最大双方向データレートのこと。

クラウドネットワークアズアサービスは、OpenFlow SDN機能を利用し、クラウド利用者がクラウドネットワーク機能をより高度に制御できるようにしたクラウドネットワーキングシステムである。そのプリミティブは、クラウドインフラ自体の中に直接実装される。

情報指向ネットワーク（ICN）では、場所とIDの間に違いがある。


ノースバウンドインタフェースにより、アプリケーションは基盤となるネットワークスイッチの詳細を知らなくても、制御プレーンの機能とサービスにアクセスすることができる。

抽象化レイヤーは、高レベルのリクエストを、そのリクエストを実行するために必要な低レベルのコマンドに変換するメカニズムである。

OpenFlow APIは、転送抽象化の例である。

ネットワークサービスの抽象化レイヤーの例として、プログラミング言語Freneticがある。

トラフィックエンジニアリングとは、ネットワーク上を流れるデータの挙動を動的に分析、調整、予測し、サービスレベル契約を満たすためのパフォーマンス最適化を目的とした手法である。

PolicyCopは11のソフトウェアモジュールと2つのデータベースで構成されており、ネットワークを監視してポリシー違反を検出し、違反したポリシーを強化するためにネットワークを再構成する。SDN の制御プレーンを利用して QoS ポリシーの遵守を監視する．

イベントハンドラーモジュールには、違反イベントを調べ、イベントの種類に応じて、自動的に集中脅威管理を提供し、ソフトウェア定義の安全なネットワークへの監視と別のソリューションからの脅威インテリジェンスを組み合わせる能力を与えることから、その知性に基づいて行動するポリシーエンフォーサーを呼び出すか、ネットワークマネージャにアクションリクエストを送信する。

DDoSとは、複数のシステムを利用してサーバーやネットワーク機器、リンクにトラフィックを流し、その利用可能なリソースを圧迫して、正当なユーザーへの対応を不能にする攻撃である。

SDNフロー転送（sdn）

編集
プロアクティブvsリアクティブvsハイブリッド[39] [40]
OpenFlowはTCAMテーブルを使用してパケットシーケンス（フロー）をルーティングする。 フローがスイッチに到着すると、フローテーブルのルックアップが実行される。 フローテーブルの実装に応じて、 vSwitchが使用されている場合はソフトウェアフローテーブルで、ハードウェアに実装されている場合はASICでこれが行われる。 一致するフローが見つからない場合は、コントローラーに追加の指示を求める要求が送信される。 これは、3つの異なるモードのいずれかで処理される。 リアクティブモードでは、コントローラーはこれらの要求の後に動作し、必要に応じて、対応するパケットのフローテーブルにルールを作成してインストールする。 プロアクティブモードでは、コントローラは、このスイッチで可能なすべての可能なトラフィック一致のフローテーブルエントリを事前に入力する。 このモードは、すべての静的エントリが事前にインストールされている今日の一般的なルーティングテーブルエントリと比較できる。 これに続いて、すべての着信フローが一致するエントリを見つけるため、リクエストはコントローラに送信されない。 プロアクティブモードの主な利点は、すべてのパケットがラインレートで転送され（TCAMのすべてのフローテーブルエントリを考慮）、遅延が追加されないことである。 3番目のモードであるハイブリッドモードは、一連のトラフィックに対するリアクティブモードと、残りのトラフィックに対する低遅延転送（プロアクティブモード）の柔軟性に従う。

用途

編集

SDMN

編集

ソフトウェア定義モバイルネットワーキング （SDMN） [41] [42]は、すべてのプロトコル固有の機能がソフトウェアで実装されるモバイルネットワークの設計へのアプローチであり、 コアネットワークと無線アクセスネットワーク 。 [43] これは、 モバイルネットワーク固有の機能を組み込むSDNパラダイムの拡張として提案されている。 [44] 3GPP Rel.14以降、 PFCPプロトコルを使用するモバイルコアネットワークアーキテクチャにコントロールユーザープレーン分離が導入された。

SD-WAN

編集
→詳細は「SD-WAN」を参照

SD-WANは、ソフトウェア定義ネットワーキングの原則を使用して管理される広域ネットワーク （WAN）である。 [45] SD-WANの主な推進力は、より高価なMPLS回線の代替または部分的な交換として、より手頃な価格の市販の専用回線を使用してWANコストを削減することである。 制御と管理はハードウェアとは別に管理され、中央コントローラーにより、構成と管理が容易になる。 [46]

SD-LAN

編集

SD-LANは、ソフトウェア定義ネットワーキングの原則に基づいて構築されたローカルエリアネットワーク （LAN）であるが、トポロジ、ネットワークセキュリティ、アプリケーションの可視性と制御、管理、およびサービスの品質には大きな違いがある。 [47] SD-LANは、制御管理とデータプレーンを分離して、有線および無線LANのポリシー駆動型アーキテクチャを実現する。 SD-LANの特徴は、物理的なコントローラーがなくても、クラウド管理システムとワイヤレス接続を使用できることである。 [48]

SDNパラダイムを使用したセキュリティ

編集

SDNアーキテクチャは、コントローラーのネットワークの中央ビューと、いつでもデータプレーンを再プログラムするその能力により、ネットワーク関連のセキュリティアプリケーションを有効化、促進、または強化する場合がある。 SDNアーキテクチャのセキュリティ自体は未解決の問題であり、すでに研究コミュニティで数回検討されているが、 [49] [50] [51] [52]以下の段落では、セキュリティアプリケーションに焦点を当てて説明する。

SDNに関するいくつかの研究は、SDNコントローラー上に構築されたセキュリティアプリケーションを、さまざまな目的であるでに調査している。 分散型サービス拒否（DDoS）の検出と軽減[53] [54]だけでなく、ボットネット[55]とワームの伝播[56]は、そのようなアプリケーションの具体的な使用例である。基本的に、このアイデアは定期的にネットワークを収集することにある標準化された方法（Openflowを使用するなど）でネットワークの転送プレーンからの統計情報を取得し、それらの統計情報に分類アルゴリズムを適用してネットワークの異常を検出する。 異常が検出された場合、アプリケーションはデータプレーンを再プログラムしてデータプレーンを軽減する方法をコントローラーに指示する。

別の種類のセキュリティアプリケーションは、移動ターゲット防御（MTD）アルゴリズムを実装することにより、SDNコントローラーを活用する。 MTDアルゴリズムは通常、特定のシステムまたはネットワークの主要なプロパティを定期的に非表示または変更することにより、特定のシステムまたはネットワークへの攻撃を通常よりも困難にするために使用される。 従来のネットワークでは、MTDアルゴリズムの実装は簡単な作業ではありない。保護するシステムの各部分について、どのキープロパティを非表示または変更するかを決定できる中央機関を構築することは難しいためである。 SDNネットワークでは、コントローラーの中心性により、このようなタスクはより簡単になる。 たとえば、1つのアプリケーションが定期的に仮想IPをネットワーク内のホストに割り当てることができ、仮想IPと実際のIPのマッピングがコントローラーによって実行される。 [57] 別のアプリケーションは、攻撃者が実行する偵察フェーズ（スキャンなど）の間に重大なノイズを追加するために、ネットワーク内のランダムなホストで偽のオープン/クローズ/フィルターされたポートをシミュレートできる。 [58]

SDN対応ネットワークのセキュリティに関する追加の値は、それぞれFlowVisor[59]およびFlowChecker[60]を使用して取得することもできる。前者は、複数の分離された論理ネットワークを共有する単一のハードウェア転送プレーンを使用しようとする。 このアプローチに従うと、同じハードウェアリソースを本番環境と開発の目的で使用できるほか、監視、構成、インターネットトラフィックを分離できる。各シナリオには、スライスと呼ばれる独自の論理トポロジを設定できる。このアプローチと連携して、FlowChecker は、ユーザーが独自のスライスを使用して展開する新しいOpenFlowルールの検証を実現する。

SDNコントローラーアプリケーションは、ほとんどの場合、起こり得るプログラミングエラーの包括的なチェックを必要とする大規模なシナリオで展開される。NICEと呼ばれるこれを行うシステムが2012年に説明された。 [61] 包括的なセキュリティアーキテクチャを導入するには、SDNに対する包括的かつ長期にわたるアプローチが必要である。 それが導入されて以来、設計者はスケーラビリティを犠牲にしないSDNを保護するための可能な方法を検討している。 SN-SECA（SDN + NFV）セキュリティアーキテクチャと呼ばれる1つのアーキテクチャ。 [62]

SDNを使用したグループデータ配信

編集

データセンター全体で実行される分散アプリケーションは、通常、同期、障害回復力、ロードバランシング、およびデータをユーザーに近づけるためにデータを複製する（これにより、ユーザーのレイテンシが減少し、認識されるスループットが向上する）。 また、Hadoopなどの多くのアプリケーションは、データセンター内のデータを複数のラックに複製して、フォールトトレランスを向上させ、データの回復を容易にする。 これらすべての操作には、1つのマシンまたはデータセンターから複数のマシンまたはデータセンターへのデータ配信が必要である。 1台のマシンから複数のマシンにデータを確実に配信するプロセスは、Reliable Group Data Delivery（RGDD）と呼ばれる。

複数の発信ポートへの転送を許可するルールをインストールすることにより、SDNスイッチをRGDDに使用できる。 たとえば、OpenFlowはバージョン1.1 [63]以降、これを可能にするグループテーブルをサポートしている。 中央コントローラーは、SDNを使用して、RGDDの転送ツリーを注意深くインテリジェントにセットアップできる。 このようなツリーは、パフォーマンスを向上させるためにネットワークの輻輳/負荷状態に注意を払いながら構築できる。 たとえば、MCTCP [64]は、データセンターネットワークの通常の構造化トポロジに依存するデータセンター内の多くのノードに配信するためのスキームであり、DCCast [65]とQuickCast [66]は、データセンター間でデータとコンテンツを高速かつ効率的に複製するためのアプローチである。

NFVとの関係

編集

NFV ネットワーク機能仮想化は、SDNを補完する概念である。 したがって、NFVはSDNまたはSDNの概念に依存しない。 NFVはソフトウェアをハードウェアから切り離し、柔軟なネットワーク展開と動的な操作を可能にする。 NFV展開では、通常、コモディティサーバーを使用して、以前はハードウェアベースであったネットワークサービスソフトウェアバージョンを実行する。 NFV環境で実行されるこれらのソフトウェアベースのサービスは、仮想ネットワーク機能（VNF）と呼ばれる[2]。 SDN-NFVハイブリッドプログラムは、標準のIT仮想化テクノロジーを使用してサービスのイノベーションとプロビジョニングを加速することを目的とした、高効率で柔軟であるケーラブルな機能を提供した。 [67] SDNは、SDNコントローラーを使用して、ルーターやスイッチなどの汎用転送デバイスを制御する俊敏性を提供する。 一方、NFVの俊敏性は、仮想サーバーを使用してネットワークアプリケーションに提供される。 既存のネットワーキングとオーケストレーションのパラダイムを使用して、スタンドアロンエンティティとして仮想ネットワーク機能（VNF）を実装することは完全に可能である。 ただし、SDVの概念を活用してNFVインフラストラクチャを実装および管理することには、特にVNFの管理とオーケストレーションを検討する場合に固有の利点があるため、協調型エコシステムにSDNとNFVを組み込むマルチベンダープラットフォームが定義されている。 [68]

DPIとの関係

編集

DPI ディープパケットインスペクションはネットワークにアプリケーション認識を提供し、SDNはアプリケーションにネットワーク認識を提供する。 [69] SDNは一般的なネットワークアーキテクチャを根本的に変更するが、高い相互運用性を提供するために、従来のネットワークアーキテクチャでの作業に対応する必要がある。 新しいSDNベースのネットワークアーキテクチャでは、DPIやセキュリティアプライアンスなどのメインの転送デバイス（ルーターとスイッチ）以外の個別のデバイスまたはソフトウェアで現在提供されているすべての機能を考慮する必要がある[70]。

関連項目

編集

参考文献

編集
  1. ^ AnirbanPaul. “ソフトウェア定義ネットワーク (SDN)”. docs.microsoft.com. 2022年3月28日閲覧。
  2. ^ a b c d e f g h i William Stallings『Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud』Addison-Wesley Professional、2015年 ISBN 0134175395
  3. ^ Benzekki, Kamal; El Fergougui, Abdeslam; Elbelrhiti Elalaoui, Abdelbaki (2016). “Software-defined networking (SDN): A survey”. Security and Communication Networks 9 (18): 5803–5833. doi:10.1002/sec.1737. 
  4. ^ Open Networking Foundation Formed to Speed Network Innovation
  5. ^ “Software-defined networking is not OpenFlow, companies proclaim”. searchsdn.techtarget.com. 2018年3月27日閲覧。
  6. ^ “InCNTRE's OpenFlow SDN testing lab works toward certified SDN product”. 2018年8月28日閲覧。
  7. ^ “Predicting SD-WAN Adoption”. gartner.com (2015年12月15日). 2016年6月27日閲覧。
  8. ^ Farias, Fernando N. N.; Junior, Antônio de O. (28 August 2019). "vSDNEmul: A Software-Defined Network Emulator Based on Container Virtualization". arXiv:1908.10980 [cs.NI]。
  9. ^ Wang, S.; Chou, C.; Yang, C. (September 2013). “EstiNet openflow network simulator and emulator”. IEEE Communications Magazine 51 (9): 110–117. doi:10.1109/MCOM.2013.6588659. ISSN 1558-1896. 
  10. ^ Oliveira, R. L. S. de; Schweitzer, C. M.; Shinoda, A. A.; Ligia Rodrigues Prete (June 2014). “Using Mininet for emulation and prototyping Software-Defined Networks”. 2014 IEEE Colombian Conference on Communications and Computing (COLCOM): 1–6. doi:10.1109/ColComCon.2014.6860404. ISBN 978-1-4799-4340-1. 
  11. ^ L. Yang (Intel Corp.), R. Dantu (Univ. of North Texas), T. Anderson (Intel Corp.) & R. Gopal (Nokia.) (April 2004). “Forwarding and Control Element Separation (ForCES) Framework”. 2018年1月2日閲覧。
  12. ^ T. V. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, and T. Woo (Nov 2004). “The SoftRouter Architecture”. 2018年1月2日閲覧。
  13. ^ J. Salim (Znyx Networks), H. Khosravi (Intel), A. Kleen (Suse), and A. Kuznetsov (INR/Swsoft) (July 2003). “Linux Netlink as an IP Services Protocol”. 2018年1月2日閲覧。
  14. ^ A. Farrel (Old Dog Consulting), J. Vasseur (Cisco Systems, Inc.), and J. Ash (AT&T) (August 2006). “A Path Computation Element (PCE)-Based Architecture”. 2018年1月2日閲覧。
  15. ^ Martìn Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, and Nick McKeown (Stanford University) (August 2007). “Ethane: Taking Control of the Enterprise”. 2018年1月2日閲覧。
  16. ^ N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. (April 2008). “OpenFlow: Enabling Innovation in Campus Networks”. 2018年1月2日閲覧。
  17. ^ N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker. (July 2008). “NOX: Towards an Operating System for Networks”. 2018年1月2日閲覧。
  18. ^ “GENI. Campus OpenFlow topology” (2011年). 2018年1月2日閲覧。
  19. ^ Kuang-Ching “KC” Wang (Oct 3, 2011). “Software Defined Networking and OpenFlow for Universities: Motivation, Strategy, and Uses”. 2018年1月2日閲覧。
  20. ^ Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla, Urs Hölzle, Stephen Stuart and Amin Vahdat (Google) (August 12–16, 2013). “B4: Experience with a Globally-Deployed Software Defined WAN”. 2018年1月2日閲覧。
  21. ^ brent salisbury (May 14, 2013). “Inside Google's Software-Defined Network”. 2018年1月2日閲覧。
  22. ^ Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, Anand Kanagala, Jeff Provost, Jason Simmons, Eiichi Tanda, Jim Wanderer, Urs Hölzle, Stephen Stuart, Amin Vahdat (2015年). “Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network”. 2018年11月2日閲覧。
  23. ^ “"MPLS-TP OpenFlow Protocol Extensions for SPTN" becomes a formal ONF standard by unanimous approval” (June 27, 2017). 2018年11月2日閲覧。
  24. ^ Camille Campbell (February 6, 2014). “Avaya Debuts Networking Innovations at 'Tech Field Day'”. 2018年1月2日閲覧。
  25. ^ Elizabeth Miller Coyne (September 23, 2016). “Huawei Exec: SDN's Become a 'Completely Meaningless Term'”. 2018年1月2日閲覧。
  26. ^ “Software-Defined Networking (SDN) Definition”. Opennetworking.org. 26 October 2014閲覧。
  27. ^ “White Papers”. Opennetworking.org. 26 October 2014閲覧。
  28. ^ Montazerolghaem, Ahmadreza.; Yaghmaee, M. H.; Leon-Garcia, A. (2017). “OpenSIP: Toward Software-Defined SIP Networking”. IEEE Transactions on Network and Service Management PP (99): 184–199. arXiv:1709.01320. Bibcode: 2017arXiv170901320M. doi:10.1109/tnsm.2017.2741258. ISSN 1932-4537. 
  29. ^ Vicentini, Cleverton; Santin, Altair; Viegas, Eduardo; Abreu, Vilmar (January 2019). “SDN-based and multitenant-aware resource provisioning mechanism for cloud-based big data streaming”. Journal of Network and Computer Applications 126: 133–149. doi:10.1016/j.jnca.2018.11.005. 
  30. ^ “SDN Architecture Overview”. Opennetworking.org. 22 November 2014閲覧。
  31. ^ S.H. Yeganeh, Y. Ganjali, "Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications," proceedings of HotSDN, Helsinki, Finland, 2012.
  32. ^ R. Ahmed, R. Boutaba, "Design considerations for managing wide area software defined networks," Communications Magazine, IEEE, vol. 52, no. 7, pp. 116–123, July 2014.
  33. ^ T. Koponen et al, "Onix: A Distributed Control Platform for Large scale Production Networks," proceedings USENIX, ser. OSDI’10, Vancouver, Canada, 2010.
  34. ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "Adaptive Resource Management and Control in Software Defined Networks," Network and Service Management, IEEE Transactions on, vol. 12, no. 1, pp. 18–33, March 2015.
  35. ^ B. Heller, R. Sherwood, and N. McKeown, "The Controller Placement Problem," proceedings of HotSDN’12, 2012.
  36. ^ Y.N. Hu, W.D. Wang, X.Y. Gong, X.R. Que, S.D. Cheng, "On the placement of controllers in software-defined networks," Journal of China Universities of Posts and Telecommunications, vol. 19, Supplement 2, no. 0, pp. 92 – 171, 2012.
  37. ^ F.J. Ros, P.M. Ruiz, "Five nines of southbound reliability in software defined networks," proceedings of HotSDN’14, 2014.
  38. ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "On the Placement of Management and Control Functionality in Software Defined Networks," proceedings of 2nd IEEE International Workshop on Management of SDN and NFV Systems (ManSDN/NFV), Barcelona, Spain, November 2015.
  39. ^ “OpenFlow: Proactive vs Reactive”. NetworkStatic.net (2013年1月15日). 2014年7月1日閲覧。
  40. ^ “Reactive, Proactive, Predictive: SDN Models | F5 DevCentral”. Devcentral.f5.com (2012年10月11日). 2016年6月30日閲覧。
  41. ^ Pentikousis, Kostas; Wang, Yan; Hu, Weihua (2013). “Mobileflow: Toward software-defined mobile networks”. IEEE Communications Magazine 51 (7): 44–53. doi:10.1109/MCOM.2013.6553677. 
  42. ^ Liyanage, Madhusanka (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. UK: John Wiley. pp. 1–438. ISBN 978-1-118-90028-4. http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118900286.html 
  43. ^ Jose Costa-Requena, Jesús Llorente Santos, Vicent Ferrer Guasch, Kimmo Ahokas, Gopika Premsankar, Sakari Luukkainen, Ijaz Ahmed, Madhusanka Liyanage, Mika Ylianttila, Oscar López Pérez, Mikel Uriarte Itzazelaia, Edgardo Montes de Oca, SDN and NFV Integration in Generalized Mobile Network Architecture, in Proc. of European Conference on Networks and Communications (EUCNC), Paris, France. June 2015.
  44. ^ Madhusanka Liyanage, Mika Ylianttila, Andrei Gurtov, Securing the Control Channel of Software-Defined Mobile Networks, in Proc. of IEEE 15th International Symposium on World of Wireless, Mobile and Multimedia Networks (WoWMoM), Sydney, Australia. June 2014.
  45. ^ Haranas (8 October 2016). “16 Hot Networking Products Putting The Sizzle In SD-WAN”. CRN. 1 November 2016閲覧。
  46. ^ “SD-WAN: What it is and why you'll use it one day”. networkworld.com (2016年2月10日). 2016年6月27日閲覧。
  47. ^ Serries (12 September 2016). “SD-LAN et SD-WAN : Deux Approches Différentes pour le Software Defined Networking”. ZDNet. 1 November 2016閲覧。
  48. ^ Kerravala (13 September 2016). “Aerohive Introduces the Software-defined LAN”. Network World. 1 November 2016閲覧。
  49. ^ Kreutz, Diego; Ramos, Fernando; Verissimo, Paulo (2013). "Towards secure and dependable software-defined networks". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. pp. 50–60.
  50. ^ Scott-Hayward, Sandra; O'Callaghan, Gemma; Sezer, Sakir (2013). "SDN security: A survey". Future Networks and Services (SDN4FNS), 2013 IEEE SDN for. pp. 1–7.
  51. ^ Benton, Kevin; Camp, L Jean; Small, Chris (2013). "Openflow vulnerability assessment". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. pp. 151–152.
  52. ^ Abdou, AbdelRahman; van Oorschot, Paul; Wan, Tao (May 2018). “A Framework and Comparative Analysis of Control Plane Security of SDN and Conventional Networks”. IEEE Communications Surveys and Tutorials to appear. arXiv:1703.06992. Bibcode: 2017arXiv170306992A. 
  53. ^ Giotis, K; Argyropoulos, Christos; Androulidakis, Georgios; Kalogeras, Dimitrios; Maglaris, Vasilis (2014). “Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments”. Computer Networks 62: 122–136. doi:10.1016/j.bjp.2013.10.014. https://zenodo.org/record/3415467. 
  54. ^ Braga, Rodrigo; Mota, Edjard; Passito, Alexandre (2010). "Lightweight DDoS flooding attack detection using NOX/OpenFlow". Local Computer Networks (LCN), 2010 IEEE 35th Conference on. pp. 408–415.
  55. ^ Feamster, Nick (2010). "Outsourcing home network security". Proceedings of the 2010 ACM SIGCOMM workshop on Home networks. pp. 37–42.
  56. ^ Jin, Ruofan & Wang, Bing (2013). "Malware detection for mobile devices using software-defined networking". Research and Educational Experiment Workshop (GREE), 2013 Second GENI. 81-88.
  57. ^ Jafarian, Jafar Haadi; Al-Shaer, Ehab; Duan, Qi (2012). "Openflow random host mutation: transparent moving target defense using software defined networking". Proceedings of the first workshop on Hot topics in software defined networks. pp. 127–132.
  58. ^ Kampanakis, Panos; Perros, Harry; Beyene, Tsegereda. SDN-based solutions for Moving Target Defense network protection (PDF). 2014年7月23日閲覧。
  59. ^ Sherwood, Rob; Gibb, Glen; Yap, Kok-Kiong; Appenzeller, Guido; Casado, Martin; McKeown, Nick; Parulkar, Guru (2009). “Flowvisor: A network virtualization layer”. OpenFlow Switch Consortium, Tech. Rep. 
  60. ^ Al-Shaer, Ehab & Al-Haj, Saeed (2010). "FlowChecker: Configuration analysis and verification of federated OpenFlow infrastructures". Proceedings of the 3rd ACM workshop on Assurable and usable security configuration. pp. 37–44.
  61. ^ Canini, Marco; Venzano, Daniele; Peresini, Peter; Kostic, Dejan; Rexford, Jennifer (2012). A NICE Way to Test OpenFlow Applications. NSDI. pp. 127–140.
  62. ^ Bernardo and Chua (2015). Introduction and Analysis of SDN and NFV Security Architecture (SA-SECA). 29th IEEE AINA 2015. pp. 796–801.
  63. ^ B. Pfaf (February 28, 2011). “OpenFlow Switch Specification”. July 8, 2017閲覧。
  64. ^ T. Zhu (October 18, 2016). “MCTCP: Congestion-aware and robust multicast TCP in Software-Defined networks”. 2016 IEEE/ACM 24th International Symposium on Quality of Service (IWQoS). IEEE. pp. 1–10. doi:10.1109/IWQoS.2016.7590433. ISBN 978-1-5090-2634-0 
  65. ^ M. Noormohammadpour (July 10, 2017). “DCCast: Efficient Point to Multipoint Transfers Across Datacenters”. USENIX. July 3, 2017閲覧。
  66. ^ M. Noormohammadpour (2018). QuickCast: Fast and Efficient Inter-Datacenter Transfers using Forwarding Tree Cohorts. arXiv:1801.00837. Bibcode: 2018arXiv180100837N. doi:10.31219/osf.io/uzr24. https://www.researchgate.net/publication/322243498 January 23, 2018閲覧。 
  67. ^ Rowayda, A. Sadek (May 2018). “An Agile Internet of Things (IoT) based Software Defined Network (SDN) Architecture”. Egyptian Computer Science Journal 42 (2): 13–29. 
  68. ^ Platform to Multivendor Virtual and Physical Infrastructure
  69. ^ Graham, Finnie (December 2012). “The Role Of DPI In An SDN World”. White Paper. 
  70. ^ Series, Y. (May 2015). “Global Information Infrastructure, Internet Protocol Aspects And NextGeneration Networks”. ITU-T Y.2770 Series, Supplement on DPI Use Cases and Application Scenarios. 
「https://ja.wiki.x.io/w/index.php?title=ソフトウェア定義ネットワーク&oldid=101071643」から取得