ETCがリリースした「800G Ethernet」の仕様は400Gを2つ並べる構造に

「800 Gigabit Ethernet Specification」をETCが2020年4月にリリース

　間が3回分開いてしまったが、今週からは800G Ethernetについて解説していこう。まず紹介するMSAは、Ethernet Technology Consortium（ETC）だ。

　実はこのEthernet Technology Consortium、『25Gbps×4で100Gbps、光Ethernet第2世代「IEEE 802.3bm-2015」の各規格が標準化』で以前紹介した25G Ethernet Consortiumと同じ団体である。

800G Ethernet Specificationの表紙。"http://25gethernet.org/"にアクセスすると、自動的に"https://ethernettechnologyconsortium.org/"にリダイレクトされる。出典は"800 Gigabit Ethernet （GbE） Specification"

　実際、About the Consortiumにははっきりと"25 Gigabit Ethernet Consortium has rebranded to Ethernet Technology Consortium."とか書いてあって清々しいが、うかつに規格名を団体名に入れてしまうと、後の対応が大変になるということのいい例かもしれない。

　ちなみに名称の変更時期は、800G Specificationのリリースに合わせたタイミングになっている（それもあってSpecificationの表紙には両方のURLが記載されている）。なお、結成当時とは異なり、ETCはかなりメンバー企業が増えた。現在、PromotorはArista、Broadcom、Cisco、Dell、Google、Microsoft、NVIDIAの7社（NVIDIAはMellanoxの買収に伴い参加）。ほかにAdopterが40社並んでいる。

もうこの時点で内部は400Gを2つ並べる構造になるのが決まっている。出典は"800 Gigabit Ethernet （GbE） Specification"

　さて、そのETCが2020年4月にリリースした「800 Gigabit Ethernet （GbE） Specification」は、ある意味で元が25G Ethernet Consortiumだった組織らしい規格だ。右がその概略図だが、SpecificationではMAC層とPCS/FEC、それとPMAのみを規定しており、PMDについては基本的に仕様の範囲外である。

　これに関してはIEEE 802.3ckに準拠の予定と記されており、ところがそのIEEE 802.3ckそのものがまだ審議中だったりするので、要するに何も決まってない状況だ。

　ちなみに、IEEE 802.3ckの標準化完了は2022年7月が予定されている。現状で言えば、2011年3月3日にDraft 1.5がリリースされ、これをベースにDraft 2.0を作ることがTask Forceで承認された。この後はTask Force内での作業が完了次第、Working Groupによる投票に対しての作業に移ることとなる。技術的な部分での審議は既に完了しているので、このDraft 1.5をベースに、各社いろいろと検討をしているのだろう。

IEEE 802.3-2018に定義された400G MACに準拠、2つのPCS間で同期

　さて、800GのSpecificationにある以下のように、ある意味で投げっぱなしである。

　このあたりは、いずれ100GレーンのPMDの仕様（というか「IEEE 802.3ck-2022」）が公開されれば、Addendumとして補足される可能性もあるが、単に現状"Electrical IEEE 802.3ck Clauses TBD."になっている箇所に、きちんとしたClausesの番号が入るだけという気もする。

　その中身について、MAC層に関しては、IEEE 802.3-2018に定義された400G MACに準拠する格好[*1]となっている。

　ここで、400G MACを800G MACに拡張したわけではないところがポイントで、送信側の内部構造は以下のような格好だ。800GMIIからの信号は64b/66bエンコードを経て66bブロックのストリームになるわけだが、一度66bブロックにしてしまえば、その先は2つのPCSに均等に分配するかたちとなる。

送信側はGatherとMarker Insertionのみが変更され、2つの400G同士で同期を取るための仕組みが追加される。出典は"800 Gigabit Ethernet （GbE） Specification"

　次のGatherが変更になっているのは、400GのPCSで言えば66bブロックについて「#0、#1、#2、#3」をまずまとめ、次に「#4、#5、#6、#7」をまとめ、というかたちとなるのに対し、ここの構成では、左のPCS-0では「#0、#2、#4、#6」をまとめ、右のPCS-1では「#1、#3、#5、#7」をまとめるという点が唯一の変更となる。

　その後は、Transcode/Scrambleを経てMarker Insertionとなるが、ここで2つのPCS間で同期が取れる（つまり、どちらかのPCSに遅れがあったら、そちらにタイミングを合わせる）ようにMarkerを追加することでタイミングを調整し、後はそのまま送り出すという格好だ。

　このPCSの出力は、それぞれ26.5625G×16なので、トータルでは26.5625G×32という超広帯域のインターフェースになってしまう。そこで、4：1のBit Muxingを挟むことで106.25G×8構成とし、PMDへ引き渡す格好だ。

　受信は逆パターンである。まず106.25G×8を1：4のBit Demuxingを通して26.5625G×32にした後でこれを2つに分割するが、DeSkewやLane reorderなどは（光ファイバー配線の具合によるが）ここは処理を32レーンまとめて行わないと場合によっては解消できない場合があるため、共通処理となる。

　ただ、その先はReverse Transcodeまで各レーン別々に処理が可能だ。最後のSelectは、送信側のGatherの逆パターンになる。両方のPCSから1つずつブロックを集めてまとめる必要があるので、ここも結果的に共通処理とならざるを得ない。ここでシーケンシャルになった66bブロックを、最後に64b/66bデコードに掛け、800GMIIへ送り出して完了というわけだ。

受信側は最初のDeskewで同期が取れるので、後は最後のSelect段で同期を取れば、あとは別々に動いても構わないと割り切った構成。出典は"800 Gigabit Ethernet （GbE） Specification"

　Specificationには、ほかにもいくつか細かな定義はあるが、ベースとなるのは「25GBASE-R」であり、それをどれだけ束ねるかという話となっていることもあり、Specificationそのものは14ページと驚くべき薄さだ。

　このあたりは、PMDやMechanical Specificationまで含んだ25G＆50G Specificationに比べてずっと少ない（もっとも、25G＆50G Specificationも29ページと驚くべき薄さではあるが）のは当然とも言える。

　このあたりは、必要な仕様を自身できちんとまとめる必要があるIEEE 802.3に対し、「ここはIEEE 802.3のClause XXXに準拠」で済む独自規格との差というべきか。

PCSを400G×2に分割した理由は低いコストと消費電力か？

　ちなみに、PCSを400G×2に分割した理由はよく分からない。少なくともSpecificationでは「2つの400Gb/sのFEC付きPCSを組み合わせて800Gb/sの容量を得る」とあっさり述べているだけだ。技術的には100G×8や200G×4の構成も不可能ではないのだろう。

　ただ、さすがに100G×8では送信側のBonding Controlや受信側のDeskewがやや面倒になりそうなことから見送ったのだろう。一方、200G×4の可能性はあったのだろうが、400G×2の方がコストが下がりそう、というあたりの理由だったように筆者は考えてる。

　100Gは既に広く利用されているし、400Gは2020年ごろには既にモジュールも登場していたが、200Gに関してはモジュールがないわけではない（例えば英L2TEKのトランシーバーモジュール）ものの、その数は少なく、コスト的には割高となっている。

　800Gのモジュールを考えたとき、200GのPMAを流用した4基構成と、400GのPMAを2基の構成で、どちらが安価で消費電力が下がるかを考えた場合、おそらく後者の方がマシという判断があったのではないかと思う。