SDNプロジェクト「OpenDaylight」がもたらすインパクト、期待できること：OpenStack Summit 2015 Tokyo（2/3 ページ）

2013年2月に発足したOpenDaylightプロジェクトは、当初のイメージとは大幅に異なる側面を持つ活動に発展しつつある。OpenStack Summit 2015 Tokyoを機に、OpenDaylightシニアテクニカルディレクターのフィル・ロブ（Phil Robb）氏、およびOpenDaylightアンバサダーである、NEC スマートネットワーク事業部 主席技術主幹の工藤雅司氏に聞いた。

[三木 泉，＠IT]

OpenDaylightにおける現在の最重要テーマは「成熟」

――ロブさんはプレゼンテーションで、OpenDaylightはOpenStackのDiabloリリース（2011年9月に提供開始されたOpenStackの4番目のリリース）に似た段階にあると言いましたね。あらためてOpenDaylightがどれくらいの成熟度にあるかをお聞かせください。

ロブ氏　「成熟」は、私たちが現在注力しているポイントです。私たちは、プロジェクトとしての成熟度を高める努力を続けています。

　まず、前回、今回のリリースでは、ドキュメント整備に力を入れています。また、気軽に質問ができるような環境づくりを進めています。

　OpenDaylightにおいて、プロジェクトはまずインキュベーション段階に属し、一定の条件を満たせば「成熟プロジェクト（Mature Project）」に昇格します。そのうち、OpenDaylightプロジェクト全体に欠かせない役割を果たすなら「コアプロジェクト（Core Project）」となり、あらゆるプロジェクトが下にくるような大きなプロジェクトになれば、「トップレベルプロジェクト（Top Level Project）」と呼びます。

　OpenDaylightには現在58プロジェクトありますが、全てインキュベーション段階です。現在これらの成熟度向上に非常に力を入れていて、今年中には、少なくとも数個のプロジェクトが成熟プロジェクトに昇格するでしょう。

2015年6月に提供開始されたOpenDaylightの3番目のリリース、Lithiumの構成要素

　私たちはまだまだ若いプロジェクトです。一方で、商用ベンダーは対象を絞り、詳細な検証を行い、これを顧客に提供しています。彼らの製品は非常に強力で成熟しています。それは、オープンソースを補うコードを提供しているからです。今後OpenDaylightプロジェクト内でアップストリームの活動がさらに進めば、ベンダーが独自にやらなければならないことは減りますし、ユーザーにとっても、ベンダーなしに構築を進めやすくなります。これがオープンソースプロジェクトの常です。OpenStackも、Linuxも、同じ道を歩んできました。

　OpenDaylightは、発足から2年半経ち、多数の強力なプロジェクトを擁し、これらのプロジェクトの相互連携を可能にする強力なプロセスを有しています。次のステップは、それぞれのプロジェクトを成熟段階に持っていくことです。

Northboundインターフェースという課題にどう取り組むか

――NorthboundインターフェースはSDNコントローラーにおける大きな課題であり続けてきました。Open Networking Foundation（ONF）でも標準化に取り組んでいますが、成果は未知数です。OpenDaylightが、これにどうアプローチしているのかを聞かせてください。

ロブ氏　いくつかの観点から説明させてください。

　まず、OpenDaylightはマイクロサービスアーキテクチャに基づいています。これを実現しているのがMD-SALです。これを通じ、OpenDaylightの各コンポーネントは、他のコンポーネントに対し、何を提供できるのかを自ら記述できます。この場合のコンポーネントは、Southboundプラグインへのインターフェースでも、レイヤー2スイッチへのVLANインターフェースでも、何でも構いません。

　コンポーネントの機能は、YANGモデルで定義されます。定義されると、YANGツールセットがこれをAPIに変換し、コンポーネントはこのAPIを通じて、NorthboundにもSouthboundにも、サービスを提供できます。さらに、共通のデータストアと非同期イベント通知により、他のサービスに対して、あなたの側に何らかの変更やイベントが発生したことを知らせることができます。

　ケーブルテレビ業界で研究開発を行う非営利団体であるCableLabsは、OpenDaylightを使って、OpenFlowによるフロー制御と合わせ、セットトップボックスの管理をしたいと考えました。これは典型的なSDNユースケースとはいえませんが……（笑）。それでも、SDNコントローラーからノードが見えるようになるのですから、管理したいと考えたわけです。OpenDaylightコントローラーの使い方としては、そもそもの目的とは違いますから普通ではありませんが、それが彼らのニーズだったのです。

OpenDaylightシニアテクニカルディレクターのフィル・ロブ氏（左）と、OpenDaylightアンバサダーである、NECの工藤雅司氏（右）

　CableLabsは、自身のニーズに合うようなSouthboundプロトコル制御用のAPIセットを作り出しました。彼らは現在、二つの事業者のネットワークで、これを導入しようとしています。CableLabsはこのため、OpenDaylightの委員会メンバーとして、活発に活動しています。つまり、NorthboundでもSouthboundでも、OpenDaylightは柔軟に拡張できます。

　Northboundについては抽象化という意味でも重要な役割を持ちます。ネットワークをプログラムできたとしても、フローベースのレベルでしかプログラムできないのであれば、あまり状況は改善していません。これではアセンブラ言語のようなものです。もっと高いレイヤーでコーディングできれば、はるかに効率は高まります。

　ONFはNorthbound Interfaceワーキンググループで取り組んでいますが、これは「標準」として確立するのが非常に難しい分野です。実際にコーディングし、検証し、穴を埋めていく作業が必要です。高速に反復開発（イテレーション）を繰り返してこそ、各種のユースケースに対して意味のある抽象化が実現できます。

Northboundはニーズに応じて異なる「言語」が生まれている

――ユーザーが求める抽象化は、ユースケースによって異なりますよね。これが大きな課題だと思います。

ロブ氏　その通りです。OpenDaylightのようなプラットフォームの良さは、マイクロサービスアーキテクチャによって、さまざまな組織がNorthbound、Southboundのインターフェースを自ら構築することもできます。また、同一のSouthboundインターフェースを共用する各種Northboundインターフェースの構築と検証が、迅速にできます。

　OpenDaylightにおけるNorthboundの取り組みとしては、五つの「言語」が開発中です。

1. シスコシステムズの仕事が基になり、現在は多数が参加している「Group Based Policy」
2. ONFのNorthbound Interfaceの実装を進めている「Network Intent Composition」
3. 特に通信事業者のユースケースをカバーする新プロジェクトの「NEMO（NEtwork Modeling）」
4. こちらも通信事業者が参加する既存プロジェクトの「ALTO（Application-Layer Traffic Optimization）」
5. ALTOと同様エール大学で開始されたものの、知的財産権上の問題でプロジェクトには至っていない「Maple」

　これらのプロジェクトの間には共通性が見られる部分もあり、今後統合や淘汰が考えられます。しかし、今は何よりも高速なイテレーションが必要です。各プロジェクトで、アプリケーションを作ってみて、必要な修正や機能強化を行うプロセスを繰り返しながら、必要に応じてプロジェクト間の統合が進むでしょう。今述べたNorthboundインターフェースのプロジェクトは全てインキュベーション段階ですので、これは健全なプロセスです。