> [!abstract] 概要(abstract の日本語訳) > 光バックボーンネットワークにおける劣化(degradation)または障害(failure)イベントは、クラウドサービスのサービスレベルアグリーメント(SLA)に影響する。これらのイベントを迅速に検知しトラブルシューティングし、その影響を最小化することが重要である。既存のテレメトリシステムは、SNMPのような古めかしいツールとベンダー固有のコントローラに依存しており、これらのシステムの柔軟性とスケールの両方に影響を与える。その結果、劣化または障害イベントをタイムリーに検知・トラブルシューティングするために必要なデータを時間内に収集できない。本論文は、集中型のベンダーに依存しないコントローラを用いてストリーミング方式で光学データを収集する光テレメトリシステムであるOpTelの設計と実装を提示する。より具体的には、OpTelは光デバイスとコントローラの間に柔軟でベンダーに依存しないインタフェースを提供し、データ管理タスク(例:クエリ可能なデータベースの作成)をデバイスからコントローラへオフロードする。その結果、OpTelは1秒粒度でのきめ細かい光テレメトリデータの収集を可能にする。OpTelはTencentの光バックボーンネットワークで過去6か月間稼働している。このきめ細かいデータ収集により、短命なイベント(すなわち一過性イベント)の検知が可能になる。既存のテレメトリシステムと比較して、OpTelは正確に2倍多くの光イベントを検知する。また、これらの光イベントのトラブルシューティングを数秒で可能にし、これは最新技術と比較して桁違いに高速である。 ## 論文情報 - **タイトル**: Detecting Ephemeral Optical Events with OpTel - **著者**: Congcong Miao([[Tencent]])、Minggang Chen([[Tencent]])、[[Arpit Gupta]]([[UC Santa Barbara]])、Zili Meng([[Tsinghua University]])、Lianjin Ye([[Tsinghua University]])、Jingyu Xiao([[Tsinghua University]])、Jie Chen([[Tencent]])、Zekun He([[Tencent]])、Xulong Luo([[Tencent]])、Jilong Wang([[Tsinghua University]]、BNRist、Peng Cheng Laboratory)、Heng Yu([[Tsinghua University]]) - **媒体**: 19th USENIX Symposium on Networked Systems Design and Implementation(NSDI 2022) - **発表年**: 2022年4月4-6日、Renton, WA, USA - **ISBN**: 978-1-939133-27-4 - **URL**: https://www.usenix.org/conference/nsdi22/presentation/miao - **通し番号**: proceedings pp.339-353 - **謝辞**: shepherdは[[Manya Ghobadi]]。Zekun HeとJilong Wangがcorresponding author。 ## 概要 Tencentの光バックボーンネットワーク向けテレメトリシステムOpTelを提案する論文。既存のSNMPベース・ベンダー固有コントローラ依存のテレメトリシステムは、ポーリング遅延がインジケータ数・デバイス数に対して線形に悪化し、15分粒度程度の粗いデータしか収集できないため、数十秒で終わる一過性(ephemeral)光イベントを検知できない。OpTelは(1)ベンダー間の差異を吸収する標準化デバイスモデルによる集中制御と、(2)デバイス側の複雑なデータ管理処理をコントローラへオフロードするpush型テレメトリパイプラインにより、1秒粒度でのデータ収集をCPUオーバーヘッドを抑えたまま実現する。Tencentの本番光バックボーンで6か月運用し、既存手法比で検知イベント数2倍・トラブルシューティング時間を数桁短縮したと報告する。 ## 問題設定 - **入力**: 光バックボーンネットワークを構成する光デバイス(OTU: 光トランスポンダユニット、OLS: 光回線システム、BA/PA/LA: ブースター/プリ/インラインアンプ、OSC: 光監視チャネル)から得られる物理層・データリンク層・ネットワーク層のインジケータ。 - **出力**: (1) 秒オーダーでの光イベント(劣化 degradation / 中断 interruption、かつ一過性 ephemeral / 持続 persistent の2軸で4類型)のリアルタイム検知、(2) 既知シグネチャとの照合による原因箇所の特定(トラブルシューティング)。 - **前提条件**: Tencentのようなクラウド事業者は特定ベンダーへの依存(vendor lock-in)や同時障害を避けるため、光回線システムとトランスポンダを複数ベンダーから調達する「vendor-free optical system」を運用する。これがベンダー横断で一貫したデータ収集を難しくしている。 - **必要なデータ**: 物理層(Tx/Rx power、SNR、Q-factor)は瞬時値(instant value)、データリンク層(post-FEC BER、loss/error frame rate)・ネットワーク層(CRC error rate)は累積値(accumulated value)として、OTU・OSC・BA/PAの複数箇所から収集する。 **Figure 1: 既存テレメトリシステム(a) と OpTel(b) の対比** ![[_attachments/nsdi22-paper-miao/fig01a-existing-telemetry.png]] ![[_attachments/nsdi22-paper-miao/fig01b-optel.png]] (Figure 1. (a) 既存のテレメトリシステムはオペレータが15分・30分・45分粒度の値しか見られず「Fiber Jitter」のような短命な劣化を検知できない。(b) OpTelはコントローラが15秒・30秒・45秒粒度の細かい値の変化を直接捉え、Fiber Jitterのような一過性イベントを検知・原因特定できる。Source: Figure 1.) ## 提案手法 - **アーキテクチャ**: OpTelは中央集中コントローラが光デバイスに直接インタフェースするvendor-agnostic設計(Figure 5)。コントローラは global manager(DevMgr + TopoMgr)、scalable collector(ロードバランサ配下の複数collectorノードクラスタ)、real-time analyticsの3モジュールで構成される。DevMgrはYangファイル([[.raw/papers/nsdi22-paper-miao.txt|論文中]]でNetconfプロトコル経由)によりデバイスをvendor-agnosticに設定し、TopoMgrは物理トポロジを維持してケーブル劣化のような直接収集できないイベントの箇所特定を助ける(ケーブル両端のTx/Rx電力を突き合わせる)。 - **標準化デバイスモデル**: ベンダー横断のインタフェースを実現する核心技術。(1) **logic model**: ベンダーに依らず共通する論理コンポーネント(OTUの場合Ethernet・ODU/ODUc・OTUc・OCHの4つ)を識別し、コンポーネント間のワークフロー(Ethernetフレームのカプセル化 → ODUフレーム等)を標準化する(Figure 6)。(2) **data model**: ベンダー間で機能は同じでも物理コンポーネントの性能範囲が異なる(例:増幅器のゲイン幅がベンダー1で15-25dB、ベンダー2で20-30dB)ため、各デバイスがコントローラ接続時に仕様データシートを渡し、設定可能パラメータの値をコントローラ側が初期化する。 **Figure 6: OTU の logic model** ![[_attachments/nsdi22-paper-miao/fig06-otu-logic-model.png]] (Figure 6. OTUをEthernet・ODU・ODUc・OTUc・OCHの5つの論理コンポーネントに分解し、2つのトランシーバ間のチャネル(Channel #0/#1/...)の対応関係を標準化して表現する。ベンダー固有の内部実装差異をこの論理モデルで吸収する。Source: Figure 6.) - **push型テレメトリパイプライン(Streamlined Telemetry Pipeline)**: SNMPのpull型・デバイス側処理集約設計を転換し、データ管理タスクを弾力的なクラウド資源を持つコントローラへオフロードする(Figure 7)。デバイス側は telemetry manager(コントローラからYangファイルを受け取りtelemetry agent/aggregatorを設定)・telemetry agent(ラインカードから瞬時値/累積値をローカルcacheへ書き込む)・cache・aggregator(gRPCでcacheのデータをまとめてコントローラへpush)の4部品で構成する。 **Figure 7: push型光テレメトリのアーキテクチャ** ![[_attachments/nsdi22-paper-miao/fig07-push-based-pipeline.png]] (Figure 7. CU(Control Unit)内のTelemetry Manager・Aggregator・Cacheと、各ラインカード(Card 1/2)内のTelemetry Agentの間の制御フロー(黒矢印)とデータフロー(赤矢印)。ラインカードのModule群からTelemetry Agentが読み取り、Cache経由でAggregatorがControllerへpushする。Source: Figure 7.) - **タイミング設計の工夫**: 実運用で判明した問題として、CU(Linux + NTP)とラインカード(組み込み機器、水晶発振器タイミング)の間にタイミングのずれがあり、telemetry agentとaggregatorを同一周期で設定すると空データがコントローラに送られデータ損失が生じる。これに対しtelemetry agentの送信周期をaggregatorより高頻度に設定することで回避する。 - **リアルタイム分析**: real-time analyticsモジュールは、閾値超過で劣化/障害イベントを検知すると同時に、過去イベントのシグネチャと照合してトラブルシューティングする。マッチする既知シグネチャがあれば自動でレポートを送り、なければオペレータが手動でクエリを投げて調べ、新規シグネチャとして登録する。 ## 新規性 - 既存の光テレメトリはSNMPに依存し、デバイス上でMIBデータベースへのクエリ処理を逐次的(serialize)に実行するため、CPU使用率を抑える代償として高頻度収集ができない(Figure 3・Figure 4でポーリング遅延がインジケータ数・デバイス数に線形増加することを実測)。OpTelはこの計算負荷をコントローラ側へオフロードすることで、デバイス側のCPU使用率をほぼ一定に保ったまま高頻度化する(Figure 11)。 - 既存研究(Cox [11]、Filer et al. [15])はvendor-freeな光システムの統一SDNコントローラという長期目標を示したのみで実運用評価がない。OpTelはこれを標準化デバイスモデルとして具体化し、6か月間の本番運用で実証した点が新規性。 - 従来の光層診断研究([[Manya Ghobadi]]・Mahajanらによる[18]、RAIL[53]、CorrOpt[52]など)はSNMPベースの光層MIBを用いて5分〜15分粒度でTx/Rx電力をポーリングしており、持続イベントの検知は遅く一過性イベントは検知不能だった。OpTelは1秒粒度データにより一過性イベントを初めて体系的に検知・分類する。 ## 実験設定 - **環境**: Tencentの光バックボーンネットワーク(O(50)リンク、O(100)スパン、O(100)セグメント、O(1000)光チャネル、O(10)ベンダーからのO(1000)光デバイス。守秘義務のため正確な数値は非公開)。 - **データセット**: (1) optical telemetryデータセット — OpTelで2020年7-12月の6か月間、全光デバイスから1秒粒度で全インジケータ(Tx/Rx power、SNR、Q-factor、post-FEC BER、loss/error frame rate、CRC error rate)を収集。(2) locationデータセット — OpTelのTopoMgrによるデバイス間トポロジ。(3) trouble ticketsデータセット — Tencentのネットワーク管理プラットフォームから抽出した光関連チケット(fiber cable・hardware・powerの3クラスに分類)。 - **比較対象**: 既存のSNMPベーステレメトリシステム(15分粒度が先行研究[8,18,39,52]で標準的に用いられるためベースラインとして採用)。 - **評価指標**: CPU使用率(収集頻度・インジケータ数別)、検知イベント数(収集頻度別、1秒粒度をground truthとして比較)、検知精度(正しく検知/誤検知/未検知の内訳)、トラブルシューティング所要時間。 ## 実験結果 - **データ収集オーバーヘッド(Figure 11)**: 収集頻度を1秒から0.1秒に上げると、SNMPベースパイプラインのCPU使用率は34%→96%に急増するのに対し、OpTelは19%→25%への微増にとどまる(§4.2)。全インジケータ収集時のCPU使用率もSNMP 34%に対しOpTel 19%。 **Figure 11(a): 収集頻度別のデバイスCPU使用率** ![[_attachments/nsdi22-paper-miao/fig11a-cpu-usage-frequency.png]] (Figure 11(a). 収集頻度0.1s/0.5s/1s/5s/10sそれぞれでのCPU使用率(%)をSNMPとOpTelで比較。0.1sではSNMP 96%に対しOpTel 25%、1sではSNMP 34%に対しOpTel 19%と、高頻度化してもOpTelの増加は緩やか。Source: Figure 11(a).) - **検知効率(Figure 12)**: OpTelは15秒・1分・15分粒度のシステムに対しそれぞれ25%・39%・71%多くのイベントを検知する。15秒より粗い粒度では一過性イベントを一切検知できない。 **Figure 12: 収集頻度の低下に伴う検知イベント割合** ![[_attachments/nsdi22-paper-miao/fig12-detection-by-frequency.png]] (Figure 12. 1秒粒度での検知イベント数を100%として正規化し、収集頻度(1s〜15min)ごとにP-I/P-D/E-I/E-Dの内訳を積み上げ棒グラフで示す。1s粒度でのみE-D(緑)・E-I(橙)の一過性イベントが検出され、15sより粗い粒度ではこれらが消失する。Source: Figure 12.) - **検知精度(Table 2)**: 15分粒度の既存システムは全イベントの35.72%のみを正しく検知し、41.40%は未検知(UND)、22.88%は誤検知(持続イベントとして誤分類等)。特にP-D(持続劣化)イベントは半数未満しか正しく検知できない。 - **イベント内訳(Table 1)**: P-I(持続中断)44.63%、P-D(持続劣化)4.28%、E-I(一過性中断)16.85%、E-D(一過性劣化)34.24%。全体の50%超が一過性イベント。イベント継続時間はロングテール分布を示し(Figure 10)、20%は1秒のみ、50%超は10秒未満で終わる。 - **将来イベント予測(Figure 13)**: 一過性劣化(E-D)イベントの後、5秒の時間窓ではP-I(持続中断)発生確率が約20%、1分の時間窓では約40%に上昇し、E-D事象が将来のP-I事象と強く関連することを示す。過去のP-I事象自体は将来の持続イベントの予測にほとんど寄与しない(記憶を持たない=memoryless)。 - **トラブルシューティング時間(Table 3)**: 光ファイバー起因イベント(全体の89.7%)は既存システムで5〜10分かかるところをOpTelは数秒で解決。ハードウェア起因(7.8%)は既存システムで数時間〜数日かかるところをOpTelは2〜60秒。電源起因(2.5%)は既存システムで数時間かかるところをOpTelは10〜30秒。 ## 考察 - Tx/Rx電力レベルが光層性能の鍵指標であり(Figure 9)、受信電力の低下がSNR・Q-factorの線形劣化を経て、閾値(約-19dBm)を下回るとFEC訂正能力の限界からデータリンク層・ネットワーク層のフレーム損失・CRCエラーが急増する非線形な現象を実測している。この物理的関係が、劣化と中断のイベント分類の根拠になっている。 **Figure 9(a): 伝送損失とRx電力の関係、および正常/劣化/中断の境界** ![[_attachments/nsdi22-paper-miao/fig09a-loss-vs-rxpower.png]] (Figure 9(a). Tx電力を固定しファイバーの伝送損失(dB)を段階的に増やしたときのRx電力(dBm)の変化。Rx power(dBm) = Tx power(dBm) - transmission loss(dB) の線形関係に従い、-10dBmを上回れば正常(Normal)、-19dBmを下回ると中断(Interruption)、その間が劣化(Degradation)と分類される。Source: Figure 9(a).) - シグネチャベースの原因箇所特定は、ファイバーケーブルイベント(OSC/PAのRx電力低下と一致するタイムスタンプ)、増幅器不安定性(周期的な3dBのRx電力降下)、電源断(OSC/BA/PAの電力値変化パターン)といった各カテゴリを、複数デバイス間の相関(inter-device analysis)から機械的に切り分けられることを事例で示す(§4.5)。 - ephemeral eventがpersistent eventの前兆になり得るという時間相関の発見(§4.4)は、単なる検知の高速化にとどまらず、予兆に基づく先回りの運用対応(トラフィックエンジニアリングでの回避等)への応用可能性を示唆する。 ## 強み / 弱点・課題 - **強み**: 6か月間の本番運用実績を伴う評価であり、ラボ環境評価にとどまる先行研究([34,37])との対比が明確。CPU使用率・検知精度・トラブルシューティング時間のいずれも定量的に既存システムとの差分を示している。 - **弱み・限界**: 守秘義務によりリンク数・イベント数などの絶対値が非公開で、他システムとの外部比較が難しい。シグネチャベースの原因箇所特定は既知パターンとの照合が前提であり、未知シグネチャは依然オペレータの手動クエリに依存する。IP層性能と光イベントの相関分析は将来課題として明示的に残されている(§5)。