イノベーションセンターの新井です。 普段は全社検証網の技術検証、構築、運用を担当しています。
私の所属するイノベーションセンターではこれまではイーサネット/IPレベルの検証網を運用して全社に提供していましたが、昨今の光伝送とIP系技術の融合の進展などにも対応して、さまざまなユースケースを検証・開発するために、光伝送に関する検証網(All Photonics Network Testbed。以下、APNテストベッド)も同一チームで構築・運用しています。
今回から複数回に分けて現在取り組んでいるAPNテストベッドで用いている技術や運用手法を解説していきます。記事内では我々と同じようにイーサネット/IP技術にはある程度詳しいが光伝送技術の知識はそれほどでもない、という方向けに解説します。
本記事のサマリーです。
- 光伝送ネットワーク(APN:All Photonics Network)の検証網、APNテストベッドについて連載します。
- 連載1回目の本記事では、光伝送のオープン化の全体像とトランスポンダーにおけるオープン化の進展について紹介します。
- 特にIP over DWDM関連やホワイトボックストランスポンダーのアーキテクチャーについて解説し、それらを使った運用手法の一端を紹介します。
- 光伝送ネットワークの概要
- トランスポンダーのアーキテクチャーとIP over DWDM
- ホワイトボックストランスポンダー
- 専用トランスポンダーかIP over DWDM構成か
- 運用における知見
- まとめ
光伝送ネットワークの概要
光伝送ネットワークではROADMやトランスポンダーといった機器が登場します。これらの役割について馴染みのない方もいるかと思いますのではじめに説明します。
光伝送で用いられる機能
長距離光伝送で用いられる機能は一般的にトランスポンダー、WDM(Wavelength Division Multiplexing)、アンプなどで構成されます。
- トランスポンダー(Transponder, TRPN) : 一般的なイーサネット信号などのクライアント信号を波長多重可能かつ長距離延伸が可能な光信号へ変換する機能です。クライアント側(端末などが接続される側)からの光信号を一旦電気信号へ変換後、再度光信号へ変換(Optical-Electric-Optical変換)してライン側(他拠点との接続側)と接続します。
- WDM(Wavelength Division Multiplexing) : 波長多重を行う機能です。単純化したわかりやすいイメージとしてはプリズムのようなものです。プリズムを通して1本の光線が色(=波長)の異なる光線に分離するように、異なる波長に情報を載せた光信号を複数まとめた光を生成したり、逆にまとめた光からそれぞれの波長の光信号を分離したりする機能のことです。WDMはその多重度に応じてさらにDWDM(Dense WDM), CWDM(Coarse WDM)などに分類されます。
- WSS(Wavelength Selective Switch) : WDM信号を各波長単位で任意の出力へ制御する波長スイッチ機能です。単純化したわかりやすいイメージとしては波長単位で可変的に動く鏡のようなものです。WSSは波長単位で多重化や出力ポート選択を行えるためスイッチ機能とWDM機能を両方実現できます。
- アンプ(Amplifier, AMP) : 光信号の強度を増幅する機能です。
ROADMはReconfigurale Optical Add/Drop Multiplexerの略で、WSSを活用することにより波長単位でスイッチ(Add/Drop)することで、Point-to-Point以外の伝送トポロジーを構成することを可能とする装置です。ROADMにより光伝送ネットワークをSDN(Software-defined-Network)的な制御とすることが可能となります。APNテストベッドでも東京を中心としたハブ&スポーク型のトポロジー、一部拠点間ではリング型のトポロジーとなっていますが、このように光伝送のみである程度自由なネットワークトポロジーが作れるのはROADMならではの利点です。
光伝送のオープン化
従来は相互接続性や管理運用の制限によりこれら一連の機能を実現する装置群を単一のベンダーで構築することが一般的でしたが、WDM可能な信号を送信するデジタルコヒーレント1トランシーバー(Digital Coherent Optics, 以降DCO)をスイッチ/ルーターに搭載するいわゆるIP over DWDMの構成(後述します)の台頭などもあり、OOLS(Open Optical Line System)と呼ばれる他社製のトランスポンダーとの連携を重視する構成が注目されています。さらにROADMにおいても標準化に関する取り組みであるOpenROADM MSA(Multi-Source Agreement)2に基づき装置の機能単位や筐体内接続を分割するDisaggregation構成をとり、トポロジー変更やネットワーク規模の拡大に対応しやすくする構成も利用されています。また、トランスポンダーやスイッチ/ルーターについてもOSとハードウェアを分割するいわゆるホワイトボックス装置も利用されています。
上記の説明を簡略化したイメージ図が下図になります。
APNテストベッドではこれらの内、最下段に記載した構成を主に用いて構築・運用しています。
トランスポンダー
ホワイトボックストランスポンダーを主に利用しています。ベンダー固有の専用筐体/OSで構成されるトランスポンダーも利用していますが、その場合はスイッチ/ルーターにも搭載可能な3rd party製の400G-ZR+/100G-ZR DCOなどQSFP型のトランシーバーを採用しています。後述するIP over DWDM構成もトランスポンダーの一種として活用しています。
ROADM
OpenROADM MSAに基づいたDisaggregatedな装置を利用しています。ハブ&スポーク型のトポロジーでは多数の拠点への「方路」を構成する必要がありますが、その方路ごとに筐体を用意するクラスター型の構成となっています。
本記事では上記2つの内トランスポンダーにおけるオープン化の進展としてIP over DWDM構成とホワイトボックス化に焦点をあてて解説し、運用で得られた知見も共有します。
ROADMのDisaggregationやOOLS利用における注意点などについては次回以降に掲載する予定です。
トランスポンダーのアーキテクチャーとIP over DWDM
トランスポンダーの役割についてIP over DWDM構成と比較しながら改めて説明します。
マックスポンダーとL2スイッチの違いについて
複数のクライアント信号を集約して1波長にまとめて送出するトランスポンダーは多重化のmultiplexer(Mux)と接続した単語で「マックスポンダー(Muxponder)」と呼ばれます。 マックスポンダーと、スイッチ/ルーターは一見似たように「複数の信号を集約して出力する」動作をしますが、実際には制御対象のレイヤが異なります。
トランスポンダー/マックスポンダー(Layer 1, 物理層)
入力ポートと出力ポートを固定的に対応付け、電気⇔光の変換や光信号変換をします。フレーム/パケットの中身は解釈しません。gearboxと呼ばれる機能部位で電気インターフェースを固定的に接続します。3
→ 「線をつなぐ/信号の形を変える」役割
スイッチ/ルーター(Layer 2/3, データリンク層/ネットワーク層)
フレーム/パケットを解釈し、MACアドレスやIPアドレスに基づいて転送先を動的に決定します。
→ 「データを理解して行き先を決める」役割
ネットワークにおける役割分担
このように従来は異なるレイヤーの装置として役割分担が行われており、一般的なネットワーク構成としては以下のようになっていました。
- 拠点内(LAN):スイッチやルーターでパケットを制御
- 拠点間接続(WAN):拠点内機器をマックスポンダーに接続し、ROADMやWDMを組み合わせて大容量・長距離伝送
400G-ZR/ZR+とIP over DWDM
従来は「専用のトランスポンダー筐体」で信号を変換し、その先にスイッチ/ルーターを接続していました。しかし近年、QSFP-DDやOSFPといった小型汎用トランシーバーの形状で長距離光伝送を実現するDCOである400G-ZR/ZR+が登場しました。
これにより、スイッチ/ルーターのポートに直接トランスポンダー機能を内蔵できるようになり、専用のトランスポンダーを使わずとも、スイッチ/ルーターから直接WDM装置(ROADMなど)に接続可能となりました。この構成を「IP over DWDM」と呼びます。
従来:
スイッチ/ルーター ⇔ トランスポンダー筐体(マックスポンダー) ⇔ ROADMなどIP over DWDM:
スイッチ/ルーター(ZR/ZR+モジュール搭載) ⇔ ROADMなど
また、400G-ZR/ZR+では、トランシーバーの制御にCMIS(Common Management Interface Specification)を用いています。これは短距離用トランシーバーの管理仕様を拡張したものであり、既存のNetwork OSを大きく変更せずに対応しやすいというメリットがあります。実際に市販されている多くのメーカーの装置で400G-ZR/ZR+を動作させることが可能になっています。このようにスイッチ/ルーター機能とトランスポンダー機能を一筐体で実現できることからDCOを搭載したスイッチ/ルーターをスイッチポンダーという名前で呼ぶ場合もあります。
特に近年では首都圏や関西圏内において、AI関連のインフラ整備やISP/CSPにおける映像伝送トラフィックの増大に伴い、複数のデータセンター間で大容量回線を必要とする動きがみられます。このような背景からネットワーク帯域の多重化と長距離光信号への変換をマックスポンダーではなくIP over DWDMで直接実現する構成も導入が始まっています。
このような構成のバリエーションとして、800G-ZRや100G-ZR DCOなど、さらなる小型・高効率なDCOも登場しています。これにより、IPレイヤと光レイヤの統合が進み、データセンター間の接続構成は省スペース・省電力でよりシンプルに設計できるようになると予想されます。
ホワイトボックストランスポンダー
L2/L3レイヤーにおけるホワイトボックススイッチの利用の進展
トランスポンダーのホワイトボックス化について説明する前にスイッチ/ルーターのホワイトボックス化について説明します。
ホワイトボックスとはネットワーク機器においてハードウェアとソフトウェア(Network OS:NOS)を分離して設計・導入できるオープンなアーキテクチャを指します。2025年現在、このホワイトボックスアーキテクチャで広く普及しているNOSが「SONiC」です。SONiCはMicrosoftによって開発され、OCP(Open Compute Project)に移管された後、現在はLinux Foundation傘下でオープンソースとして継続的に開発が進められているLinuxベースのNOSです。SONiCは複数のホワイトボックススイッチベンダーに対応しており、主に大規模なデータセンターネットワークを実現するために、クラウド事業者やデータセンター運用者を中心に採用が進んでいます。
SONiCが備える特徴のうち、後述するホワイトボックストランスポンダーにも共通する点として、以下の2つが挙げられます。
ハードウェア選定の自由度が高い
SONiCは複数のハードウェアベンダーの筐体で動作可能なため、目的や要件に応じて最適な機器を選択できます。
オープンな運用手法が活用可能
SONiCはLinuxをベースに開発され動作しており、基本的には既存のリッチなLinux運用手法を活かした管理・自動化が可能です。また、gNMI(gRPC Network Management Interface)によるStreaming Telemetryなど広く用いられるモダンな運用手法との親和性も高く、効率的なネットワーク運用を実現できます。
1のハードウェア選定の自由度向上を実現している方法について少し詳しく説明します。
ネットワークスイッチは、パケットを高速処理するために スイッチASIC(Application Specific Integrated Circuit)と呼ばれる専用チップを用いています。NOSは、このASICを制御する必要がありますが、従来はASICベンダーごとに異なる専用SDK(Software Development Kit)を用いて実装する必要がありました。また、これらのSDKはライセンス契約が必要になるケースも多く、オープンなNOSの開発や移植性において障壁となっていました。
このような状況を改善するために策定されたのが、SAI(Switch Abstraction Interface)です。 SAIはNOSとASIC SDKの間に位置する抽象化された共通APIであり、ASIC固有の仕様を意識することなくOS開発者が共通のインターフェース経由でハードウェアを制御できるように設計されています。SAIは現在もOCPで開発が進められています。
このSAIにより、NOSは特定ベンダーのSDKに依存せず、同一のSAI APIを介して複数のASICで動作可能となり、開発効率が大きく向上し多数のハードウェアでの動作を行えるようになりました。SONiCもこのSAIを利用してスイッチASICを制御しており、多数のホワイトボックス筐体とともに利用できます。
ホワイトボックストランスポンダーへ
ホワイトボックストランスポンダーも基本的にはホワイトボックススイッチの特徴を引き継いでいます。
ホワイトボックストランスポンダーの開発において主たる役割を果たしてきたのはNTTを含めて多数の事業者が参画するTelecom Infra Project(TIP)です。TIPはOCPなどで成功したOpenなコンピューティングの取り組みを通信事業者においても実現できないか目指している団体ともいえます。
ホワイトボックストランスポンダーでオープンなアーキテクチャの実現に貢献している仕組みがTAI(Transponder Abstraction Interface)です。TAIは前述したSAIの光伝送版ともいえるものです。SAIがスイッチASICの制御を抽象化するAPIであるのに対してTAIはその名の通りトランスポンダーに必要な光伝送の部品を抽象化します。
| API | 主対象 | 利用領域 | 開発体制 |
|---|---|---|---|
| SAI | スイッチASIC | スイッチ/ルーター | OCP |
| TAI | トランスポンダー | 光伝送 | TIP |
TIPではこのTAIを活用したNOSであるGoldstone OSの仕様とリファレンス実装を開発し、我々が現在APNテストベッドで活用しているトランスポンダーのOSもこのGoldstone OSを元にした製品です。
さらにSONiCがdockerコンテナとして各機能を実装している構成であるのと類似して、下記のようにkubernetesのpodとして各機能が実装されており、ユーザーからも中身が理解しやすいものとなっています。
$ kubectl get pod NAME READY STATUS RESTARTS AGE north-noscmd-9vxkx 1/1 Running 0 68d tai1-2-54cf969f6b-rhtz2 1/1 Running 0 68d tai2-1-68b48b6c54-jtc42 1/1 Running 0 68d tai2-2-5868f89fdb-zrmmh 1/1 Running 0 68d tai1-1-5774878878-kr59b 1/1 Running 0 68d redis-xcvrd-8lcrf 1/1 Running 0 68d prep-xcvrd-2hx2f 0/1 Completed 0 68d xcvrd-2vgps 1/1 Running 0 68d config-mgmt-ndtmp 1/1 Running 0 68d line-protection-hgvnh 1/1 Running 0 68d redis-cache-k22gt 1/1 Running 0 68d oc-terminal-device-p7bpc 1/1 Running 0 68d oc-interfaces-f9rcs 1/1 Running 0 68d oc-macsec-r8mxd 1/1 Running 0 68d collector-as-qmxqx 1/1 Running 0 68d collector-as-tai-xnmmg 1/1 Running 0 68d collector-pm-qnsns 1/1 Running 0 68d collector-inventory-6vm2t 1/1 Running 0 68d alarm-z96sp 1/1 Running 0 68d oc-platform-vp86h 1/1 Running 0 68d perfmon-4l67b 1/1 Running 0 68d north-netconf-bh6zj 1/1 Running 0 68d redis-ztp 1/1 Running 0 68d xlate-telemetry-5bz22 1/1 Running 0 68d north-gnmi-tnxk9 1/1 Running 0 68d tai-gearbox2-1-779cf9d6d-q2s2j 1/1 Running 1 (68d ago) 68d ztp 1/1 Running 0 68d tai-gearbox1-1-fdfc7d6cd-mtkhk 1/1 Running 1 (64d ago) 68d
また、Goldstone OSやその派生OSにおいても、SONiCなどスイッチOSと同じようにONIE(Open Network Install Environment)というインストール環境を利用でき、OSのインストール等が容易になっています。
専用トランスポンダーかIP over DWDM構成か
DCOというプラガブルモジュールを用いたIP over DWDM構成と専用トランスポンダーのホワイトボックス化を説明しました。さらに、市場には説明した2種類以外にも400G-ZR/ZR+等を用いつつスイッチ/ルーター機能を排することで専用トランスポンダーでありながら価格を低減したモデルなども存在しており、現在ではトランポンダー機能のあり方が多様になってきています。そのためネットワーク設計者は光伝送分野だけではなくIP/イーサネットレイヤーも含めた最適なアーキテクチャーを再検討する必要があります。
一般論としては下記のような比較ができますが、APNテストベッドでは複数のトランスポンダー構成を用いて、単純なコスト比較のみならず実際に検証・運用し、さまざまな観点から比較をしています。
| 専用トランスポンダー(ホワイトボックス含む) | IP over DWDM(L2/L3機器と400G-ZR/ZR+などの組み合わせ) | |
|---|---|---|
| フォームファクター | CFP2などの大型トランシーバーもしくはラインカード(内蔵型)が多い | QSFPやOSFPなどの小型トランシーバー |
| 制御API | ホワイトボックス装置のTAIは光機能を詳細に抽象化可能 | CMISは簡易な制御 |
| 伝送距離 | 長距離にも対応 | メトロエリア(数100km以内)程度がメイン |
| 光パラメーターの最適化 | 細かいチューニングが可能 | 固定的な部分が多い |
| ライフサイクル | スイッチ/ルーターに比べれば長期 | 上位レイヤーも含めた多機能が求められるためバージョンアップの必要可能性が比較的高い |
| 運用体制 | 伝送レイヤーとL2/L3レイヤーの運用者の既存のすみ分けが流用可能 | イーサネット/IPと伝送の両方の知見が必要なため新たな体制や運用ツールが必要な可能性がある |
運用における知見
APNテストベッドの構成
APNテストベッドでは冒頭説明した通り、ROADMを用いてハブ&スポーク型とリング型を組み合わせたトポロジーのネットワークを構築し、そこにこれまで説明した多彩なトランスポンダーを接続しています。 過去には単一ベンダーで光伝送システムを構成するのが一般的だったため、このような異ベンダーのトランスポンダーからの光波長を区別するため「エイリアン波長」と呼んでいる場合もありますが、我々のAPNテストベッドでは一般的な仕様としています。
複数ベンダーシャーシ/トランシーバーの混在運用
我々のホワイトボックストランスポンダーの運用においては、そのオープン性を活かし、複数ベンダー製のシャーシに共通のOSを搭載させています。これまでに3社のハードウェアを導入してきましたが、いずれも大きなトラブルはなく、安定した運用が可能であることを確認しています。
一方で、トランシーバーに関してはベンダー間の相互接続性が課題となる場合もありました。 とくにCFP2形状のDCOについては、光パラメータの細かな調整が可能である一方、異なるベンダー間で接続できないケースが確認されました。実際に、全く通信ができない組み合わせも存在しており、注意が必要です。 これに対してIP over DWDM構成でよく用いられる400G-ZR/ZR+トランシーバーはCMISによる標準インターフェースの普及や仕様の成熟により、初期の一部例外を除いて現在ではほぼ全てのベンダー間で安定した動作が確認できています。
長距離伝送を可能とするDCOは、DSP(Digital Signal Processor)などの信号処理に必要な部品が短距離用トランシーバーよりも一般に高消費電力・高発熱・高体積となり、シャーシ毎に物理的な搭載制約を伴うことがあります。 使用する際は事前に筐体の制限を十分に確認し、実際に搭載して試験するとともに、搭載位置の設計を慎重に検討する必要があります。
以上を踏まえると、オープンな光伝送環境においても適切なトランシーバー選定とパラメータ調整、設計により十分な互換性と運用性を確保できることが示されており、マルチベンダー環境であってもオープンな光伝送の利点を享受することは現実的かつ有効な選択肢といえます。
gNMIの活用
APNテストベッドでは、トランスポンダーの状態監視や可視化にgNMIを活用しています。gNMIは、OpenConfig4が策定したオープンなネットワーク管理プロトコルであり、ベンダー依存のSNMPやCLIベースの取得手法に比べ、構造化されたデータを効率的かつリアルタイムに収集できる点が大きな特長です。詳しくは当ブログの以前の記事「次世代の監視技術 - Telemetry技術のご紹介 - NTT docomo Business Engineers' Blog」もご確認ください。
監視構成では、gNMIクライアントに gnmic を活用し、複数の機器からストリーム形式でOpenConfigベースのメトリクス(光パワーレベル、エラーレート、SNR:Signal Noise ratioなど)を秒単位で連続取得しています。gnmicはGoogle Cloud上のGKEにデプロイし、オンプレミスのネットワークから自社サービスであるFIC(Flexible InterConnect)を通してメトリクスを取得しています。取得データはPrometheus形式に変換することでGoogle Cloud Monitoringに連携、さらにPrometheus/Grafana連携によりダッシュボードでリアルタイム表示・履歴管理・アラート通知まで対応しています。
gNMIを活用した我々の監視構成では以下のようなメリットが生まれています。
- 機器追加時にはKubernetesのConfigMapであるYAMLファイルを1つ編集するだけで監視対象に追加可能
- YAMLファイルはGitHub上で管理しておりそれを書き換えるだけで機器追加に対応できています。
- 光学パラメーターの劣化をリアルタイムに検知し、障害予兆に即応可能
- ラベル付きの時系列データを標準的なフォーマットで取得できるため、既存のツールが活用しやすく、障害の分析や予測に役立てることができます。
- エージェントレスで通信でき、ベンダー固有の監視ソフトが不要
まとめ
本記事では光伝送ネットワークのオープン化について概観し、特にIP over DWDM構成とホワイトボックストランスポンダーにおけるアーキテクチャーと実際の運用上の知見を紹介しました。次回以降は光波長自体を伝送するROADMによるネットワークについて紹介する予定です。
- 光の強度のみならず波としての性質(位相など)にも情報をのせて伝送する技術。デジタルコヒーレントはその信号情報処理に専用半導体(DSP:Digital Signal Processor)を用いています。微細加工技術の進展により小型化・省電力化が進んでいます。↩
- OpenROADM MSA(Multi-Source Agreement)は光伝送の特にROADM網において複数のベンダーで相互接続が可能とするため、物理的な光インターフェースの仕様やAPI、装置のアーキテクチャーを規定しています。詳しくは次回以降の連載や公式Webサイトを参照ください。↩
- OTN(Optical Transport Network)スイッチという光のフレーム情報でスイッチングする方式も存在します。↩
- ネットワーク機器のAPIをマルチベンダーで共通的に提供できるようにすることを目的とした取り組み。OpenConfig↩