الخلاصة

  • قالت RFC 1272 إن عنوانَي IP عند الطرفين لا يحددان أي نطاق إداري مجاور نقل الحركة عبر حدّ الشبكة.
  • قد تساعد العدّادات الموضوعة عند الحدود على مطابقة التقارير، لكن التفاصيل النافعة تعتمد على الطوبولوجيا ودقة القياس والتخزين وكلفة الجمع والأمن.
  • فصلت المذكرة تقارير الاستخدام عن الفوترة وإنفاذ السياسات، وتركت مفتوحاً قرار العدّ عند دخول الحزمة إلى الموجّه أو خروجها منه.

الاسم الناقص كان اسم الشبكة المجاورة

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

لم تطلب RFC 1272 من كل شبكة أن تحاسب عن كل مستخدم على الإنترنت. ركز نموذجها على نطاق الإدارة الواحدة والنطاقات المجاورة المتصلة به مباشرة. يمكن للمزوّد أن يقيس الحركة التي تعبر الحدّ مع جارٍ وأن يتبادل معه كشفاً. وإذا أراد ذلك الجار توزيع تكاليفه على شبكات أبعد، فذلك من مسؤوليته. المحاسبة هنا تكرارية: تتولى كل إدارة العلاقة التي تستطيع رصدها، من دون ادّعاء امتلاك رؤية عالمية للمستخدم النهائي.

يغيّر هذا التمييز معنى موضع القياس. يرى المضيف حركة أحد الطرفين. أما الموجّه عند حدّ الشبكة فيرى ما يدخل النطاق المحلي أو يغادره، ويمكنه تقديم دليل عن الربط المجاور. وأشارت المذكرة إلى أن ترويسات IP لا تحمل وحدها هوية النظام الوسيط؛ فقد تلزم معلومات من طبقات أدنى أو إعدادات مكونات الحدّ. عنوانا الطرفين وحدّ المحاسبة يجيبان عن سؤالين مختلفين.

للقياس كلفته أيضاً

كان موضع الجهاز خياراً واحداً بين خيارات. وصفت RFC 1272 مراقبات مخصصة، ومراقبات للخط، وعدادات برمجية داخل الموجّهات، ومجموعات منسقة من «router spiders». ويتوقف الموضع الأنسب على الطوبولوجيا والخدمة المقاسة. قد يساعد القياس عند الحدّ المزوّد والمستهلك على مقارنة سجلاتهما، لكنه ليس أمراً بتجهيز كل موجّه بأداة قياس.

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

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

التقرير ليس فاتورة ولا قاعدة

حددت RFC 1272 غرضها بوضوح: معلومات خلفية لمعمارية تقارير الاستخدام، لا معيار إنترنت. قد تساعد التقارير المشترك على فهم سلوكه، والمزوّد على قياس الالتزام بسياسة، أو طرفاً على توزيع التكاليف. لكن التقرير وحده لا ينفّذ سياسة، ولم توصِ الوثيقة بممارسات فوترة. كما لم تحسم من يدفع ثمن إعادة إرسال الحزم.

وتركت سؤالاً مفتوحاً عمداً: هل تُحسب الحزمة حين يستقبلها الموجّه أم حين يمررها فقط؟ فقد يسقط الموجّه حزمًا عند الازدحام. يعكس العدّ عند الدخول الموارد التي استهلكتها الحركة المعروضة، أما العدّ عند الخروج فيجنب احتساب حركة لم تُمرّر. لذلك طلبت RFC 1272 أن تتيح المعمارية الخيارين؛ فالجواب متعلق بالسياق والسياسة، لا بحقيقة تقنية واحدة.

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

المصادر: RFC 1272؛ RFC 2722؛ RFC 2990.