1.2.3

研究開発項目①-2 「光電ハイブリッドスイッチ制御アルゴリズム」【成果の概要】光電ハイブリッドスイッチシステムプロジェクトにおいて、本研究開発項目ではディスアグリゲー
ション型次世代データセンタ向けアーキテクチャに有効なトラフィック振り分けを実現するためにトラフィック振り分けアルゴリズム及びネットワークコントローラの高速制御技術の開発を進めてきた。
本項では試作した光電ハイブリッドスイッチシステムを用いた実証・評価について報告する。
主な成果は以下の通りである。（１）ネットワークコントローラに組み込む振り分けアルゴリズム
として、サービス駆動方式とデータ駆動方式の２つのアプローチから検討を行い、光電ハイブリッド
スイッチシステムと親和性があり、分散深層学習に効果がある振り分けアルゴリズムを提案した。
（２）1000 ラック規模まで拡張可能、かつ 100 マイクロ秒で光スイッチ制御が可能な高速コントロー
ルプレーン技術を提案した。（３）多様な光部品の機能・状態・構成をコントローラから統一的に操作可能な表記法を開発した。これらの機能を、ネットワークコントローラプラットフォームのオープ
ンソースモジュールとしてその機能を実装し、光電ハイブリッドスイッチシステムとしての動作を実証した。
【最終目標】
研究開発項目⑤「光電ハイブリッドスイッチシステム実証」と連携して、FPGA を用いたコントローラのサブシステムを含めて、光電ハイブリッドスイッチシステムとしての動作確認を行い、トラフィック振り分けアルゴリズムを確立する。また、開発した成果物をオープンソースソフトウェアとして公開する。
【成果】＜光電ハイブリッドスイッチ制御アルゴリズムの課題設定とアプローチ＞
デジタル化社会を支える ICT 基盤であるデータセンタにおいて、今後予想されるデータ処理量、および通信量の増加に対応するため、データセンタにおける光ネットワーク技術への期待が高まっている。例えば、光回線スイッチは、電気パケットスイッチと比較すると、経路の切替に時間を要するという欠点がある一方で、通信帯域の増加に対して消費電力が一定であるという利点がある。そこで光スイッチと電気スイッチを相補的に組み合わせた光電ハイブリッドスイッチシステムは、通信帯域の拡張と消費電力の削減の両面から有望な技術である[1][2]。
佐藤[2]は、空間および波長ルーティングスイッチを効率的に組み合わせた大規模高速光回線スイッチアーキテクチャを提案しており、1000 ラック以上の規模のデータセンタにも適用可能なことを理論的に示している。また、多ポート化が容易であり、切替速度も 100 マイクロ秒を切る PLC（Planar Lightwave Circuit）スイッチ[3]やシリコンフォトニクススイッチ技術が実用フェーズに近づいている。
光電ハイブリッドスイッチネットワークの典型的な構成例を図 1.2.3-1 に示す。データセンタでは、サーバが収容された複数のラックが大容量・高速ネットワーク（データセンタネットワーク）を介して相互接続されている。このデータセンタネットワークは電気パケットスイッチから構成される電気
ネットワークと、光回線スイッチから構成される光ネットワークからなる。各ラックには ToR (Top ofRack)スイッチが設置され、それは光コアスイッチと電気コアスイッチ双方へのインタフェースを有- 23 -

している。
一般的にデータセンタを流れるフローには大容量だが数が少ないエレファント（elephant）フローと、小容量だが数の多いマイス（mice）フローが混在していることが知られている。光電ハイブリッ
ドスイッチネットワークでは、エレファントフローは光コアスイッチ経由で、マイスフローは電気コ
アスイッチ経由でという具合にフローの特性に応じてネットワーク経路を切り替えることで、それぞれのスイッチの利点を活かすことが可能である。なお以下では、光コアスイッチや電気コアスイッチ
等の資源管理を担い、経路切替を制御するサーバをネットワークコントローラ（図中では、以下「コントローラ」）と呼ぶ。また、ネットワークコントローラと各種スイッチを結ぶ制御ネットワークを含めてコントロールプレーンと呼ぶ。
本研究開発項目では、ネットワークコントローラに組み込む振り分けアルゴリズムを各種比較検討
し、ディスアグリゲーション型次世代データセンタ向けアーキテクチャに有効な方式を明らかにする。
またその振り分けアルゴリズムを実装するネットワークコントローラの機能概要と仕様概要を明らかにし、参照実装をオープンソースソフトウェアとして公開する。
また、1000 ラック以上の規模にもスケールし、100 マイクロ秒以下の経路切替が可能になる多ポー
ト高速光スイッチの特性を活かすためには、これを制御するコントロールプレーンのスケーラビリテ
ィ及び高速化が必須となる。そこで本研究開発項目では、産業用途のリアルタイム Ethernet 規格（IEC61158）である EtherCAT [4]を活用した高速コントロールプレーン技術を提案する[5][6]。

図 1.2.3-1 光電ハイブリッドスイッチネットワーク＜トラフィック振り分けアルゴリズムの開発＞
光電ハイブリッドスイッチネットワークの実現方式は、経路の切替点と、経路を切り替えるための制御トリガの 2 つから整理できる。経路の切替点として、エンドポイントであるサーバで切り替える
方法と、サーバラックに設置された ToR スイッチにて切り替える方法が考えられる。本研究開発項目
では、ToR スイッチとして OpenFlow [7]スイッチを用いることで、トラフィックを振り分けることを前提とする。制御トリガは、サービス駆動とデータ駆動があり、トラフィックの性質と用途に応じて使い分けることができる。サービス駆動方式は、アプリケーションが送信パケットに付与するヒント
情報（タグ）を基にフローを切り替える方式であり、プロアクティブに素早い（数十マイクロ秒）切- 24 -

替に有用である。一方、データ駆動方式は、ToR スイッチから得られた統計情報を基にフロー又はフ
ロー群を切り替える方式であり、リアクティブ制御のため、より幅広いシーンでの光スイッチ活用が可能となる。しかし、現行の OpenFlow スイッチ等の汎用スイッチを用いる場合、切替時間が課題となる。
なお、サービス駆動方式とデータ駆動方式は共存が可能であり、個別のデータセンタにおいて、サービスに応じた最適化と自律的なトラフィック最適化を両立できる。本節では、近年のデータセンタ
において主要なワークロードとなりつつある分散深層学習のトレーニングに適したサービス駆動方式のトラフィック振り分けアルゴリズムを提案する。

電気コアSW
光コアSW
コントローラ光ToR-SW

光ToR-SW②データ駆動⽅ 式①サービス駆動⽅ 式
サーバからの
光パス要求

トラフィックの
監視
輻輳検知
システム

光パス要求
コントローラ

図 1.2.3-2 2 種類のトラフィック振り分けアルゴリズム
深層学習や高性能計算シミュレーションで使われる典型的な集合通信アルゴリズムの一つに
AllReduce があり、各プロセス（サーバ）に分散されたデータの合計や最大値を求める集約演算を実行するために用いられる。分散深層学習においては AllReduce にかかる通信時間が最も支配的である。
図 1.2.3-3 に分散深層学習での AllReduce が使われる様子を示す。深層学習では学習モデルのパラメー
タ数や学習に用いるデータ量に比例して、学習モデルの性能が向上することが知られている。処理の大規模化に合わせて使用する計算サーバ数も増加の一途をたどっているが、計算サーバ数に比例して、
演 算 時 間に 対 す る 通 信時 間 が 増 加 し 、 通 信 がボ ト ル ネ ッ ク に な る 傾向 に あ る 。 し た が っ て、
AllReduce を光スイッチネットワークにオフロードすることは、性能面からも消費電力の面からも利点があると考える。

- 25 -

図 1.2.3-3 データ並列化分散深層学習の概要
AllReduce の実装方法として様々なアルゴリズムが考案されているが、プロセス間で論理リングを形成し、隣のプロセスとのみデータ交換を行うリングベース AllReduce アルゴリズムは、帯域を効率的に使うことができることが知られている。さらに論理リングは、AllReduce 実行中は不変であるため、経路切替を行う必要がない。換言すると、リングベース AllReduce アルゴリズムは、光回線ネッ
トワークと相性がよい。図 1.2.3-4 に示す例では、アプリケーション中の AllReduce の呼び出しをトリガとして、プロセス 1→プロセス 2→プロセス 4→プロセス 3→プロセス 1 と論理リングを形成し、関数終了時に論理リングを解放する。この際、各プロセス間は光スイッチを介して、光パスを確立することになる。本節では非常に単純なリングの例を示したが、計算サーバが複数の GPU を持っているなど、計算サーバ内の並列度も考慮した階層的な、より大規模なシステムに対応する手法[11]も提案したが、本報告では詳細を割愛する。
提案した AllReduce アルゴリズムの効果を、計算機シミュレータ SimGrid を用いて検証した（図1.2.3-5）。SimGrid には、MPI プログラムを実際に実行して取得したプロファイル情報を用いて、通信や演算処理をシミュレーションすることが可能であるので、今回はこの機能を用いた。なお、実環境
における実装方法は後述する。

図 1.2.3-4 リングベース AllReduce における論理リング形成。
黄色線は光スイッチ#1 経由、緑色線は光スイッチ#2 を経由するものを示す。この例では、プロセス 1→プロセス 2→プロセス 4→プロセス 3→プロセス 1 と論理リングを形成している。
- 26 -MPI Allreduce-benchmark

Targeted architecture (ABCI, Sierra)
Intra-node

SMPIInter-node
Network configuration

図 1.2.3-5 SimGrid を用いたシミュレーション実験

図 1.2.3-6

256GPU 使用時における実行時間の内訳

図 1.2.3-7 Flat ring-based Allreduce アルゴリズムの性能評価- 27 -

256 基の GPU（32 台のサーバ）を用いて ResNet50 という学習モデルのトレーニングを行なった場
合のシミュレーション結果を図 1.2.3-6 と図 1.2.3-7 に示す。HYBRID 及び HYBRID_NV が提案手法であり、NV はサーバ内の GPU 通信を高速化した場合の結果である。図 1.2.3-6 では演算時間と通信時間の比率を示している。提案手法により通信時間が削減でき、「通信／演算」比が減少していることがわかる。図 1.2.3-7 はサーバ台数を増やした場合の実行時間の変化を示している。提案アルゴリズ
ムは電気スイッチのみを使った場合にも効果があることがわかるが、ハイブリッドスイッチを用いることでさらに数パーセント実行時間を削減できる。さらに効果はサーバ台数が増えるに従って大きくなる。これは大規模化するほど電気スイッチのホップ数が増えるからである。
この結果より、光コアスイッチの切替時間が数十マイクロ秒から 100 マイクロ秒と十分短ければ、多段の電気スイッチ構成よりも高速化できることを確認できた。
＜EtherCAT を用いた光スイッチ制御＞
前節で示したように、振り分けアルゴリズムの効果を活かすためには、光スイッチ自体の高速化のみならず、光コアスイッチへ経路切替を素早く通知するコントロールプレーンの高速化が必要になる。
データセンタネットワークは Ethernet 技術に基づいて構築されることが一般的であり、コントロー
ルプレーンのために独自ネットワーク技術を導入することは、コストや運用の面から現実的ではない。
また、TCP/IP ベースの制御では数十マイクロ秒で確実な応答性能を実現するのは困難である。そこ
で、産業用途のリアルタイム Ethernet 規格（IEC61158）である EtherCAT [4]を利用する着想を得た。
EtherCAT は確実な応答性能と高精度同期性能から、半導体製造装置、工作機械といった産業用製造装置の内部通信バスや、工場内通信ネットワーク等に採用されている。
まず EtherCAT ネットワークを構成する要素について簡単に説明する。一つのネットワークセグメ
ントには一つのマスタと複数のスレーブが存在し、ネットワークのトポロジはデジーチェインやリングが一般的である。モータやアクチュエータ、シーケンサなどがスレーブとなる。概念的には、マスタとスレーブは固定長のメモリ空間を共有し、このメモリ空間はスレーブごとに分割されている。
EtherCAT におけるプログラミングは、このメモリ空間の読み書きを介して、機器を制御したり、その状態を監視したりすることになる。メモリ空間は Ethernet フレーム（以下、テレグラムと呼ぶ）にマッピングされ、マスタからスレーブに周期的に送信される。この周期を PDO (Process Data Objects)周期と呼ぶ。PDO 周期の開始時にマスタからテレグラムが送出され、テレグラムはスレーブ間をバ
ケツリレー方式で転送さる。その過程でスレーブはテレグラムに割り当てられた各自のメモリ空間を読み書きする。
提案方式では、空間スイッチや波長スイッチといった光コンポーネントにスレーブ機能を実装する
ことで、マスタからその制御を一括して行う。詳細は後述するが PDO 周期を数十マイクロ秒に設定することが可能であり、サブ 100 マイクロ秒での動作が期待できる。さらにネットワークセグメントを増やして、マスタの並列度を上げることで大規模なデータセンタネットワークにも対応可能である。
なお、現時点で EtherCAT の理論送信レートは 100 Mbps である。現時点ではギガビットイーサネッ
トへの対応もアナウンスされており、以下ではこれを EtherCAT G と呼ぶ。
続いて、EtherCAT 技術を用いて、1000 ラック以上の規模の光ネットワークに対して、100 マイクロ秒以下での経路切替が可能になるか検討する。要求に従って光パスを構築するネットワーク構成時間
CT は、各 EtherCAT スレーブでの処理時間の合計（ST）とネットワーク伝搬遅延（D）の和（CT = ST+ D）とおおよそ見積もることができる。EtherCAT スレーブの処理時間は、0.8 マイクロ秒で一定と- 28 -

仮定する。これは EtherCAT スレーブが用いている ASIC の性能を考えると妥当な値と考える。さらに各スレーブのデータサイズを 8 バイト、マスタの並列度を 16 と仮定する。ST はスレーブ数と 0.8
マイクロ秒の乗算から、D はテレグラムサイズ（ヘッダサイズ＋スレーブ数×8 バイト）とデータ転送レートの除算から求めることができる。表 1.2.3-1 に、EtherCAT と EtherCAT G におけるネットワー
ク構成時間 CT を示す。これより、100 マイクロ秒以内の構成時間の制約を満たしつつ、EtherCAT の場合で 960 スレーブ、EtherCAT G の場合で 1280 スレーブに対応できることがわかる。スレーブは 1
ラックに対応するので、本方式は 1000 ラック規模のデータセンタにも対応できると言える。

EtherCAT
EtherCAT G

表 1.2.3-1 光スイッチ制御性能の見積#slaves/masterST
DT
60
48 マイクロ秒
40 マイクロ秒
80
64 マイクロ秒
5.3 マイクロ秒

CT
88 マイクロ秒
70 マイクロ秒

EtherCAT を用いた光コアスイッチ制御の実現性を確認するために、図 1.2.3-8 に示すように 2 基の
1x2 ファイバスイッチを用いた簡単な実験系を構築した。EtherCAT マスタとしてオープンソースソフ
トウェアの SOEM (Simple Open EtherCAT Master)を、スレーブとして Microchip 社の EVB-LAN9252DIGIO 評価ボードを用いた。SOEM は C 言語のライブラリであり、Linux OS 上に SOEM を用いた単純なコントローラを実装した。EVB-LAN9252-DIGIO はデジタル I/O ピンを有しており、このピンを介して 1x2 ファイバスイッチの経路を制御する。
実験で得られたタイミングチャートの一例を図 1.2.3-9 に示す。この場合、変更要求を受信してから光スイッチの切替が完了するまで 144 マイクロ秒程度かかることがわかる。PDO 周期の開始（③）
から設定完了（④）までの時間が 73 マイクロ秒であり、この処理時間はほぼ一定である。一方で、③から④にかけての時間は、PDO 周期開始のタイミングに依存し、最悪の場合は PDO 周期分待つ必要がある。この結果より、EtherCAT を用いて光ネットワークを制御することは原理的には可能であるが、ソフトウェア実装による性能上の課題が明らかになった。具体的には、（１）PDO の最小値が200 マイクロ秒である、（２）パケット処理が遅い、という理由から、多ポート高速光スイッチの制
御に求められる時間制約とスケーラビリティを満たすためには、EtherCAT マスタのハードウェア化が必要であるとの結論に至った。

- 29 -

Network
Controller

RX

VM

EtherCAT master
Simple Open EtherCAT
Master Library

TX

Optical Switch
Controller

NIC 1

SW1

TX

RX

SOEM

SW2

100Mbps

RX
TX

3.3V to 5V
power supply
level convertor

EtherCAT slave

NIC 2

NIC 3

EVB-LAN9252-DIGIO

switch modules

図 1.2.3-8 ソフトウェアベース EtherCAT マスタを用いた実験構成

20us

73us

①

② ③ ④

⑤

図 1.2.3-9 ソフトウェアベース EtherCAT マスタ使用時の光スイッチ制御タイミングチャート例① t = 0 マイクロ秒: マスタが要求を受信、② t = 52 マイクロ秒: マスタが共有メモリへの書き込みを開始、③ t = 61 マイクロ秒: 書き込みの完了、④ t = 71 マイクロ秒: PDO 周期の開始、⑤ t = 144 マイク
ロ秒: 光スイッチの設定完了。

- 30 -

＜MEOW (Multimaster EtherCAT-based control plane for Optical netWorks)の開発＞
前節での検証を踏まえて、SoC FPGA を用いた光電ハイブリッドスイッチネットワーク向けコント
ロールプレーンである MEOW (Multimaster EtherCAT-based control plane for Optical netWorks)を提案する。MEOW は図 1.2.3-10 に示すように、ネットワークコントローラ、デバイスコントローラ、デバイ
スの 3 種類のコンポーネントから構成される。MEOW ネットワークコントローラはシステムに一つ存在し、資源管理、API サーバとして動作する。ネットワークコントローラは Northbound API として、
アプリケーション・サーバ向けに REST API を提供し、Southbound API として、スイッチ等ネットワ
ーク機器向けのインタフェースを提供する。Southbound API は電気コアスイッチと光コアスイッチごとにインタフェースが異なり、前者は OpenFlow、後者は EtherCAT を想定した独自 API を実装する。
MEOW デバイスコントローラは、図 1.2.3-11 に示すように複数の EtherCAT マスタを管理する。
EtherCAT スレーブ機能を有する光コアスイッチを MEOW デバイスと呼ぶ。本研究開発項目にて、動作検証のため開発した MEOW デバイスコントローラと 4x4 光ファイバスイッチとして機能する
MEOW デバイスの写真を図 1.2.3-12 に示す。
MEOW を ONOS (Open Network Operating System) [8]上に実装した。ONOS はソフトウェウェア定義
ネットワーク（SDN）コントローラプラットフォームのオープンソースソフトウェア実装であり、拡張可能性が高いモジュール構成を採用している。また、キャリアグレードの採用実績もあるなど実用性も高い。
さらにデバイスコントローラを Xilinx ZCU106 評価ボード上に実装した。ZCU106 評価ボードにはZynq UltraScale+マイクロプロセッサ SoC、DDR4 メモリ、FMC 拡張ポート、高速シリアルトランシーバ等が搭載されている。Zynq は Arm Cortex マイクロプロセッサとプログラマブルロジック (PL)が単一チップ上に実装されている。マルチマスタ EtherCAT 機能は PL 領域に実装した。当領域は 100
MHz で駆動し、単一チップ上に 6 つのマスタを実装している。現在の実装では、マスタ間の PDO 周
期の同期を実装していないが、原理的には同期は可能である。Petalinux 2018.3 が Arm Cortex マイク
ロプロセッサ上で動作しており、MEOW デバイスコントローラはリアルタイム性を保証するためにユーザ空間プロセスとカーネル空間リアルタイムタスクの混成として実装している。ネットワークコ
ントローラからの要求の受付処理はユーザ空間プロセスで実現し、PDO 周期での送受信処理はカー
ネル空間タスクが担っている。

- 31 -

Server

Northbound API

SDN controller (ONOS)MEOW network
controller

OpenFlow

MEOW device
controller
EtherCAT

OpenFlow

Path finder(Path lookup table)

Southbound API

Electricalswitches

Opticalswitches
ToR SW
Serverrack

図 1.2.3-10

MEOW の概要

ONOS
MEOW board

図 1.2.3-11

…

CPU

Slave

Wavelength
SW

Wavelength
SW

Slave

Slave

Wavelength
SW

Wavelength
SW…

MEOW device
controller

FPGA
MasterMasterMasterMasterMasterMasterMasterMaster

Slave

Slave

Slave

Space SW

Space SW

Slave

Slave

Space SW

Space SW

MEOW デバイスコントローラの概要- 32 -

2x2 Optical switch x 2

1x2 Optical switch x 4

EtherCAT slave(EVB-LAN9252-DIGIO)MEOW device controller

MEOW device(EK-U1-ZCU106-G-J)(4x4 Optical fibre switch)

図 1.2.3-12

MEOW デバイスコントローラと MEOW デバイスの実装例＜光部品表記法の開発＞
本システムでは、光ネットワークの構成管理や経路探索を体系的に実現するために、多様な光部品の機能を統一的かつ自動処理可能な形式で記述する FBD（Functional Block based Disaggregation）モデル[9]を採用する。FBD モデルを用いることで、光ネットワークを機能ブロック（AWG や FXC などのコンポーネント）単位でモデル化し、ネットワークコントローラやアプリケーションからの要求光パスに対し各部品の必要設定を自動計算できる。具体的には、次のように光ネットワークの設計から
経路計算までを行う。なお、FBD モデルを用いたトポロジ情報生成ツールおよびサンプルライブラ
リについて、CPPC ホームページ[10]で公開している。
（1） オープンソース CAD（KiCAD）を用いた GUI 操作（シンボルライブラリを使用）により、任意の光コンポーネントのライブラリを生成する。コンポーネント属性として、光切替機
能を GNU MathProg モデリング言語を用いた機械可読な整数線形計画問題として記述する。
これにより任意の二点間の経路を自動で計算することが可能となる。
（2） オープンソース CAD を用いた GUI 操作（回路図エディタを使用）により、（1）で生成した
光コンポーネントを任意に組み合わせた光ネットワークを設計する。開発したプラグイン
プログラムにより、設計した光ネットワークのトポロジ詳細情報を XML 形式で出力する。
（3） (1)で生成したトポロジ情報を自動解析するプログラムにより、全トランシーバペア間の経路計算を行うことで、ネットワークコントローラが利用するルックアップテーブルを生成する。
本プロジェクトで開発する光電ハイブリッドスイッチは論理的に対称な構成であるため、全要素を一度にインストールし、物理的にも対称な構成で使用する場合には、任意の経路を計算可能な FBD- 33 -

モデルのフレームワークを使用せずに、簡易なアルゴリズム（対称性を前提として for ループで制御
要素番号を回すなど）により、経路設定情報を生成することも可能である。ただし、そのような簡易なアルゴリズムを利用すると、段階的なインストールに対応できない。さらに、図 1.2.3-13 に示すような論理的に同一でも物理的に異なる接続を考慮することができない。図 1.2.3-13 に示す(a)と(b)は論
理的には同様の機能を提供するが、途中の光スイッチの接続が異なる。そのため、C1_P1 から C6_P4までの光パスを同様に設定しようとしても、(a)と(b)とでは設定すべき光スイッチポート接続が異なる。このような非対称な接続は、例えば、光デバイスのポート毎の物理特性に応じて最適な組み合わせで光ファイバコードを接続する場合に必要となる。FBD モデルを用いることで、これらの非対称なインストール状況に一律に対応可能となる。

図 1.2.3-13

光スイッチの論理接続と物理接続の関係

図 1.2.3-14

KiCAD で記述した光コンポーネント例

生成した JSON フォーマットのルックアップテーブルの一例（抜粋）を図 1.2.3-15 に示す。ルック
アップテーブルでは、始点と終点のトランシーバポートペア（図中“src”と“dst”）に対し、設定すべき光スイッチと波長の設定内容がリストで記載される。具体的には、”set-switch”において、光スイッ
チ機器を示す“id”と、各スイッチ機器で設定すべき入出力ポートペアのリストが記載される。また、“set-lambda”において、設定すべき波長制御機器（波長可変光送信器/受信機、チューナブル波長フィ
ルタなど）を示す“id”、および、設定波長を示す“lambda”、さらに、一つの機器で複数のポートを持つ場合に対応するためポートを指定する項目（図では“inport”）を含むリストが記載される。なお、
図の例では波長可変受信機を想定した光電ハイブリッドスイッチアーキテクチャの例が記載されているが、開発した光部品表記法は、波長可変光送信器、あるいは、チューナブル波長フィルタを用いた
アーキテクチャへも問題なく適用可能である。通常、データセンタ内で使用される Ethernet は双方向
- 34 -

通信であり、本プロジェクトで使用を想定する光トランシーバは２芯双方向通信が基本である。送信端からの光パスリクエストに対し、ペアとなるパスを自動で設定するために、始点終点のトランシー
バポートペアに対し、ペアとなるパス設定が“pair-config-set”として記載されている。
ルックアップテーブルでは、光パスの設定のための情報に加え、EtherCAT のコントロールプレー
ンネットワークの構成情報も記載される。これにより、光電ハイブリッド光スイッチ制御のための必要な情報がすべて一元管理できることとなる。“master-info”に EtherCAT マスタの情報がリストで記載される。リスト表記の採用により、マルチマスタの情報を不足なく記載することが可能である。
“control-info”ではスレーブ機器がリストで記載され、マスタ機器との対応を取るための情報も含まれる。

図 1.2.3-15

自動生成した JSON フォーマットのルックアップテーブルの一例（抜粋）。

左：スイッチ設定記述部。右：EtherCAT コントロールプレーン情報記述部。

- 35 -

図 1.2.3-16

光部品表記法を用いた経路制御の流れ＜MPI 通信ライブラリ支援機能の開発＞
前述した分散深層学習をはじめとして高性能計算アプリケーションなど、大規模な並列処理プログ
ラムでは MPI（Message Passing Interface）通信ライブラリがデファクトとして広く使われている。サービス駆動方式において、MPI を用いて記述されたプログラムの実行に合わせて、ONOS を経由して光パスを確立するための仕組みを実装した。MPI ライブラリとしてトラフィック振り分けアルゴリズ
ムを実装することで、アプリケーション自体を変更することなく、光電ハイブリッドスイッチネット
ワークを活用できる。
実装の概要を図 1.2.3-17 に示す。実行の流れとしては以下の通りである。
（1） 通信に参加する計算サーバのリスト（ホストリスト）と光パスのトポロジファイルを入力として、mpirun ラッパースクリプトを実行すると、request.json が生成される。なお、- 36 -

mpirun とは MPI プログラムのランチャープログラムである。
（2） mpirun ラッパースクリプトは ONOS に request.json を POST して光パスを確立する。
（3） mpirun ラッパースクリプトは mpirun を実行し、MPI プログラムを起動する。
電気ネットワークと光ネットワークへの経路の切替は ToR スイッチ（OpenFlow スイッチ）で実現する。経路の切替は、パケットに付与されたヒント情報（タグ）に基づいて行うが、ここでは ToS(Type of Service)値を用いることとする。振り分けの OpenFlow ルールはあらかじめ ToR スイッチに登録しておく。MEOW ネットワークコントローラは、経路と ToS 値の対応を管理しており、光パス確立の要求に合わせて、計算サーバに払い出されて適切に設定される。ToS 値の変更には Linux OS のiptables コマンドを利用する。
ホスト名規則: KRRRR-NNN- RRRR: ラック番号- NNN: ノード番号

mpirun wrapper
launchhostlist

topology

K0001-001
K0001-002
K0002-001
K0002-002
K0003-001
K0003-002
K0004-001
K0004-002

torus
X=8
Y=1

1

2

K0001

K0002

K0003

K0004

request.json

mpirun{"requests":[{"dir":"B","src":"K0001","dst":" K0002","user":"meowadmin","hosts":["K0001-002", "K0002-001"]},{"dir":"F","src":" K0002","dst":" K0003","user":"meowadmin","hosts":["K0002-002"]},{"dir":"F","src":" K0003","dst":" K0004","user":"meowadmin","hosts":["K0003-002"]},{"dir":"F","src":" K0004","dst":" K0001","user":"meowadmin","hosts":["K0004-002"]}
]}

ONOS

図 1.2.3-17

MEOW と MPI ランタイムとの連携動作＜システム検証実験（シングルマスタ）＞
MEOW の実現可能性を検証するために、図 1.2.3-18 に示すように、1 つのデバイスコントローラと
8 つのデバイスから構成される小規模な実験環境を用意した。MEOW デバイスとしては、＜EtherCATを用いた光スイッチ制御＞にて示した予備実験と同じく EVB-LAN9252-DIGIO 評価ボードを用いた。
MEOW デバイスコントローラと 8 つのデバイスは、Opsero OP031-1V8 EtherFMC カードを経由してカスケード接続した。
実験では、ネットワークコントローラによるパス確立リクエスト送出から、すべてのデバイスがリクエストの処理を完了するまでの経過時間を測定した。接続末尾の EVB-LAN9252-DIGIO 評価ボードのデジタル I/O ピンはオシロスコープに入力されており、この信号のアサーションを観測することで操作完了とみなす。なお、本実験では EtherCAT スレーブに光スイッチが接続されておらず、光スイ- 37 -

ッ チ 自 体の 切 替 時 間 は結 果 に 含 ま れ な い 。 また 、 予 備 実 験 で は ネ ット ワ ー ク コ ン ト ロ ー ラとEtherCAT マスタ間の通信時間を含まなかったが、本実験では含むことに注意されたい。
ネットワークコントローラとして、簡単化と測定の容易さのため、PC サーバ上の ONOS の代わりに、Raspberry Pi 4 Model B（以下、RasPi と呼ぶ）上に実装した簡易コントローラを用いた。コント
ローラからリクエスト送出するタイミングで、RasPi の GPIO ピンの出力をオンにし、オシロスコー
プでこれをトリガとすることでリクエストの処理経過時間を測定した。なお、RasPi の CPU クロックは 1.5 GHz に固定している。また、RasPi と MEOW ボードは NETGEAR GS324（仕様上のポート間遅延の 4.7 マイクロ秒）を介して接続した。

Network controller(RasPi 4B)

Ethernet(1Gbps)Device controller(ZCU106)

Ethernet(100Mbps)

GPIO

Device(LAN9252)
Device(LAN9252):

Device(LAN9252)
Device(LAN9252)

Oscilloscope

GPIO

MEOW device controller
EK-U1-ZCU106-G-J

MEOW device
EVB-LAN9252-DIGIO

図 1.2.3-18

シングルマスタ実験構成- 38 -

8x

1000 リクエストの処理を観測したときのタイミングチャートを図 1.2.3-19 に示す。前述したように、
リクエスト処理完了時間はデバイスがリクエストを受信したタイミングによってばらつく。PDO 周
期の直前でリクエストを受信した場合は、待ち時間なくテレグラムを送出できる。一方、PDO 周期の直後にリクエストを受信した場合は、次の PDO 周期が来るまで、つまり今回の設定では最悪 30 マ
イクロ秒、テレグラムの送出を待つ必要がある。処理時間の最小値は 70.0 マイクロ秒（③）であり、最大値は 103.4 マイクロ秒（③+⑥）であった。最悪ケースでは目標値をやや超過するもの概ね許容範囲内であると考える。

図 1.2.3-19

タイミングチャート（横軸の目盛線は 10 マイクロ秒）。

① 簡易ネットワークコントローラがリクエストを開始、② リスエストの送信が完了、③ すべてのスレーブ処理が完了、④ 送信処理に要した時間、⑤ コンテキストスイッチに関係するジッタ時間、⑥ POD サイクル待ちに起因するジッタ時間。
＜システム検証実験（マルチマスタ）＞
前節に続き、さらに今後の展開を見据えて、複数のマスタを並列で動作させた場合の動作確認を行なった。図 1.2.3-20 に示すように、８つの MEOW デバイスを２つずつネットワークセグメントに配置することで、４つのマスタ機能を並列で動作させた。
結果を図 1.2.3-21 に示す。シングルマスタでは PDO サイクルが 30 マイクロ秒で動作したが、4 マスタでは安定動作しなかったため、PDO サイクルを 80 マイクロ秒に設定した。この影響もあり処理時間の最小値は 100 マイクロ秒になるものの、最大値は 187 マイクロ秒となった。問題の分析と解析は今後の課題とする。

- 39 -

SimpleNetwork
Controller

Seg#1
MEOW device controller

Slave

SoC FPGA
MasterMasterMasterCPU
MasterMasterMasterSeg#2

図 1.2.3-20

マルチマスタ実験構成

図 1.2.3-21

Seg#4

Seg#3

4 マスタでのタイミングチャート（PDO サイクル 80 マイクロ秒）① 簡易ネットワークコントローラがリクエストを開始、② マスタがスレーブにリクエストの送信を開始、③ すべてのスレーブ処理が完了、④ POD サイクル待ちに起因するジッタ時
間。

＜MPI プログラムを用いたシステム動作検証＞
図 1.2.3-22 に示すような、4 ラックの光電ハイブリッドスイッチネットワークを模した環境を構築した。各ラックには計算サーバが 1 台ずつ存在する。光スイッチは電気スイッチを用いて模擬している。本実験では MEOW コントロールプレーンを用いて、期待する動作を確認できた。
- 40 -

10GbE SW

Rack01: V101

P104

1/11(73) V114
1/21(81) V201

P102

P104

P103

Port 1
node 03NP200
10.1.103.1/24

P102

enp2s0f1

1/22(77) V202

光波⾧送受信機
光コアSW
Plane #2

Port 0

enp3s0f1

node 0210.1.102.1/24

光SW#2
P101

1/20(69) V103

P103

1/19(73) V103

1/21(81) V201

光波⾧送受信機
光コアSW
Plane #1

P101

1/10(73) V114

1/20(69) V102

1/22(77) V202

光SW#1

192.168.114.3/24
SW 03
10.1.103.254/24

192.168.114.2/24
SW 02
10.1.102.254/24

internal
connection

enp3s0f1

node 0110.1.101.1/24

1/21(81) V201

1/11

1/22(77) V202

1/10

1/20(69) V101

Rack02: V102
1/8(73) V114

1/8

1/21(81) V201

L2 SW 04-VLAN114
192.168.114.254/24

192.168.114.1/24
SW 01
10.1.101.254/24

1/7

1/7 (73) V114

1/22(77) V202

192.168.114.4/24
SW 04
10.1.104.254/24
1/20(69) V104

1/19(73) V104

enp2s0f1

Port
Port
0 1
Port 1

node 04
NP200
Port 010.1.104.1/24

Rack03: V103

図 1.2.3-22

Rack04: V104

MPI AllReduce の検証環境（1 ノード×4 ラックの実験環境）

さらにスイッチ切替時の挙動をミクロに確認するため、スイッチでのポートミラーリングと FPGA
スマート NIC（Napatech NT200）によるパケットキャプチャを用いて、パケット間隔の変化を観測した。iperf を用いて 4Gbps の UDP トラフィックを生成し、MEOW ネットワークコントローラ経由でToS 値を切り替えた。結果を図 1.2.3-24 に示す。横軸がパケットに付与したシーケンス番号であり、縦軸がパケット間の間隔である。ToS 値が 0 のときは電気スイッチ、4 のときは（模擬）光スイッチ
を経由している。経路切替時にパケット損失は観測されなかったが、1 ミリ秒強の受信遅延が発生していることがわかる。この原因は Linux OS の iptables コマンド操作による ToS 値設定に関係していると推測されるが、詳細な調査は今後の課題である。

- 41 -

電気コア V114
電気スイッチの経路

1/22(77) V202
10G SW
電気コアスイッチ

1/10(73) V114

192.168.114.3/24
SW 03
10.1.103.254/24

1/21(81) V201

Port 0光波⾧送受信機＋光コアSW
Plane #1

NIC

None

Iperf -c192.168.114.4/24
SW 04
10.1.104.254/24

1/21(81) V201

光スイッチの経路

enp2s0f1

Smart
NIC

internal connect
1/11(73) V114

Port 11/22(77) V202
← port mirroing

Port 0enp2s0f1

Port 1

Smart
NIC

NIC

CaptureIperf -snode 04NP200
10.1.104.1/24

node 03NP200
10.1.103.1/24

Rack03: V103

Rack04: V104

図 1.2.3-23

パケット測定実験環境

図 1.2.3-24

パケット間隔の観測

さらに ONOS 内部でのリクエスト処理時間の内訳を表 1.2.3-2 に示す。ONOS は Java で実装されており、メモリ管理にガベージコレクション（GC）を採用しているため、初期化時のクラスロードやGC の影響による性能劣化を考慮する必要がある。今回の実験では、初回の実行時間を除いた 10 回試行した場合の平均値を測定した。MEOW デバイスマネージャとの通信と計算サーバの ToS 値の設定
は同時並行に実行できるため、リクエスト処理時間はこれらの総和になるわけではないが、数百マイ
クロ秒かかっており、さらなる高速化の必要がある。
- 42 -

表 1.2.3-2 ONOS リクエスト処理時間の内訳
処理内容
REST-IF から要求された JSON 形式のリクエストから、光パスの設定に必要な情報（波長、ポート番号、パスの向き等）の取出し
光スイッチのポートの排他制御
複数のパスを一括りにして扱うグループの割当
リクエストメッセージの組立て
MEOW デバイスマネージャへのメッセージの送受信
ホストリストに登録されたサーバに対する ToS 値の設定

実行時間
（マイクロ秒）
133.2
13.1
4.7
33.7
164.8
308.8

＜まとめ＞
本研究開発項目では、光電ハイブリッドスイッチネットワークの特性に適合したトラフィック振り分けアルゴリズムを提案し、分散深層学習での効果を確認した。さらにトラフィック振り分けアルゴ
リズムの効果を発揮するためにも高速なコントロールプレーン技術が必要である。そこで、1000 ラ
ック規模まで拡張可能であり、100 マイクロ秒で光スイッチ制御が可能な高速コントロールプレーン
技術 MEOW を提案し、動作検証を完了した。具体的には、リアルタイム Ethernet 規格である
EtherCAT をベースに、マスタ機能のハードウェア化および多重化を実現し、オープンソースネット
ワークコントローラである ONOS を拡張することでコントロールプレーンとしてシステム化した。
FPGA と汎用ハードウェアを用いて提案システム試作し、約 70 マイクロ秒から約 100 マイクロ秒で光スイッチ制御が実現可能なことを確認した。このように必要要件を、汎用で安価なコモディティハー
ドウェアとオープンソースソフトウェアを用いて実現できることを明らかにし、光電ハイブリッドス
イッチシステムの実用化に向けたソフトウェア制御技術を確立できた。我々の知る限り、データセン
タ規模のネットワーク制御に EtherCAT を用いることは前例がない。
さらに研究開発項目⑤「光電ハイブリッドスイッチシステム実証」と連携して MEOW の技術をシステム実証にて検証した。また、開発したネットワークコントローラを参照実装として検証できるよ
うに、オープンソースソフトウェアとして github 上（https://github.com/ryousei/meow-rest）に公開した。

- 43 -