الخلاصة

  • منحت RFC 3919 وكلاء RMON-2 أسماء مشتركة لمسارات فك ترميز IPv6 وMPLS، لكنها لم تجعل تلك الأسماء وصفًا لكل خدمة تحملها الحزم.
  • يظهر الحد بوضوح في مدخلات MPLS نفسها: يمكن التمييز بين أحادي الإرسال ومتعدد الإرسال عند المدخل، لكن البروتوكولات المتفرعة «لا يمكن تحديدها منهجيًا».

يبدأ الرصد عن بُعد بسؤال يبدو بسيطًا: ما أنواع الحزم التي يستطيع المسبار التعرّف إليها؟ أجاب دليل بروتوكولات RMON-2 بقائمة لما يستطيع الوكيل مراقبته. وبذلك أمكن ربط العدادات وجداول المضيفين أو المحادثات بمسار تغليف مسمّى. لم يكن الدليل إحصاءً شاملًا لكل حزم الشبكة، ولم يجعل المسبار يتعلم محلّلًا جديدًا لمجرد أن المسؤول أضاف صفًا. وتصف RFC 2021 ذلك بأنه قابلية توسع محدودة: ينبغي أن يعرف البرنامج مسبقًا منطق الفصل ذي الصلة قبل أن يسمح الإعداد بتمديد فك الترميز طبقة أخرى.

نُشرت RFC 3919 في أكتوبر 2004 كمذكرة معلوماتية، وأضافت وحدات تعريف لمعرّفات بروتوكولات IPv6 وMPLS. كان هدفها محددًا: تحسين قابلية التشغيل البيني بين وكلاء RMON-2. فإذا سمّت مجسّات مختلفة المسار نفسه بأسماء لا تتوافق، تعذر على أدوات الإدارة مقارنة عروض البروتوكولات بثقة. وتوضح المذكرة أن تنفيذ RMON-2 المتوافق يمكن أن يتم من دون هذه المعرّفات. إنها مفردات مشتركة، لا اختبار توافق جديد ولا دليلًا على دعمها في كل مسبار. (RFC 3919؛ سجل RFC Editor)

تكمن أهمية المقارنة داخل الوثيقة نفسها. في IPv6، يحدد حقل Protocol المؤلف من ثماني بتات البروتوكول التالي. لذلك يستطيع المعرّف متابعة قيمة فصل معروفة: تسمي RFC 3919 بروتوكول ICMPv6 بالرقم 58، وتفصل بين UDP فوق IPv6 أصلي وUDP داخل نفق IPv6 عبر IPv4. المساران ether2.ip6.udp وether2.ip.ipip6.udp ليسا تسميتين قابلتين للتبادل؛ فكل منهما يحتفظ بسجل التغليفات التي مرّ بها المحلّل، لا بالكلمة الأخيرة UDP وحدها.

أما في MPLS فيتوقف الفرع مبكرًا. تعرّف RFC 3919 المدخلين mplsu وmplsm، وتميز أحادي الإرسال من متعدد الإرسال بقيمتي EtherType ‏0x8847 و0x8848، وتورد ترميزات لأنواع أخرى من وصلات الربط. ثم يتوقف التعريفان: لا يمكن تحديد بروتوكولات MPLS المتفرعة منهجيًا. ولا يعني ذلك أن MPLS لا يحمل IP مطلقًا أو أن الحزم خلف التسميات لا يمكن فك ترميزها. المعنى الأضيق هو أن هذه المجموعة من المعرّفات لا تحدد شجرة فرعية عامة ومشتركة تحت مدخلات MPLS. (RFC 3032)

يمنع هذا الحدّ اسم الدليل من الوعد بما يتجاوز وصفه. قد يعرف المسبار التأطير الخارجي أو مدخل MPLS، من دون أن يملك اسمًا ثابتًا مشتركًا لكل حمولة أو خدمة خلف مكدس التسميات. فتسمية التوجيه لا تعلن بذاتها عائلة بروتوكولات؛ ويتوقف تفسيرها على آليات وسياق آخرين. لا تحاول RFC 3919 استنتاج هذا السياق من التسمية، ولا تعد بأن يمنح وكيلان مختلفان الصف نفسه رقمًا محليًا واحدًا.

والتمييز بين اسم البروتوكول والفهرس مهم كذلك. تحدد RFC 2895 ترميز protocolDirID وسلاسل المعاملات. أما جداول العد فتستخدم protocolDirLocalIndex. وتنص RFC 2021 على أن هذا العدد الصحيح لا يحمل معنى إلا داخل كيان SNMP بعينه. إنه إحالة محلية إلى دليل المسبار، لا معرّفًا عالميًا يمكن نسخه إلى بيانات مسبار آخر وافتراض تطابق معناه. تأتي قابلية التشغيل البيني من قواعد وصف مشتركة وتفسير منضبط، لا من ترقيم محلي موحد.

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

المصادر