[論文レビュー] tinyNBI: Distilling an API from essential OpenFlow abstractions

C. Jasson Casey, Andrew M. Sutton+1 more|arXiv (Cornell University)|Mar 26, 2014

Software-Defined Networks and 5G参考文献 4被引用数 4

ひとこと要約

本論文では、5つのOpenFlowバージョンからコアとなるOpenFlowの抽象化を抽出し、洗練された低レベルC APIにした、最小限でバージョンに依存しないNorthbound Interface（NBI）であるtinyNBIを提案する。バージョン固有の複雑さを抽象化することで、さまざまなスイッチにおけるフローテーブル、マッチ、アクション、インストラクションの信頼性の高いポータブルな設定を可能にし、SDN開発者の開発の複雑さを軽減し、保守性を向上させる。

ABSTRACT

If simplicity is a key strategy for success as a network protocol OpenFlow is not winning. At its core OpenFlow presents a simple idea, which is a network switch data plane abstraction along with a control protocol for manipulating that abstraction. The result of this idea has been far from simple: a new version released each year, five active versions, com- plex feature dependencies, unstable version negotiation, lack of state machine definition, etc. This complexity represents roadblocks for network, software, and hardware engineers. We have distilled the core abstractions present in 5 existing versions of OpenFlow and refactored them into a simple API called tinyNBI. Our work does not provide high-level network abstractions (address pools, VPN maps, etc.), instead it focuses on providing a clean low level interface that supports the development of these higher layer abstractions. The goal of tinyNBI is to allow configuration of all existing OpenFlow abstractions without having to deal with the unique personalities of each version of OpenFlow or their level of support in target switches.

研究の動機と目的

• OpenFlowにおける増大する複雑さとバージョンの分断を解消し、開発者がプロトコルおよびスイッチの差異を管理することに負担を負わせないため。
• すべてのバージョンに共通する基本的なOpenFlow抽象化のみを露わにする、最小限で安定したAPIを設計するため。
• アプリケーションの論理をOpenFlowバージョンの差異やスイッチ固有の機能サポートから分離するため。
• 異種のOpenFlowスイッチ間で、フローテーブル、アクション、マッチ、インストラクションの信頼性の高いポータブルな設定を可能にするため。
• 低レベルのプロトコルの複雑さを再実装せずに、高レベルのネットワーク抽象化を構築する基盤を提供するため。

提案手法

• 著者らは、OpenFlowバージョン1.0から1.3.1までの5つのバージョンからコアとなる抽象化を抽出し、データパス、フローテーブル、マッチ、アクション、インストラクション、ポート、グループ、キュー、メーターといった共通するプリミティブを同定した。
• 構造化されたデータ型（例：ofp_flow）を用いてマッチとインストラクションのセットを束縛する、スイッチに依存しないモデルを採用したCベースのAPIを設計した。
• 構成関数（例：ofp_add, ofp_del, ofp_build_match, ofp_build_action, ofp_build_instruction）を少数の関数として提供し、スイッチ構成の構築と管理を可能にした。
• 機能宣言を要件を通じてサポートし、アプリケーションが実行前に必要なプリミティブと機能を宣言できるようにした。
• 実験者拡張はバイナリデータブロックを介して処理し、ベンダーサイドメッセージの選択子としてOFP_EXTENSIONを用いた。
• 標準化された操作（例：ofp_get, ofp_stats）を通じて、照会、構成、統計取得を可能にし、スイッチ間で一貫したインタラクションを確保した。

実験結果

リサーチクエスチョン

• RQ1 複数のOpenFlowバージョンのコア抽象化を抽象化する最小限でバージョンに依存しないAPIをどのように設計できるか？
• RQ2 すべてのOpenFlow 1.xバージョンに共通するコア抽象化は何か？ そして、SDNアプリケーション開発の安定した基盤として機能できるか？
• RQ3 OpenFlowスイッチにおけるバージョン固有の機能サポートやネゴシエーションの複雑さから、アプリケーション開発者をどのように保護できるか？
• RQ4 低レベルNBIにより、スイッチタイプやOpenFlowバージョンごとに複数のアプリケーションバリアントを必要としなくなるか？
• RQ5 簡素化され、ポータブルなAPI内で、実験者拡張をどのように一貫してサポートできるか？

主な発見

• tinyNBIは、5つのOpenFlowバージョンから本質的なOpenFlow抽象化を1つの一貫性のあるC APIに抽象化し、アプリケーション内でのバージョン固有の論理を排除した。
• マッチとインストラクションのセットを束縛する構造化されたデータ型（例：ofp_flow）を通じてフローテーブルの構成が可能になり、フローのインストールおよび削除が簡素化された。
• アプリケーションは事前に必要な機能と能力を宣言できるため、実行前に互換性を保証でき、ランタイムエラーを低減した。
• バイナリデータブロックを用いた一貫性のある実験者拡張のサポートにより、検証なしにベンダー固有の機能を実装でき、抽象化を損なわずに拡張が可能になった。
• 構成、照会、統計、変更のすべての主要なOpenFlow操作が、少数で一貫性のある関数セットを通じてサポートされた。
• OpenFlowバージョニングやスイッチの差異からアプリケーションの論理を分離することで、コードの複雑さが軽減され、保守性が向上した。