الخلاصة

  • كان على تنفيذ TALI 2.0 أن يعامل الطرف الآخر كإصدار 1.0 إلى أن تحمل رسالة moni ما يعرّف الإصدار 2.0؛ ولم يكن مسموحاً بإرسال العمليات الجديدة قبل ظهور هذا الدليل.
  • كانت RFC 3094 مقترحاً معلوماتياً من Tekelec. ونصّ تنبيه IESG صراحة على أنها بديل لعمل SIGTRAN الجاري، وأن IETF لم يقيّم متانتها التقنية أو اكتمالها.

يظهر الحد قبل تبادل أي رسالة SS7. تصف RFC 3094 واجهة Transport Adapter Layer Interface (TALI)، وهي مقترح من Tekelec لنقل الإشارات بين شبكة تبديل دوائر وشبكة IP. تستطيع بوابة الإشارات حمل رسائل SCCP وISUP وما يرتبط بـMTP عبر TCP/IP، إلى جانب وظائف الإدارة والتسجيل الديناميكي للدوائر. ويعرض المستند صيغ الرسائل والمؤقتات وحالات الأطراف وسلوك الإصدارين 1.0 و2.0 بالتفصيل. لكن دقة المواصفة لا تجعلها معياراً ولا تثبت استخدامها؛ ومقدمة RFC تقول ذلك بوضوح.

يضع تنبيه IESG، في مقدمته، TALI بوصفه بديلاً من مورّد لتقنيات كانت مجموعة SIGTRAN في IETF تطورها على مسار المعايير. ويذكر أن IETF لم يراجع المتانة التقنية أو الاكتمال، ويدعو المستخدمين المحتملين إلى فحص عمل SIGTRAN قبل الاختيار. لا يقول التنبيه إن IETF حكم بأن TALI معيب، أو رفضه، أو أثبت أنه لم يُنشر في شبكة فعلية. إنه يحدد نطاق المراجعة ويقترح المقارنة.

أوضح تحدٍّ هندسي داخل TALI هو التوافق مع الإصدارات السابقة. لم يوفر الإصدار 1.0 وسيلة بسيطة لمعرفة إصدار الطرف الآخر. يعيد الإصدار 2.0 استخدام رسالة moni (المراقبة)، ويخصص أول 12 بايتاً من بياناتها لوسم إصدار ثابت، مع ترك الباقي لاستخدامات خاصة بالتنفيذ؛ ولا يجوز أن يتجاوز حقل البيانات 200 بايت. وتحتفظ الرسالة بوظيفة الصدى التي يمكن استخدامها لقياس زمن الذهاب والإياب أو لأغراض محلية أخرى.

عند فتح الاتصال، يهيئ تنفيذ 2.0 المتغير far_end_version على القيمة 1.0. ويمكنه الإعلان عن إصداره، لكن لا يجوز له افتراض أن الطرف البعيد يملك القدرات نفسها. عليه فحص رسالة moni الواردة والتعرف على سلسلة إصدار معروفة. وإذا لم تصل رسالة تعريف، أو لم يتعرف على الوسم، يظل الطرف الآخر محسوباً على الإصدار 1.0.

تتحكم هذه الحالة في ثلاث عمليات جديدة للإصدار 2.0: mgmt وxsrv وspcl. فتنفيذ 1.0 سيعدّها عمليات غير صالحة ويغلق المقبس فوراً. لذلك يجب أن ينتظر الطرف 2.0 حتى يتأكد من أن الطرف المقابل يعمل بالإصدار 2.0 أو أحدث قبل إرسالها. وإذا ظهر أن المقابل على 1.0، يعود التنفيذ إلى وظائف 1.0. كما تصف المواصفة كيف يمكن لتنفيذ 1.0 تجاهل البيانات الإضافية في moni ومتابعة تبادل المراقبة والإقرار المعتاد. لا يعني التوافق أن كلا الطرفين يفهم كل وظيفة؛ بل يمنع إرسال عملية سيرفضها الطرف الأقدم ويحافظ على الاتصال قابلاً للاستخدام.

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

ويجب قراءة تاريخ المعايير المحيط بها بالقدر نفسه من التحفظ. كانت RFC 2719 قد وصفت معمارية SIGTRAN. ثم عرّفت وثائق معيارية لاحقة طبقات تكييف مثل M2UA وM3UA وSUA، وأصبح SCTP أحد وسائل النقل المستخدمة في هذا العمل. وتناقش RFC 3094 نفسها بديلاً يعتمد SCTP. تثبت هذه السجلات وجود مواصفات ذات صلة، متزامنة أو لاحقة؛ لكنها لا تثبت أن TALI استُبدل، أو أن شبكة بعينها هاجرت، أو أن تنفيذين تبادلا البيانات بنجاح.

تعود RFC 3094 إلى أبريل 2001، وتصنيفها Informational وتصرح بأنها لا تحدد معياراً للإنترنت. النشر والآلية الموصوفة وحدود المراجعة ثلاث حقائق منفصلة. لا تثبت آلة الحالات المفصلة وجود تشغيل فعلي، ولا يثبت تنبيه IESG فشلاً تقنياً. تحتاج هذه الاستنتاجات إلى تنفيذ عامل أو اختبارات أو سجلات تشغيل أو حركة مرصودة.

المصادر