الخلاصة

  • يعرّف RFC 10005 شكلين transitive وnon-transitive من BGP Link Bandwidth Extended Community، يحملان قيمة IEEE 754 من 32 بت بوحدة بايت في الثانية، لكنه يترك طريقة حساب القيمة وسياسة الموازنة والحساب التجميعي محلياً.
  • قد تمثل القيمة وصلة أو مساراً مجمعاً أو عدد خوادم أو مجرد نسبة. لذلك يحتاج الدليل إلى تتبع كل صاحب قرار من UPDATE الأول حتى مجموعة multipath وFIB والمرور الفعلي.

بدأت المشكلة عند حدود شبكتين. أعلن الطرف الأول سعة مجمعة قدرها 70. قبل الطرف الثاني الرقم، مع أن وصلته المحلية إلى ذلك الطرف لا تتجاوز 50، واستخدمه كنسبة في توزيع المرور. لم يكذب بروتوكول BGP؛ بل نقل القيمة المطلوبة تماماً. لكن السؤال الذي لم يُكتب في أي تذكرة كان: من يملك حق القول إن 70 البعيدة تصف ما يستطيع المستقبل تسليمه محلياً؟

تعرض النسخة الحالية من مسودة حالات الاستخدام هذا المثال: مسار بعيد 30 وآخر 70، في حين أن الوصلة المحلية للثاني 50 فقط. اعتماد 30/70 قد يصنع ازدحاماً. يستطيع المستقبل اختيار القيمة البعيدة، أو سرعة الوصلة المحلية، أو دالة تجمعهما مثل الحد الأدنى. القرار محلي، وكذلك تبعته.

نُشر RFC 10005 في يونيو 2026 بوصفه Proposed Standard. قيمته الأساسية أنه يجعل النقل بين التطبيقات قابلاً للتشغيل البيني؛ أما المعنى الاقتصادي والتشغيلي للرقم فلا يسكن داخل الحقل.

ما الذي يثبته الترميز؟

يستخدم الشكل transitive النوع 0x00، ويستخدم non-transitive النوع 0x40، وكلاهما يحمل SubType 0x04. يشغل Global Administrator بايتين، وينبغي أن يكون ASN للجهاز الذي ألحق community، لكنه قد يكون أي قيمة من بايتين. إذا لم يتسع ASN يستخدم AS_TRANS؛ ولا يدعم الترميز ASN كاملاً من أربعة بايتات.

ينص RFC على أن Global Administrator لا يغير معنى community. وهو لا يصادق هوية الكاتب ولا يثبت ملكيته لمورد أو قيامه بقياس. تحديد الكاتب يحتاج الجلسة والسياسة والإعداد وإصدار البرنامج وسجل التغيير.

يحمل Local Administrator عدداً عائماً 32-bit وفق IEEE 754، بوحدة بايت لا بت في الثانية. هذه قاعدة فك ترميز، لا شهادة قياس. يترك RFC طريقة تحديد عرض النطاق خارج النطاق. وتستخدم مسودة الحالات القيمة لسرعة وصلة، أو مجموع مسارات، أو طاقة خدمة وعدد خوادم، أو وزن نسبي.

صاحب القرار الأول: من أنشأ القيمة

ينبغي أن يتيح المرسل اختيار transitivity وضبط Global Administrator والقيمة عبر سياسة محلية، مع إظهار القيمة الافتراضية. قد تختلف defaults بين التطبيقات. لذلك لا يكفي أن يكتب المشغل اسم الشركة المصنعة في سجل الإثبات.

يمكن للمرسل إعلان صفر. يذكر RFC الصيانة مثالاً كي لا يجذب المسار مروراً، لكن المستقبل يحدد ما يفعله الصفر. نية المصدر ليست أمراً عالمياً.

على المنشئ حفظ مصدر القيمة: سرعة interface مضبوطة أو مكتشفة، مجموع مسارات، عدد خوادم، وزن يدوي؛ ووقت الحساب، ومجال prefixes، ومدة الصلاحية، وحدود النشر. من دون ذلك يصبح الرقم معلومة بلا نسب.

صاحب القرار الثاني: من غيّرها داخل السياسة

يسمح RFC بإضافة community أو تحديثها في Adj-RIB-In، وبفعل الشيء نفسه في Adj-RIB-Out. يمكن أن يدخل UPDATE بقيمة ويخرج بأخرى بصورة مطابقة للمعيار. عند هذه النقطة لا يعود المشغل ناقلاً فقط؛ إنه صاحب إعلان جديد.

عندما يغيّر المتحدث next hop، يمكن أن يزيل القيمة أو يحافظ عليها أو يعيد توليدها. ينبغي للتطبيق عرض default وتوفير تحكم لكل session. إذا لم يتغير next hop، كما في route reflection، فلا ينبغي تغيير community.

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

صاحب القرار الثالث: من سمح لها بعبور الحدود

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

أثناء الترحيل قد تحمل route شكلين، وينبغي أن تتطابق القيمتان. قد يفهم برنامج قديم شكلاً واحداً فقط. إذا حدّث جهاز وسيط شكلاً دون الآخر، يستخدم مستقبلون مختلفون أوزاناً مختلفة. لا يكفي تحديث Route Reflector وحده؛ هذه ليست غاية التوافق التي يعد بها RFC.

يجب أن يحدد سجل النشر المجال الإداري، والجار المصرح له، والغرض، ونوع community، وأي filter. عبارة «انتقلت مع BGP» لا توضح من سمح بمعلومة السعة أن تغادر.

صاحب القرار الرابع: من حولها إلى مرور

إذا كانت كل المسارات المشاركة تحمل قيماً غير صفرية، يستطيع المستقبل استخدام القيم أو نسبها للأوزان. عند اختلاط الصفر بغيره، أو كون الجميع صفراً، تحدد local policy النتيجة. إذا غابت community صالحة عن أي مسار، ينبغي استخدام equal load balancing ما لم يغير الإعداد ذلك.

القيمة السالبة لا ينبغي أن تُنشأ وتُهمل عند الاستقبال. الصفر صالح وليس malformed. إذا وُجدت قيم متعددة، فالقاعدة الافتراضية اختيار الأصغر، بما فيها الصفر، من دون اعتبار transitivity، مع إمكان override محلي. ولا ينبغي أن تدخل القيمة في best-path selection؛ تأثيرها يأتي بعد تأهل المسارات لـmultipath.

إذن وجود الحقل في RIB لا يثبت عضوية multipath، وعضوية multipath لا تثبت أوزان hardware، والأوزان لا تثبت توزيع flow فوراً. كل طبقة تحتاج قراءة مستقلة.

التطبيقات تكشف تعدد السلطات

توضح وثائق Juniper أن القيمة المضبوطة ليست حركة المرور المشاهدة وأن النسبة قد تكون المقصودة حتى لو لم تطابق سرعة interface. وتعرض Cisco DMZ Link Bandwidth وتوزيعاً موزوناً. ويسجل دليل Arista EOS إعادة توليد القيمة لكل جار وخيارات التجميع.

هذه أدلة على وجود knobs فعلية، لا على سلوك موحد أو تشغيل feature في شبكة بعينها. running code هو إصدار محدد، وإعداد فعال، وUPDATE مستلم، وFIB مقروء، ونتيجة مقاسة.

دفتر واحد لسلسلة موزعة

لكل prefix مهم، احفظ route قبل policy وبعدها، والجار، وaddress family، وnext hop، والنوع، وGlobal Administrator، والبايتات الخام والقيمة المفكوكة. أضف تصنيف المصدر ودالة local/remote، وأي إزالة أو حفظ أو إعادة توليد، ومن وافق عليها.

ثم احفظ multipath candidates وسبب التأهل، ومعالجة zero/missing/multiple، وأعضاء FIB وأوزانها في hardware. اربطها بحصة المرور، والصفوف، والفقد، والكمون، ونتيجة التطبيق، ووقت التغيير وحد rollback.

تضع Running-Code Primacy لدى Heng Lu الدليل الجاري فوق سلطة الوثيقة أو النية. وتحدد Minimum Initial Specification الطبقة المشتركة في قواعد قابلة للتحقق للتشغيل البيني والأمان، وتترك الخيارات اللاحقة للمشغلين.

الرقم واحد، لكن كل من أنشأه أو غيّره أو نشره أو استخدمه يحتفظ بسلطته—وبالمسؤولية الموافقة لها.