الخلاصة

  • اقترحت RFC 3474 معرف CALL_ID يبقى ثابتاً طوال حياة Call في ASON، بصيغة خاصة بالمشغل وأخرى مصممة لتكون فريدة عالمياً.
  • كان الثبات يخص هوية العلاقة؛ أما Connections وحالة RSVP والتسميات المحلية والموارد والإشارة والحركة والخدمة فبقي كل منها بحاجة إلى إثبات مستقل.

قد تبقى خانة في السجل بعد أن يختفي المسار الذي ربطه الناس بها. في مارس 2003 وثقت RFC 3474 هذه الفجوة داخل مستوى التحكم في ASON. ونشرت الوثيقة بصفة Informational لا Internet Standard، أي إنها سجلت اقتراحاً لتوسيع GMPLS RSVP-TE ولم تثبت تبنياً عاماً أو تشغيلاً لدى ناقل بعينه.

كان الفصل بين Call وConnection هو محور التصميم. فـCall علاقة بين طرفين يديرها Call controller، في حين أن Connection تحقيق يحمل الموارد وتديره جهة Connection controller. تستطيع العلاقة أن تستمر فيما تنشأ المسارات أو تستبدل أو تنقطع. لذلك لم يكن السجل الإداري والبنية التي تحمل الحركة شيئاً واحداً.

أعطى CALL_ID هذه العلاقة مرجعاً مستمراً. جمعت الصيغة العالمية رمز الدولة وفق ISO، ورمز الناقل وفق ITU، ورمز نقطة وصول تحت سيطرة المؤسسة، وعنوان LSR المصدر، ومعرفاً محلياً بطول 64 بت يبقى ثابتاً طوال حياة Call.

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

وكانت سلطة التعيين منفصلة أيضاً. يستطيع المستخدم الأول إرسال CALL_ID صفرياً. عندها يعين أول عقدة شبكية قيمة جديدة، أو تتحقق من قيمة غير صفرية موجودة. تمرر العقد الوسيطة القيمة بلا تغيير، حتى لو لم تفهم امتداد ASON. ويمكن أن تحمل Path وResv وPathTear وPathErr وNotify المرجع نفسه. هذا يفيد الربط بين السجلات، لكنه لا يجعل حالة كل Connection متطابقة.

في نموذج الفصل الأساسي، كان لـCall عادة Connection واحدة أو أكثر. لكن الاستعادة بأسلوب break-before-make قد تتركه مؤقتاً بلا أي Connection: يزال المسار القديم قبل اكتمال البديل. يبقى CALL_ID خلال هذه الفجوة. ولو حسبت لوحة التشغيل وجود Call على أنه دائرة عاملة، لأخفت اللحظة التي غابت فيها الوصلة فعلاً.

أما الفصل الكامل الاختياري فكان أوضح. أتاح CALL_OPS إنشاء Call أو مزامنتها من دون إنشاء Connection في العملية نفسها. ويمكن للحالة المستقرة أن تضم صفراً أو واحدة أو عدة Connections. لم يكن الصفر تناقضاً، بل تعبيراً عن اختلاف دورة حياة العلاقة عن دورة حياة الاتصال.

أظهر SPC_LABEL حداً مماثلاً. ففي soft permanent connection كان يربط مقطع دخول مهيأ بصورة دائمة بمقطع مبدل، لكن كيفية تكوين الربط ظلت سياسة محلية خارج نطاق الوثيقة. وعبر الشبكات الفرعية غير GMPLS بقيت التسميات محلية لعقدة التحكم، وقد تهيأ يدوياً أو تكتشف مسبقاً. صحة الربط المحلي لا تثبت الاستمرارية المادية من طرف إلى طرف.

بعد إعادة التشغيل قد تأتي المعلومات من تخزين دائم، أو استنتاج من الجار، أو أمر من نظام الإدارة. استعادة CALL_ID تثبت أن النظام تذكر العلاقة. ولا تثبت اتفاق الجار أو اكتمال RSVP أو بقاء برمجة العتاد أو وجود الإشارة أو تقديم الخدمة.

ولم تدمج Notify الطبقات. فقد تحمل الرسالة جلسات مرتبطة بـCALL_ID، وقد تضم رسالة واحدة جلسات تخص Calls متعددة. كان غلاف الإشعار وهوية Call وحالة كل Connection عناصر قابلة للربط، لا حقيقة واحدة.

يجب احترام التسلسل الزمني للوثائق اللاحقة. وصفت RFC 4139 قابلية تطبيق ASON ومتطلباته. ثم جاءت RFC 4974 عام 2007 على Standards Track بإجراءات أكمل، وصرحت بأن Call لا توفر بذاتها اتصال الحركة، وأن لها صفراً أو واحدة أو عدة Connections. وأضافت RFC 6004 خصائص UNI. يبين هذا المسار تطوراً، ولا يرفع اقتراح 2003 بأثر رجعي ولا يثبت تطبيقه.

وفق تمييز Heng Lu بين الرمز والقرار والواقع التشغيلي، يكون CALL_ID رمز تنسيق. قبول Call قرار، وإشارة Connection قرار آخر من سلطة مختلفة. أما الموارد المبرمجة والإشارة المادية والحركة ثنائية الاتجاه ونتيجة التطبيق فهي مشاهدات. يستطيع مفتاح مشترك وصلها، لكنه لا ينقل حجية طبقة إلى أخرى.

لذلك يسجل التاريخ الموثوق جهة تعيين CALL_ID وصيغته ونطاق فرادته وسياق عنوان المصدر وبداية Call ونهايتها. ولكل Connection هوية وفترة ارتباط ورسائل RSVP وتسميات وموارد وإنهاء مستقل. وبعد ذلك تربط قياسات الإشارة والحركة والخدمة بالمسار الذي قاستْه فعلاً. هكذا تستمر العلاقة في السجل من دون اختلاق استمرارية للشبكة.

المصادر