Architecture

openNaEFをシステムとして利用する際の全体構成と

各サブシステムについて説明します

OPEN

NETWORK

A*

Engineering

Framework

OpenNaEF World

OpenNaEFは、Coreと呼ばれる2次元時間軸を持つネットワークトポロジオブジェクトストアを中心に、各種のOperation Interface(API)やActivationモジュール、Discoveryモジュール、InventoryViewアプリケーション、TopologyViewアプリケーションなどからなります

OpenNaEF core

ネットワーク技術 (VLAN, MPLS, DCE/DCB, WDM 等) のロジックを実装し、これらの技術を用いたネットワーク構成の把握・更新を容易にするフレームワーク。以下の機能を持つ。

  • 装置物理構成

  • 装置論理構成 (ポート、VLAN, MPLS, VRF, VPN, WDM etc.

  • ​​ネットワーク構成 (VLAN, VPLS 等のトポロジ管理, WDM リングおよび波長管理等)

  • マルチレイヤ管理 (プロトコルレイヤ階層を表現。ファイバ上の WDM 上の VLAN 上の VRF 上の VPN サービス等)

  • サービス管理 (契約情報と装置物理情報・装置論理情報・ネットワーク構成の結びつけ)

OpenNaEF Operation Interfaces

OpenNaEFには操作するための様々な操作インターフェースを備えています。

1.) OpenNaEF Shell 

2.)Javaで利用するDTOオブジェクトインターフェース、Bulder オブジェクトインターフェース

3.)Restにて扱うためのRestfuiAPI

4.)OpenNaEFオブジェクトストアに生じた変更を通知するインターフェース

​

​

OpenNaEF Shell

OpenNaEF Shellインターフェースを用いることで、コマンドラインからネットワークモデルを操作することができます。

Data transfer object --DTO

DTOとは

 

  • JavaにてNaEFアプリケーションを開発する際に利用するインターフェースです

  • NAEFオブジェクトの外部提示用オブジェクトです。

  • NAEFオブジェクトの属性値のマップを保持してます。

    • すべての属性値は適切なkeyを与えることで取得できます。

    • 便利のために、単なるgetメソッドをラップした特定属性専用メソッドが用意されているクラスもあります。

    • 詳細な仕様はDTO仕様を参照のこと（Wikiへのリンク）。

  • 他のNAEFオブジェクトへの関連は、同等の他のDTOへの参照オブジェクトとして保持しています。このためネットワークのグラフ構造のトラバース​（追跡）を容易にします。

​

DTOが必要な理由

  • NAEFの内部オブジェクトの大半は他のオブジェクトへの参照を持っている。そのため普通にシリアライズするとほとんど全てのオブジェクトが芋づる式に引き出されてしまいます。そこで内部オブジェクト表現 (MVO形式) とは異なる、DTO (Data Transfer Object) 形式で情報を外部に提示し、他のオブジェクトへの関連は、直接保持せず、他のオブジェクトへのDTO参照形式で保持しています。

​

遅延初期化

  • 属性値はDTO生成時に初期化されず、DTOへの属性アクセス時にはじめて初期化され、以後キャッシュされます

更新

  • renewを実行することで、NAEFの最新情報を反映することができます。

Builder interface

そこでBuilderはコマンド操作を隠蔽し、必須属性の存在チェックや内容チェックを自動的に実行してデータ構造の一貫性を保つサービスを提供している。

ビルダーを用いることにより、NaEF applicationのカスタマイズを実施するプログラマーは、NaEFの内部構造やコマンドの詳細な構文を知ることなしに、インベントリに対して必要な操作を実施することができる。

 

コマンドビルダーの実行

コマンドビルダーは1つのトランザクションで実行される。

複数のコマンドビルダーを順次、1つのトランザクションで実行することができる。

InventoryBuilder#execute系のメソッドを参照のこと。

1つのアプリケーションインスタンス内では、トランザクションの実行は直列化されることが保証される。すなわちInventoryBuilder#execute系メソッドはすべてsynchronizedでインスタンス単位で直列化されることが保証されている。

複数のアプリケーションインスタンスが存在していて、各アプリケーションインスタンスで独立に更新が発生した場合には、NAEF上ではトランザクション実行は並列実行となる。

​

通常コマンドビルダー

(Command Builder)

ユーザないし外部システム契機で、インベントリに対して追加変更削除を行うビルダーである。ユーザ操作や差分反映によりインベントリの内容としてある特定の内容を設定しあるいは変更、削除したいという場合に用いる。

 

通常ビルダーといえばこのビルダーを指す。

 

補完トランザクションビルダー

(Complemental Transaction Builder)

システムないしアプリケーションのデータ一貫性を保つために、通常コマンドビルダーに付随して実行されるビルダーが補完トランザクションビルダーである。

  1. 補完トランザクションビルダーの例として以下のものがある。

    1. VRF自動設計

    2. ノード間自動同期

    3. vlan-linkの自動メンテナンス

  2. 補完トランザクションビルダーは通常インベントリ更新トリガー契機で実行される。

  3. 補完トランザクションビルダーを、トリガー契機ではなく、たとえば定期実行契機で実行することもできる。いつ起動するかは開発者が任意に決定する。

​

動的コマンドビルダー

(Conditional Command Builder)

トランザクション実行時にコマンドを組み立てるビルダーである。

​

動的コマンドビルダーは随時コマンドの再評価を行うことができる。InventoryBuilder#execute系メソッド内で再評価を強制的に実行する。従って実行時点で何らかの変更が編集対象に加わっていたとしても、その影響を軽減ないし解消して適切なコマンドを生成することができる。影響を吸収できないくらい大きな変更が発生していた場合にはエラーとなる (編集対象ポートが存在しない等)。

​

現時点でサポートされている動的コマンドビルダーは以下の通り。

  1. VPLS系コマンドビルダー 

  2. VRF系コマンドビルダー

​

OpenNaEF Rest API

NaEF オブジェクトストア内のエンティティ毎のCRUD操作を提供するRestful APIです

Notification interface

NAEFサービスは外部通知の機能を持つ。

  • トランザクションがコミットされると、そのトランザクションで発生したオブジェクトの変更をひとまとめにしたDtoChangesオブジェクトが配信される。

    • DtoChangesオブジェクトには以下の2種類の情報が含まれる。

      • 新規に作成されたオブジェクト

      • 内容が変更されたオブジェクト

        • 削除も内容変更として扱われる。

  • DtoChangesから新規追加オブジェクトを取得することができる。

  • DtoChangesから変更オブジェクトと変更内容を取得することができる。

OpenNaEF Application

inventory.web

inventory.WebアプリケーションはNaEFネットワークオブジェクトストアに格納されている情報をWEBアプリケーションとして参照更新可能なUIを提供します。

topology.viewer 

Topology.view　アプリケーションはNaEFネットワークオブジェクトストアに格納されているトポロジ状態をレイヤ毎のトポロジとして表示可能なアプリケーションです。

TOSS(testbed operation support system)

TOSSシステムは、沖縄オープンラボテストベッドにて利用されているテストベッド予約、自動設定システムです。詳しくは一般社団法人沖縄オープンラボラトリ（https://www.okinawaopenlabs.org/）にて紹介する予定です。TOSSのソースコードは、沖縄オープンラボのGitHub（https://github.com/oolorg）にて公開予定です。

OpenNaEF Activation

NaEFScript

　モデル変更点を複数の意味的に完結する断片に分解し (assemble), その断片に対応したConfig生成テンプレートを掛け合わせ、Configフラグメントを生成します。さらにConfig fragmentを必要な単位で合成し (composition), 最終的な Config 全体を生成することができます. この機能は、従来型のネットワーク装置のConfigをマルチベンダー・マルチテクノロジーで生成するための特徴的な機能となっています。

　また、SDNのテクノロジにおいてはOverlayの要求からUnderlay を生成し、OpenFlowやdetaplaneAPIを操作する要求を生成することも可能です。

OpenNaEF Discovery

Discoveryサービスでは実際の構成を検出する処理を、SSH,telnet,SNMP,netconf,restapi等で取得した情報からNaEFモデルを生成します。

実機や実ネットワークとNaEFオブジェクトモデルの不一致を検出し、モデルまたは実機を変更して差異を発見し適用することが可能です。

OpenNaEF WorkBench

OpenNaEFをワークフローベースで操作するアプリケーションです。DiscoveryやActivationなどのサブシステムを作成したワークフローによって操作することが可能です。