الخلاصة

  • ربط RFC 1595 كل مقياس بطبقة Section أو Line أو Path أو VT، وبالطرف القريب أو البعيد، وبنافذة حالية أو مكتملة. الرقم المجرد يفقد حدود ما قيس.
  • يبدأ زمن عدم الإتاحة من أول ثانية ضمن عشر ثوانٍ SES متتالية. وإذا عبر التسلسل حدّ ربع الساعة، فقد تعيد قراءة لاحقة توزيع SES وUAS في النافذة الماضية.
  • سمح RFC 2558 وRFC 3592 بالنشر الفوري ثم التصحيح بأثر رجعي، أو بتمرير المشاهدات في خط تأخير من عشر خانات. السرعة وثبات النسخة الأولى خاصيتان مختلفتان.

صف تاريخي ينتظر ثواني من المستقبل

لنفترض أن سلسلة أخطاء شديدة بدأت قبيل نهاية ربع الساعة. بعد الانتقال تصبح الفترة الماضية هي interval 1 ويمكن لمدير الشبكة قراءتها. لكن الوكيل لم ير بعد عشر ثوانٍ SES متوالية، ولذلك لا يعرف إن كانت الثواني الأخيرة ستبقى في عدّادات الخطأ أم ستدخل زمن عدم الإتاحة.

عند وصول الثانية العاشرة يبدأ عدم الإتاحة من الأولى، لا من العاشرة. وإذا كانت الأولى في النافذة السابقة وجب نقل بعض تاريخها إلى UAS. حذّر RFC 1595 صراحة من أن طلبَي GET متتابعين في الثواني الأولى من النافذة الجديدة قد يعيدان قيماً مختلفة لـSES وUAS في Path أو Line أو VT السابق.

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

لماذا تعود قاعدة العشر ثواني إلى الوراء

في طبقات Line وPath وVT، تجعل عشر ثوانٍ SES متتالية الواجهة غير متاحة منذ أول ثانية، وتدخل العشر كلها في UAS. وتحتاج العودة إلى الإتاحة عشر ثوانٍ متتالية بلا SES، ولا تُحسب تلك العشر ضمن عدم الإتاحة.

عندما تكون الطبقة متاحة تتزايد عدّادات أخطائها. وعندما تصبح غير متاحة لا يتزايد فيها سوى UAS. لذلك ليست المهلة مجرد تخفيف لإنذار متذبذب؛ إنها تختار الدفتر الذي ستُسجّل فيه ثوانٍ شوهدت بالفعل. كما أن آلة الحالة لا تُصفّر عند حدّ الدقائق الخمس عشرة.

الرقم ينتمي أولاً إلى طبقة وطرف

لا تنهي أجهزة SONET/SDH كل الطبقات في كل موضع. قد ينهي المكرّر Section فقط؛ وتنهي أجهزة add-drop والتوصيل الرقمي Line؛ وقد تصل المضاعفات الطرفية إلى Path وVT/VC. مثلت الـMIB هذه الأسطح بإدخالات واجهة ومكدسها.

تأتي مخالفات Section من B1، وLine من B2، وPath من B3، وVT العائم من V5. ولـLOS وLOF وAIS وLOP وRDI نطاقات طبقية أيضاً. حتى ifOperStatus=down إسقاط لحالة السطح المدار، وليس عنوان القطعة المادية المعطلة.

أما الطرف البعيد فهو شاهد مختلف. جُمعت بيانات Path البعيدة من FEBE في البايت G1. واشترط RFC 2558 وسم إحصاء الثانية البعيدة بأنه absent عند وجود عيب وارد في الطبقة نفسها أو طبقة أدنى. الغياب ليس صفراً: الصفر نتيجة مشاهدة، أما الغياب فهو فقدان إمكانية المشاهدة.

صحّح مبكراً أو انتظر قبل النشر

شرح RFC 2558 خيارين. إذا حدّث الوكيل الأداء في الزمن الحقيقي، فعليه أن يستطيع تصحيح ES وSES وSEFS وCV وUAS بأثر رجعي بعد اكتمال تسلسل العشر ثواني. وإذا عبر التسلسل الحدّ شمل التصحيح النافذة السابقة.

أما الخيار الثاني فيمرّر ملاحظات كل ثانية عبر خط تأخير بعشر خانات. لا تدخل الثانية العدّاد حتى يُعرف تصنيفها. تكون القراءة الأولى مستقرة، لكنها تتأخر عشر ثوانٍ عن الزمن المادي. أبقى RFC 3592 هذا التصميم في 2003.

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

وأضاف RFC 2493 زمن الانقضاء وعدد النوافذ الصحيحة وغير الصحيحة، وفصل الجداول الحالية عن التاريخية والتجميعية الاختيارية. قد يترك إعادة تشغيل الوكيل أو نقص بيانات البروكسي تاريخاً غير كامل. كانت 96 نافذة سقفاً ليوم واحد؛ اشترط RFC 1595 أربعاً على الأقل وجعل 32 القيمة الافتراضية.

إشعار يحمل زمناً يسبق إرساله

طلبت النصوص اللاحقة إرسال linkDown بعد التأكد من عدم الإتاحة، مع إسناد زمنه الفعلي إلى أول UAS، أي قبل نحو عشر ثوانٍ. وينطبق المنطق نفسه على linkUp.

يجيب وقت الإرسال عن سؤال: متى عرف الوكيل ما يكفي؟ ويجيب الزمن الفعلي: أين وضعت آلة الحالة الانتقال؟ حذف أحدهما يصنع إما معرفة فورية زائفة أو بداية متأخرة للحدث.

حتى معنى «شديد» له مصدر

وثّق RFC 2558 اختلاف عتبات SES بين مواصفات متعددة وأضاف sonetSESthresholdSet. لا يلزم الوكيل بدعم كل المجموعات، وتغيير المجموعة يبطل إحصاءات SES السابقة.

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

يعيد Running-Code Primacy للكاتب Lu Heng الرمز إلى ما نفّذه النظام وشاهده. ويحصر Minimum Initial Specification العقد المشترك في إيصال أدنى قابل للمقارنة، مع إبقاء التخزين والاستجابة قرارات محلية ظاهرة. ويحوّل Why BTW.Media Exists ذلك إلى واجب تحريري: نشر الغياب والتأخير والمراجعة قبل تحويل أول رسم إلى حقيقة نهائية.

نظّم حدّ ربع الساعة القياس. وجعل توثيق النهائية منه دليلاً.

المصادر وحدود الأدلة

تستند الوقائع التقنية إلى سجلات ونصوص RFC Editor الخاصة بـRFC 1595 (النص)، وRFC 2558 (النص)، وRFC 3592 (النص)، وRFC 2493 (النص). وتوفر نصوص Lu Heng انضباطاً تفسيرياً، لا حقائق تقنية عن SONET.

تسلسل الوثائق مؤرخ بدقة: نُشرت RFC 1595 في مسار المعايير في مارس 1994، ثم حلت RFC 2558 محلها في مارس 1999، وحلت RFC 3592 محل RFC 2558 في سبتمبر 2003. وتغيرت معالجة الأمن أيضاً؛ فلم تناقش RFC 1595 الأمن، بينما حذرت RFC 2558 من أن وصول GET وSET قد يكشف معلومات حساسة عن الإعداد والتحكم.

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