الخلاصة

  • سمحت RFC 3473 لرسالة Notify في RSVP-TE بالوصول مباشرة إلى عقدة غير مجاورة مسجلة، واستخدمت ACK من RFC 2961 لتأكيد الاستلام.
  • لم تكن Notify بديلاً عن PathErr أو ResvErr؛ لذلك أثبت ACK وصول التنبيه، لا تقارب الحالة أو تبديل الحماية أو عودة المرور والتطبيق.

قد يسبق التنبيه الإصلاح الذي يصفه. جعلت RFC 3473 هذا الفارق الزمني جزءاً ظاهراً من البروتوكول.

نُشرت الوثيقة في يناير 2003 وحولت وظائف GMPLS العامة في RFC 3471 إلى كائنات RSVP-TE. شملت التسميات المعممة والمسارات ثنائية الاتجاه والقيود والحماية وفصل قناتي التحكم والبيانات والاسترداد. قامت RFC 3472 بالدور الموازي لـ CR-LDP. أما Notify فعالجت سؤالاً أضيق: كيف تصل معلومة العطل سريعاً إلى العقدة القادرة على تغيير المسار حين لا تكون مجاورة لمكان العطل؟

كان يمكن لـ Path أن يحمل Notify Request لطلب إخطار صاعد، ولـ Resv أن يطلب إخطاراً هابطاً. احتوى الكائن عنوان IPv4 أو IPv6 لعقدة Notify. تحفظه العقدة في كتلة الحالة المقابلة، وتنقله عقدة العبور عادة إلى الأمام.

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

عند وقوع خطأ مناسب، استطاعت العقدة الكاشفة استهداف عقدة غير مجاورة. تمرر العقد الوسيطة غير المقصودة الرسالة دون تعديل، أو تغلفها العقدة المرسلة في رأس IP جديد إلى الهدف. لم تستخدم Notify خيار Router Alert. صار لمسار الدليل طريق مختلف عن موقع العطل وعن مسار PathErr أو ResvErr قفزة بقفزة.

حدد ERROR_SPEC الخطأ والعقدة الكاشفة أو الوصلة الفاشلة، وحددت أوصاف الجلسة حالات LSP المعنية. أمكن للخطأ نفسه توليد إخطار في الاتجاهين، لكن لم يجز إنشاؤه بلا Notify Request مناسب سابق.

قدمت RFC 2961 معرف الرسالة وACK للتسليم الموثوق. كان على عقدة Notify أن تعيد Ack بعد الاستلام. أجابت هذه الدورة عن سؤال محدود: هل وصلت رسالة RSVP المحددة إلى هذه الوجهة؟

لم تثبت صحة وصف العطل فيزيائياً، ولا إزالة الحالة في كل عقدة، ولا وجود سعة بديلة، ولا تبديل المصفوفة الضوئية، ولا عودة الحزم أو التطبيق. صرحت RFC 3473 بأن Notify لا تستبدل رسائل الخطأ القائمة. كانت مسار دليل مساعداً، لا سجل التزام لآلة حالة RSVP.

فصل علم Path_State_Removed بين الرسالة والفعل أكثر. استطاعت عقدة تسجيل أنها حذفت حالة Path فعلاً عند تمرير PathErr. كان ACK للتنبيه ودليل الحذف المحلي إيصالين مختلفين، ولا يمثل أي منهما الطريق كله.

أمكن جمع الإخطارات المرسلة إلى العقدة نفسها والتي تشترك في ERROR_SPEC. تركت طريقة الجمع للتنفيذ، وكانت مهلة المؤقت الافتراضية ميلي ثانية واحدة. خفف ذلك الحمل، لكنه لم يجعل زمن الغلاف زمن كل حدث، ولم يجعل تعافي الجلسات المجمعة معاملة ذرية واحدة.

كشفت الحالة الإدارية ضرورة دليل تالٍ. بعد إرسال Notify تحمل Down، كان على المرسل رؤية Path مقابلة تحمل Down خلال مهلة قابلة للضبط، افتراضياً ثلاثين ثانية. إن لم تظهر، يبدأ الإزالة ويرسل رسائل tear أو error. لم يعتبر البروتوكول أول إنذار نهاية العمل.

وقد تتعطل قناة التحكم وحدها مع بقاء التحويل. أثناء انتظار إعادة التشغيل أمكن حفظ حالة RSVP وMPLS. إخطار «قناة متدهورة» لم يثبت توقف البيانات، وإخطار «قناة نشطة» لم يثبت اكتمال مزامنة الحالة أو عودة الخدمة.

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

فصلت RFC 4090 وRFC 4872 وRFC 4873 لاحقاً التحويل السريع والاسترداد من طرف إلى طرف والاسترداد القطاعي. أضافت أفعالاً ونطاقات، لكنها لم تجعل التنبيه والقرار والتبديل والنتيجة المرصودة حقيقة واحدة.

وفق أولوية الكود العامل لدى Heng Lu، تبقى Notify سجلاً رمزياً حتى تُلاحظ الحالة التي يفترض أن تحدث. تفسر المواصفة الأولية الدنيا ترك التجميع والسياسة محليين. وتمنع طبقات الواقع ACK من استعارة سلطة خدمة ثبت تعافيها.

يحفظ السجل الأمين Path أو Resv الذي ثبت الطلب، والهدف الفعلي بعد السياسة، والكاشف، وERROR_SPEC، والجلسات، وMessage ID، والإرسال والاستلام وACK. ويحفظ منفصلة PathErr/ResvErr، وحذف الحالة، والحماية أو الإزالة، وبرمجة العتاد، والإشارة، والمرور ونتيجة التطبيق. لا يصح وصف «تعافى» إلا في آخر هذه السلسلة.

المصادر