الخلاصة

  • XRO يفرض قيداً على كامل المسار، بينما يضع EXRS القيد داخل نطاق مقطع محدد من ERO؛ وكلاهما سلطة سلبية على ما لا يجوز استخدامه، لا وصف للمسار البديل.
  • البت L الواضح يعني يجب الاستبعاد، أما البت L المضبوط فيعني ينبغي التجنب؛ وقد تسمح سياسة الحساب المحلية بالعبور في الحالة الثانية.
  • التنوع نتيجة يجب إثباتها بسجل المسار والطوبولوجيا والموارد الفعلية، وليس وعداً يحمله علم في رسالة.

ماذا يحدث في الحساب؟

يحدد RFC 3209 المسار الصريح عبر ERO، ويضيف RFC 4874 إشارات للاستبعاد عندما لا يلزم أن يحسب المُدخل المسار الكامل. يستطيع XRO تسمية بادئة IPv4 أو IPv6، أو واجهة غير مرقمة، أو نظاماً مستقلاً، أو SRLG، مع إمكان تمييز خصائص الواجهة والعقدة وSRLG. ويستطيع EXRS، بوصفه كائناً فرعياً داخل ERO، تقييد جزء من المسار بدلاً من كامل الرحلة. لذلك يجب على عقدة الحساب، عند اختيار القفزة التالية أو توسيع مسار صريح مرن، أن تحذف الموارد التي تغطيها استبعادات إلزامية وأن تقلل الموارد الاستشارية قدر الإمكان.

إذا ناقض XRO إلزامي إدراجاً في ERO، تسود قيمة الاستبعاد: ترفض العقدة رسالة Path وتعيد خطأ Routing Problem المحدد. وإذا أزالت القيود كل خيار للتوجيه، ينبغي أن تعيد PathErr يبين أن المسار حُجب بواسطة Exclude Route. وقد تُرفض رسالة XRO أيضاً إذا كانت معقدة أكثر مما تستطيع العقدة أو سياستها معالجته. هذه حالات فشل في الإعداد، لا اختيار تلقائي لمسار احتياطي.

أما عقدة لا تدعم XRO فقد تمرره بسبب رقم فئة XRO من دون فحص. كما قد تُتجاهل كائنات فرعية أو سمات غير مدعومة. لذلك لا يكفي افتراض أن كل وسيط فهم القيد: يجب فحص Record Route على عقدة الحساب لملاحظة الانتهاكات ومحاولة إعادة الحساب أو إعادة التوجيه حيث يسمح التنفيذ. عدم الدعم، والحدود بين مجالات الحساب، وسياسة إزالة معلومات ERO لأسباب أمنية، كلها تحدد ما يبقى من السلطة عند كل حد.

مجال القيد ومجال المعرفة

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

يحدّث RFC 6001 آلية RFC 4874 للشبكات متعددة الطبقات والمناطق في GMPLS، بإضافة استبعادات لقدرة التحويل وبطاقات التسمية، مع إبقاء الفرق بين MUST-exclude وSHOULD-avoid. أما RFC 8390 فيضيف معرّفات تنوع في XRO وEXRS، قد يخصصها عميل أو PCE أو الشبكة لمسار LSP أو مسار مرجعي لا يعرف الطالب موارده التفصيلية. يمكن لهذا أن يقلل كشف الطوبولوجيا ومتطلبات المعرفة لدى الطالب، لكنه ينقل عبء صحة المطابقة والتحقق إلى PCE أو الشبكة التي تحل المعرّف. التمييز بين التنوع الإلزامي والاستشاري، وأخطاء المعرّف غير المتسق أو غير المدعوم، والاحتفاظ بمعرّفات التنوع عبر الحدود حتى عندما تزال معلومات ERO العادية لأسباب أمنية، ليست تفاصيل تجميلية؛ إنها شروط توافق.

المصالح والكلفة والحدود المعرفية

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

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

تجهيزات تحقق عملية

  1. رسالة Path أساسية: أنشئ عقدة حساب لها مساران ممكنان، وضع واجهة في XRO ببت L واضح؛ تحقق من أن القفزة المختارة لا تستخدم الواجهة، لا من أن XRO سمّى المسار المتبقي.
  2. تعارض ERO: أدرج المورد نفسه في ERO وXRO الإلزامي؛ تحقق من رفض Path ورسالة Routing Problem، لا من قبول الإدراج الصريح.
  3. انعدام الحل: استبعد كل القفزات الممكنة؛ تحقق من PathErr الذي يصف الحجب بواسطة Exclude Route.
  4. التعقيد: أرسل XRO يتجاوز قدرة التنفيذ أو السياسة؛ تحقق من PathErr الخاص بـ XRO شديد التعقيد.
  5. L-bit: كرر الاختبار ببت L مضبوط؛ سجل أن المرور قد يبقى مسموحاً وفق سياسة الحساب، ولا تسميه MUST.
  6. عدم الدعم: مرر XRO عبر عقدة غير داعمة أو بفرع فرعي غير مدعوم، ثم افحص Record Route لاحتمال الانتهاك وإعادة الحساب.
  7. متعدد الطبقات: اختبر استبعاد switching capability وlabel وفق RFC 6001 عبر طبقتين؛ تحقق من بقاء دلالة الإلزام والتجنب.
  8. التنوع والحدود: استخدم معرّفاً عميلاً أو PCE أو شبكياً لمسار مرجعي وفق RFC 8390، ثم اختبر معرّفاً غير متسق أو غير مدعوم، وراقب الاحتفاظ به عبر الحد.
  9. التحقق النهائي: قارن Record Route مع قاعدة الطوبولوجيا والموارد الفعلية؛ لا تعتبر نجاح الإشارة دليلاً على فصل فيزيائي.

مسار قرار المشغّل

حدّد أولاً المستفيد وحدود المسار المطلوب. استخدم MUST فقط عندما يكون الفشل أفضل من إعادة استخدام المورد؛ استخدم SHOULD عندما تكون الإتاحة أهم من الفصل الصارم. افحص دعم XRO وEXRS وRFC 6001 وRFC 8390 في كل مجال وحد، وحدد سياسة خطأ عند انسداد المجموعة. بعد الإعداد، راجع Record Route ومعرّف المسار المرجعي، ثم طابقهما مع الطوبولوجيا. إذا لم تثبت المطابقة، تعامل مع التنوع على أنه غير مثبت، لا كميزة مؤكدة.

المصادر