UItra Ethernet Consortium ワーキンググループの最新情報

UItraイーサネットコンソーシアムの研究方向性

UItra イーサネット コンソーシアムは、物理層、リンク層、トランスポート層、ソフトウェア層からイーサネット テクノロジを向上させることに取り組んでいます。 現在のイーサネット エコシステムとの互換性を前提として、イーサネットの転送パフォーマンスを向上させ、イーサネット通信プロトコルとアプリケーション プログラム インターフェイスの改善に取り組んでいます。 また、ストレージ、管理、セキュリティ構造、テレメトリ機能も向上し、UItra Ethernet テクノロジーが人工知能とハイパフォーマンス コンピューティングのネットワーク ニーズを満たすことができます。

Ultra Ethernet Consortium は、重点を置く必要があるネットワーク タイプを Type2 ネットワーク (バック エンド ネットワーク) として特定し、Type1 ネットワーク (フロント エンド ネットワーク) での使用に反対していませんが、Type2 のネットワーク パフォーマンスが低下することはありません。 Type1に適応させる必要があります。

タイプ 1 およびタイプ 2 ネットワーク

UEC はネットワーク タイプごとにパフォーマンス メトリックを決定します

電気通信大学ワーキンググループ

UEC は当初、物理層、リンク層、トランスポート層、ソフトウェア層の XNUMX つのワーキング グループを設置し、優れた成果を上げました。 最近、ストレージ、管理、互換性とテスト、パフォーマンスとデバッグのワーキング グループが設立され、活動を開始したばかりです。 以下の図は、UEC のワーキンググループを示しています。

UECのXNUMXつのワーキンググループ

物理層ワーキンググループ

物理層ワーキング グループは、物理パフォーマンスの向上、遅延の削減、イーサネット物理インフラストラクチャの管理の改善に取り組んでいます。 これには、イーサネット物理層仕様、電気信号および光信号特性、アプリケーション インターフェイス、およびデータ構造の開発が含まれます。 その目標は、基盤を強化し、イーサネットが Al および HPC の厳しい要件を確実に満たせるようにすることです。 現在の物理層ワーキング グループは、100G/レーンおよび 200G/レーンの PHY 仕様の策定に取り組んでおり、100G/レーンのメディア タイプと PHY でサポートされるレートとタイプを決定しました。 200G/Lane の仕様は IEEE P802.3dji の承認後に決定されます。

物理層ワーキング グループは、リンク品質予測のためのいくつかの新しい概念を導入しました。UCR (修正不可能なコードワード比)、MTBPE (PHY エラー間の平均時間)、および MTTFPA (誤ったパケット受け入れまでの平均時間) であり、物理層の予測と測定に特化しています。レイヤリンクの品質をより正確に測定します。

リンク層ワーキンググループ

リンク層ワーキング グループは、リンク層伝送の信頼性と効率の向上、およびリンク層テレメトリ機能の向上に取り組んでいます。

リンク層の主な研究方向は次のとおりです。

リンク層の信頼性:

リンク層でのエンドツーエンドのエラー パケット再送信のために、LLC サブ層と MAC CONTROL サブ層の間に位置する LLR サブ層をリンク層に追加します。

クレジットベースのフロー制御:

リンク層でエンドツーエンドのクレジットベースのフロー制御メカニズムをサポートし、リンク間のフレームのロスレス伝送を管理します。 CBFC (クレジットベースのフロー制御) メカニズムは、PFC フロー制御の代わりに使用されます。 受信者は定期的にバッファ スペースをピアに送信し、送信者はメッセージの優先順位とバッファ サイズに基づいてメッセージを送信します。 バッファ スペースは、適応型ルーティングの選択にも使用できます。

クレジットベースのフロー制御

パケットレートの向上:

フレーム送信効率を高めるために、イーサネット メッセージ ヘッダーの圧縮に取り組んでいます。 イーサネットの長期的な進化の過程で、メッセージ ヘッダーは拡大し続け、その結果、伝送効率が比較的低くなりました。 多くの分野はインテリジェント コンピューティング ネットワークでは使用されません。 したがって、メッセージ ヘッダーを圧縮し、フレームの送信効率を向上させることが不可欠です。

圧縮メッセージと非圧縮メッセージがネットワーク内で共存するには、メッセージが圧縮されているか非圧縮であるかを示すフラグがメッセージ ヘッダーに必要です。 送信者は、元の機能に影響を与えることなくメッセージを圧縮するかどうかを選択できます。

現在、メッセージ ヘッダー圧縮には複数の解決策があり、議論中です。

ネゴシエーション：

リンク層のパラメータと特性のネゴシエーション方法を確立します。 リンク層のいくつかの新機能 (LLR、CBFC、PRI など) をサポートするにはネゴシエーションが必要です。 主なアイデアは、LLDP を拡張し、デバイス間の新しいリンク層機能のネゴシエーションのために UEC OUI を追加することです。

トランスポート層ワーキンググループ

UET (UEC トランスポート層) ワーキング グループは、最も困難なアプリケーションの拡張、信頼性の高いメッセージ送信、安全なデータ送信、およびネットワークの輻輳の回避に取り組んでいます。 その目標は、RoCE 伝送の欠点を解決し、効率的で信頼性が高く、安全な大規模伝送を提供することです。 ターゲットのトランスポート エンドポイントは 256,000 に達し、サポートされるプロセスの数は 100,000,000 に達します。

UET の主なモジュールを次の図に示します。

UETの主要モジュール

UET には、パケット配信、セキュリティ、セマンティクスという XNUMX つのモジュールが含まれています。 各モジュールの機能は次のとおりです。

• パケット配信サブレイヤー (PDS):

PDS には、信頼性と輻輳管理という XNUMX つのモジュールが含まれています。

信頼性モジュールは、次の XNUMX つの主要な要件をカバーする必要があります。

1. 極端なスケーラビリティ
2. 秩序あるメッセージ送信
3. 順序付けされていないメッセージ送信

信頼性モジュールは XNUMX つのメッセージ送信モードで設計されており、各モードは HPC、Al、ML、およびその他のアプリケーション シナリオを満たす特定の目的に使用されます。 XNUMX つのメッセージ送信モードは次のとおりです。

信頼性の高い順序配送 (ROD):

このモードはメッセージを順番に送信し、メッセージを順番に送信する必要があるアプリケーションに使用されます。

信頼性の高い、順序付けされていないオペレーション配信 (RUD):

このモードでは、メッセージをセマンティック層に XNUMX 回しか送信できませんが、ネットワーク内で順序付けされていない配信を許容できます。 信頼できるトランスポート層は、重複メッセージを検出して、各メッセージがセマンティック層に XNUMX 回だけ送信できるようにする必要があります。

冪等操作に対する信頼性の高い順序なし配信 (RUDI):

このモードは、RDMA の読み取りおよび書き込み操作用に最適化されています。

信頼性の低い、順序付けされていない配信 (UUD):

信頼性の低いメッセージには、UET の多くの新しいセマンティクスが含まれる可能性があります。 UDD のユーザーは信頼性の高い送信を必要とせず、他の信頼性の高い方法を使用します。

輻輳管理モジュールは輻輳管理や負荷分散などを含めて検討中であり、各FEPに基づいて輻輳管理を行うことができる。 中心となるのは、受信者のクレジットに基づくフロー制御です。 輻輳制御は、ウィンドウ サイズと注入速度を定義します。 目標は、レートを下げてメッセージを制限し、中間ノードとエンドポイントでの輻輳を回避することです。 パス負荷分散は、特定のメッセージがどのパスを選択するかを定義し、ECMP を使用してパスを選択できます。

• 輸送セキュリティ:

トランスポート セキュリティは UET 設計の最優先事項であり、すべてのデータ ペイロードとほとんどの送信ヘッダーの暗号化と認証をオプションで行います。

• セマンティクス：

UET セマンティック レイヤーは、高性能で拡張性の高い操作を提供し、特殊な Al およびフル機能の HPC 展開を可能にします。

セマンティック層は、ユーザー ソフトウェアと PDS (メッセージ配信層) の間のブリッジです。 セマンティック レイヤーは、一連の
この層は、さまざまなオプションのイニシエーターやターゲット完了通知機能など、オプションのソートを提供します。

セマンティック レイヤーは、コネクションレス呼び出し API を提供し、*CCL、MPI、OpenSHMEM、およびその他の API をネイティブにサポートする必要があります。

ソフトウェア層ワーキンググループ

ソフトウェア層は、*CCL、MPI、SHMEM など、現在広く採用されているさまざまな通信ライブラリとの互換性を通じて、データ プレーン フレームワークとして libfabric API を使用することにより、UEC の迅速な導入を促進します。 関連するアクセラレータ API を含む、さまざまなアクセラレータと FEP の間の対話を定義します。 これは、スイッチ、FEP、およびアグリゲーション マネージャー (AM) のコントロール プレーンとデータ プレーンのメカニズムを定義し、異なる UEC ベンダー間の相互運用性を可能にします。 これは、UEC が複数のワークロード プロファイルをサポートする必要性に対処します。

ソフトウェア層ワーキンググループ

ソフトウェア層が INC に対して実行する必要がある作業には、次のものが含まれます。

• INCの収集通信(libfabric)を使用してAPl(C言語を使用)を定義します。

• 利用可能な INC を確認するための検出メカニズムを定義する off負荷能力。

• これらのライブラリが Aggregation Manager (AM) と通信するために使用する RPC インターフェイスを定義します。 INC リソースを提供する AM と UEC スイッチ間の通信に使用される RPC インターフェイスを指定します。

• 集合通信用にネットワーク デバイス (AM によって構成) の FEP を構成するための OpenConfig 拡張機能 offロードとパフォーマンスとエラーの監視。

• 複数の機能プロファイルを持つ INC 準拠のネットワーク デバイスの動作。INC テクノロジーをハードウェア実装に簡単に適用できるように、UEC 伝送プロトコルの開発をガイドします。