الخلاصة

  • حين لا تكفي 255 ثُمانية، تسمح RFC 9885 بأن تمثل عدة TLV من النوع والمفتاح نفسيهما كائناً واحداً؛ يجب أن يكون كل جزء قابلاً للتحليل منفرداً، وعلى المستقبل جمع الأجزاء كلها بصرف النظر عن ترتيبها أو موضعها في شظايا LSP.
  • الإشارة الجديدة من النوع 30 معلوماتية فقط، ولا تسمي codepoints واحداً واحداً، ويُحظر أن تغير آلية البروتوكول ما ترسله أو ما تعالجه بسبب ظهورها.
  • لذلك يبقى التفويض خارج الإشارة: سجل يثبت نسخة كل مستقبل وسلوكه مع codepoint المقصود، ثم اختبار مرحلي وحدود توقف ومسار رجوع.

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

هذه الفجوة الصامتة هي ما تجعل RFC 9885 مسألة قيادة تشغيلية لا مجرد تعديل في الترميز. تحمل IS-IS المعلومات في بنية Type-Length-Value. ولأن حقلي Type وLength يتكون كل منهما من ثُمانية واحدة، لا تتجاوز قيمة TLV منفردة 255 ثُمانية. توسع الشبكات وتراكم صفات هندسة الحركة جعلا كائناً منطقياً واحداً يتجاوز الوعاء القديم. لذلك قننت الوثيقة تكرار TLV كآلية توسع افتراضية عندما لا تنص المواصفة الأصلية على طريقة أخرى.

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

تُجمع الدلالة لا قصاصات البايت

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

ولا يعني إهمال الترتيب إهمال التناقض. قد تتكرر قيمة ثابتة مثل metric من دون أن تكون جزءاً من المفتاح. اختلافها بين الأجزاء خطأ. وكذلك تكرار sub-TLV يفترض ظهوره مرة واحدة بقيم متعارضة. إن لم تحدد المواصفة الأصلية معالجة أدق، تُستخدم أول واقعة في LSP ذي الرقم الأدنى؛ وفي IIH تُستخدم الواقعة الأولى.

وتفصل الوثيقة بين تسامح المستقبل وانضباط المرسل. لا يجوز للمستقبل رفض جزأين طول كل منهما 100 بايت لمجرد أنهما كانا سيتسعان في TLV واحدة. أما المرسل فلا ينبغي أن ينتج عدة أجزاء إلا إذا كان الإجراء منطبقاً على codepoint وتجاوزت البيانات سعة TLV واحدة فعلاً. وإذا كانت TLV الكاملة تتسع لكن LSP الحالي مزدحماً، فالأفضل نقلها كاملة إلى LSP آخر.

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

النوع 30 علامة تشخيص، لا تفاوض

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

للمساعدة في التشخيص، سجلت الوثيقة sub-TLV من النوع 30 والطول صفر داخل Router CAPABILITY. تعلن هذه الإشارة دعماً عاماً للـ codepoints التي لم تصرح نصوصها السابقة بآلية الأجزاء. ونطاق الحاوية يكون لكل مستوى من IS-IS.

ثم تضع المواصفة الحد الحاسم: الإعلان لأغراض معلوماتية فقط. يجب ألا تغير تطبيقات IS-IS ما ترسله أو كيفية معالجة ما تستقبله بناء عليه. فهو ليس مصافحة تفاوضية، ولا موافقة موزعة، ولا قاطع أمان تلقائياً.

كما أن النوع 30 لا يملك صيغة تسرد codepoints المدعومة. تفترض المواصفة دعماً واسعاً، لكنها تعترف بأن التطبيق الحقيقي قد يدعم الآلية في codepoints محددة فرضتها حالات استخدامه. ما يبدو إشارة واحدة يخفي مصفوفة من المنصات والإصدارات والأدوار والأنواع.

ويجيب عمود MP في سجلات IANA عن سؤال مختلف. تعني Y أن الإجراء ينطبق معيارياً على codepoint. لا تعني أن البرنامج المثبت نفذه، أو أن توليده مفعّل، أو أن كل المستقبلين داخل المستوى يعيدون بناء الدلالة نفسها.

سجل التفويض ملك المشغّل

توصي RFC بأن توفر التطبيقات المرسلة مفاتيح تمكين وتعطيل لكل codepoint. وإذا أمكن التعطيل، فيجب تسجيل حالتين: وصول MP-TLV أثناء التعطيل، وحاجة إنشاء LSP محلي إلى MP-TLV أثناء تعطيل التوليد. تكشف السجلات التعرض والحاجة، لكنها لا تصدر أمراً بالتفعيل.

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

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

المصادر