Tech Sketch Bucket of Technical Chips by TIS Inc.

OpenDaylightアプリケーションの作り方 (MD-SAL)

Pocket

前回の記事 では、OpenDaylightの簡単な概要やアーキテクチャと、AD-SALによるOpenDaylightアプリケーションの作成方法についてお話しました。

今回は、もう一つのフレームワークであるMD-SALでのOpenDaylightアプリケーション作成方法をご紹介します。

MD-SALの考え方

Model-Driven Service Abstraction Layer(MD-SAL)とは、OpenDaylightに存在する、データの交換や変換を抽象化するフレームワークの1つです。MD-SALでは、管理対象機器の情報やトポロジなど、様々なデータをモデルとしてMD-SAL内部のデータストアに格納します。各種Serviceはこのデータストアへのデータの更新や取得を行い、データの変化によって発生する通知や、連携するServiceが発生させる通知の受信、Remote Procedure Call(RPC)の実行などによって処理を行っていきます。

SAL-Comparison.pnghttps://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:FAQ より引用)

データストアのモデル構造はYang(後述)を使用して定義します。このYangモジュールを読み込むことによって、MD-SAL内のデータストアで該当データを扱うことが可能になります。また、データを扱うJava APIがYangTools(後述)によって自動的に生成され、これを利用してアプリケーションを実装します。この他、MD-SALではデータモデルがYangによって統一的に定義される特徴を利用し、外部からデータストアに共通的な手段でアクセスできるNorthbound APIを提供しています。AD-SALでは保持するデータの形式に決まりがなく、Northbound APIは必要に応じて実装しますが、MD-SALではYangモジュールを読み込んだ時点でRESTCONF(後述)によってデータストアのデータにアクセス可能になります。

Plugin_design_process.pnghttps://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:FAQ より引用)

MD-SALの特徴をまとめると、以下のようになります。

  • MD-SALには、Yangによる統一的なデータモデルを持ったデータストアが存在する
  • サービスの連携や処理は、データストアへのデータアクセスや通知の送受信などを中心に進む
  • RESTCONFによる共通的なNorthbound APIが提供される
  • アプリケーションから利用するデータアクセスAPIはYangToolsを利用して自動生成する

AD-SALとの違いは様々な点で存在しますが、一言で述べるとすれば、モデルを介して連携することで、MD-SALのほうがよりサービス間の結合を弱め、より管理対象の機器を抽象化できるものであると考えられます。

YangとNETCONF、RESTCONF

Yangとは、NETCONFのRPC、通知、状態操作、データストア内のデータ構造を定義するデータモデリング言語です。YangはRFC 6020で規定されており、RFC 6991(Common YANG Data Types)など、関連する仕様がいくつか存在します。YangToolsは、このNETCONFとYangを用いてJavaで開発を行うためのツール、ライブラリ群です。NETCONFはIETFによって標準化されたネットワーク管理プロトコルであり、ネットワーク管理システムから管理対象装置への設定情報の投入と操作、削除の仕組みや、その対象となるデータストアの定義を提供します。NETCONFはRFC 4741でベースプロトコルと、その他いくつかの関連仕様から成ります。また、RESTCONFは、HTTPプロトコルを利用し、Yangで定義されたデータが保持されるデータストアにREST形式でアクセスするためのプロトコルであり、まだドラフト段階の仕様です。

MD-SALによるOpenDaylightアプリケーションの作成

ここまでで、MD-SALを構成する要素と、簡単なアーキテクチャの説明を行いました。それでは次に、MD-SALを利用したOpenDaylightアプリケーションの作成手順と例を見てみます。

開発環境

MD-SALを利用しても、OpenDaylightアプリケーションに変わりはないため、開発環境としてはAD-SALと同様、EclipseとMavenを利用します。また、最終的に生成する必要があるものもAD-SALと同様、OSGi Bundleですが、Yangモジュールと生成したAPIを格納したBundleと、それを利用したServiceの本体であるBundleの2種類を生成する点でAD-SALと少し異なります。

HelloWorld

前回はAD-SALでレイヤ2スイッチを実装しましたので、今回は同等のアプリケーションをMD-SALで実装してみます。具体的にはMACアドレスの学習テーブルをYangモジュールとして格納したBundleと、PACKET-INイベントでMACアドレスとポートの対応をデータストアに保存し、Flowを生成して対象スイッチにFlowを設定するようなBundleを作成し、OpenDaylightのOSGi Frameworkにロードして実行します。対象とするスイッチは、MD-SALで対応するOpenFlow1.3のスイッチです(※)。本記事にはソースコードの抜粋のみ記載しますが、今回使用するソースコード全体は以下に配置してありますので、適宜参照下さい。
HelloWorld ソースコード

※今回利用しているmininetではOpen vSwitch 1.9.0 がOpenFlowスイッチとして利用されていますが、これはOpenFlow1.3に完全準拠していません。そのため、本来OpenFlow1.3では明示的にtable-miss Flowエントリをスイッチに設定しなければPACKET-INは通知されないはずですが、table-miss Flowエントリが認識されず、PACKET-INは1つもFlowの条件に一致しなかった場合に発生してしまいます。このような理由から、今回の例ではスイッチの接続を認識した時点でのProactiveなflow-modは行いません。

今回のOpenDaylightアプリケーション作成の流れの概要は、以下のとおりです。

  1. Yangモジュール側Bundleの作成
    1. YangでスイッチとMACアドレスの組とポートが対応したモデルを記述
    2. YangToolsでソースコードを自動生成し、Bundleを作成
  2. Service側Bundleの作成
    1. Activatorにて、HelloWorldで利用する他のサービスの定義や、パケット受信時のコールバック登録
    2. HelloWorldにてFlooding、Forwardingなどのパケット処理と、データストアへのMACアドレス学習エントリやFlow設定を実装し、Bundleを作成

まず、Yangモジュール側から作成します。モデルが依存しているデータタイプや、YangToolsをdependencyとして記述します。また、MavenによってYangToolsを実行してソースコードを自動生成させるため、buildにその内容を記述します。
■pom.xml(抜粋:dependencies)

■pom.xml(抜粋:build)

■pom.xml(抜粋:build)

次に、Yangモジュールを記述します。
■mac-port.yang(抜粋)

記述が完了したら、Maven InstallでBundleを作成します。Yangモジュールと、そこから生成されるJavaソースのマッピングについては、以下に詳細が記載されていますので、適宜参照下さい。
https://wiki.opendaylight.org/view/YANG_Tools:YANG_to_Java_Mapping

今度はService側の作成です。まずはpom.xmlの作成ですが、内容の構成はAD-SALの時とさほど変わらず、利用するライブラリが異なります。記述の際は、作成したYangモジュールを忘れずに含めましょう。
■pom.xml(抜粋:dependency)

次にActivatorを実装します。AD-SALではComponentActivatorAbstractBaseを継承してActivatorを作成しましたが、MD-SALを通してデータ交換を行うServiceのActivatorは、その特性によってConsumerまたはProviderのどちらかとなり、それによって継承するクラスが異なります。

Providerとは以下の操作を行うものを指し、AbstractBindingAwareProviderを継承します。

  • 通知を発行する
  • RPCを実装し、Consumerから呼び出される
  • MD-SALのデータストアにデータを書き込む

また、以下の操作を行うものはConsumerに該当し、AbstractBindingAwareConsumerを継承します。

  • 通知を受け取る
  • RPCをコールする
  • MD-SALのデータストアからデータを読み込む
  • (必要に応じて)通知を発行する
  • (必要に応じて)RPCを実装し、Consumerから呼び出される
  • (必要に応じて)MD-SALのデータストアにデータを書き込む

今回は通知を受け取り、MD-SALのデータストアにMACアドレスやFlowを書き込むことから、AbstractBindingAwareConsumerを継承します。また、初期化処理はonSessionInitializedをオーバーライドして実装します。

■Activator.java(抜粋:クラス定義)

SALからの利用サービスの取得や、コールバックの設定も行います。データストアへのアクセスはDataBrokerServiceを利用し、通知受信にはNotificationServiceを利用します。また、パケット転送などを行うにはPacketProcessingServiceを利用します。
■Activator.java(抜粋:利用サービス定義)

Activatorの次は、Serviceを実装します。ここでは説明の簡略化のため、細かくモジュール分けをせずに必要な処理を記述しています。処理の流れとしてはAD-SALとほぼ変わりませんが、処理を行うための手続きがMD-SAL固有のものになります。最も異なるのは、MACアドレスの学習やFlowの登録時、MD-SALのデータストアにデータを書き込む点です。Yangのデータモデルはツリー構造になっており、MD-SALのデータストアも同様であるため、ツリーの中でデータの位置を特定できるInstanceIdentifierを指定してアクセスします。データを生成する際は、各データモデル用のBuilderクラスがYangToolsによって自動生成されるため、これを利用していきます。

■HelloWorld.java(抜粋:MACアドレス学習テーブルの取得)

■HelloWorld.java(抜粋:InstanceIdentifierの作成)

■HelloWorld.java(抜粋:MACアドレス学習テーブルエントリの作成)

Flowをスイッチに設定するには、Flowのデータをデータストアに書き込みます。これによりデータ変更通知がForwardingRulesManagerに届き、そこからRPCでSouthboundを経由して、スイッチへFlowが書き込まれます。

■HelloWorld.java(抜粋:Flowの設定)

記述が完了したら、Maven InstallでBundleを作成しましょう。

コンソールからの動作確認

OpenDaylight Hydrogen Base Editionの起動

OpenDaylightは現在も開発が進んでいますが、今回も、Hydrogenでの動作を行うことにします。前回と異なる点として、実行時にオプション(-of13)を指定します。これはOpenFlow1.3への対応を明示するもので、ロードされるモジュールが異なります。

■実行

ネットワーク環境の準備

今回も前回と同じくmininetを利用しますが、OpenDaylightと同様に、こちらにもオプションを指定して起動します。今回は単純にスイッチを1つにして、2つのホスト間の疎通を確認する構成とします。

■Mininet起動

この時点で、画面上にはスイッチが1つ表示されます。

ODL_MDSAL_1.png

HelloWorldのロードと実行

作成した2つのOSGi Bundleを、OSGi Frameworkにロードし、開始してみます。なお、今回も実行前にはSimpleForwarding、LoadBalancer、ARPHandlerは停止させておいてください。

■SimpleForwarding、LoadBalancer、ARPHandlerの停止と、HelloWorld_Model、HelloWorld_Implの実行

HelloWorldが起動状態になりました。MD-SALはYangModelを読み込むと、RESTCONFによってデータストアにアクセスできるようになると説明しましたが、この時点でデータストアがどうなっているか確認してみます。想定としては、学習したMACアドレスとFlowは存在しないはずです。

■データストアの確認(ping実行前)

正しくアクセスできることが確認できました。内容も、想定どおり空になっています。次に、この状態でスイッチのFlow(テーブル0)に何も設定されていないことを確認します。想定としては、ここにも何も設定されていないはずです。

■Flow設定確認(ping実行前)

想定どおり、ping前は、スイッチにはFlowは存在しません。では、pingを実行してみましょう。

■ping実行

正しくpingが通ることが確認できました。それでは、データストアを確認してみます。先程は空でしたが、今度は学習したMACアドレスと、登録したFlowが確認できるはずです。

■データストアの確認(ping実行後)

データストアに正しく値が登録されていることが確認できました。最後に、スイッチのFlowを確認します。

■Flow設定確認(ping実行後)

スイッチのFlowも正しく設定されていることが確認できました。

まとめ

少し時間が空いてしまいましたが、前回に引き続き、今回はMD-SALによる簡単なOpenDaylightアプリケーションの作成の仕方を説明しました。 OpenDaylightのWiki には、各ServiceについてのAD-SALからMD-SALへの移行プランが記されており、今後のServiceはMD-SALを利用したものが中心になっていく事が伺えます。OpenDaylightは2014年9月29日に次期バージョンであるHeliumのリリースが予定されていますが、今後も変更点を追いつつ、機能を試していく予定です。

エンジニア採用中!私たちと一緒に働いてみませんか?