期待のネット新技術

Silicon Opticsにおける「LPO」の課題を解決…を期待されるも、明確な回答になれない「LRO」の難しい立ち位置

LPOとLRO(2)

 前回から、「Silicon Opticsの現状」シリーズの周辺の話題として、LPO(Linear-drive Pluggable Optics)とLRO(Linear Receiver Optics)について紹介している。前回はLPOを紹介したのだが、その亜種というか、LPOの問題に対応しようとした結果生まれたLROを、今月は紹介したい。

LPOの運用で直面する、既存規格との互換性の問題

 LPOの運用上の問題は、故障時の対処もさることながら、前回の最後にも書いた既存の規格との互換性のなさである。「普通に通信する分には問題なさそうだが、状況が悪化した時に突如通信できなくなり、しかも理由が判らない」という可能性があるというのは、管理者からすれば悩みの種でしかない。「標準規格品を持ってこい」と文句言われても仕方ないところだ。

 そもそもLPOというかCPOも同じなのであるが、ターゲットはどこかというとハイパースケールデータセンターにおける、エンドポイント(つまりGPUとかAIプロセッサー)同士の相互接続用である。これは100G-DR-LPOとか400G-FR4-LPOのSpecificationの先頭に、明確に"AI clusters in hyperscale data centers are seeking high-speed interconnects, with low power consumption, high port density, low cost, and low latency. Volumes are large enough to demand transceiver solutions that address these specific needs."(ハイパースケールデータセンターのAIクラスターは、低消費電力、高ポート密度、低コスト、低遅延を備えた高速相互接続を求めている。その規模は、これらの特定のニーズに対応するトランシーバーソリューションを必要とするほど十分に大きい)と記されていることからも分かる。

 ところが、AIプロセッサーはすでに相互接続用にEthernetのMACを実装しているものが少なくないので、このままではLPOモジュールを装着できないし、CPOのSwitchと繋ぐとトラブルの温床になり得る。GPUの場合は、そもそも主要なGPUは自前で相互接続用ネットワーク(NVIDIAならNVLink、AMDならInfinityFabric)を搭載しており、Ethernet Switchを使う必要性がない。

 PCI Express Switch経由でつなぐという方法はあるから、Ethernet Switchを利用する可能性も皆無ではないが、今では必要性はかなり薄い。あとはあるとすれば、AIアクセラレータを搭載したBlade Serverどうしの相互接続用という可能性の方が高いだろう。

 では、Blade ServerならLPOを使えるか? というと、使えなくはないのだが、そのためにはLPO対応のNetwork Cardを別途用意して、そこにLPO Moduleを装着するという迂遠な方法になる。大抵のBlade ServerにはEthernet MACが搭載されているが、これは100GBASE-DR1には対応できてもLPOには対応できないためだ。この時点で、LPOの目的の1つである"Low cost"がどこかに行ってしまう事になる。

 そもそも何でLPO(やCPO)が既存の標準規格と完全に仕様を合致させられないかと言えば、本来ならASICとTransceiverの両方にDSPを入れていたのを、1つに省いてしまったことに起因する。前回も紹介した下図(図01)に話を戻すと、以前ASIC側のDSPはPMAの処理だけに関わっており、なので光Link(つまりTP2とTP3の間)の通信状況に応じて出力を変化させるとか温度補正を行うといった細かな調整作業は、Transceiver側のDSPの作業だった。

図01:前回も紹介した図。従来Pluggable Transceiver Moduleに搭載されていたDSPを、ASIC側に肩代わりさせることが、LPOの基本的なアイデアとなる。LPO-MSA"Paper: Link Diagnostics in LPO Applications"より抜粋して作成

 といってもPICのすぐ脇にEICがあるから、PICの状態に応じてEICで制御を行うのは、極めて容易だった。ところがLPOにすると、こうした微調整を全部ASIC側で処理する必要があり、当然Transceiver側のDSPでやる時よりもLatencyが増える。

 処理性能的にはASIC側のDSPで間に合うように設計されているとはいえ、処理を開始するまでの時間がTransceiver側のDSPと同じようにできるかと言えば、答えはNoであり、加えて言えば従来型のTransceiver Moduleでは可能だった追加の信号(例えばPICの周囲に温度センサーを付けて、そのデータをDSP側で取り込んで補正に使うとか)は、LPOでは望むべくもない。細かいところでLPOの仕様が異なる、というのはこうした細かな補正がASIC側DSPではカバーしきれない、という話でもある。

送信側のみにDSPを入れ、互換性を確保したLRO

 で、そのための力業の解決策として出て来たのがLROである。構造を簡単にまとめたのが図02である。要するに今LPOで問題になっているのは、送信側のパラメータが完全に100GBASE-DR1とか400GBASE-FR4と一致しないことであり、その理由はPICのそばにDSPがない(ASIC側任せである)ことに起因する。だったら送信側だけ、Module内部にDSPを入れてやればそのまま行けるだろうという発想だ。

 実はこの形式の名称はまだLROで固まっている訳ではない。業界を見渡してみると、例えばAmphenol Communications SolutionsのOP13TI8-005DDatasheetを見てみると明確にLROと記載されている。

図02:200Gbps/λでDR4(つまり800Gbps)×2というTransceiver Module。

 ただ仕様を定める側はいろいろで、例えばOIF(Optical Internetworking Forum)ではRTLR(Retimed Tx Linear Rx)という名称で現在仕様策定に向けて作業中であることを示している。他にも、次のような呼び方がされる場合もあり、非常に分かりにくい。

  • ARO(Analog Receive Optics)
  • HALO(HAlf Linear Optics)
  • TRO(Transmit Retimed Optics)

 ただ、前回も紹介したLPO MSAもLROという名称で標準化作業を予定しているし、一般にはLROが一番名前の通りがよさそうだ。いずれは別の名称になるかもしれないが、とりあえずこの原稿ではLROで通すことにする(※)。

※注:OIFがLROを使わないのは、TCP Offloadの際のLRO(Large Receive Offload:セグメントされた状態で受信したTCPパケットを結合して、大きなパケットにしてホストに渡す機能)と混乱するからなのかもしれない(なぜOIFがLROという用語を使わないか、の説明は見つからなかった)

図03:LPO MSAのFAQより。赤線部に注目。

 そんなLROのメリットとしては、次の点が挙げられる。

  • IEEEの100GBASE-DR1/400GBASE-FR4と完全に互換になる
  • Module内のDSPの数を半分に減らせるので、従来のPluggable Transceiver Moduleと比べて消費電力をその分減らせるし、コストも削減できる。
  • 送信側の性能がホスト(ASIC)側に依存しなくなる
  • 温度補償対応や診断機能などを実装できる
従来のモジュールとLPO、LROの構成の比較。

抱える課題も多いLROは“中継ぎ”に留まるのではないか?

 ただし、消費電力を減らせるのはともかく、コストを減らせるか? というと、実はちょっと「?」である。というのは現在のPluggable Transceiver Moduleに搭載されているチップはすでにDSPを2つ(送信/受信用各1)搭載しており、これを流用するとなると、受信側のDSPを殺して使うことになるわけだが、当然これで価格が下がるはずもない。

 理論上はDSPを1個だけ搭載したチップを作れば、半減とは言わないまでもそれなりに価格は下がるはずだ。しかし、新しいチップを製造するための初期コスト(設計コストは大分抑えられるだろうが、製造のための初期コストは変わらない)は掛かるし、量産効果がどこまで見込めるかも怪しく、下手をするとむしろ価格が上がりかねない(従来のPluggable Transceiver Moduleと同じくらいの数のLRO Moduleが売れる、というのなら下がるだろうが)。

 一方で、LPOでの問題をそのまま引き継いでいる部分も少なくない。LPOもそうだが、LROではPD(Photo Detector)で受信した信号をAFEで変換した後、そのままASIC側のDSPまで信号を引っ張る必要がある。ここが現状100Gbpsでこの先200Gbpsを目指すという話になっているので、ここの配線の挿入損失に伴う信号減衰やS/N比悪化が大きな問題になる。LROの場合、送信側に関して言えば500mどころか2kmとか10kmまで到達可能な実装が可能である。ところが受信側がこれに耐えられない。現状はLPOと同じく、100Gbpsで500m以内という制約から逃れられないことになる。

 Gearboxを入れられない、というのも問題である。LROの場合、送信側はDSPがModule内にあるから、例えば100Gbpsのレーンを50Gbps×2とか25Gbps×4で受けて2:1なり4:1のGearboxを介して100Gbpsにできるが、受信側はそういうことができない。送受信で非対称な構成を許す(例えば送信は25Gbps×4、受信側は100Gbps×1)というなら不可能ではないが、実際にはこんな構成は許されないので、Gearboxは使えないことになる。

 また、ASIC側にLROの対応が必要となる。現実問題としてLPOに対応しているASICならばちょっとした対応でLROに対応できる。実際BroadcomのTomahawk 5以降はLPO/LROの両対応(Tomahawk 4は不明)になっている。ただこれはSwitch側はともかくEndpoint側からすると、LPOの場合と同じくLRO対応のNetwork Cardを必要とすることになり、ますますコスト面でのメリットがなくなる結果になる。

 現実問題として、LROは非常に立ち位置が微妙な製品となっている。使うとすればSwitch側にLROを入れて、その先に従来のEthernetを搭載したServerなりAI Processorなりがぶら下がるという形だろうか。消費電力が下がることは多少期待できるが、価格面でのメリットは現実問題としてないだろう。

 そして、今のところ100Gbps/λが速度の上限だし、配線距離も最大500m以内で、本当に近距離ラック間(AIプロセッサーとかNVIDIAなどのGPUメーカーが称するところのPodあるいはSuperPodという単位)が限界だろう。標準化団体がないことも問題で、一応先の図03に示されるようにLPO MSAがLROの標準化も手掛ける意向を示してはいるが、現時点ではまだ何も存在しない。

 正直、この先どこまで普及するかも怪しいところで、長期的にはCPOに集約されていく流れにおける、中継ぎ以上にはなれないのではないか? と筆者は考えている。

大原 雄介

フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/