الخلاصة

  • جعل RFC 3063 تخصيص الوسم ينتظر عودة الخيط، فنقل منع الحلقة إلى شرط يسبق إنشاء المسار بدلاً من استنتاجه من جدول التوجيه وحده.
  • ظلت سعة لون الخيط وعدّاد قفزاته وTTL ثابتة؛ لكن الضمان بقي محصوراً في الإجراء، ولم يثبت نشر الآلية أو تسليم الحزم.

لم يظهر الوسم إلا في النهاية

ليست أهم فكرة في RFC 3063 مجرد اكتشاف الحلقة، بل ربط الاكتشاف بقرار محدد: في وضع المنع لا يرسل الموجّه ربط الوسم حتى يعود خيط التحكم.

لا تطلب MPLS من كل موجّه إعادة قراءة المسار كله عند تمرير كل حزمة. يربط موجّه تبديل الوسوم وسمًا بفئة تكافؤ التمرير (FEC). وإذا تغيرت القفزة التالية بينما لا يزال توجيه الطبقة الثالثة يدور في حلقة، فقد يؤدي نشر الوسم مبكراً إلى إنشاء LSP يرث الحلقة. لذلك يجعل RFC 3063 إنشاء المسار بوابة: يجب أن يستوفي المسار المرشح قواعد الخيط أولاً، ثم يُسمح بإعلان الربط.

نُشر النص في فبراير 2001 بصفة Experimental، ويقول صراحة إنه لا يضع معياراً للإنترنت. يعرّف الخيط كسلسلة من رسائل التحكم بالمسار، تحمل ثلاثة عناصر: لوناً، وعدّاد قفزات، ووقت حياة (TTL). يجمع اللون عنوان IP للعقدة المبادرة ومعرّف حدث محلياً، بحيث يُقصد به التميّز بين العقد والأحداث. إذا عاد اللون نفسه إلى عقدة سبق أن رأته، فهذا يكشف أن الخيط عاد عبر مسار حلقي. يحافظ عدّاد القفزات على قيمة تزداد على امتداد المسار؛ وتُستخدم قيمة خاصة «مجهولة» في بعض حالات الحلقة. أما TTL فيحد المسافة التي يمكن أن تقطعها رسالة التحكم، لكنه ليس بحد ذاته دليلاً على خلو المسار من الحلقة.

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

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

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

إيصال من مستوى التحكم لا أثر للحزم

يفصل معمار MPLS في RFC 3031 بين إجراءات توزيع الوسوم وتطبيقها في مستوى التمرير. لذلك تخبرنا عودة الخيط أن حالة محددة من مستوى التحكم اجتازت قواعد الخوارزمية؛ لكنها لا تثبت أن كل جداول التمرير تلقت الوسم الصحيح، أو أن الحزم سلكت المسار، أو أن ترتيباً آخر للأحداث لم ينتج حلقة عابرة. لهذه الادعاءات نحتاج إلى أدلة مستوى البيانات: حالة FIB، والعدادات، والمجسات، وفترة رصد محددة.

تصف مواصفة LDP اللاحقة RFC 5036 كشفاً قابلاً للتهيئة باستخدام TLV من نوعي Path Vector وHop Count. يسجل متجه المسار معرّفات LSR التي عبرتها الرسالة؛ ويؤدي تكرار معرّف أو بلوغ حد مضبوط إلى معاملة الرسالة كحلقة. هذه آلية LDP مختلفة عن خيط RFC 3063 التجريبي. وجودها في مواصفة لاحقة لا يكشف نسبة نشر آلية الخيط، ولا يثبت أن التقييس رفضها لسبب تقني. ويتناول RFC 5715 لاحقاً التقارب الخالي من الحلقات بعد تغير الطوبولوجيا، وهو موضوع قريب لكنه غير مطابق لمنع إنشاء LSP حلقي.

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