要約

  • Ultra Ethernet Consortium は、AMD、Arista Networks、Broadcom、Cisco、Eviden/Atos、Hewlett Packard Enterprise、Intel、Meta、Microsoft が2023年7月19日に共同で立ち上げた Joint Development Foundation（JDF）プロジェクトである。これは従来の商用企業やネットワーク事業者ではなく、仕様開発を目的とする産業コンソーシアムである。コンソーシアムは一般的なネットワーク会社や運用会社ではなく、仕様開発を目的とする産業コンソーシアムである。
  • その目的は、単なるより高速な Ethernet リンクや RoCE 置き換えにとどまらない。バージョン1.0.3の仕様は573ページに及び、ソフトウェア、トランスポート、ネットワーク、物理層に加えて、管理、ストレージ、テスト、コンプライアンスまでを対象とする。
  • Ultra Ethernet Transport は複数の送達モード、パケット単位のマルチパス、選択的再送、送信側・受信側の両方による輻輳制御、ECN、任意のパケットトリミング、任意のローカル再試行、任意のクレジットベースフロー制御、任意のエンドツーエンド輸送セキュリティを組み合わせる。
  • AMD、Broadcom、Nokia、Keysight の製品とデモで実装が始まっていることは確認できるが、公開コンプライアンスは依然として実装者の自己申告が中心であり、独立した認証を包括的に集約した登録簿や大規模展開の完全な公開台帳は確認されていない。
  • UEC の戦略的優位は、既存 Ethernet の敷居の低さと、マルチベンダーなサプライチェーンにある。一方の主要リスクは、エンドポイントの実装難易度、任意機能の断片化、RAND 型特許義務、管理・テストの未成熟性、仕様公開と実運用での相互運用性検証との間のギャップだ。

なぜ AI がネットワークをコンピュータの一部にしたのか

Ultra Ethernet Consortium は、計算経済のあり方が変化する中で誕生した。一般的な企業向けネットワークでは、インフラは複数の独立フローを十分な帯域と可用性で運ぶことが期待される。しかし、大規模 AI 学習システムや HPC では、ネットワークは同期的な単一計算の一部として機能する。数千の加速器が、パラメータ、勾配、科学データを共同演算で交換する。ある処理は、最も遅い参加ノードが必要な情報を受け取るまで進行しない。したがって、経路のわずかな偏り、短時間の輻輳、パケット欠損が起きるだけで、ネットワーク平均利用率が健康に見えていても、ネットワーク平均利用率が高いように見えていても非常に高価なプロセッサが遊休化する。

このため、運用者が最適化すべき対象は変化する。総帯域は依然重要だが十分条件ではない。ジョブの完了時間、待ち行列遅延、インカスト、損失回復、トラフィック分散、輻輳管理。大半のパケットを速く届けても、少数のパケットが遅れたままだとネットワーク全体が停止することがある。通常のトランスポート再送制御は、長いメッセージから1パケットが失われた場合に過度の時間ロスを生む。単一の経路にフローを固定した設計は、トポロジ内では効率を低下させる。

UEC の基本的な主張は、これらの問題は、スイッチの単一機能だけ、あるいは個別の輻輳アルゴリズムだけで解決できないということだった。通信はネットワークではなく、まずアプリケーション層の意味論やソフトウェアライブラリから始まる。次にメモリ登録、リモート操作、トランスポート状態、パケット配達、輻輳制御、IP 転送、Ethernet リンク、光インタフェース、物理符号化まで連続する。これらのレイヤを分断して設計すると、どこか一部を最適化してもボトルネックが別箇所へ移る。

UEC の提案は調整型アーキテクチャである。既存の Ethernet と IP を残しつつ、AI/HPC の大規模負荷に対して既存仕様が十分でない箇所だけを変更・拡張する。これは「見慣れた Ethernet に別のロゴを貼るだけ」の設計ではない。上位 API からリンク符号化速度まで、既知のネットワーク上における一貫した挙動を定義するための専用メカニズムを組み込む試みだ。

この違いが UEC の意義を示している。UEC 自体は加速器、工場、データセンター、クラウドリージョンを所有しない。参加企業や他の実装者が、NIC、スイッチ ASIC、システム、ドライバ、試験機材に同仕様を組み込む。影響はエンドポイントとインフラの共同実装に表れる。

UEC とは何か、何でないか

Ultra Ethernet Consortium は、正式には Joint Development Foundation Projects, LLC、Consortium for HPC/AI/ML Ethernet Series という法的系列名を持つ UEC プロジェクトの公開名である。法的に、UEC は Joint Development Foundation および Linux Foundation の広い枠組みに属し、会員制度、運営、知的財産、資金、対外関係を規定する既存の法的プロセスの下で機能する。

この法的構造の理解は重要だ。UEC は、会社・アライアンス・標準化機関としてあいまいに言及されることが多いが、実態としては通常の商社のような独立会社、自己資本、時価評価、独立会計で構成されるものではない。UEC は Ethernet 製品を販売したり、公共ネットワークを運用したり、会員が宣伝するハードウェアを所有したりしない。仕様作成を中心にしたコンソーシアムであり、参加企業間の実装契約を接続する役割を担う。

UEC は Ultra Ethernet Transport（UET）そのものではない。UET は仕様の中核であるトランスポート設計だが、UEC の作業は libfabric へのマッピング、メッセージ/パケット意味論、ネットワーク前提、リンクオプション、物理要件、管理、ストレージ整合、性能測定、デバッグ、コンプライアンス、テストまでを含むより広い。

UEC は、IEEE 802.3ではない。IEEE 802.3は MAC と物理層の基本標準を独自の正式プロセスで策定する。UEC はこのエコシステムを前提として連携関係を持つが、代替しない。IETF 由来の IPv4、IPv6、Explicit Congestion Notification（ECN）などのメカニズム、libfabric を管理する OpenFabrics の仕組み、ストレージ・オープンハードウェア・アクセラレータ接続を扱う関連組織も同様に UEC の上位実装の前提として並行する。

UEC のサイト表現は、あたかも国際標準化機関のように読める場合があるが、最も妥当で根拠のある整理は、JDF 配下の仕様開発国際組織であるという点だ。ICANN や ISO の公式標準機関に属しているわけではなく、ISO 番号を持つわけでもない。これは用語上の違いではなく、権限の由来と実装者が負う法的責任の実態に関わる。

UEC は、公開仕様を出して製品を自動的に相互運用可能にする権限を持たず、競合が仕様を通じて協調することを支援する。ワークグループと特許義務、適合性文書、隣接組織連携の実装を担う。

九社の設立コンソーシアム

設立は2023年7月19日、AI と HPC のサプライチェーンを構成する異なるレイヤの9組織（AMD、Arista Networks、Broadcom、Cisco、当時 Eviden（Atos 関連）、Hewlett Packard Enterprise、Intel、Meta、Microsoft）をもって告知された。この広がりは当初から戦略的優位だった。スイッチベンダーだけが設計すると、アプリケーションやエンドポイントの制約を見落とす。加速器ベンダーだけでは、単一エコシステム最適化に偏りがちである。クラウド事業者主導だけでは、シリコン、光、OS の実装経験を集約するのが難しく、仕様を製品へ普遍化しにくい。

AMD はプロセッサ、加速器、エンドポイント向けネットワークを持ち寄り、Arista と Cisco は大規模 Ethernet スイッチングと運用知見を提供した。Broadcom はスイッチングシリコン、NIC、超高速 SerDes を提供。HPE と Eviden は HPC システムと専門的な相互接続ノウハウを提供。Intel はプロセッサと Ethernet ソフトウェアを寄与し、Meta と Microsoft はハイパースケール運用者として、巨大クラスタの利用率改善と単一総合ベンダー依存の軽減を直接の動機として関与した。

コンソーシアム内には競争関係のある事業主体も共存する。メンバーは NIC、スイッチ ASIC、システム、クラウド容量、光モジュール、ソフトウェア、サポートを販売しており、特許ポートフォリオの一部は実装に必要になりうる。一部の企業は広い汎用標準で市場が拡大することを志向しつつ、他方で差別化された専有機能にも利益を得る。UEC は競争をなくすのではなく、最低限の共通インタフェースで対立するプレイヤーが共通基盤で競争できる場を作る。

HPE の Slingshot は技術系譜として示唆的である。Slingshot は Ethernet 互換で adaptive routing と輻輳管理を備えた商用 HPC ファブリックだ。HPE 発の記載では、UEC へ HPC 向け Ethernet 仕様の寄与があり、UET の一部は Slingshot の転送思想を受けていると推定される。なお、比率は独立検証がなく、UEC 公式の会計値とは扱えない。確度の高い点は、UEC が白紙から設計されたわけではなく、HPC、クラウドネットワーキング、RDMA、Ethernet の実運用経験を取り込んだ点にある。

この混成の設計背景は、「公開」と「開放」の扱いに慎重さを要求する。UEC 仕様1.0は公開され、複数ベンダーで実装可能を意図するが、同時に各メンバーは既存知見、特許、製品ロードマップを持ち込む。ドキュメント公開は技術経済条件を消去しない。

競合が協働するために設計された法的系列

Joint Development Foundation モデルは、UEC に対して事業主体化せずに正式枠組みを与える。UEC には目的、範囲、会員種別、Steering Committee、ワークグループ、知的財産義務が定義される。JDF の非営利の傘組織は法人資産と合意管理を保持し、競合間の協業を既存法令に沿って進めやすくする。

Steering Committee はプロジェクトを統治する。公開されている範囲での主な責務は、ワークグループ調整、参加者承認、資産と財務の管理、会長の選任・交代、進捗監視、公表物・商標管理である。原則は合意制で、失敗時は出席条件を満たす参加者の四分の三多数で決定できる。文書化された異議申立ては会長へ提出される。

当初会長は Meta の Brad Booth。仕様1.0.3では、AMD の J Metz を会長、HPE の Barry Davis を副会長、Arista の Hugh Holbrook を Technical Advisory Committee（TAC）議長、Marvell の Puneet Agarwal を TAC 副会長として列挙する。Paul Congdon が仕様編集者。これ以外にも物理・リンク・トランスポート・ソフトウェア作業の責任者と著者が記載されている。2026年サミット議題には別の運用責任者が示されているが、これらの肩書は仕様上の正式職位と完全一致しない。公表される公開情報からは、完全な最新の体制図は得られない。

会員種別は Steering、General、Contributor の3種。Steering は統治に参加し、通常は Steering Committee 代表を置く。General は技術グループを横断して作業可能だが委員会議席は持たない。Contributor は選定されたグループにのみ参加し、3分の2以上決議には関与しない。最新の公開ページでは General と Contributor の年会費はそれぞれ20,000ドル、5,000ドルで、Linux Foundation 会費が別途必要とされる。Steering の審査基準や現在の価格は明確ではない。

権限の偏りは実務上重要だ。広い会員構成は実装経験と展開範囲を広げる一方、ガバナンスは対等ではない。Steering に入り大規模グループを同時に運用できる資本規模の企業は、特許や製品開発を維持できるため実務上の影響力が高い。非 Steering の参加者は完成版を取得できるが、草案全体に対等に参加できない。非会員は最終仕様を取得できるが、起草プロセス全体は見えない。

プロジェクト内部情報は、一般企業秘密と同じ扱いではないが、対応ワーキンググループの公開承認までは、ドラフト素材は開示されない。これは競合が未成熟アイデアを市場へ過早に投げることを防ぐ一方、外部からは却下提案、投票ログ、中間実装上の懸念、機能採否交渉などが見えない。

4つのワークグループから573ページ仕様への拡張

2023年の当初、UEC はソフトウェア、トランスポート、リンク、物理層の4作業部会を公表した。構成は UEC のエンドツーエンド志向を示していた。会員開放は直ちに無制限公開されず、200社超が関心を示した中で、参加を段階的に進めるための教育と独占禁止対応を要求した。競合が同一製品・プロトコル要件を議論する場面では慎重さが必要だった。

2023年12月には、UEC は約40社と300人超を報告し、TAC を設置して部会を8つに拡張した。TAC の目的はアーキテクチャ的一貫性を保つことにあり、どのトランスポート仕様も、別部会で未調整の挙動を仮定していてはならない。

2024年3月には、活動企業は55社、アクティブ参加者750人超に拡大し、意図されるアーキテクチャの説明がより明確になった。

この更新で、libfabric を上位ソフトウェア API として明示し、パケットスプレッディング、柔軟順序、複数送達モード、送受信側双方の輻輳制御、ECN、パケットトリミング、Link Layer Retry、任意のクレジットフロー制御、トランスポートセキュリティ、将来のネットワーク内集合演算を導入する方向が示された。さらに、UET は既存の Ethernet スイッチ上でも機能し、機能拡張スイッチで性能向上が可能という点が示された。

制度的範囲は技術進展と共に拡大した。UEC は2024年7月に1,193アクティブ参加者、2024年8月に97社の会員という数字を示したが、定義が完全公開ではない。したがって、その後の発表数を単純加算して現在値を推計するのは誤りとなる。2025年には追加で27社の参加を主張したが、退会・統合・重複期間があるため、厳密な現在会員総数はそのまま採れない。サイトは全会員を全件表示していないことも明言する。

UEC は2025年6月11日、Ultra Ethernet Specification 1.0を公開し、公開仕様として参照可能な設計文書化を開始した。これは実装の青写真段階から実運用参照段階への転換点だった。1.0.1は9月に出され、受信クレジット起点輻輳制御のアルゴリズムと編集上の問題を修正。1.0.2は2026年1月に公開され、輻輳管理アルゴリズムを修正した。ただし公式文書の一部で1月21日と28日の発行日の食い違いがあり、この不一致は説明なく埋めない方針を維持すべきだ。

2026年7月16日公開の1.0.3は、本調査時点での参照基準であり573ページ。200Gb/s/レーン信号化と、機能交渉のブール選択を組み込んでいる。リリースノートは、パケット送達、輻輳クレジット、Link Layer Retry、物理層 ordered set 制御、トランスポートセキュリティ、アトミック操作、トリミングに関する必須修正と編集上の明確化を区別する。必須修正と注記の違いは、実装保持動作に影響するか、文書整合性に留まるかを分ける重要点だ。

2026年に開催された Member Summit（デンバー）では第2段階が示された。議題は展開、製品化、コンプライアンス、運用、性能、デバッグ、ストレージ統合、スイッチとエンドポイント試験に集中。中心設計の整合性は存在するが、実装者の能力、品質、運用性、更新体制が可用性を左右する局面だ。

5つの機能レイヤに分散するアーキテクチャ

現在の仕様は Ultra Ethernet を、ソフトウェア、トランスポート、ネットワーク、リンク、物理層に分割する。分割は理解しやすくするが、価値はそれぞれを連結する前提条件にある。

上位では AI フレームワーク、MPI、SHMEM、Collective operations ライブラリが OpenFabrics Interface、特に libfabric を介して相互接続する。UET Semantic Services Sublayer はアプリケーション意図をトランスポート事象に変換する。Packet Delivery Sublayer はその意図をパケット化し、到達させる。輻輳制御は、ファブリック投入量と経路間分散を制御し、セキュリティはエンドツーエンドの任意運用として提供。IPv4/IPv6 がネットワーク転送を担い、Ethernet リンクはトリミング、Link Layer Retry、クレジットベースフロー制御、任意機能のネゴシエーションを行う。物理層は100または200Gb/s/レーンの信号仕様と要求特性を定義する。

既存ネットワークの重要部分は維持される。UEC は IP 経路を廃止しない。等価コスト経路と ECN 対応スイッチを前提にする。多くの知性は Fabric Endpoint 側に残る。これらはエントロピー選択、トランスポート状態、データ配置、輻輳信号受信を処理する。高度化したスイッチは追加機能を提供できるが、UET を通過させるために全ファブリックを刷新する必要はない。

この構造は移行の柔軟性と分類の難しさを同時に生む。コンシューマは、通常 Ethernet+ECMP+ECN 上で UET Endpoint を使う運用ができる。別構成ではトリミング、リンク再試行、仮想チャネルクレジット、豊富なテレメトリ、将来のネットワーク内演算を追加する。名称はどちらも Ultra Ethernet でも、性能・損失回復・運用難易度は実質的に異なる。

5レイヤ設計は障害の切り分けを難しくする。問題はアプリマッピング、エンドポイント状態機構、輻輳パラメータ、スイッチキュー設定、DSCP マッピング、光インタフェース、ファームウェア、セキュリティシステムのいずれからも起こりうる。パケットを通すだけでは不十分で、混在トラフィック・障害・世代更新時に意味論と性能を維持できるかが問われる。

ソフトウェアの契約：アプリ専用 API ではなく libfabric

UEC は、適合対象エンドポイントの基準上位 API として libfabric 2.0を採用した。これにより、UEC は既存の HPC・高度ネットワーキングソフトウェアエコシステムを活用し、各フレームワークに新規の独自インタフェースを強制しない。libfabric はすでに fabric、domain、endpoint、completion queue、event queue、address vector、memory region、メッセージング、remote memory、atomics を表現する。

UEC はこれらの概念をマッピングし、制約を加えて、各ベンダーが UET 挙動へ変換できるようにする。価値は「トランスポート以上」の継続性にある。MPI、SHMEM、加速器通信ライブラリは下位実装が変わっても、従来の抽象を使い続けられる。結果として、1つの NIC がどの実装で配達するかや、どのスイッチシリコンがリパスを処理するかを意識しないアプリ設計が可能になる。

ただし、同一の libfabric 実装であっても性能や能力は一致しない可能性が残る。エンドポイント数上限、atomic 操作、メモリ登録手法、completion 挙動、ハードウェアオフロード、セキュリティ機能などは実装により異なる。したがって「libfabric supported」の1行チェックだけでは採用判断にならない。

UEC のソフトウェア層はジョブと認可の意味論も担う。AI/HPC インフラでは、複数ジョブが共有基盤上で実行され、プロセスやメモリ領域、セキュリティ境界がジョブごとに分かれる。仕様は、どの endpoint がどのジョブに属するか、どのバッファを使用可とするか、どのようにリモート操作を対応づけるか、completion やエラー情報をソフトウェアへ戻すかを定義する。これらが欠けると、ベンチマークでは高性能でも、スケジューラやランタイム、実アプリでは使いづらくなる。

UEC は libfabric を所有していないため、OpenFabrics エコシステムとの連携が不可欠だ。UEC は UET を libfabric へマップする一方で、API 保守者と利用者コミュニティと調整する。UEC は同様に、IEEE の Ethernet、IETF ネットワーク機構、ストレージ組織、ベンダーOS と協調する依存関係を持つ。

Fabric Endpoint と負荷プロファイル

Fabric Endpoint（FEP）は UET が終端する論理位置である。OS インスタンスを1つ以上の分離されたファブリック平面に接続し、ユーザ空間プロバイダ、カーネルドライバ、NIC/加速器内トランスポート、メモリ登録、セキュリティ文脈、completion queue、address vector、パケット配達と輻輳制御に使う状態を含みうる。

エンドポイント中心設計により、大半のスイッチは従来の Ethernet/IP 認識可能な装置でよい。FEP 側でエントロピー値を選び、パケット状態・輻輳状態を保持し、認可されたメモリへデータを配置し、ACK、トリミング、他の制御信号を解釈する。これにより、スイッチ内の専有知能への依存は下げられる一方、NIC シリコン、ファームウェア、ドライバ、ソフトウェア側に複雑性が集中する。

UEC は3種類の実装プロファイルを定義する。AI Base、AI Full、HPC は別個のネットワークという意味ではなく、実装要件の束である。AI Base は汎用的な AI 通信を低コスト・低状態でカバーする。AI Full は defer 可能送信、exact matching、fetch や compare 型の atomic 操作などを追加。HPC プロファイルは AI Full の主要機能を含みながら defer 送信を除外し、順序制御、短メッセージ、HPC 意味論をより重視する。

この設計は各製品がフルセットを実装する必要を避ける意図がある。大量 AI NIC はコレクティブ移動を優先でき、HPC endpoint では順序性と atomics の厳密性が重要になる。一方で任意機能の問題は残る。あるプロファイル内であっても、任意機能の有無でセキュリティ・リンク拡張・容量・性能が変わる。

用語自体が警鐘を示す。正式な1.0.3仕様は AI Base、AI Full、HPC を採用する。別のコンプライアンス readme（2025年）は AI Base、AI Extended、HPC を使う。支持されるのは「AI Full」が現行表記であり、適合性パッケージは旧式か不整合である可能性が高い。公開テストを行う関係者や購入者は、主張ごとに仕様版と用語を明示するべきだ。

アプリケーションの意図からパケット送達へ

UET 内では、Semantic Services Sublayer がアプリケーション意図を運ぶ。メッセージ識別、バッファ宛先、tag 付き/未 tag 付き操作、リモートメモリアクセス、atomics、completion 振る舞い、ジョブ ID、バッファ認可、応答とエラーを定義する。Packet Delivery Sublayer が次にそれをパケット化し、別 endpoint へ到達させる。

信頼性モードでは、エンドポイントは Packet Delivery Context（PDC）を設定する。PDC はシーケンス番号、ACK、重複検出、順序モード、輻輳情報、再送方向、トラフィック分類を保持する。1つの FEP 対で複数 PDC を持てる。

この状態管理は軽視できない。大規模クラスタでは通信関係が膨大になり、宛先ごとに重い状態を要求すると、メモリや探索コストがボトルネックになる。UEC は単一接続モデルへの拘束を要求しない。代わりに4種類の送達サービスを用意し、信頼性と順序の組み合わせを分けている。

Reliable Unordered Delivery（RUD）は、意味論には完全1回配達を保証するが順序は任意。複数経路でのパケットスプレッディング、選択的再送、重複抑止、直接データ配置を特徴とする。宛先が再順序待機バッファを構築せず、オフセットで配置できるため、長い集合通信でも欠落した1パケットを待つために全パケットが列で詰まる問題を緩和できる。

Reliable Ordered Delivery（ROD）は、完全1回かつ順序保証を維持する。単一路と単一エントロピーを用い、順序外到着分は破棄し、欠番から Go-Back-N 回復を行う。RUD ほど高度には見えないが、順序が必須な用途では必要な意味論を保つ。UEC は、順序はアプリ要件として扱い、全トランスポートが順序コストを払う設計を前提としない。

Reliable Unordered Delivery for Idempotent Operations（RUDI）は別のトレードオフだ。少なくとも1回配達で重複を許容し、受信側のシーケンス状態と ACK 負荷を減らす。最終結果が同一である処理（たとえば一部リモートメモリアクセス＋同期バリア）では有効だが、誤って非冪等操作に使うとアプリ状態を破壊する。重複判定はパケット層ではなく上位ソフトで決定される。

Unreliable Unordered Delivery（UUD）は、ベストエフォートのデータグラムを提供する。従来の信頼性/順序保証は限定的で、制御トラフィック共有時には UUD 側が過度に負荷をかけない設計が求められる。

4方式は、エンドポイントが処理コストと意味論要件のバランスを取りやすくする UEC の中核思想を示す。効率向上の一方、実装・試験面は広くなり、相互選択の組み合わせ不整合リスクも増える。

Packet spraying: 単発経路への運に依存しない活用

従来の ECMP は通常、フロー全体を固定ハッシュで1経路に割り当てる。Clos ファブリックでは、複数の大流量フローが同じリンクに集中し、別の余力あるルートを使わないことがある。AI の長時間転送は、たまたま悪い経路選択で全生存期間を拘束されることがある。

UET は、パケット粒度でエントロピーを切り替えることでこれに対応する。送信側は多数のエントロピー値を使い、既存 ECMP が複数経路へ分散できるようにする。Packet Delivery Sublayer がシーケンス情報を供給し、Congestion Management Sublayer がエントロピー/経路を選定、スイッチは通常のハッシュを実行し、逆方向のフィードバックで輻輳しやすい値を送信側が回避する。

パケットスプレッディングは他要素とセットでなければ成立しない。パケットは順序外到達が前提で、RUD は再順序待ち行列なしで直接配置できる。選択的再送は対象分のみを戻す。輻輳フィードバックで混雑した経路を回避する。したがってこれは単発分散技術ではなく、複数経路の多様性を前提にしたトランスポート全体モデルだ。

UEC は、すべてのスイッチが独自の適応経路制御アルゴリズムを必須としない。基本実装は ECMP 上でラウンドロビンまたは擬似ランダムエントロピーを使える。先進的なエンドポイントは ECN・遅延・トリミングをエントロピー値に結び付け、混雑経路を回避する。ベンダーの適応転送は UEC と共存可能だが、経路情報の唯一のソースではない。

期待効果はファブリックの有効利用向上と列遅延低減だが、課題は各エンドポイントのフィードバック解釈一貫性と、パケット再順序、欠損、混合トラフィックでの相互作用にある。同一プロトコルでも、均質な実験室環境と多世代スイッチ・複合トラフィックの実運用では挙動が変わる。独立かつマルチベンダーな実証は依然限定的だ。

三つの輻輳制御メカニズム

UEC は単一の普遍アルゴリズムを提示しない。核の輻輳は主に3種類を想定する。

Network-signal Congestion Control（NSCC）は送信元主導。送信側はウィンドウを保持し、飛行中バイト数を推定、ACK/NACK、タイムアウト、遅延、ECN といったネットワーク信号で更新する。これはパケット単位のマルチパスと連携して動く。

UEC は、ウィンドウが自然に送信を止める挙動を強調する。純粋なレート制御はフィードバック欠如を過誤解釈する可能性があるという主張だ。

これは設計上の論点であり、NSCC がすべての実装より優れるという独立証明ではない。結果はアルゴリズム実装、スイッチ信号、トポロジ、トラフィックパターン、パラメータ選択に左右される。DCQCN 等との比較は、単独での性能主張にはならない。

Receiver-credit Congestion Control（RCCC）はインカスト対策。多数の送信元が同一先端へ同時送信する場合、受信側リンクがボトルネック化し得るため、受信側が需要を追跡し、クレジットを送信元間で配分し、競合に応じて実効ウィンドウを調整する。RCCC は NSCC と併用可能で、核輻輳と受信側過負荷は別ドメイン。

Transport Flow Control（TFC）もクレジットを使うが、主に点対点でバッファが小さい場面を対象とする。直接受信バッファのオーバーフロー回避が目的で、上記2方式と同一と扱うのは不正確だ。

UEC は全ファブリックで ECN の利用を前提とし、dequeue 段でのマーキングなど運用前提も示す。エンドポイントは ECN を ACK、遅延、トリミング信号と合わせて解釈する。したがって、スイッチ側の設定整合が本質で、トランスポート実装自体が正しくても誤設定のネットワークでは不良になる。

保守履歴も重要。1.0.1は RCCC 発信元アルゴリズムを修正、1.0.2は輻輳管理のケースを修正、1.0.3はクレジットと Link Layer Retry の相互動作を修正した。これは仕様改版の自然な進展であると同時に、クレジット、再送、経路制御状態が複雑に連関することを示している。運用ではバージョン固定管理と回帰試験が前提になる。

Packet trimming と正確な損失回復

Packet trimming は、リンク上で全フレーム保存が困難な場合のスイッチ動作を変更する。フレームを破棄する代わりに、ヘッダと必要なメタ情報を残したうえで、ペイロードを多くまたは全部切り落とし、trimmed として受信側へ通知する。受信側は不足分を送信側へ特定して通知可能になる。

これは ECN 単体の印だけ表示する方式より情報量が高い。ECN は輻輳が起きたことを示すが、trimming はペイロード喪失した具体パケットを示す。RUD と選択的再送と組み合わせると、タイムアウト待ちを避けつつ対象データのみ再送しやすくなる。

トリミング自体は任意のスイッチ機能であるが、適合エンドポイントは関連要件で trimmed パケットを受け取れる必要がある。これにより、通常 Ethernet でも UET を稼働でき、改善されたファブリックではより豊富な欠失情報を活用できる。ただし移行時は経路・プロファイル・トポロジにより trimming を制限する必要がある場合がある。

UEC は trimming 対象通信を、リクエスト・制御パケット・再送・トリミングトラフィックの4種に分類する。エンドユーザは DSCP 値、スイッチキュー、endpoint キュー、優先度を一貫設定しなければならない。仕様は一元管理方式を一律に規定していないため、運用誤設定は制御信号を枯渇させ、回復処理と制御トラフィックの競合を招く。

trimming は実装全体の難しさを象徴する。仕様上のパケット形式が示されても、運用結果はスイッチキュー、エンドポイント論理、テレメトリ、設定、障害処理に依存し、相互運用性はパケット定義そのものよりシステム性質になる。

リンク回復、クレジット、機能ネゴシエーション

Link Layer Retry（LLR）は物理リンク段で損傷を回復し、トランスポート側の全体再送に至る前に対処する。ピア間でシーケンス欠落や破損フレームを検出すると、リンク層の NACK を出して送信側へ再送を要求し、ローカルバッファから再送出する。回復が早ければ、全域経路を再利用する再送より短時間で済む。

LLR の価値は速度の高いレーンと高密度ポートほど増す。光・電気的ノイズによる断続欠落は、同期 AI ジョブに大きな遅延を与えることがある。一方、LLR はシーケンス状態、再送バッファ、制御メッセージ、破棄ウィンドウ、追加故障モードを増やす。クレジット更新やリンクリセットとの同時運用も必要となる。1.0.3では CBFC 情報と LLR の競合ケースを含む境界値を修正した。

Credit-Based Flow Control（CBFC）はリンクレベルの仮想チャネル方式で、受信側の残容量を送信側へ知らせる。優先度による一時停止より粒度の細かい制御が可能。UEC は lossless 制御をサポートするが、全 UET 展開が無損失を要求する設計ではない。

CBFC は Priority Flow Control と同義ではない。信号方式と粒度が異なるが、両者ともバッファ枯渇防止を狙う。CBFC は設定整合と制御フレーム受信の正確性を要求し、エンド側のローカルウィンドウはエンドツーエンドウィンドウや受信側クレジットと組み合わさって複数の制御ループを形成しうる。

UEC は LLDP を用いた機能ネゴシエーションで、互換性のない隣接先へ機能を有効化しない。ここではプロファイル、仮想チャネル、DSCP 対応、優先度、リセット、ソフト更新、部分展開組み合わせを考慮する。1.0.3は機能ネゴシエーションのブール能力を追加し、リンクごとの明示合意要件を強化した。

こうして通常 Ethernet から拡張 Ethernet へ段階的遷移が可能になる。一方、製品選択の言語では誤解が起きる。あるスイッチは trimming、LLR、CBFC なしで UET を中継できるが、別のスイッチは一部機能のみ特定バージョンでのみ対応する。信頼できる導入一覧は、仕様名だけでなく有効機能セットを明示しなければならない。

100と200ギガビット/レーンの物理符号化

UEC の物理層は、Ethernet のハードウェア開発ロードマップに接続する。1.0版では100Gb/s/レーン符号化を前提に作業が始まった。1.0.3では200Gb/s/レーンを追加し、最新世代の高密度リンク・システムに合わせた。

ただしこれはドキュメント上の対応であり、すべての UEC 製品が即時に200G レーンを備えることを意味しない。

物理層では、前方誤り訂正（FEC）の統計、訂正可能/不能な codeword 比率、ordered set 制御、リンク品質報告、物理層エラーと LLR の連携なども扱われる。トランスポート回復は、下位層が観測・報告できる情報に依存するため、物理設計はトランスポート戦略と切り離せない。

速度が上がると、光、SerDes、FEC、ローカルリトライ、トランスポート回復の境界が経済的に重要になる。強い FEC は残留エラーを減らすが遅延と電力を増す。リンクリトライは局所復旧を速める代わりにバッファと状態を要する。エンドツーエンド再送はネットワークを通るため遅延は増えやすい。UEC はこれらを連携設計し、ベンダー任せの最適化を避けようとしている。

200Gb/s/レーン追加は、UEC が進化し続けることの表れでもある。1.0仕様実装は後方互換を保ちながら新しい物理能力へ備える。試験装置、ファームウェア、管理機構は各ポートの対応能力を識別しなければならない。UEC 仕様の一般論から、レーン速度を断定しないことが重要だ。

エンドツーエンド転送セキュリティ（任意）

Transport Security Sublayer（TSS）はエンドポイント間の任意運用セキュリティを提供する。脅威モデルはスイッチを信頼前提に置かない。機密性、完全性、リプレイ耐性、ジョブ隔離、secure domains、グループ鍵、鍵更新、ハードウェア信頼根幹との連携を提供しうる。

設計上、secure domains は加盟ノード群が暗号文脈を共有する。識別子、association 番号、epoch、secure origin ID、鍵派生が、エンドポイント対ごとに独立セッションを張るより拡張しやすい。加速器の入れ替えやジョブ構成変化が激しい環境向けに必要な設計でもある。

TSS はシステムの一部にすぎない。運用上は鍵管理機関、証明書や他の信頼基盤、ジョブ加盟管理、鍵配布と失効、epoch 遷移、エンドポイント復旧、ハードウェア暗号化、セキュリティテレメトリを整備する必要がある。ネットワーク運用ではプロファイル選択時に TSS 機能を未必化してもよく、UEC 適合が即座に通信経路全体暗号化を意味しない。

任意性は導入形態の違いを反映する。専有クラスタで物理的制御を強くし、性能を優先する環境では制御ベースで進める。一方、マルチテナントのクラウドでは強い分離と暗号保護が必要だ。各プロファイルで価格条件と導入時の差を明確化することが不可欠。

最も深刻なリスクは暗号化オーバーヘッドそのものではなく、ライフサイクルの事故だ。メンバー情報の陳腐化、失効遅延、epoch 不整合、エンドポイント障害後の再統合、どのジョブがどのメモリへアクセス可能かの検証不全。これらはトランスポートセキュリティを規格外の外部オーケストレーションと ID 系に結び付ける。

現在の「UEC compliant」とは

UEC はバージョン1.0からコンプライアンス素材の公開を始めたが、制度として成熟した独立認証枠組みには至っていない。公開されるパッケージは実装者の自己申告寄りに設計され、要件対応表はプロファイルで整理し、テストベッドは推奨エンドポイントとスイッチ構成を示す。公開情報には、外部独立機関が「UEC 全体」を合格・不合格を明示した一覧はない。

この区別は重要だ。ある製品は UEC 要件を反映した能力を装備している可能性があるが、選択機能だけを実装している段階のこともある。ベンダーが完全準拠を主張しても、独立第三者によるエンドツーエンドの多ベンダー検証とは一致しない。

テストベッド推奨は有用だが意図的に限定的である。ベストプラクティス向けのトポロジと検証を提示する一方、相互運用性の幅、総合性能、ストレス、スケール、API ライフサイクルを網羅しない。UEC と RoCE の混在トラフィック、反復障害、大規模ドメインでの鍵管理には十分な裏取りがない。

さらに AI Full/AI Extended の不整合は、版管理の厳密性が必要であることを示す。検証主張は、どの仕様、どの改訂、どのプロファイル、どの任意機能を対象にしたものかを明示するべきだ。根拠が自社内部試験か、コンソーシアム内デモか、独立ラボかを識別する必要がある。

次段階として求められるのは、版ごとの公開試験定義、複数ベンダーの plugfest、独立管理された結果（不合格含む）、endpoint、スイッチ、ソフトウェア、システム構成を分離して示す登録簿だ。現時点では「UEC compliant」は出発点であり、完成条件ではない。

公開仕様、しかし RAND 特許義務

Ultra Ethernet Specification 1.0.3は公開で取得可能で、Creative Commons Attribution-NoDerivatives 4.0で配布される。再配布自体は属性表示が必要だが、改変配布は許可されない。著作権アクセスと特許アクセスは別問題である。

公開作業文書の多くは、合理的・差別しない条件（RAND）での仕様開発を前提にしている。RAND は royalty free を意味しない。価格が普遍的に低いことを保証せず、協定交渉をなくすわけでもなく、有効性、地域、法的防御条件などの論点を残す。実務的条件は、個別特許の宣言、メンバー間のコミット、双務契約の有無で変わる。

UEC には Necessary Claims（必要主張）の公開台帳がある。調査時点では、Broadcom、Microsoft、Huawei、Qualcomm、AMD、HPE、Google、Marvell ほか、1.1関連の将来系提出を含む登録が確認された。これは実装や販売前に知財調査が必要であることを示す透明性指標でもある。

UEC は主張が特許が有効か・実際に不可欠か・侵害か・具体価格かを断定しない。共通ライセンスは公開しない。小規模実装者は、価格・交渉負担を大きく受ける可能性がある。公開仕様があっても、特許解消コスト、シリコンコスト、試験コストが高いと市場は依然集約化しうる。

知財ガバナンスは、企業インセンティブをも形成する。各社は自社技術を広い市場へ拡張するため仕様へ寄与しつつ、既存技術が共通設計へ反映される条件も確保したい。特許申告は、早期かつ明瞭な場合のみ予期せぬ障害を避けられる。採択後にライセンス条件が導入障壁へ変わる可能性を排除できない。

正確には「公開で、マルチベンダーであり、RAND 上の義務がある」という記述が妥当で、いわゆる「ロイヤルティ不要」の表現は誤りだ。調達チームは技術仕様と同様にライセンス戦略を前提条件として扱う必要がある。

実装と試験の最初の波

実装の実証は1.0公開後から可視化したが、成熟段階はばらつく。

AMD は2025年4月、AI Pollara 400 NIC を市販化し、UEC 向け機能を前提とする設計と説明した。Pollara はプログラマブル endpoint で、仕様が進化しながらハードウェアに入る重要な兆候だ。開発中の機能を前提とする設計は独立試験済み1.0.3完全適合とは同義ではない。

Broadcom は2025年6月、テラビット級スイッチ ASIC である Tomahawk 6を発表した。10月には Thor Ultra 800G NIC を発表し、UEC 機能の完全適合を主張した。販売側声明は重要だが、公的に独立ベンダーが認定した証拠にはならない。サンプリング方法、ソフトウェア成熟度、対応プロファイルは別に確認する必要がある。

Nokia と Keysight は2025年10月に、Nokia 7220と7250ファミリを用いた800GbE でのエンドツーエンド UET デモを実施。Keysight がトラフィック生成と検証を担当した。これは商用系へ UEC サポートが入りつつあることを示すが、完全版のマルチベンダーendpoint、運用規模、独立的適合認定を示さない。

他のメンバーも UEC 対応のスイッチ、システム、ソフト、検証計画を公表しており、2026サミットは製品化に焦点を当てた。これらの証拠は仕様採用が進行していることを示すが、NIC 単位量産数、認定済みスイッチ数、公開クラウド領域、完全なファブリック体験については未確定だ。

この波は、仕様公開→ベンダー設備投資→トラフィックデモ→コンプライアンス要件整理→運用報告、という構造で読むのが有用だ。独立 plugfest と本番結果が不足している点は共通。

RoCE、InfiniBand、Slingshot、UALink

UEC は、Ethernet が RDMA を送れなかったわけでも、特殊ファブリックが機能しないわけでもないという問題提起ではない。むしろ現在の AI 負荷規模と同期性に対し、Ethernet 上で端到端的に再設計された配達・経路・輻輳制御の柔軟性が必要だとする。

RoCEv2 は直接の前段で、ルーティング可能な RDMA トランスポートとして広く採用される。UEC は RoCE がフロー全体の経路固定、Go-Back-N 再送、受信側再順序化、DCQCN の難調整、Priority Flow Control 依存、インカスト時の問題などの従来型運用を指摘する。これは UEC 側の技術的見立てであり、RoCE 全体が常に低性能という意味ではない。

対比は動的だ。ベンダーはプログラマブル NIC で適応ルーティング、packet spraying、改善された輻輳制御、RoCE 互換拡張などを追加しうる。AMD は Pollara で、RoCEv2 と UEC RDMA を同一プラットフォームで併置可能として示した。UEC は RoCE が成熟した代替として、かつ RoCE の進化にも影響を与える可能性がある。

InfiniBand は成熟した専用 RDMA エコシステムで、XDR 200Gb/s/レーンを含む Infiniband Trade Association 2.0の動き、更新されたテレメトリが特徴だ。UEC の差別化は InfiniBand が劣るからではなく、Ethernet の広い鎖を通して AI/HPC 性能を実現する選択肢とベンダー選択性にある。

HPE Slingshot は、Ethernet 互換で adaptive routing と輻輳管理を備えた商用 HPC ファブリックとして、UET 技術への実務的参考例を提供した。これは商用プラットフォームとして高度に統制された環境で動作する一方、業界共通仕様として全産業を開く UEC とは別レイヤに位置づけられる。

UALink は補完が本質で、直接代替ではない。現在の公開仕様は200G で、主にポッド内低遅延の scale-up 接続（最大1,024加速器）を想定する。UEC1.0 の中心は scale-out（スイッチを介したノード間接続）だが、今後の scale-up 最適化やネットワーク内集合演算が進めば、収束か競合のどちらかに進展しうる。

NVIDIA Spectrum-X などのアクセラレータ専有構成と比較すると、密接統合は最適化を速やかに実現する反面、特定エコシステム依存を深める。UEC はその一部を共通インタフェース化し、複数提供者選択に置き換える試みである。移行価値は性能、サポート、特許条件、運用コスト合計で決まる。

運用の本質は、プロトコルより重い

573ページの仕様でも、運用は573ページだけで完結しない。UEC 1.0は、管理面の重要事項の一部を公開仕様外または周辺で扱う。運用者は、プロファイル、トラフィック分類、ECN 閾値、エントロピー集合、任意リンク機能、鍵、ファームウェア、テレメトリ、障害ポリシーをエンドポイントとスイッチで整合させる必要がある。

混在トラフィックは問題を難しくする。UET、RoCE、TCP、ストレージ、管理、および順序付き/順不同 UET が同時に走る。分類キューや公平性設定は、仕様を実装済みであるだけでは決まらない。孤立した制御器のアルゴリズムは、別制御器の異なる前提と競合し、共存時に性能悪化を招く。

エンドポイントの複雑性は構造的リスクである。UET はマルチパス、Direct placement、選択再送、複数送達、ウィンドウ・クレジット制御、trimming 受信、セキュリティ、エンド状態を取り込むため、NIC ダイ面積、ファームウェア容量、検証工数、消費電力、障害診断条件を増大させる。エンドポイントはベンダー選択を広げる一方、各サーバで購入するコンポーネントの実装難易度を高める。

任意機能は差別化と断片化を同時に生む。ある企業は AI Base+ECMP/ECN を優先し、別企業は AI Full/TSS/trimming/LLR/CBFC を実装する。両者は UEC 文脈に属していても、意味論・性能・安全性は同一ではない。コンプライアンス表は、実際には運用品質表へと置換される。

バージョン保守は継続的になる。1.0.1〜1.0.3の修正は、輻輳・クレジット・再試行・パケット挙動に及ぶ。大規模クラスタには世代を超えた NIC ファームウェア、スイッチリリース、試験ツールが混在するため、ある層だけ更新すると別層との不整合を露呈しやすい。

UEC の外部連携は運用上重要だ。Open Compute Project はオープンなシステム・ハードウェア統合、OpenFabrics Alliance と libfabric コミュニティはアプリ接続、IEEE 802.3は Ethernet 標準、SNIA と NVM Express はストレージ・管理要件、IETF は IP・ECN 関連の基盤を担う。各組織の決定やロードマップは異なるため、連携は重複を減らすが同時普及を保証しない。

最終証拠は稼働基盤だ。仕様は挙動を定義し、ベンダーは製品を公表し、サミットは合意形成する。だが独立の障害条件下で、複数ベンダーの endpoint とスイッチが大量ジョブを完了させ、運用者が失敗原因を説明できることがなければ、信頼性は成立しない。

現在の評価: 仕様の勝利から実装の信頼性へ

2026年7月時点で、UEC は当初不透明だった複数点を達成した。広い連携ネットワークを形成し、5レイヤ統合アーキテクチャを示し、1.0仕様を公開し、修正版を継続し、200G/レーンへ拡張し、特許宣言を開示し、製品と試験の報告を増やした。プロジェクトは継続的に進展し、実装期へ明確に移行した。

この進展は、前の不透明期の疑問を別の意味で前進させるが、不確実性を消さない。現在の Steering 構成と会員全体は一元的に公開されておらず、公表ページと規約の間でアクセスの説明がずれる。TAC の正式任命は議事とサミット責務で完全に一致しない。1.0.2の発行日は文書間で食い違いがある。適合性パッケージも AI Extended を残す。どれも、バージョン精度が重要なプロジェクトにおけるガバナンス透明性のシグナルだ。

採用判断を揺らぐのは、これらの隙間でもある。UEC は、独立検証済みの完全運用台帳、独立認定の製品登録、自己予算、監査済み決算を公開していない。十分なエビデンスは、最大規模の目標値に対して「完全に相互運用可能な UEC 1.0」環境をまだ示していない。デモとベンダー主張は価値があるが、同時に商業的利害を持つ主体からの情報でもある。

それでも機会は大きい。Ethernet はデータセンターの共通母体であり、AI インフラ市場は次世代の NIC、スイッチ、光学、ソフトを吸収する規模を持つ。運用者には、単一ベンダー依存の回避と加速器利用率改善という共通要求がある。共通スタックは購入力の変換に使える可能性がある。

ただしリスクとして、「Ultra Ethernet」が不完全な部分集合の屋根となる危険がある。基本中継だけが機能して、プロファイル、輻輳、セキュリティ、管理で設計が別れれば、ブランドは実装より早く広まり、真の相互運用は遅れる。RAND のコストが高く不透明なら、選択可能な供給者は狭まる。RoCE が主要な機能だけを吸収して UEC の主要要素を実質的に再現した場合、UEC は市場ラベルとしては影響力を持つ一方、正式タグとしては競争優位を取り切れない可能性がある。

決定的な問いは、仕様公開ができることではない。すでにできている。問われるのは、独立の組織が同一契約を実装し、必要な技術をライセンスし、ファブリックをスケールで運用し、仕様更新と互換を保てるかどうかである。UEC がインフラとして成立するのは、その主張が運用現場で生き残る時だ。