ソフトウェア定義ネットワーク（SDN）-OpenFlowのアーキテクチャと役割

前回の記事では、テクノロジーとしてのSDNの概要、必要な理由、IT業界がSDNをどのように採用しているかについて説明しました。それでは、レイヤーをさらに深く理解し、SDNのアーキテクチャとテクノロジーの実装におけるOpenflowプロトコルの役割を理解しましょう。

SDNは大きく3つのレイヤーで構成されています：

1. アプリケーション層
2. コントロールレイヤー
3. インフラストラクチャレイヤー

ボトムツーアップのアプローチでこれらのレイヤーを理解してみましょう。

インフラストラクチャレイヤー ネットワークトラフィックを転送するための基盤となるネットワークを形成するさまざまなネットワーク機器で構成されています。データセンター内のネットワークスイッチとルーターのセットである可能性があります。このレイヤーは、ネットワーク仮想化が制御レイヤー（SDNコントローラーが基盤となる物理ネットワークを配置および管理する場所）を介して配置される物理レイヤーになります。

コントロールレイヤー は、ネットワークインフラストラクチャを制御するためにSDNコントローラーのインテリジェントロジックが存在するコントロールプレーンの土地です。これは、すべてのネットワークベンダーがSDNコントローラーとフレームワーク用の独自の製品を考案するために取り組んでいる分野です。このレイヤーでは、さまざまな種類のネットワーク情報、状態の詳細、トポロジの詳細、統計の詳細などを取得して維持するために、多くのビジネスロジックがコントローラーに記述されています。

SDNコントローラーはネットワークを管理するためのものであるため、スイッチング、ルーティング、L2 VPN、L3 VPN、ファイアウォールセキュリティルール、DNS、DHCP、クラスタリングなどの実際のネットワークユースケースの制御ロジックが必要です。いくつかのネットワーキングベンダーやオープンソースコミュニティでさえ、SDNコントローラーでのこれらのユースケースの実装に取り​​組んでいます。実装されると、これらのサービスはAPI（通常はRESTベース）を上位層（アプリケーション層）に公開します。これにより、ネットワーク管理者はSDNコントローラー上でアプリを使用して、基盤となるネットワークを構成、管理、監視することが容易になります。コントロールレイヤーは中央にあり、ノースバウンドとサウスバウンドの2種類のインターフェースを公開しています。

• ノースバウンドインターフェース ：上位のアプリケーション層との通信を目的としており、通常、SDNコントローラーのRESTAPIを介して実現されます。 S アウトバウンドインターフェース ：ネットワーク要素の下位のインフラストラクチャ層との通信を目的としており、一般にサウスバウンドプロトコル（Openflow、Netconf、Ovsdbなど）を介して実現されます。

アプリケーション層 は、ネットワークトポロジ、ネットワーク状態、ネットワーク統計などに関するすべてのネットワーク情報を活用して、可能な限り革新的なアプリケーションを開発するためのオープンエリアです。ネットワークの自動化、ネットワーク構成、管理、ネットワークモニタリング、ネットワークトラブルシューティング、ネットワークポリシー、およびセキュリティ。このようなSDNアプリケーションは、実際のエンタープライズおよびデータセンターネットワークにさまざまなエンドツーエンドのソリューションを提供できます。ネットワークベンダーは、SDNアプリケーションのセットを考えています。たとえば、Brocadeには次の非常に便利なアプリケーションがあります。

• ブロケードフローオプティマイザー

• Brocade仮想ルーター

• BrocadeNetworkアドバイザー

HPEは、さまざまな企業の多くのSDNアプリも含むSDNアプリストアを持つベンダーの1つでもあります。例：

• HPEネットワークオプティマイザー

• HPEネットワークプロテクター

• HPEネットワークビジュアライザー

• HPSDNVANコントローラー用のNECUNC

• AricentSDNロードバランサー

• TechMスマートフローステアリング

• TechMサーバーロードバランサー

前の記事でOpenflowについて簡単に触れたので、Openflowプロトコルを介した制御層からインフラストラクチャ層（ネットワークスイッチ）へのサウスバウンド通信の詳細について説明します。

Openflowは、コントロールプレーンをデータプレーンからショーケースで分離するための鍵であるという意味で、SDNの革命に貢献してきました。 Openflowは、Open Networking Foundation（ONF）によって提供される標準仕様であり、現在の世界のネットワーキングのさまざまな要件をサポートすることで、時間とともに進化しています。 Openflowプロトコルの現在のバージョンは1.5.1です。

Openflowは、SDNコントローラーとネットワーク機器（通常はスイッチ）間の通信の標準仕様を提供するプロトコルです。これにより、SDNコントローラーがルーティングの決定を下し、転送ルール、セキュリティルールが基盤となるネットワークのスイッチにプッシュされるようになります。

SDNコントローラーとスイッチは、Openflowメッセージの共通言語を理解できるように、Openflow仕様を実装する必要があります。ネットワークスイッチを制御するために、SDNコントローラーはルールをスイッチにプッシュして、ネットワークトラフィックがスイッチに到達したときにスイッチが決定できるようにします。スイッチは、Openflowテーブルでそのようなルールを維持する必要があります。 Openflowによると、このようなルールは「フロー」と呼ばれ、「フローテーブル」に保存されます。

大まかに言って、フローには3種類の情報が含まれています。

1. 一致フィールド：ヘッダーフィールド（送信元宛先イーサネットアドレス、VLAN ID、VLAN優先度など）、L3（IPv4 / IPv6送信元宛先アドレス、プロトコルタイプ、DSCPなど）、L4フィールド（TCP / UDP / SCTP送信元宛先ポート）、ARPフィールド、ICMPフィールド、MPLSフィールドなど。
2. アクション：パケットが基準に一致した場合、パケットをどう処理するかを定義します。アクションには、ドロップ、スイッチの一部のポートでの転送、パケットの変更（VLAN IDのプッシュ/ポップ、MPLSラベルのプッシュ/ポップ、IP TTLのインクリメント/デクリメント）、ポートの特定のキューへの転送などがあります。
3. カウンター：フローに一致したパケットの数を追跡するため

具体的には、フローには、Openflowの仕様でさらに確認できるいくつかの情報が含まれています。

Openflowチャネルまたは接続は、コントローラーがスイッチと通信してスイッチを構成、管理、監視できるようにするための、スイッチとコントローラー間のセットアップです。 Openflowの仕様に従い、OpenflowはTCPまたはTLS接続で実行され、コントローラーは6653ポートで接続をリッスンします。スイッチは接続を開始することが期待されており、接続要求をコントローラーに送信する必要があります。

オプションで、接続をコントローラー側から開始することもできます。この場合、スイッチはパッシブモードになり、接続をリッスンします。どちらの側から見ても、通常のTCPまたはTLS接続の設定になります。確立されると、OpenflowメッセージはTCPまたはTLS接続を介して交換されます。たとえば、以下は、コントローラーとのTCP接続を開始するためのオープンソースのOpenflow仮想スイッチ（OpenVswitch）のコマンドです。

ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653

ここで、192.168.56.101はコントローラーIPであり、6653は接続をリッスンするコントローラーポートです。

Openflowは、接続設定メッセージ、構成メッセージ、スイッチ統計メッセージの取得、キープアライブメッセージ、非同期イベントメッセージ、エラーメッセージ、実験者メッセージなど、スイッチとコントローラー間の通信を可能にするさまざまなメッセージを定義します。

Openflowメッセージについて簡単に理解しましょう：

• TCP接続が確立されると、Openflow HELLOメッセージが両方のエンティティ間で交換され、さらに通信が行われるOpenflowバージョンがネゴシエートされます。スイッチとコントローラーが異なるOpenflowバージョンで実行されている可能性があるため、これが必要です。どちらも、サポートされている最高のバージョンに同意します。
• バージョンネゴシエーションが完了した後、コントローラーは最初にOpenflow機能リクエストメッセージを送信して、主にスイッチのデータパスIDを応答メッセージで取得し、スイッチがサポートする機能を決定します。
• ネットワークトラフィックを処理するようにスイッチを構成するために、フローエントリなどのOpenflowメッセージをコントローラーから送信できます。これらは、スイッチ内のフローテーブルで維持されます。
• フローエントリをグループ化するために、スイッチ内のグループテーブルに保存できるグループメッセージを介してコントローラーによってグループを構成できます。
• スイッチから統計情報の詳細を取得するには、フロー統計、ポート統計、キュー統計、グループ統計、テーブル統計などのOpenflowメッセージをコントローラーから送信できます。
• 接続の有効性を確認するために、リクエストと返信をエコーするOpenflowメッセージをコントローラーまたはスイッチから送信できます。
• スイッチからのフロールールの削除、スイッチからの構成適用失敗エラー、スイッチからのポートのアップ/ダウンステータスなどの非同期Openflowメッセージを、スイッチからアップデートコントローラに送信できます。

これまで、SDNアーキテクチャ、そのレイヤー、Openflowの役割を確認して、コントロールプレーンをデータプレーンから分離するSDNコアの原則を実現してきました。次に、コントローラーがOpenflowを使用して、基盤となるネットワークを構成および管理する方法を確認する必要があります。

基本的に、コントローラーは、Openflowのプラグインコードを実装する必要があります。これにより、基盤となるネットワークのOpenflowスイッチとの間でOpenflowメッセージを送受信し、理解することができます。

Openflowスイッチを構成するには、コントローラーはフロールールをスイッチのOpenflowテーブルにプッシュする必要があります。これに基づいて、スイッチはスイッチに到達するネットワークトラフィックを処理できます。フローエントリのOpenflowメッセージには、ネットワークからのパケットの一致基準（L2、L3、L4フィールドなど）用の多数のタプルフィールドのセットがあります。これは、ACLルール、セキュリティポリシールール、QoSレート制限帯域幅ルールの構成に役立ちます。ルーティングルール、ポートミラーリングルール、およびパケット変更ルール。

Openflowスイッチを監視するために、Openflowは、スイッチとネットワークの統計情報を取得するためのさまざまなリクエストメッセージと応答メッセージ、およびフロー削除イベント、ポートステータスのUP / DOWN変更など、スイッチ側で発生した手動の変更または障害に関するコントローラーを更新するイベントメッセージを提供します。

Openflowスイッチでベンダー固有のタスクを実行するために、Openflowは実験的なメッセージを提供します。ベンダーは、メッセージ本文を定義し、コントローラーとスイッチの間でカスタム情報を自由に交換できます。このようにして、Openflowは多くのSDNアプリケーションで使用され、ネットワークの制御と管理を容易にするソリューションを提供しています。

This article is co-authored by Tarun Thakur.

参照：

• https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/
• https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
• http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/