الخلاصة

  • عرّف RFC 3020 أربع سياسات لتفعيل حزمة MFR: وصلة واحدة على الأقل، أو جميع الوصلات، أو عدد تحدده العتبة، أو قاعدة خاصة بالتنفيذ.
  • لذلك أثبتت حالة up أن السياسة المختارة تحققت، ولم تثبت عودة السعة كاملة أو سلامة ترتيب الإطارات أو وصولها المفيد إلى التطبيق البعيد.

لم تتغير أي وصلة. ومع ذلك انتقلت الواجهة المنطقية من down إلى up.

كان في الحزمة وصلتان عاملتان من أربع. خفّض المدير mfrBundleThreshold من ثلاث إلى اثنتين، فأعاد الوكيل تقييم الشرط وأصدر انتقالاً صحيحاً. لم تكن الشاشة مخطئة؛ الخطأ المحتمل كان في تسمية تغيير السياسة إصلاحاً للبنية التحتية.

نُشر RFC 3020 في ديسمبر 2000 ليحدد MIB لمراقبة وظيفة UNI/NNI Multilink Frame Relay والتحكم فيها وفق FRF.16. جمعت الوظيفة وصلات فعلية متعددة في حزمة منطقية، وقدمتها إلى طبقة Q.922 كواجهة واحدة، ثم أعادت ترتيب الإطارات التي سلكت مسارات مختلفة.

تكمن قيمته التاريخية في كشف مصدر الحالة. صحة التجميع لم تكن مجموعاً طبيعياً لحالات أعضائه؛ بل نتيجة قاعدة اختارها مشغّل وطبقها وكيل على مجموعة محددة من الوصلات.

كان للحزمة اسم إداري غير أسماء أعضائها

ظهرت كل وصلة فعلية في Interface MIB عبر ifIndex. وظهرت الحزمة نفسها كواجهة منطقية لها ifIndex آخر. أما جدول MFR المتخصص فاستخدم mfrBundleIndex.

اختار المدير فهرس MFR عند إنشاء السطر، بينما اختار الوكيل فهرس الواجهة العام. وربط RFC 3020 المجالين بجدولي تحويل. اختلاف الرقمين لم يكن دليلاً على وجود حزمتين، بل على سلطتين مختلفتين للتسمية.

أنشأ SET بقيمة createAndGo في mfrBundleRowStatus سطر الحزمة، وكان على الوكيل إنشاء واجهتها العامة. أمكن دعم createAndWait اختيارياً. واستخدم سطر العضو ifIndex للواجهة الفعلية وأشار إلى حزمة موجودة عبر mfrBundleLinkConfigBundleIndex؛ وإلا بقي notReady.

أثبت وجود السطر قبول كائن الإعداد. ولم يثبت أن بروتوكول العضو وصل إلى up، أو أن شرط الحزمة تحقق، أو أن إطاراً وصل.

حملت كلمة up أربع دلالات تشغيلية

في class A كان يكفي عضو واحد عامل. وفي class B وجب أن تعمل جميع الوصلات. واستخدمت class C العدد الموجود في mfrBundleThreshold. أما class D فكانت مخصصة وخاصة بالتنفيذ. وكانت A هي القيمة الافتراضية.

عند class C أدى بلوغ العتبة إلى انتقال الحزمة إلى operational up/active، وأدى الهبوط دونها إلى inactive. وعندما لم تكن العتبة منطبقة أعاد الكائن -1. وفي class D اعتمد معناها على التنفيذ.

اتبعت إشعارات linkUp وlinkDown للحزمة الحساب نفسه. تغيّر ifOperStatus عندما أصبح عدد الأعضاء العاملين كافياً أو غير كاف وفق الفئة والعتبة.

في حزمة من أربعة أعضاء، تكفي وصلة واحدة للفئة A. وقد تبقى ثلاث وصلات غير كافية للفئة B. وفي C بعتبة اثنتين يغيّر العضو الثاني الحالة الثنائية، بينما يزيد الثالث والرابع السعة فقط. أما D فتحتاج إلى نسخة التنفيذ وقاعدته لإعادة بناء القرار.

حفظ الإشعار من دون الفئة والعتبة وعدد الأعضاء المهيئين والعاملين يمحو سبب اللون الأخضر. فالسياسة لم تكن ملاحظة جانبية على الحالة؛ بل كانت منتجها.

السعة المتاحة ليست نتيجة التطبيق

فصلت MIB بين عدد الوصلات المهيئة وعدد الوصلات النشطة، وأبلغت عن عرض النطاق المتاح للحزمة بصورة مستقلة.

وبذلك لم تعنِ حالة up اكتمال العضوية. كما لم يكن عرض النطاق المبلغ عنه قياساً لthroughput التطبيق؛ إذ لم يتضمن الحمل المعروض أو نافذة القياس أو الازدحام أو إعادة الإرسال أو إيصالاً من الطرف البعيد.

وعالجت الكائنات التجزئة وحجم الجزء ورقم التسلسل وأقصى فرق في التأخير، مع round-trip delay لكل وصلة. فالتجميع يحتاج إلى استعادة الترتيب، لا إلى عد الوصلات وحده.

كان الحد الأدنى للاتصال والسعة المتعهد بها هدفين مختلفين. لا يستطيع مؤشر واحد أن يقوم مقام العقدين من دون إخفاء معلومات.

حدث واحد لإعادة الترتيب قد يخفي فقد عدة إطارات

عدّ mfrBundleResequencingErrors الأحداث لا الإطارات. وضرب RFC 3020 مثالاً: إذا وصلت 56 ثم 59 و60، واعتُبرت 57 و58 مفقودتين، زاد العداد مرة واحدة.

لذلك لم تعنِ زيادة واحدة فقد إطار واحد. ولم يثبت ثبات العداد اكتمال التسليم من دون معرفة إعادة الضبط والالتفاف وإعادة تشغيل الوكيل وفجوات الجمع وأنواع العطل غير المشمولة.

سجلت عدادات الأعضاء إطارات التحكم غير الصحيحة وانتهاء المؤقت واشتباه loopback والتسلسل غير المتوقع وعدم تطابق أسماء الحزمة. وجاءت حالة العضو من state machine في FRF.16 لا من إشارة كهربائية بسيطة.

قارن mismatch trap أسماء محلية مهيئة بأسماء بعيدة مبلغ عنها. ونبّه RFC إلى أن القيم المهيئة نفسها ربما أنشأتها الأتمتة. أثبت التنبيه وجود خلاف بين رؤيتين، لكنه لم يحدد وحده إن كان الأصل محلياً أو بعيداً أو آلياً أو قديماً.

أمكن لهذه الأدلة أن تكشف تدهوراً داخل حزمة ما زالت up، لكنها لم تثبت ما استلمه التطبيق.

أمكن لتغيير القاعدة أن ينتج تنبيه التعافي التالي

كانت الفئة والعتبة والمؤقتات والتجزئة وحجم التسلسل ذات وصول أقصى read-create. وأمكن للمدير إنشاء السطور وتغييرها وحذفها وتعيين العضو إلى حزمة.

لكن الحد الأقصى في المخطط لم يثبت أن كل تنفيذ أتاح الكتابة. سمحت متطلبات المطابقة بحد أدنى read-only لعدة كائنات مع وجوب الإبلاغ عن القيمة المستعملة. تعريف المخطط وقدرة الوكيل وصلاحية المستخدم حقائق منفصلة.

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

حذّر قسم الأمن من أثر SET غير المحمي في العمليات. لم يحدد SNMPv1 وحده أي principal يحق له قراءة الكائنات أو تغييرها أو إنشاؤها أو حذفها، حتى داخل شبكة تحميها IPsec. أوصى RFC بـUSM وVACM في SNMPv3 وحمّل المشغّل مسؤولية منح الحقوق الصحيحة.

أثبتت المصادقة من غيّر. وأثبت التفويض حقه في التغيير. ولم يثبت أي منهما أن العتبة الجديدة تلبي هدف الخدمة.

لم تكن صفة Proposed Standard دليلاً على النشر

نُشر RFC 3020 بوصفه Proposed Standard. وحدّثه RFC 9141 لاحقاً لاستبدال مراجع خدمة FTP المتقاعدة لدى IETF فقط، من دون تغيير دلالة التفعيل.

تثبت المصادر تصميم MIB، ولا تثبت منتجاً أو نشر شبكة أو حادثاً أو توافراً مقاساً أو تسليماً لعميل. لا يدعي المقال هذه الأمور.

تفصل Reality Layers لدى Lu Heng بين السطر والسياسة وحالة العضو وواجهة التجميع وعدادات السلامة ونتيجة المستقبل. وتصبح Running-Code Primacy حاسمة في class D الخاصة بالتنفيذ. وتوضح Minimum Initial Specification كيف تكون MIB محدودة نافعة من دون ادعاء المراقبة من طرف إلى طرف.

هذه عدسات تحليلية معلنة. لم يكتب Lu Heng RFC 3020 ولم يؤيده.

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

المصادر