الخلاصة

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

الخريطة تتسع، صندوق الموجّه لا يتسع

في غرفة العمليات تسع الخريطة كل طريق يقترحه المتحكم. أما الموجّه فلا يملك رفاً سحرياً. في ليلة صيانة، قد تبدو إضافة طريق ثانٍ حلاً أنيقاً. ثم يأتي السؤال الذي يدفع الفواتير: هل تستطيع العقدة تركيبه؟ ومَن يتحمل نقل حركة العملاء إليه؟

تعالج RFC 10066، المنشورة في أكتوبر 2026، هذا التفاوت. فهي تسمح لبروتوكول التحكم PCEP بوصف عدة طرق لحركة البيانات تحت مسار واحد، يسمى LSP. سبقتها بنية SR Policy إلى وصف سياسة يمكن أن تضم عدة قوائم للمقاطع. لكن RFC 9862 لم تحدد طريقة إرسال تلك القوائم المتعددة عبر PCEP. كانت الخريطة جاهزة قبل الظرف الذي يحملها.

للظرف الجديد سعة محددة. يحسب طرف يسمى PCE الطرق ويقترحها. ويتلقى عميله، المسمى PCC، الاقتراح ويطبقه. يعلن الاثنان أولاً دعمهما لتعدد الطرق، والعدد الأقصى الذي يستطيع كل منهما التعامل معه. على PCE أن يحترم السقف الأصغر عند إرسال الخطة. وإذا تجاوز سقف PCC، يرد العميل برسالة خطأ محددة: PCErr، النوع 19 والقيمة 36. يستطيع المتحكم اقتراح خطة؛ وتعلن العقدة كم طريقاً تستطيع حمله.

قد ينطبق السقف على جلسة التحكم كلها، أو على LSP واحدة. وإذا وصلت بيانات PATH-ATTRIB من دون اتفاق سابق على الميزة، فذلك خطأ بروتوكولي. تظهر قدرة العقدة المعلنة في رسائل يمكن فحصها. وعلى المشغّل أن يقارنها بما يستطيع الجهاز والبرنامج والموارد تنفيذه. الرقم في رسالة OPEN وعد بالقدرة؛ وتركيب الطريق في جدول التمرير واقعة أخرى.

وفي الاتجاه المعاكس توجد مفارقة مقصودة. يستطيع PCC أن يرسل تقريراً يسمى PCRpt عن طرق تعمل فعلاً، حتى لو كان عددها أكبر مما يستطيع PCE حسابه. تطلب RFC 10066 من PCE قبول التقرير. فالعميل يصف الواقع؛ ولا يطلب خطة جديدة. لو رفض المتحكم كل واقع أوسع من حساباته، لأصبحت لوحة المراقبة هادئة جداً، والشبكة أقل وضوحاً.

وزن صفر يبقي الطريق على الورق

يمكن إرفاق وزن اختياري بكل طريق في الحقل MULTIPATH-WEIGHT. وهو عدد غير سالب من 32 بت. إذا لم يُذكر الوزن، فالقيمة واحد. كلما زاد وزن الطريق، زادت حصته المقصودة من الحركة مقارنة بمجموع الأوزان.

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

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

وتترك RFC 10066 قياس كل طريق على حدة لعمل لاحق. يستطيع حقل METRIC وصف LSP كلها، لكنه لا يعطي زمناً أو خسارةً مستقلين لكل قائمة مقاطع. أما RFC 10067 فتعالج مسألة أخرى: ربط الطريق المتجه إلى الخارج بالطريق العائد. تحت عنوان «خدمة واحدة» تختبئ عدة طرق واتجاهات. الخط الأخضر الواحد في الواجهة يريح مدير المناوبة. وعند العطل يحتاج المهندس إلى تفاصيل أقل راحة: أي اتجاه كان مفتوحاً؟ أي وزن تغير؟ وأين انتهت الحزم؟

تقسم الرسائل سلطة القرار. يحسب PCE ويقترح. يعلن PCC قدرته ويصف ما يعمل. وتقرر المؤسسة المشغلة متى تغير الطريق، وكيف توزع الحركة، وما القياس الذي يثبت نجاح البديل. تميز ملاحظة Heng Lu رقم 73 بين المشاركة والتفويض. مَن يتحمل أثر تحويل حركة العملاء يملك القرار، لا مَن رسم الخريطة الجميلة.