اتحاد Ultra Ethernet: إعادة بناء Ethernet للذكاء الاصطناعي واسع النطاق

الخلاصة

• اتحاد Ultra Ethernet Consortium مشروع تابع لـ Joint Development Foundation أطلقته في 19 يوليو 2023 شركات AMD وArista Networks وBroadcom وCisco وEviden/Atos وHewlett Packard Enterprise وIntel وMeta وMicrosoft. وهو اتحاد صناعي لتطوير المواصفات، وليس شركة تقليدية أو مشغّل شبكة.
• يتجاوز نطاق UEC كثيراً مجرد وصلة Ethernet أسرع أو بديل لـ RoCE. فالمواصفة 1.0.3، البالغ حجمها 573 صفحة، تغطي طبقات البرمجيات والنقل والشبكة والوصلة والطبقة الفيزيائية، إلى جانب أعمال الإدارة والتخزين والاختبارات والامتثال المحيطة بالمكدس الأساسي.
• يجمع Ultra Ethernet Transport بين عدة أنماط للتسليم، وتعدد المسارات على مستوى الحزمة، وإعادة الإرسال الانتقائية، والتحكم في الازدحام من جهة المرسل والمستقبل، وECN، وقص الحزم الاختياري، وإعادة المحاولة المحلية الاختيارية، والتحكم الاختياري بالتدفق القائم على الاعتمادات، وأمن النقل الاختياري من طرف إلى طرف.
• تدل منتجات وعروض AMD وBroadcom وNokia وKeysight على بدء التنفيذ، إلا أن الامتثال العلني ما زال يعتمد أساساً على الإقرار الذاتي من الجهة المنفذة، ولم يُنشر سجل شامل لشهادات مستقلة أو إحصاء لعمليات نشر واسعة النطاق.
• تستند الفرصة الاستراتيجية لـ UEC إلى القاعدة المركبة لـ Ethernet وسلسلة توريدها متعددة المورّدين. أما أبرز المخاطر فهي تعقيد نقاط النهاية، والتجزؤ الناتج عن الميزات الاختيارية، والتزامات براءات RAND، وعدم نضج الإدارة والاختبارات، والفجوة بين نشر المواصفة وإثبات قابلية التشغيل البيني في بيئة الإنتاج.

لماذا جعل الذكاء الاصطناعي الشبكة جزءاً من الحاسوب

نشأ Ultra Ethernet Consortium استجابة لتغيّر في اقتصاديات الحوسبة. ففي شبكة مؤسسية عادية، يُنتظر من النسيج الشبكي نقل عدد كبير من التدفقات المستقلة بمعدل نقل وتوافر مقبولين. أما في نظام كبير لتدريب الذكاء الاصطناعي أو في آلة حوسبة عالية الأداء، فتصبح الشبكة جزءاً من عملية حسابية واحدة متزامنة. وقد يتبادل آلاف المسرّعات معلمات النماذج أو التدرجات أو البيانات العلمية ضمن عمليات جماعية. وقد لا تنتقل المرحلة التالية قبل أن يتلقى أبطأ مشارك المعلومات اللازمة. لذلك يمكن لاختلال بسيط بين المسارات، أو لحالة ازدحام، أو لفقد حزمة واحدة، أن يترك معالجات مرتفعة التكلفة في حالة انتظار رغم أن متوسط استغلال النسيج يبدو جيداً.

يغيّر ذلك ما يحاول المشغّلون تحسينه. لا تزال السعة الإجمالية مهمة، لكنها لا تكفي. إذ تهم أيضاً مدة إكمال المهمة، وزمن الاستجابة في الذيل، وincast، والتعافي من الفقد، وتوزيع الحركة على المسارات المتوازية، ومقدار الحالة التي ينبغي لنقاط النهاية الاحتفاظ بها. قد تؤدي شبكة تسلّم معظم الحزم بسرعة لكنها تؤخر نسبة صغيرة منها إلى تعطيل عملية جماعية كاملة. وقد تكون طريقة إعادة إرسال مقبولة للحركة التقليدية بطيئة أكثر من اللازم إذا فُقدت حزمة واحدة من رسالة طويلة. كما قد ينخفض أداء تدفق مثبت على مسار واحد متساوي الكلفة بينما تبقى سعة متاحة في مواضع أخرى من الطوبولوجيا.

كانت الفرضية المؤسسة لـ UEC أن هذه المشكلات لا تُحل بميزة جديدة واحدة في المحوّل أو بخوارزمية واحدة معدّلة للازدحام. يبدأ مسار الاتصال فوق الشبكة، في مكتبات البرمجيات ودلالات التطبيق، ثم يمر بتسجيل الذاكرة، والعمليات البعيدة، وحالة النقل، وتسليم الحزم، والتحكم في الازدحام، والتوجيه عبر IP، ووصلات Ethernet، والبصريات، والإشارات الفيزيائية. وإذا صُممت هذه الطبقات بمعزل بعضها عن بعض، فقد يؤدي التحسين في موضع إلى نقل عنق الزجاجة أو إنشاء افتراضات غير متوافقة في موضع آخر.

إجابة UEC هي معمارية منسقة. تحتفظ بـ Ethernet وIP لأن المشغّلين يعرفونهما، ولأن سلسلة توريد هائلة نمت حول المحوّلات والبصريات والكابلات وأنظمة تشغيل الشبكات والقياس عن بعد والإدارة. وفي الوقت نفسه تغيّر أو توسع الأجزاء التي يراها الاتحاد غير ملائمة للأحمال الكبيرة للذكاء الاصطناعي وHPC. والنتيجة ليست «Ethernet عادية بشعار جديد»، بل محاولة لجعل شبكة مألوفة تحمل نقلاً متخصصاً يُعرَّف سلوكه من واجهة البرمجيات حتى سرعة المسار الفيزيائي.

توضح هذه النقطة سبب أهمية UEC للبنية التحتية الرقمية. فالمشروع لا يملك مسرّعات أو مصانع أو مراكز بيانات أو مناطق سحابية. لكنه يحدد عقوداً يمكن للشركات الأعضاء وغيرهم من المنفذين وضعها داخل بطاقات NIC، ودوائر ASIC الخاصة بالمحوّلات، والأنظمة، وبرامج التشغيل، والمكتبات، ومعدات الاختبار. ولن يتحقق تأثيره إلا عندما تتبادل هذه المنتجات المستقلة الحركة بصورة صحيحة عند الأعطال والازدحام والترقية وخلط المورّدين.

ما هي UEC وما ليست عليه

Ultra Ethernet Consortium هو الاسم العلني لمشروع رسمي يحمل اسمه القانوني الكامل Joint Development Foundation Projects, LLC, Consortium for HPC/AI/ML Ethernet Series. تضع بنية «السلسلة» المشروع داخل Joint Development Foundation والعائلة الأوسع لـ Linux Foundation. وتمنح المشاركين إطاراً قانونياً قائماً للعضوية والحوكمة والملكية الفكرية والتمويل والعلاقات الخارجية، من دون إلزامهم بإنشاء شركة مستقلة جديدة.

تكتسب هذه البنية أهمية لأن UEC توصف أحياناً على نحو غير دقيق بأنها شركة أو تحالف أو هيئة معايير. فهي ليست شركة تجارية لها مساهمون ورأس مال وتقييم وحسابات مستقلة. ولا تبيع منتجات Ethernet، ولا تشغّل شبكة عامة، ولا تملك العتاد الذي يروّج له أعضاؤها. إنها اتحاد لتطوير المواصفات ضمن إطار قانوني وحقوقي للملكية الفكرية. والغرض من وثائقها العلنية أن تصبح عقود تنفيذ بين شركات متعددة.

كما أن UEC ليست هي Ultra Ethernet Transport ذاته. فـ UET هو معمارية النقل في قلب المواصفة، لكن عمل الاتحاد أوسع من ذلك. فهو يشمل مواءمة البرمجيات مع libfabric، ودلالات الحزم والرسائل، وافتراضات الشبكة، وخيارات طبقة الوصلة، ومتطلبات الطبقة الفيزيائية، والإدارة، والمواءمة مع التخزين، والأداء وتصحيح الأخطاء، والامتثال والاختبارات. واختزال المشروع في «بروتوكول RDMA جديد» يخفي التصميم العابر للطبقات الذي يجعله طموحاً وصعباً.

وليست UEC أيضاً مجموعة IEEE 802.3. فهذه المجموعة تطور معايير Ethernet الأساسية في طبقتي MAC والطبقة الفيزيائية من خلال عمليتها الرسمية الخاصة. تعتمد UEC على ذلك النظام وتحافظ على علاقة تنسيق، لكنها لا تحل محله. وتنطبق الحدود نفسها على آليات IETF التي يستخدمها UET، ومنها IPv4 وIPv6 وExplicit Congestion Notification؛ وعلى منظومة OpenFabrics التي تدير libfabric؛ وعلى الهيئات العاملة في التخزين والعتاد المفتوح وروابط المسرّعات.

استخدم موقع المشروع لغة توحي بمكانة منظمة دولية للمعايير. والوصف الأكثر أماناً والأقوى دليلاً هو أن UEC منظمة دولية لتطوير المواصفات ضمن إطار JDF. ولا يوجد دليل على أنها جزء من International Organization for Standardization، أو أن وثائقها معايير ISO، أو أن لها رقماً معيارياً لدى ISO. والتمييز ليس لفظياً فحسب؛ فهو يحدد مصدر السلطة، وكيفية المشاركة، والالتزامات القانونية التي قد تواجه المنفذين.

لذلك ينبغي تقييم UEC على أساس الدور الذي تؤديه فعلاً. فهي تنسق المنافسين والمشغّلين حول تصميم تقني مشترك، وتنشر المواصفات، وتدير مجموعات العمل والتزامات البراءات المعلنة، وتطوّر مواد الامتثال والعلاقات مع الهيئات المجاورة. لكنها لا تستطيع بمجرد الإعلان أن تجعل منتجاً قابلاً للتشغيل البيني أو أن تجبر السوق على اعتماد معماريتها.

الائتلاف المؤسس من تسع شركات

أُعلن الاتحاد في 19 يوليو 2023 بواسطة تسع مؤسسات تشغل طبقات مختلفة من سلسلة توريد الذكاء الاصطناعي وHPC: AMD وArista Networks وBroadcom وCisco وEviden، التي كانت مرتبطة آنذاك بـ Atos، وHewlett Packard Enterprise وIntel وMeta وMicrosoft. كان هذا التنوع أصلاً استراتيجياً منذ البداية. فقد يهمل نقل تصممه شركات المحوّلات وحدها قيود التطبيقات ونقاط النهاية. وقد يُحسَّن تصميم تقوده شركات المسرّعات حول منظومة عتاد واحدة. أما مشروع تقوده شركات سحابية وحدها فقد يفتقر إلى خبرة السيليكون والبصريات والأنظمة اللازمة لتحويل المعمارية إلى منتجات.

قدمت AMD المعالجات والمسرّعات وشبكات نقاط النهاية. وقدمت Arista وCisco خبرة التحويل عبر Ethernet على نطاق واسع والخبرة التشغيلية. وساهمت Broadcom بسيليكون التحويل وبطاقات NIC وSerDes عالي السرعة. وجلبت HPE وEviden خبرة أنظمة HPC والروابط المتخصصة. وأسهمت Intel بالمعالجات وEthernet والبرمجيات. ومثلت Meta وMicrosoft مشغّلين hyperscale لديهم حوافز مباشرة لرفع استغلال مجموعات الذكاء الاصطناعي الكبيرة وتقليل الاعتماد على مورّد متكامل واحد.

كما يضم الائتلاف مصالح تجارية متنافسة. يبيع الأعضاء بطاقات NIC ودوائر المحوّلات والأنظمة والسعة السحابية والبصريات والبرمجيات والدعم. ويمتلك بعضهم محافظ براءات قد تكون ضرورية للتنفيذ. ويستفيد بعضهم من معيار واسع متعدد المورّدين، بينما يمكنه أيضاً الربح من ميزات مملوكة ومتميزة. لذلك لا يلغي الاتحاد المنافسة؛ بل ينشئ منتدى يتفق فيه المتنافسون على واجهات دنيا ويواصلون التنافس في جودة التنفيذ والأداء والتكامل والشروط التجارية.

يوفر Slingshot من HPE مثالاً مفيداً على الأصل التقني. فهو نسيج HPC تجاري متوافق مع Ethernet ويضم توجيهاً تكيفياً وإدارة للازدحام. وقد ذكرت تعليقات مرتبطة بـ HPE أن مواصفة «HPC Ethernet» قُدمت إلى UEC، وقدرت أن نسبة كبيرة من UET مشتقة من أفكار النقل في Slingshot. لم تُتحقق النسبة الدقيقة بصورة مستقلة ولا ينبغي عرضها كحساب رسمي للاتحاد. أما النقطة الأوسع فمؤيدة جيداً: لم يبدأ UEC من صفحة فارغة، بل استفاد من خبرة إنتاجية في HPC والشبكات السحابية وRDMA وEthernet.

هذا المزج بين الأنظمة السابقة سبب لاستخدام كلمة «مفتوح» بدقة. فالمواصفة المعتمدة متاحة للتحميل علناً، والمعمارية مصممة للتنفيذ من مورّدين متعددين. لكن المشروع أيضاً مكان يساهم فيه الأعضاء بمعرفة سابقة وبراءات وخرائط طريق للمنتجات. انفتاح الوثيقة لا يزيل الشروط الاقتصادية أو القانونية المحيطة بالتقنية.

سلسلة قانونية صُممت لتعاون المنافسين

يمنح نموذج Joint Development Foundation اتحاد UEC هيكلاً رسمياً من دون تحويله إلى شركة تشغيل تقليدية. فللمشروع اسم ونطاق وفئات عضوية وSteering Committee ومجموعات عمل والتزامات ملكية فكرية. وتوفر مظلة JDF البنية المؤسسية وغير الربحية ويمكنها الاحتفاظ بأصول المشروع واتفاقياته. ويخفض ذلك كلفة إنشاء اتحاد ويمنح المنافسين عملية معترفاً بها للتعاون.

يتولى Steering Committee حوكمة المشروع. وتشمل مسؤولياته الموثقة تنسيق مجموعات العمل، وقبول الأعضاء، وإدارة الأصول والتمويل، واختيار الرئيس أو استبداله، ومراقبة التقدم، والتحكم في الإفصاح العام وعلامات المشروع. يُفضَّل التوافق. وإذا تعذر، تنص الوثيقة التنظيمية على آلية أغلبية فائقة من ثلاثة أرباع المشاركين المؤهلين الذين يستوفون متطلبات الحضور. ويمكن تقديم الاعتراضات المكتوبة إلى الرئيس.

كان Brad Booth من Meta الرئيس الأصلي. وتسمي المواصفة 1.0.3 الحالية J Metz من AMD رئيساً، وBarry Davis من HPE نائباً للرئيس، وHugh Holbrook من Arista رئيساً للجنة Technical Advisory Committee، وPuneet Agarwal من Marvell نائباً لرئيس TAC. ويظهر Paul Congdon محرراً للمواصفة. كما تسمي الوثيقة قادة ومؤلفين في أعمال الطبقة الفيزيائية والوصلة والنقل والبرمجيات. وتذكر أجندة قمة 2026 مسؤولين تشغيليين إضافيين. ولا تعني تلك الأدوار بالضرورة استبدال الألقاب الرسمية الواردة في المواصفة، كما لا يتوفر هيكل تنظيمي عام كامل وحديث.

تتضمن الوثيقة التنظيمية ثلاث فئات للعضوية: Steering وGeneral وContributor. يشارك أعضاء Steering في الحوكمة ويعيّنون عادة ممثلين في Steering Committee. ويستطيع أعضاء General العمل في جميع المجموعات التقنية لكنهم لا يشغلون مقاعد في اللجنة. أما أعضاء Contributor فيشاركون في مجموعات مختارة ولا يملكون حق التصويت في قرارات الأغلبية الفائقة. تعرض صفحة العضوية العامة حالياً فئتي General وContributor بسعر سنوي قدره 20 ألف دولار و5 آلاف دولار على التوالي، إضافة إلى عضوية Linux Foundation، لكنها لا تشرح بوضوح مسار القبول أو السعر الحالي لفئة Steering.

الاختلاف في السلطة الرسمية مهم. فالعضوية الواسعة تقدم خبرة وانتشاراً في التنفيذ، لكن الحوكمة ليست موزعة بالتساوي. الشركات الكبيرة القادرة على شغل مقاعد Steering وتخصيص مهندسين لعدة مجموعات وإدارة برامج براءات ومنتجات تملك نفوذاً عملياً أكبر من أعضاء Contributor الأصغر. ويمكن لغير الأعضاء تحميل المواصفة النهائية، لكنهم لا يشاهدون عملية المسودة كاملة ولا يشاركون على قدم المساواة.

لا تُعامل المعلومات الداخلية للمشروع كبيانات شركة سرية عادية، لكن يُمنع الأعضاء من كشف مواد المسودات قبل موافقة اللجنة المعنية على النشر. قد يساعد ذلك المنافسين على مناقشة أفكار غير مكتملة من دون إشارات سوقية مبكرة. لكنه يعني أيضاً أن الجمهور لا يرى المقترحات المرفوضة أو سجلات التصويت أو مخاوف التنفيذ الوسيطة أو المفاوضات التي أنتجت الميزات الاختيارية. المواصفة النهائية مفتوحة؛ أما الطريق إليها فمرئي جزئياً فقط.

من أربع مجموعات عمل إلى مواصفة من 573 صفحة

ركز الهيكل العلني الأول لـ UEC في 2023 على أربع مجموعات عمل: البرمجيات والنقل والوصلة والطبقة الفيزيائية. عكس التسلسل طموح المشروع من طرف إلى طرف. ولم تُفتح العضوية فوراً كقائمة مراسلة عامة غير مقيدة. فقد أبدت أكثر من 200 مؤسسة اهتماماً، ونفذ الاتحاد الانضمام على مراحل مع اشتراط توجيه بشأن الإجراءات وقواعد مكافحة الاحتكار. كان الحذر مفهوماً لأن المشاركين يتنافسون مباشرة في أسواق عدة وسيناقشون متطلبات مشتركة للمنتجات والبروتوكولات.

بحلول ديسمبر 2023، أفاد UEC بوجود نحو 40 شركة وأكثر من 300 فرد. وكان قد أنشأ Technical Advisory Committee وتوسع إلى ثماني مجموعات عمل. كان غرض TAC الحفاظ على اتساق المعمارية: لا ينبغي لتصميم النقل أن يفترض سلوكاً في المحوّل أو طريقة إشارات أو API لم توافق مجموعة أخرى على دعمها. وفي مارس 2024 أفاد الاتحاد بوجود 55 شركة وأكثر من 750 مشاركاً نشطاً ونشر وصفاً أوضح كثيراً للمعمارية المقصودة.

قدمت تحديثات مارس الأفكار الأساسية التي ظهرت لاحقاً في المواصفة المعيارية: libfabric بوصفه API موجهاً للبرمجيات، وpacket spraying، والترتيب المرن، وأنماط التسليم المتعددة، والتحكم في الازدحام من جهة المرسل والمستقبل، وECN، وpacket trimming، وLink Layer Retry، والتحكم الاختياري القائم على الاعتمادات، وأمن النقل، والعمليات الجماعية المستقبلية داخل الشبكة. كما شددت على أن UET يمكنه العمل عبر محوّلات Ethernet موجودة، في حين توفر المحوّلات المحسّنة أداء إضافياً.

نما الحضور المؤسسي بالتوازي مع العمل التقني. أفاد UEC بوجود 1,193 مشاركاً نشطاً في يوليو 2024 و97 مؤسسة عضواً في أغسطس. وهذه أرقام مؤرخة صادرة عن الاتحاد وتعتمد تعريفات ليست علنية بالكامل، لذلك لا ينبغي جمعها آلياً مع إعلانات لاحقة. وفي 2025 قال الاتحاد إن 27 شركة إضافية انضمت، لكن المغادرة والاندماجات وتداخل الفترات تمنع ذلك من إثبات مجموع حالي دقيق. ويذكر الموقع نفسه أن جميع الأعضاء لا يظهرون في الصفحة.

أصدر الاتحاد Ultra Ethernet Specification 1.0 في 11 يونيو 2025. وكانت تلك اللحظة التي انتقل فيها UEC من خارطة طريق إلى خط أساس علني للتنفيذ. تلتها النسخة 1.0.1 في سبتمبر وصححت خوارزمية المصدر في receiver-credit congestion control ومشكلات تحريرية. ووصلت 1.0.2 في يناير 2026 وصححت خوارزميات إدارة الازدحام، رغم اختلاف الوثائق الرسمية على ما إذا كان تاريخ الإصدار 21 أو 28 يناير. وينبغي إبقاء هذا التعارض ظاهراً بدلاً من تسويته من دون بيان.

النسخة 1.0.3، المنشورة في 16 يوليو 2026، هي المرجع الحالي عند حد البحث. تبلغ 573 صفحة وتضيف دعماً لإشارات 200 غيغابت في الثانية لكل lane وقدرة منطقية للتفاوض. كما تحدد ملاحظات الإصدار تصحيحات إلزامية تتعلق بتسليم الحزم واعتمادات الازدحام وLink Layer Retry وcontrol ordered sets في الطبقة الفيزيائية، إلى جانب توضيحات لأمن النقل والعمليات الذرية والحزم trimmed. الفرق بين التصحيحات الإلزامية والتوضيحات التحريرية مهم، لأن بعض التغييرات تؤثر في السلوك المطابق وتتطلب صيانة للتنفيذ.

أظهرت قمة الأعضاء في دنفر عام 2026 انتقالاً ثانياً. ركزت الأجندة على النشر وتحويل المواصفة إلى منتجات والامتثال والإدارة والأداء وتصحيح الأخطاء وتكامل التخزين واختبار المحوّلات ونقاط النهاية. الوثيقة المعمارية الأساسية موجودة؛ أما مصداقية المشروع فتعتمد الآن أكثر على قدرة المنفذين على بناء المكدس وتأهيله وتشغيله وترقيته عبر حدود المؤسسات.

معمارية واحدة عبر خمس طبقات وظيفية

تقسم المواصفة الحالية Ultra Ethernet إلى طبقات البرمجيات والنقل والشبكة والوصلة والطبقة الفيزيائية. هذا التقسيم مفيد، لكن قيمة المشروع تكمن في الافتراضات التي تربط الطبقات.

في الأعلى تتفاعل أطر الذكاء الاصطناعي وMPI وSHMEM ومكتبات العمليات الجماعية عبر OpenFabrics Interfaces، ولا سيما libfabric. يترجم UET Semantic Services Sublayer عمليات التطبيق إلى معاملات نقل. ويقرر Packet Delivery Sublayer كيف تُجزأ الرسائل وتُرتب ويُعترف بها ويُتعافى منها. تتحكم إدارة الازدحام في مقدار البيانات الداخلة إلى النسيج وكيفية توزيع الحركة على المسارات. ويحمي أمن النقل الاختياري حركة الطرف إلى الطرف. يوفر IPv4 أو IPv6 القياسي التوجيه في طبقة الشبكة. وتوفر Ethernet الوصلة مع packet trimming وLink Layer Retry وCredit-Based Flow Control والتفاوض على الميزات اختيارياً.

أما الطبقة الفيزيائية فتحدد الإحصاءات ومتطلبات الإشارات عند 100 أو 200 غيغابت في الثانية لكل lane.

تحافظ هذه البنية على أجزاء مهمة من الشبكة الحالية. لا يحدد UEC بديلاً لتوجيه IP. بل يتوقع ECMP تقليدياً ومحوّلات تدعم ECN. وتبقى نسبة كبيرة من الذكاء في Fabric Endpoints، التي تغيّر قيم entropy، وتتابع حالة النقل، وتضع البيانات، وتستجيب لإشارات الازدحام. يمكن للمحوّلات المحسّنة إضافة وظائف، لكن التصميم لا يفرض استبدال النسيج بأكمله قبل تمرير حركة UET.

يوفر ذلك ميزة في الانتقال لكنه ينشئ مشكلة تصنيف. قد يستخدم نشر ما نقاط نهاية UET فوق Ethernet تقليدية مع ECMP وECN. وقد يضيف نشر آخر trimming وإعادة المحاولة على الوصلة واعتمادات لكل قناة افتراضية وقياساً أكثر ثراءً وعمليات مستقبلية داخل الشبكة. يمكن تسمية الاثنين Ultra Ethernet رغم اختلاف أدائهما وخصائص التعافي وتعقيدهما التشغيلي بدرجة جوهرية.

كما تجعل المقاربة ذات الطبقات الخمس عزل إخفاقات التنفيذ أكثر صعوبة. فقد يأتي الأداء السيئ من مواءمة التطبيق، أو آلة حالة نقطة النهاية، أو معاملات الازدحام، أو إعداد صفوف المحوّل، أو مواءمة DSCP، أو البصريات، أو firmware، أو نظام الأمن. مرور الحزم وحده لا يكفي. يجب أن يحافظ النظام على الدلالات والأداء المقصودين عند التوسع والحركة المختلطة والأعطال وتغير الإصدارات.

عقد البرمجيات: libfabric بدلاً من API مملوك للتطبيق

تختار UEC الإصدار libfabric 2.0 بوصفه API علوياً أساسياً لنقاط النهاية المطابقة. يربط هذا الخيار المشروع بمنظومة برمجيات قائمة لـ HPC والشبكات المتقدمة بدلاً من مطالبة كل إطار بتبني واجهة مملوكة جديدة. يمثل libfabric بالفعل fabrics وdomains وendpoints وcompletion queues وevent queues وaddress vectors وmemory regions والرسائل وعمليات الذاكرة البعيدة والعمليات الذرية. وتقوم UEC بمواءمة هذه المفاهيم وتقييدها لكي يحوّل المزوّدون الاستدعاءات إلى سلوك UET.

القيمة الاستراتيجية هي الاستمرارية فوق النقل. تستطيع MPI وSHMEM ومكتبات اتصال المسرّعات استخدام تجريدات مألوفة حتى لو تغير المزوّد الموجود أسفلها. من حيث المبدأ، يمكن للتطبيق طلب عملية من دون معرفة مورّد NIC الذي ينفذ التسليم أو نوع سيليكون المحوّل الذي يوجّه الحزم. وهذه إحدى الآليات الرئيسية التي قد ينشئ بها نقل مشترك خياراً بين المورّدين.

لا يضمن التجريد تنفيذات متكافئة. قد يدعم المزوّدون أحجام inject مختلفة، وحدود scatter/gather مختلفة، وأعداداً مختلفة من endpoints، وعمليات ذرية وتقنيات تسجيل ذاكرة وسلوك completion وhardware offload ووظائف أمنية مختلفة. قد تواجه مكتبة مبنية على API نفسه حدوداً مختلفة في الأداء والقدرات. لذلك تحتاج المشتريات وتأهيل البرمجيات إلى أكثر من علامة تقول «libfabric supported».

تحمل طبقة البرمجيات أيضاً دلالات المهام والتفويض. غالباً ما تشغل أنظمة الذكاء الاصطناعي وHPC مهام كثيرة على بنية مشتركة، لكل منها عمليات ومناطق ذاكرة وحدود أمنية خاصة. يجب على المواصفة تحديد نقطة النهاية التابعة لكل مهمة، والذاكرة المسموح بالوصول إليها، وكيف تطابق العملية البعيدة، وكيف تعود معلومات الإكمال أو الخطأ إلى البرمجيات. هذه القرارات تحدد ما إذا كانت الشبكة السريعة قابلة للاستخدام من المجدول وبيئة التشغيل والتطبيق، لا مجرد رقم مبهِر في اختبار حزم.

يعتمد المشروع على منظومة OpenFabrics لأنه لا يملك libfabric. توضح هذه العلاقة سمة أوسع لـ UEC: المعمارية مركبة من مكونات تُحكم في أماكن مختلفة. يمكن للاتحاد تحديد مواءمة نقله مع libfabric، لكنه يحتاج إلى التنسيق مع القائمين على API ومستخدميه. توجد تبعيات مشابهة مع Ethernet لدى IEEE، وآليات الشبكات لدى IETF، وهيئات التخزين، وأنظمة تشغيل المورّدين.

Fabric Endpoints وملفات الأحمال

Fabric Endpoint، أو FEP، هو الموضع المنطقي الذي ينتهي عنده UET. يربط نسخة واحدة من نظام التشغيل بمستوى واحد أو أكثر من مستويات النسيج المعزولة، وقد يضم مزوّد user space، وبرنامج تشغيل kernel، ونقلاً داخل NIC أو المسرّع، ونظام تسجيل ذاكرة، وسياقاً أمنياً، وcompletion queues وaddress vectors والحالة المستخدمة لتسليم الحزم والتحكم في الازدحام.

يسمح هذا التصميم المرتكز على نقطة النهاية لمعظم المحوّلات بأن تبقى أجهزة Ethernet وIP واضحة الوظيفة. يختار FEP قيم entropy، ويحافظ على حالة الحزم والازدحام، ويضع البيانات في ذاكرة مصرح بها، ويفسر acknowledgements وtrimming وغيرها من التغذية الراجعة. قد يقلل ذلك الاعتماد على ذكاء توجيه مملوك داخل المحوّل، لكنه يركز التعقيد في سيليكون NIC وfirmware وبرامج التشغيل والبرمجيات.

تحدد UEC ثلاثة ملفات تنفيذ: AI Base وAI Full وHPC. ليست هذه أنواع شبكات منفصلة، بل حزم تحدد الوظائف التي يجب على التنفيذ دعمها. يقصد بـ AI Base تغطية اتصالات الذكاء الاصطناعي الشائعة بكلفة وحالة تنفيذ أقل. يضيف AI Full وظائف مثل deferrable sends وexact matching وعمليات ذرية من نوع fetch أو compare. ويتضمن ملف HPC معظم قدرات AI Full، لكنه يستبعد deferrable send ويمنح وزناً أكبر للترتيب والرسائل القصيرة ودلالات HPC.

يحاول نظام الملفات منع إلزام كل منتج بتنفيذ الحد الأقصى من الميزات. فهو يقر بأن NIC مخصصاً للذكاء الاصطناعي واسع الانتشار قد يعطي الأولوية لحركة البيانات الجماعية، بينما قد تحتاج نقطة نهاية HPC إلى ترتيب وعمليات ذرية أقوى. لكن الملفات لا تزيل الخيارات. يستطيع المنتج تنفيذ ميزات اختيارية داخل ملف، وقد يختلف منتجان يحملان الاسم نفسه في الأمن وتحسينات الوصلة والسعة والأداء.

وتظهر إشارة تحذير في المصطلحات نفسها. تستخدم المواصفة المرجعية 1.0.3 أسماء AI Base وAI Full وHPC. بينما يستخدم readme منفصل للامتثال من 2025 أسماء AI Base وAI Extended وHPC. التفسير الأقوى دليلاً هو أن «AI Full» هو الاسم الحالي وأن مادة الامتثال قديمة أو غير متسقة. وحتى تصحيح حزمة الاختبار العامة، ينبغي للمورّدين والمشترين تحديد إصدار المواصفة والاسم الدقيق للملف وراء كل ادعاء.

من نية التطبيق إلى تسليم الحزم

داخل UET يحمل Semantic Services Sublayer نية التطبيق. فهو يحدد هوية الرسالة، وعناوين المخازن، والعمليات tagged وuntagged، والوصول البعيد إلى الذاكرة، والعمليات الذرية، وسلوك completion، ومعرّفات المهام، وتفويض المخازن، والاستجابات والأخطاء. ثم يحدد Packet Delivery Sublayer كيف تتحول هذه النية إلى حزم وكيف تصل إلى نقطة نهاية أخرى.

في الأنماط الموثوقة تنشئ نقاط النهاية Packet Delivery Contexts. يحتوي PDC على حالة مثل أرقام تسلسل الحزم، والإقرارات، واكتشاف التكرار، ونمط الترتيب، ومعلومات الازدحام، وحالة اتجاه العودة، وفئة الحركة. يرتبط PDC واحد بنمط تسليم واحد وفئة حركة واحدة، ويمكن أن توجد عدة PDCs بين زوج FEP نفسه.

هذه الحالة ليست تفصيلاً بسيطاً. فقد تنشئ المجموعات الكبيرة أعداداً هائلة من علاقات الاتصال. وإذا احتاجت كل علاقة إلى حالة واسعة في الهدف، فقد تصبح ذاكرة نقطة النهاية وكلفة البحث قيداً. لذلك لا تجبر UEC كل عملية على نموذج اتصال واحد، بل تعرف أربعة أنماط تسليم بعقود مختلفة للموثوقية والترتيب.

يوفر Reliable Unordered Delivery، أو RUD، تسليم كل حزمة مرة واحدة بالضبط إلى طبقة الدلالات، مع السماح بوصول الحزم خارج الترتيب. ويدعم packet spraying عبر مسارات عدة، وإعادة الإرسال الانتقائية، ومنع التكرار، والوضع المباشر للبيانات. ولأن الهدف يستطيع وضع البيانات وفق الإزاحات بدلاً من انتظار مخزن لإعادة الترتيب في النقل، يمكن لعملية جماعية طويلة استخدام عدة مسارات من دون تسلسل كل الحزم خلف وحدة مفقودة.

يوفر Reliable Ordered Delivery، أو ROD، تسليماً مرة واحدة وبالترتيب. يستخدم مساراً واحداً وقيمة entropy واحدة، ويتخلص من الحزم الخارجة عن الترتيب، ويعتمد على Go-Back-N بدءاً من أول تسلسل مفقود. يبدو أقل تعقيداً من RUD، لكنه يحافظ على دلالات ضرورية عندما يكون الترتيب الصارم مهماً. تعامل UEC الترتيب كمتطلب للتطبيق بدلاً من فرض كلفته على كل نقل.

أما Reliable Unordered Delivery for Idempotent Operations، أو RUDI، فيقدم مقايضة مختلفة. فهو يضمن التسليم مرة واحدة على الأقل ويسمح بالتكرار، ما يقلل حالة التسلسل والإقرار المعتادة في الهدف. يمكن أن يكون مفيداً حين لا يغير تكرار العملية النتيجة النهائية، مثل بعض حركات الذاكرة البعيدة المتبوعة بحاجز منفصل. لكنه خطر إذا استُخدم خطأ. طبقة الحزم لا تستنتج ما إذا كانت العملية idempotent؛ يجب على البرمجيات اتخاذ القرار. استخدام RUDI لعملية غير idempotent قد ينتج حالة تطبيق غير صحيحة.

يوفر Unreliable Unordered Delivery، أو UUD، datagrams بأفضل جهد من دون ضمانات عادية للموثوقية أو الترتيب. وهو داخل الإطار الدلالي نفسه، لكنه لا يحمل متطلبات التحكم في الازدحام نفسها التي يحملها RUD وROD. يجب على التطبيقات تجنب الإضرار بالحركة الخاضعة للتحكم عندما تشترك UUD معها في صفوف أو فئات.

تكشف الأنماط الأربعة فلسفة مركزية: ينبغي للشبكة أن تعرض آليات متعددة لكي يطابق البرنامج كلفة النقل مع دلالات العملية. الفائدة هي الكفاءة، والكلفة هي سطح تنفيذ واختبار أكبر وفرص أكثر لاختيار مزوّد أو تطبيق أو مشغّل توليفة غير متوافقة.

Packet spraying: استخدام النسيج بدلاً من الاعتماد على مسار محظوظ

غالباً ما يضع ECMP التقليدي تدفقاً كاملاً على مسار واحد بواسطة hash. وفي نسيج Clos واسع قد يتحول ذلك إلى قرعة. يمكن لعدة تدفقات كبيرة أن تتصادم على الوصلات نفسها بينما تبقى سعة مماثلة غير مستخدمة في مواضع أخرى. وقد يظل نقل طويل للذكاء الاصطناعي مقيداً طوال حياته بمسار اختير بصورة غير موفقة.

يعالج UET ذلك بتغيير entropy على مستوى كل حزمة. يستطيع المرسل استخدام عشرات أو مئات القيم، ما يسمح لآليات ECMP الحالية في المحوّلات بتوزيع الحزم على طرق عديدة. يوفر Packet Delivery Sublayer معلومات التسلسل، ويختار Congestion Management Sublayer قيمة entropy أو المسار، وتنفذ المحوّلات عملية hash المعتادة، ثم تُعلم التغذية الراجعة المرسل بالقيم التي تبدو مزدحمة.

لا يصبح packet spraying عملياً إلا لأن أجزاء أخرى من التصميم تدعمه. يمكن للحزم الوصول خارج الترتيب. يستطيع RUD وضع البيانات مباشرة من دون انتظار إعادة ترتيب كاملة في النقل. وتستعيد إعادة الإرسال الانتقائية ما فُقد فقط. وتقلل تغذية الازدحام استخدام المسارات المتضررة. لذلك ليست الآلية حيلة مستقلة لموازنة الحمل، بل جزءاً من نموذج نقل مبني حول تنوع المسارات.

لا تشترط UEC أن يشغل كل محوّل خوارزمية مملوكة للتوجيه التكيفي. يمكن للتنفيذات الأساسية استخدام round-robin أو entropy شبه عشوائية فوق ECMP قياسي. وقد تربط نقاط النهاية المتقدمة إشارات ECN أو زمن الاستجابة أو trimming بقيم معينة وتتجنب المسارات المزدحمة. يمكن للتوجيه التكيفي الخاص بالمورّد أن يتعايش مع UET، لكنه ليس المصدر الوحيد للوعي بالمسار.

الوعد هو استغلال أفضل للنسيج وزمن أقل في الذيل. أما السؤال غير المحسوم فهو مدى اتساق تفسير نقاط النهاية المختلفة للتغذية الراجعة، وكيف يتفاعل spraying مع مخازن المحوّلات وإعادة الترتيب والأعطال والحركة المختلطة. خوارزمية تعمل جيداً في مختبر متجانس قد تتصرف بصورة مختلفة في نسيج كبير يضم أجيالاً متعددة من المحوّلات وفئات حركة مختلفة. ولا تزال الأدلة المستقلة متعددة المورّدين محدودة.

ثلاث آليات ازدحام لثلاثة اختناقات مختلفة

لا تحدد UEC خوارزمية ازدحام عالمية واحدة. فهي تميّز بين الازدحام في قلب الشبكة، وincast عند المستقبل، ومحدودية مخازن نقاط النهاية.

Network-signal Congestion Control، أو NSCC، آلية تقودها جهة الإرسال. يحتفظ المرسل بنافذة ازدحام، ويقدّر حجم البيانات في الطريق، ويعدل النافذة وفق acknowledgements وnegative acknowledgements وtimeouts وزمن الاستجابة وإشارات الشبكة مثل ECN. كما ينسق سلوك النافذة مع تعدد المسارات على مستوى الحزمة. وتجادل UEC بأن النافذة تتوقف بصورة طبيعية عن إدخال بيانات جديدة عندما تعجز الحزم عن مغادرة الشبكة، بينما قد يسيء متحكم قائم على المعدل وحده تفسير غياب التغذية الراجعة.

هذا هو الطرح المعماري للاتحاد، وليس دليلاً مستقلاً على أن كل تنفيذ لـ NSCC يتفوق على DCQCN أو غيره من آليات RoCE. تعتمد النتائج على تفاصيل الخوارزمية، وطريقة وسم المحوّلات، والطوبولوجيا، وأنماط الحركة، والمعاملات المختارة. لذلك لا تكفي عبارة «يستخدم NSCC» لإثبات الأداء.

يستهدف Receiver-credit Congestion Control، أو RCCC، مشكلة incast. فعندما ترسل مصادر كثيرة في الوقت نفسه إلى وجهة واحدة، قد تصبح الوصلة الأخيرة عنق الزجاجة حتى لو لم يكن قلب الشبكة مزدحماً. يتابع المستقبل الطلب ويوزع الاعتمادات على المرسلين، فينظم معدل الوصول الكلي ويغير النافذة الفعلية لكل مصدر بحسب المنافسة. ويمكن تشغيل RCCC إلى جانب NSCC لأن ضغط المستقبل وازدحام القلب مشكلتان مختلفتان.

يستخدم Transport Flow Control، أو TFC، الاعتمادات أيضاً، لكنه يخدم اتصالات نقطة إلى نقطة ذات مخازن محدودة. وهدفه المباشر منع امتلاء مخزن المستقبل عندما تكون قابلية تحمل الفقد منخفضة. يمكن استخدامه مع تعدد المسارات أو بدونه. واعتبار كل آليات الاعتماد شيئاً واحداً يخفي نطاق الفشل المختلف الذي صُممت كل آلية لمعالجته.

تتوقع المواصفة استخدام Explicit Congestion Notification في أنحاء النسيج، وتضع افتراضات تشغيلية بشأن الوسم، منها الوسم عند dequeue بدلاً من الاعتماد على enqueue وحده. تفسر نقاط النهاية ECN مع acknowledgements وزمن الاستجابة وtrimming. لذلك يصبح الاتساق في إعدادات المحوّلات ضرورياً. قد يكون تنفيذ النقل صحيحاً، ومع ذلك ينتج النسيج سيئ الإعداد أداء ضعيفاً.

يكشف تاريخ الصيانة مقدار الصعوبة. صححت النسخة 1.0.1 خوارزمية مصدر RCCC، وصححت 1.0.2 حالات في إدارة الازدحام، وصححت 1.0.3 تفاعلات بين الاعتمادات وLink Layer Retry. هذه علامات طبيعية لمواصفة حية، لكنها تبين أيضاً أن حالات الاعتمادات وإعادة الإرسال والتحكم في المسار قد تتفاعل بطرق دقيقة. سيحتاج المشغّلون إلى انضباط في الإصدارات واختبارات regression، لا إلى مطابقة أولية فقط.

Packet trimming والتعافي الدقيق من الفقد

يغيّر packet trimming ما يفعله المحوّل القادر عندما لا يستطيع الاحتفاظ بالحزمة كاملة. فبدلاً من إسقاط الإطار من دون معلومات إضافية، يزيل معظم payload أو كله، ويحافظ على ما يكفي من الرأس والبيانات الوصفية للتعرف إلى الحزمة، ويضع علامة trimmed، ثم يرسل الإشعار المختصر نحو المستقبل. يستطيع المستقبل بعدها إبلاغ المرسل بالبيانات المحددة التي فُقدت.

يوفر ذلك معلومات أدق من وسم ECN. فـ ECN يقول إن ازدحاماً وقع، بينما يحدد trimming حزمة لم يبق payload الخاص بها. ومع RUD وإعادة الإرسال الانتقائية، يمكن تسريع التعافي من دون انتظار timeout أو إعادة تسلسل طويل بسبب فقد واحد.

الميزة في المحوّل اختيارية، لكن نقاط النهاية المطابقة مطالبة باستقبال الحزم trimmed وتفسيرها عندما تنطبق المتطلبات. تساعد هذه اللامتماثلية على نشر UET فوق محوّلات عادية، مع السماح للأنسجة المحسّنة بتقديم معلومات فقد أغنى. لكنها تنشئ مشكلة في الترقية أيضاً؛ فقد تحتاج شبكة محسّنة جزئياً إلى تقييد trimming بحسب المسار أو الملف أو الطوبولوجيا لضمان أن كل نقطة نهاية مستقبلة تتعامل معه بصورة صحيحة.

تحدد UEC كذلك فئات حركة مختلفة للطلبات، وحزم التحكم، وإعادات الإرسال، والحركة trimmed. وعلى المشغّلين مواءمة قيم DSCP وصفوف المحوّلات وصفوف نقاط النهاية ومستويات الأولوية باتساق. لا توفر المواصفة نظام إدارة عالمياً لهذه المواءمة. وقد يؤدي الخطأ إلى تجويع حركة التحكم، أو تشويه تغذية الازدحام، أو جعل حزم التعافي تنافس الحركة التي يفترض أن تصلحها.

يلخص packet trimming تحدي التنفيذ الأوسع. يستطيع البروتوكول تحديد السلوك على السلك، لكن النتيجة التشغيلية تعتمد على صفوف المحوّل، ومنطق نقطة النهاية، والقياس عن بعد، والإعداد، ومعالجة الأعطال. قابلية التشغيل البيني خاصية للنظام كله وليست خاصية لتنسيق الحزمة وحده.

استعادة الوصلة والاعتمادات والتفاوض على الميزات

يحاول Link Layer Retry، أو LLR، استعادة الخطأ في وصلة فيزيائية قبل أن يتفاعل النقل من طرف إلى طرف. يكتشف الطرف فجوة تسلسل أو إطاراً تالفاً، ويرسل negative acknowledgement على مستوى الوصلة، ويجعل المرسل يعيد الإطار المتأثر من مخزن محلي. وإذا نجح التعافي بسرعة فقد يتجنب النقل إعادة إرسال أطول عبر المسار الكامل.

تزداد القيمة المحتملة مع ارتفاع سرعات lanes وكثافة المنافذ. فقد تنشئ أخطاء بصرية أو كهربائية عرضية تأخيراً كبيراً في مهمة شديدة التزامن. لكن LLR يضيف حالة تسلسل ومخازن replay ورسائل تحكم ونوافذ إسقاط وأنماط فشل جديدة. كما يجب أن يتعايش مع تحديثات الاعتمادات وإعادة ضبط الوصلة. وصححت 1.0.3 حالات حافة عدة، منها race بين معلومات اعتماد CBFC وLLR.

يعمل Credit-Based Flow Control، أو CBFC، لكل قناة افتراضية على مستوى الوصلة. يخبر المرسل بمقدار سعة الاستقبال المتبقية، ويمكنه توفير تحكم أدق من إيقاف واسع قائم على الأولوية. تعرضه UEC كوسيلة لدعم سلوك lossless مضبوط من دون اشتراط أن تكون كل شبكة UET عديمة الفقد بالكامل. CBFC اختياري، وUET مصمم للعمل فوق شبكات best effort.

ينبغي ألا يُعامل CBFC على أنه اسم آخر لـ Priority Flow Control. تختلف الآليتان في الإشارات والدقة، رغم أن كلتيهما تسعى إلى منع overflow. وما زال CBFC يحتاج إلى إعداد متسق وتسليم صحيح لإطارات التحكم الخاصة به. ويمكن للاعتمادات المحلية أن تتفاعل مع نوافذ الطرفين واعتمادات المستقبل، فتنتج حلقات تحكم متداخلة متعددة.

تستخدم UEC تفاوضاً مبنياً على LLDP لاكتشاف الميزات الاختيارية ومنع طرف من تفعيل قدرة لا يدعمها الجار. يجب أن يراعي التفاوض الملفات والقنوات الافتراضية وDSCP ومواءمة الأولويات وإعادة الضبط وترقيات البرمجيات والتوليفات الجزئية للميزات. وأدخلت 1.0.3 قدرة تفاوض منطقية، ما يعزز أهمية الاتفاق الصريح على كل وصلة.

توفر هذه الخيارات مساراً من Ethernet الأساسية إلى Ethernet محسّنة. لكنها تنشئ أيضاً مصفوفة قد تخفيها لغة المشتريات. يمكن لمحوّل أن يمرر UET بصورة صحيحة من دون trimming أو LLR أو CBFC. وقد يدعم محوّل آخر هذه القدرات في إصدارات برمجية أو أوضاع منافذ محددة فقط. يحتاج سجل نشر موثوق إلى مجموعة الميزات الدقيقة، لا إلى اسم الاتحاد وحده.

الإشارات الفيزيائية عند 100 و200 غيغابت في الثانية لكل lane

تربط الطبقة الفيزيائية UEC بخارطة طريق العتاد. صُمم العمل الأولي للإصدار 1.0 حول إشارات 100 غيغابت في الثانية لكل lane. وأدخلت 1.0.3 دعماً لـ 200 غيغابت في الثانية لكل lane. ينسجم ذلك مع جيل أعلى كثافة من الوصلات والأنظمة، لكنه قدرة في المواصفة وليس دليلاً على أن كل منتج UEC يدعمها فوراً.

يتناول عمل PHY أيضاً إحصاءات forward error correction، ونسب codewords المصححة وغير القابلة للتصحيح، وcontrol ordered sets، وتقارير جودة الوصلة، والتفاعل بين الأخطاء الفيزيائية وLLR. هذه التفاصيل مهمة لأن قرارات التعافي في النقل تعتمد على ما تستطيع الطبقات الأدنى رؤيته والإبلاغ عنه.

عند سرعات إشارات أعلى تصبح الحدود بين البصريات وSerDes وFEC وlink retry والتعافي في النقل ذات أثر اقتصادي. قد تقلل FEC الأقوى الأخطاء المتبقية على حساب زمن الاستجابة والطاقة. وقد تستعيد إعادة المحاولة المحلية الخطأ أسرع لكنها تحتاج إلى مخازن وحالة. أما إعادة الإرسال من طرف إلى طرف فأبسط عبر الشبكة لكنها قد تهدر وقتاً أطول. تحاول UEC تحديد طريقة تعاون هذه الطبقات بدلاً من ترك كل مورّد يحسّنها منفرداً.

كما توضح إضافة 200G لكل lane أن الهدف يتحرك. ينبغي لمنفذي 1.0 الحفاظ على التوافق مع التخطيط لقدرات فيزيائية جديدة. ويجب على معدات الاختبار وfirmware وأنظمة الإدارة التمييز بين قدرات كل منفذ. ولا يجوز للمشترين استنتاج سرعة lane من ادعاء عام بدعم UEC.

أمن نقل اختياري من طرف إلى طرف

يوفر Transport Security Sublayer، أو TSS، حماية اختيارية من نقطة نهاية إلى أخرى. ولا يشترط نموذج التهديد الثقة في المحوّلات. ويمكنه تقديم السرية والسلامة والحماية من replay وعزل المهام وsecure domains ومفاتيح جماعية وتدوير المفاتيح والتكامل مع جذور ثقة في العتاد.

يستخدم التصميم مجالات آمنة يشترك أعضاؤها في سياق تشفيري. وصُممت المعرّفات وأرقام الارتباط والـ epochs وهوية المصدر الآمن واشتقاق المفاتيح للتوسع أفضل من إنشاء جلسة مستقلة لكل زوج من نقاط النهاية. وهذا ضروري عندما تتغير مجموعة المسرّعات وعضوية المهام بسرعة.

البروتوكول جزء واحد فقط من نظام الأمن. يجب على مشغّل الإنتاج تشغيل سلطات المفاتيح والشهادات أو جذور ثقة أخرى، وخدمات عضوية المهام، والتوزيع والإلغاء، وانتقالات epochs، واستعادة نقاط النهاية، والتشفير في العتاد، والقياس الأمني. يمكن للشبكة أن تطابق ملفاً من دون تفعيل كل وظائف TSS الاختيارية. «متوافق مع UEC» لا يعني تلقائياً أن الحركة مشفرة.

تعكس الاختيارية افتراضات مختلفة للنشر. قد يعطي نسيج مخصص ومضبوط فيزيائياً الأولوية للأداء ويعتمد على ضوابط البيئة. وقد تحتاج سحابة متعددة المستأجرين إلى عزل قوي وحماية تشفيرية. يجب على نظام الملفات والمشتريات إظهار هذا الفرق.

الخطر الأشد ليس كلفة التشفير وحدها، بل فشل دورة الحياة في الحجم الكبير: عضوية قديمة، أو إلغاء متأخر، أو epochs غير متسقة، أو التعافي بعد فشل نقطة نهاية، أو العجز عن إثبات أي مهمة تستطيع الوصول إلى أي ذاكرة. تربط هذه المشكلات أمن النقل بأنظمة orchestration والهوية خارج المواصفة الأساسية.

ماذا يعني «UEC compliant» حالياً

بدأت UEC نشر مواد الامتثال مع الإصدار 1.0، لكن النظام العلني ليس برنامج شهادات مستقلاً ناضجاً. صُممت الحزمة المتاحة أساساً للإقرار الذاتي من المنفذين. تربط المصفوفات متطلبات المواصفة بالملفات، وتصف إرشادات testbed إعدادات موصى بها لنقاط النهاية والمحوّلات. ولم يُعثر على قاعدة عامة شاملة تسجل فيها جهة مستقلة المنتجات التي نجحت أو فشلت في برنامج UEC كامل.

التمييز ضروري لأن ادعاءات مختلفة تنتشر في السوق. قد يكون المنتج مصمماً حول ميزات UEC قيد التطوير، أو ينفذ وظائف مختارة على السلك، أو يدعم ملفاً أو أجزاء منه في إصدار برمجي محدد. وقد يعلن مورّد امتثالاً كاملاً للميزات، أو يولد مختبر حركة UET عبر محوّل. ولا يعادل أي من ذلك تلقائياً شهادة مستقلة من طرف إلى طرف متعددة المورّدين.

إرشادات testbed العامة مفيدة لكنها محدودة عن قصد. فهي تقدم طوبولوجيات وفحوصاً للممارسات الجيدة، لا تأهيلاً كاملاً للنظام. ولا تغطي بالكامل التشغيل البيني الأوسع، والأداء، والضغط، والحجم، ودورة حياة API. كما لا تثبت السلوك عند خلط UET وRoCE، أو الترقيات الجزئية، أو الأعطال المتكررة، أو مجالات المفاتيح الكبيرة، أو أكبر أعداد نقاط النهاية المستهدفة.

يبرهن التعارض بين AI Full وAI Extended على الحاجة إلى versioning منضبط. ينبغي للمشتري أن يسأل عن المواصفة ومستوى التصحيح والملف والميزات الاختيارية وأنماط الوصلة ووظائف الأمن التي يغطيها الادعاء. ويجب أن تحدد الإجابة ما إذا كان الدليل من اختبار داخلي، أو عرض ثنائي، أو حدث للاتحاد، أو مختبر مستقل.

تتضمن المرحلة التالية الموثوقة تعريفات اختبار عامة مرتبطة بإصدارات دقيقة، وplugfests متعددة المورّدين، ونتائج تديرها جهة مستقلة بما فيها النتائج السلبية، وسجلاً يميّز نقاط النهاية والمحوّلات والبرمجيات والأنظمة الكاملة. وإلى أن يحدث ذلك، تبقى عبارة «UEC compliant» بداية للتحقق لا ضماناً كاملاً.

وثيقة مفتوحة مع التزامات براءات RAND

تتاح Ultra Ethernet Specification 1.0.3 علناً وتوزع بترخيص Creative Commons Attribution-NoDerivatives 4.0. يسمح الترخيص بإعادة التوزيع مع الإسناد، لكنه لا يسمح بتوزيع نسخ معدلة. والأهم أن حق الوصول عبر copyright منفصل عن حق استخدام البراءات.

تستخدم مواثيق مجموعات العمل الموثقة عموماً نموذج تطوير مواصفات تقليدياً مع ترخيص براءات بشروط معقولة وغير تمييزية. لا تعني RAND بالضرورة royalty free، ولا تضمن سعراً عالمياً، ولا تزيل التفاوض، ولا تمنع الخلاف على الصلاحية أو الضرورة أو النطاق الجغرافي أو الشروط الدفاعية. تعتمد الصورة التجارية على كل براءة معلنة والتزام العضو وأي اتفاق ثنائي.

تحافظ UEC على سجل علني لإعلانات Necessary Claims. وعند حد البحث ظهرت إعلانات مرتبطة بـ Broadcom وMicrosoft وHuawei وQualcomm وAMD وHPE وGoogle وMarvell وغيرها، منها إيداعات متصلة بأعمال مستقبلية للنسخة 1.1. يحسن السجل الشفافية لأنه يوضح أن المنفذين قد يحتاجون إلى فحص الملكية الفكرية قبل بناء منتج أو شحنه.

يصرح الاتحاد بأنه لا يحدد ما إذا كانت البراءة المعلنة صحيحة أو ضرورية فعلاً أو منتهكة أو متاحة بسعر معين. كما لا ينشر ترخيصاً مشتركاً. وقد يواجه المنفذون الصغار تكاليف قانونية ومعاملات تستطيع الشركات الكبيرة استيعابها بسهولة أكبر. يمكن لمواصفة عامة أن تنتج سوق تنفيذ مركزاً إذا كانت كلفة تصفية البراءات والسيليكون والاختبار مرتفعة.

يؤثر إطار الملكية الفكرية أيضاً في حوافز الحوكمة. تساهم الشركات بالتقنية جزئياً لإنشاء سوق واسعة لمنتجاتها وجزئياً لضمان تمثيل قدراتها في التصميم المشترك. لا تحمي إعلانات البراءات المنفذين من المفاجآت إلا إذا كانت مبكرة وواضحة بما يكفي. ولا تزيل احتمال تحول الترخيص إلى حاجز بعد اتساع الاعتماد.

لذلك فالوصف الصادق هو «منشورة علناً ومتعددة المورّدين مع التزامات RAND»، وليس «حرة من الرسوم على نحو عالمي». تحتاج فرق المشتريات إلى الملف التقني ومسار الترخيص معاً.

الموجة الأولى من المنتجات والاختبارات

بدأت أدلة التنفيذ تظهر حول إصدار 1.0، لكن الأمثلة تقع في درجات نضج مختلفة.

أتاحت AMD بطاقة Pollara 400 AI NIC تجارياً في أبريل 2025، ووصفتها بأنها مصممة حول قدرات UEC قيد التطور. Pollara منصة endpoint قابلة للبرمجة وإشارة مهمة إلى انتقال النقل إلى عتاد يُشحن فعلاً. لكن الصياغة مهمة: التصميم حول ميزات متطورة لا يساوي شهادة مستقلة ضد كل متطلبات 1.0.3 النهائية.

أعلنت Broadcom في يونيو 2025 عن Tomahawk 6 بوصفه ASIC للتحويل بسرعة 102.4 تيرابت في الثانية مع ميزات ذات صلة بأنسجة UEC. وفي أكتوبر أعلنت Thor Ultra 800G NIC وقالت إن التصميم يقدم امتثالاً كاملاً لميزات UEC. هذا ادعاء مهم من المورّد، لكن الدليل العام لا يحوله إلى شهادة مستقلة من الاتحاد. ينبغي فصل sampling ونضج البرمجيات والدعم الدقيق للملفات.

أعلنت Nokia وKeysight في أكتوبر 2025 عن عرض حركة UET من طرف إلى طرف عبر عائلات محوّلات مراكز البيانات Nokia 7220 و7250 عند 800 Gigabit Ethernet. وفرت Keysight توليد الحركة والتحقق. يثبت الاختبار أن حركة UET تستطيع عبور أنظمة تحويل تجارية وأن دعم معدات الاختبار يتطور. لكنه لا يثبت ملف endpoint كاملاً متعدد المورّدين أو حجم إنتاج أو شهادة مستقلة لكل الميزات الاختيارية.

وصف أعضاء آخرون محوّلات وأنظمة وبرمجيات وخطط اختبار قادرة على UEC، وركزت قمة 2026 بقوة على productisation. تدعم الأدلة انتقالاً إلى التنفيذ، لكنها لا تثبت عدداً دقيقاً من بطاقات UET المشحونة أو المحوّلات المعتمدة أو مناطق السحابة العاملة أو الأنسجة الكاملة.

أفضل قراءة للموجة هي سلسلة أدلة. المواصفة العامة تتيح التصميم. إعلانات السيليكون وNIC تظهر الاستثمار. عروض الحركة تظهر بعض التشغيل البيني. مصفوفات الامتثال تنظم المتطلبات. تقارير المشغّلين ستظهر القيمة التشغيلية. أما plugfests المستقلة ونتائج الإنتاج فستوفر الثقة الأوسع التي ما زالت ناقصة.

RoCE وInfiniBand وSlingshot وUALink

تدخل UEC سوقاً فيها بدائل ناضجة وتقنيات مجاورة. لا يقوم طرحها الاستراتيجي على أن Ethernet لم تحمل RDMA من قبل أو أن الأنسجة المتخصصة لا تعمل، بل على أن حجم أحمال الذكاء الاصطناعي الحالية وتزامنها يبرران معمارية Ethernet جديدة من طرف إلى طرف، أكثر مرونة في التسليم واستعمال المسارات والتحكم في الازدحام.

RoCEv2 هو السلف المباشر وتقنية واسعة الانتشار. يضع حركة RDMA فوق Ethernet قابلة للتوجيه وله دعم واسع في التطبيقات والمنتجات. تنتقد UEC عمليات RoCE الشائعة لأنها تثبت التدفق الكامل على مسار واحد، وتستخدم Go-Back-N وإعادة ترتيب عند المستقبل، وتتطلب ضبط DCQCN صعباً، وتعتمد على Priority Flow Control في تصميمات كثيرة، وتظهر سلوكاً ضعيفاً عند incast أو bursts جماعية. هذه مواقف تقنية للاتحاد، وليست دليلاً على ضعف كل شبكة RoCE.

المقارنة متحركة أيضاً. يستطيع المورّدون إضافة adaptive routing وpacket spraying وخوارزميات ازدحام أفضل أو وظائف شبيهة بـ UEC إلى NIC قابلة للبرمجة مع الحفاظ على توافق RoCE. فعلى سبيل المثال تعرض AMD في رسائل Pollara كل من RoCEv2 وUEC RDMA كخيارات على عتاد قابل للبرمجة. يمكن لـ UEC أن تنافس RoCE كنقل كامل وتؤثر في الوقت نفسه في تطور منتجات RoCE المستقبلية.

InfiniBand هو البديل المتخصص الأهم. يقدم منظومة متكاملة لـ RDMA والازدحام وموثوقية الوصلة والإدارة مع خبرة طويلة في HPC. ويتضمن عمل 2.0 لدى InfiniBand Trade Association دعماً فيزيائياً لـ XDR عند 200 غيغابت في الثانية لكل lane وقياساً محدثاً. أقوى تمييز لـ UEC ليس القول إن InfiniBand تفتقر إلى الأداء، بل إمكانية تحقيق سلوك IA/HPC عبر سلسلة توريد Ethernet الأوسع، وتوجيه IP القياسي، وخيار أكبر بين المورّدين.

يشغل HPE Slingshot موضعاً وسطاً. فهو نسيج HPC تجاري متوافق مع Ethernet، يضم adaptive routing وإدارة ازدحام، وقدم سوابق تقنية مهمة لـ UET. ويثبت أن السلوك المتخصص يمكن بناؤه فوق Ethernet، لكنه يوضح أيضاً الفرق بين منصة تجارية مضبوطة ومواصفة على مستوى الصناعة.

غالباً ما تكون UALink مكمّلة لا بديلاً مباشراً. تستهدف مواصفتها العامة 200G الحالية اتصال scale-up منخفض الكمون بين المسرّعات داخل pod، وتصف أنظمة حتى 1,024 مسرعاً. أما UEC 1.0 فهي أساساً نسيج scale-out يربط العقد عبر المحوّلات. يمكن لمركز بيانات استخدام وصلة scale-up داخل pod وUEC بين pods أو العقد. وقد تقرّب أعمال UEC المستقبلية في النقل scale-up والعمليات الجماعية داخل الشبكة الحدود وتنتج تقارباً أو منافسة.

يوفر NVIDIA Spectrum-X والأنسجة المملوكة للمسرّعات مقارنة أخرى. يستطيع مكدس متكامل بإحكام تحسين العتاد والبرمجيات والدعم سريعاً، لكنه يزيد الاعتماد على منظومة واحدة. تستبدل UEC بعض هذا التكامل بوعد الواجهات المشتركة واختيار المورّد. ويعتمد نجاح المقايضة على الأداء والدعم وشروط البراءات والتشغيل البيني والكلفة التشغيلية الكلية، لا على كلمة «مفتوح» كمجرد شعار.

المشكلة التشغيلية أكبر من البروتوكول

يمكن لمواصفة من 573 صفحة تحديد متطلبات كثيرة، لكن نسيج الإنتاج ما زال يحتاج إلى نموذج تشغيل. تترك UEC 1.0 أعمال إدارة مهمة خارج الوثيقة المعيارية الأساسية أو حولها. يجب على المشغّلين إعداد الملفات وفئات الحركة وعتبات ECN ومجموعات entropy وميزات الوصلة الاختيارية والمفاتيح وfirmware والقياس وسياسة الأعطال بصورة متسقة بين نقاط النهاية والمحوّلات.

تجعل الحركة المختلطة الأمر أصعب. فقد يحمل نسيج مركز البيانات UET وRoCE وTCP والتخزين والإدارة وخدمات UET المرتبة وغير المرتبة. لا تُحل مسألة توزيع الصفوف والعدالة بينها بمجرد صحة تنفيذ كل بروتوكول. قد تعمل خوارزمية ازدحام جيداً منفردة، ثم تتصرف بصورة سيئة عند منافسة متحكم آخر يعتمد إشارات وافتراضات مختلفة.

تعقيد نقطة النهاية خطر هيكلي آخر. يضع UET تعدد المسارات والوضع المباشر وإعادة الإرسال الانتقائية وأنماط التسليم المتعددة والتحكم بالنوافذ والاعتمادات واستقبال trimming والأمن وحالة كبيرة داخل FEP. قد يزيد ذلك مساحة die في NIC وحجم firmware وجهد التحقق والطاقة وعدد حالات الفشل المطلوب تشخيصها. تمكّن ذكاءات نقطة النهاية سلسلة توريد واسعة، لكنها قد تضع أصعب تنفيذ في المكوّن الذي يجب على كل خادم شراؤه.

تنشئ الميزات الاختيارية تمييزاً للمنتجات وتجزؤاً في الوقت نفسه. قد يحسّن مورّد endpoint أساسياً لـ AI Base مع ECMP وECN عاديين. وقد يدعم آخر AI Full وHPC وTSS وtrimming وLLR وCBFC. كلاهما في منظومة UEC، لكن المشغّلين لا يستطيعون افتراض الدلالات أو الأداء أو الأمن نفسه. يجب أن تتحول مصفوفات الامتثال إلى مصفوفات تشغيلية للقدرات.

ستكون صيانة الإصدارات مستمرة. أثرت التصحيحات من 1.0.1 إلى 1.0.3 في الازدحام والاعتمادات وإعادة المحاولة وسلوك الحزم. وقد يضم cluster كبير إصدارات مختلفة من firmware في NIC، وإصدارات متعددة للمحوّلات وأدوات الاختبار. ويمكن لترقية طبقة من دون تنسيق البقية أن تكشف بالضبط التفاعل العابر للطبقات الذي يسعى الاتحاد لتجنبه.

لهذا تعد العلاقات الخارجية مركزية وليست رمزية. يستطيع Open Compute Project ربط النقل بالأنظمة والعتاد المفتوح. وتربط OpenFabrics Alliance ومجتمع libfabric التطبيقات. ويقدم IEEE 802.3 عمل Ethernet الرسمي. وتضيف SNIA وNVM Express متطلبات التخزين والإدارة. وتوفر تقنيات IETF آليات IP وECN وما يتصل بها. لهذه الهيئات عمليات قرار وخرائط طريق مختلفة؛ يقلل التنسيق التكرار لكنه لا يضمن اعتماداً متزامناً.

الاختبار التشغيلي النهائي هو البنية العاملة. يمكن للوثيقة تحديد السلوك، وللمورّد إعلان منتج، وللاتحاد تنظيم قمة. لا يعوض أي من ذلك cluster تنجز فيه نقاط نهاية ومحوّلات مستقلة مهاماً حقيقية عند الازدحام والعطل والترقية، ويستطيع المشغّلون تفسير ما حدث.

الأهمية الراهنة: من نجاح المواصفة إلى مصداقية التنفيذ

بحلول يوليو 2026 حقق UEC أموراً كانت غير مضمونة عند الإطلاق. فقد أنشأ ائتلافاً واسعاً، ووضع معمارية متكاملة ذات خمس طبقات، وأصدر مواصفة 1.0 كاملة، وحافظ عليها عبر إصدارات تصحيح، وأضاف 200G لكل lane، وكشف إعلانات براءات، وجذب إعلانات منتجات واختبارات. المشروع نشط، وانتقلت أجندته بوضوح نحو التنفيذ.

يجعل التقدم الشكوك التالية أكثر أهمية لا أقل. لا يظهر العدد الحالي الدقيق للأعضاء وroster الخاص بـ Steering في سجل مرجعي واحد. وتصف صفحات العضوية العامة والوثيقة التنظيمية الوصول بطرق مختلفة. ولا تتطابق القيادة الرسمية الحالية لـ TAC بالكامل مع أدوار القمة. كما تختلف وثائق رسمية في تاريخ 1.0.2، وتستخدم حزمة الامتثال مصطلحات ملف قديمة. لا يهدم أي من ذلك المعمارية، لكنه مؤشر على ضبط الوثائق والشفافية في مشروع تعتمد فيه النتائج على الإصدارات الدقيقة.

أما الفجوات الأهم فتتعلق بالاعتماد. لا تنشر UEC إحصاء للنشر، ولا سجل منتجات تحقق منه طرف مستقل، ولا ميزانية مستقلة أو حسابات مدققة. ولا يوجد دليل عام على شبكة UEC 1.0 كاملة التشغيل البيني عند أهداف الحجم القصوى للاتحاد. عروض المورّدين وادعاءاتهم ذات قيمة، لكنها تأتي من أطراف ذات مصلحة تجارية. ولا تزال المقارنات المحايدة مع RoCE الحالية وInfiniBand والمنصات Ethernet المتكاملة محدودة.

تبقى الفرصة كبيرة. Ethernet هي القاسم المشترك في مراكز البيانات، وسوق بنية الذكاء الاصطناعي كبير بما يكفي لدعم أجيال جديدة من NIC والمحوّلات والبصريات والبرمجيات. ولدى المشغّلين حوافز قوية لتقليل الاعتماد على مورّد واحد وتحسين استخدام المسرّعات. ويمكن لمكدس مشترك تحويل هذه الحوافز إلى قوة شراء.

الخطر هو أن تصبح «Ultra Ethernet» مظلة لمجموعات ميزات غير متوافقة. فإذا عمل التوجيه الأساسي لكن اختلفت الملفات والازدحام والأمن والإدارة، قد تنتشر العلامة أسرع من التشغيل البيني. وإذا كان ترخيص RAND غالياً أو غامضاً، قد تضيق مجموعة المورّدين. وإذا امتصت منتجات RoCE أكثر الأفكار جاذبية من دون نقل جديد، قد تؤثر UEC في السوق من دون أن تصبح الاسم المهيمن.

لم يعد السؤال الحاسم ما إذا كان الاتحاد يستطيع نشر مواصفة متقدمة. لقد فعل. السؤال هو ما إذا كانت المؤسسات المستقلة تستطيع تنفيذ العقود نفسها، وترخيص التقنية الضرورية، وتشغيل النسيج في الحجم الكبير، والحفاظ على التوافق مع تطور المواصفة. لن تتحول UEC إلى بنية تحتية إلا بقدر ما تصمد هذه الادعاءات أمام الأنظمة العاملة.