الخلاصة

  • يعرّف RFC 7570 حاوية عامة اختيارية لسمات القفز في كل من ERO للإشارة وRRO للتقرير. والكائن الفرعي في ERO هو النوع 35، بطول متغير، ويحمل TLV أو أكثر من Hop Attributes ضمن حد طول الكائن نفسه.
  • يوضع الكائن بعد كائن ERO يعرّف القفزة، أو بعد كائنات الملصقات المرتبطة بها؛ وتنطبق السمات على الكائن أو الكائنات الفرعية السابقة مباشرة. لذلك فالموضع يحدد النطاق، لكنه لا يمنح المدخل سلطة على بقية LSP.
  • يحدد المستند الذي يعرّف السمة أنواع كائنات ERO السابقة المقبولة، وما إذا كان الترتيب مهماً وكيف يُفسَّر، وقواعد التعديل والتقرير. ولا ينبغي الخلط بين سياسة R وبين معنى السمة نفسها.

البنية العملية هي: كائن تحديد القفزة، ثم النوع 35، ثم TLV الخاصة بالسمة. إذا كان R=1 يفحص العقدة TLV وفق قواعد RFC 5420 المطلوبة؛ وإذا كان R=0 تطبق قواعد المعالجة الاختيارية. هذه إشارة إلى أسلوب التعامل مع المحتوى عند القفزة المعنية، وليست تعريفاً لما تطلبه السمة أو تفويضاً بتغيير العقد الأخرى. وتبقى المعاني، وشروط المكان والترتيب، وإمكان التعديل، ومتطلبات التقرير في وثيقة السمة وفي سياسة العقدة وتفويضها المحلي.

قد ترفض العقدة الطلب بسبب سياسة RSVP أو التحكم في القبول، وقد تعدّل السمة عندما تسمح إجراءات TLV المعرفة بذلك. أما الكائن غير المدعوم أثناء معالجة ERO فقد يؤدي إلى Routing Error / Bad EXPLICIT_ROUTE PathErr مع اقتطاع ERO عند الكائن المخالف. كما أن الكائن المشوّه أو غير الصالح لا يتحول إلى طلب صالح بمجرد وضع R=0. ووفق RFC 3209، ينتج الكائن غير المعروف الذي صادفته المعالجة خطأ Bad Explicit Route Object، في حين يمكن تمرير كائن لم تُصادفه العقدة بعد إلى الأمام. وبالنسبة للأعلام: لا تنطبق إلا الأعلام المعرّفة على أنها صالحة في هذا السياق؛ الأعلام غير الصالحة تُتجاهل بصمت، أما الأعلام المجهولة فينبغي أن تؤدي إلى Unknown Attributes Bit PathErr.

ينبغي فصل مستويين من التقرير. فسمات LSP العامة، المحمولة عادة في LSP_ATTRIBUTES أو LSP_REQUIRED_ATTRIBUTES، تُبلّغ عادة عبر RRO Attributes وفق RFC 5420. أما السمة التي أُرسلت فقط داخل ERO Hop Attributes فتُبلّغ عادة عبر RRO Hop Attributes، وهو النوع 35 في RRO. يمكن للعقدة أن تقول إنها نظرت في السمة أو أن تضيف TLV، لكن وثيقة السمة وحدها تحدد هل يوجد التزام بتقرير الامتثال. ويمرر العبور التقرير عادة دون تعديل، غير أن حدود النطاق قد تحذفه أو تعدّله لأسباب السرية أو حجم الرسالة. لذلك فغياب دليل RRO لا يثبت الفشل، ووجوده ليس برهاناً غير قابل للتغيير؛ إنه دليل مشروط بسياسة المجال ووثيقة السمة.

يقدم RFC 7571 مثالاً محدوداً فقط: طلب OAM loopback موجّه إلى عقدة معينة، مع حالة loopback في RRO Hop Attributes. لا تعني هذه الآلية العامة «loopback»، ولا يقرر المثال معنى السمات المستقبلية. يحتاج المستفيد الذي يريد سلوكاً في قفزة محددة إلى معرفة أن العقدة المعنية تدعم السمة وتسمح بها؛ أما نجاح إعداد LSP الاختياري وحده فلا يثبت التنفيذ.

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

  1. حدّد القفزة المطلوبة والكائن السابق مباشرة، ثم تحقق من أن وثيقة السمة تسمح بذلك النوع والترتيب.
  2. افحص التفويض المحلي وسياسة القبول، وحدد هل يبرر الغرض R=1 أم أن R=0 مقبول مع نقص الإثبات.
  3. افحص طول Path وERO، وتوافق العقد، وقواعد الأعلام، وإمكان التعديل، ثم حدّد سياسة RRO عند حدود المجال.
  4. بعد الإشارة، قارن Path وPathErr وRRO: لا تعتبر نجاح الإعداد دليلاً اختيارياً على الامتثال من دون تقرير معرف في وثيقة السمة.

تركيبات تحقق على مستوى الحزمة

  • Fixture A: ضع ERO لعقدة A، ثم type=35 بعده، وTLV للسمة مع R=0؛ تحقق من أن A هي القفزة المخاطبة وأن عقدة B لا تُستنتج منها سلطة أو امتثال.
  • Fixture B: أرسل النوع 35 نفسه مع R=1 إلى عقدة لا تدعمه؛ تحقق من PathErr من نوع Routing Error / Bad EXPLICIT_ROUTE وأن ERO مقتطع عند الكائن المخالف.
  • Fixture C: اجعل TLV تحمل علماً غير صالح ثم علماً مجهولاً؛ افصل بين التجاهل الصامت للأول وUnknown Attributes Bit PathErr المتوقع للثاني.
  • Fixture D: قارن LSP_ATTRIBUTE في RRO Attributes مع سمة ERO في RRO Hop Attributes، ثم احذف RRO عند حد مجال؛ يجب تسجيل أن الدليل أصبح غائباً لا أن السمة فشلت.
  • Fixture E: أرسل ترتيباً أو نوع كائن سابق لا تسمح به وثيقة السمة؛ تحقق من الرفض أو التعديل المحلي، ولا تفسر R بأنه إذن بتجاوز القاعدة.

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

المصادر