الخلاصة

  • لم يفرض RFC 3654 على عنصر التوجيه Forwarding Element (FE) أن يواصل تمرير الحزم دائماً أو أن يتوقف دائماً بعد فقدان رابطته بعنصر التحكم Control Element (CE). بل ألزم المعمارية باكتشاف الانقطاع واستعادة الرابطة ومزامنة الحالة، وبإتاحة ضبط سلوك FE مسبقاً.
  • وصف RFC 7121 لاحقاً نمطين للاسترداد: يعيد أحدهما FE إلى مرحلة ما قبل الارتباط، أما الآخر فيمكنه تجربة عناصر CE احتياطية ومواصلة التوجيه حتى انتهاء مهلة. ولا يثبت إنشاء رابطة جديدة وحده استعادة كل حالة FE.

عنصر واحد على الشبكة، ووظيفتان منطقيتان

في نوفمبر 2003، وصف RFC 3654 عنصر الشبكة على أنه مكونات تحكم وتوجيه تتعاون، مع أنها تبدو للجهات الخارجية كجهاز IP متكامل. ينفذ Control Element وظائف مثل بروتوكولات التوجيه والإشارة، بينما يعالج Forwarding Element الحزم واحدةً واحدة. هذا فصل منطقي لا يشترط صندوقين منفصلين. وذكر RFC قابلية التوسع والتطور المستقل للوظيفتين، لكنه لم يزعم أن هذا التصميم أصبح واسع الانتشار. RFC 3654

تظهر المسألة الصعبة عندما يحتفظ FE بجداول ووظائف مبرمجة، لكنه يفقد الرابطة مع CE الذي يديرها. إن قول «تعطل التحكم» لا يحدد مصير الحزم: قد يواصل FE العمل بالحالة الموجودة، أو يتوقف، أو يحاول الوصول إلى CE احتياطي. جعل RFC 3654 هذه احتمالات مختلفة لا وصفاً واحداً للفشل.

المطلوب قرار معروف سلفاً، لا إجابة موحدة

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

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

مواصفات التوافر العالي اللاحقة أضافت حالات ومهلة

عرّف RFC 5810، المنشور عام 2010 على مسار المعايير، بروتوكول ForCES وطبقة مواءمة النقل لتلبية متطلبات RFC 3654. وحدد RFC 5812 نموذج FE بما يشمل قدراته وحالته الراهنة وتهيئته المطلوبة والكتل الوظيفية المنطقية. فالقدرة ليست الحالة الحالية، وكلتاهما تختلفان عن التهيئة التي يريدها CE. RFC 5810 RFC 5812

أضاف RFC 7121 الصادر عام 2014 إجراءً للتوافر العالي داخل عنصر ForCES. يحدد FE Protocol Object عنصر CE الرئيسي والعناصر الاحتياطية؛ وتساعد فواصل نبضات heartbeat وسياساتها على اكتشاف مشكلات الاتصال. في النمط 0 الافتراضي يعود FE إلى مرحلة ما قبل الارتباط بعد الانقطاع؛ وإذا ارتبط مجدداً، يجب إعادة إنشاء حالته. أما النمط 1 فيستخدم استرداد إعادة التشغيل: يجرب FE عناصر CE الاحتياطية بالتناوب أثناء عمل مهلة CE Failover Timeout Interval. وقد يواصل FE تمرير الحزم في حالة «غير مرتبط» بحسب السياسة المضبوطة. وإذا انتهت المهلة من دون ارتباط، ينتقل FE إلى مرحلة ما قبل الارتباط ويوقف مسار التوجيه. بعد إعادة الارتباط يمكن لـ CE محاولة مزامنة الحالة التي فقدها FE، لكن طريقة المزامنة خارج نطاق معمارية ForCES، وغالباً ما تتضمن رسائل تهيئة واستعلامات جديدة. RFC 7121

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

تناول RFC 3532، وهو وثيقة أخرى من ForCES، إعادة توزيع الموارد ديناميكياً واحتمال تأخر نموذج عنصر التحكم عن حالة عنصر التوجيه. هذا موضوع قريب لكنه مختلف. يتتبع هذا المقال الإجراء الذي يحدده FE عند فقدان الرابطة والاسترداد عالي التوافر، لا نقل الموارد أو تقادم الجرد. RFC 3654 وثيقة معلوماتية؛ وتوثق المعايير اللاحقة تطور التصميم لا تبني مشغل معين له. RFC 3532 RFC 3746 RFC 1812 سجل RFC Editor للوثيقة سجل IETF Datatracker للوثيقة

المصادر