الخلاصة

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

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

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

صدر RFC 3387 في سبتمبر 2002 بصفة Informational عن باحثين في Service Management Research Group ضمن IRTF. لم يضع بروتوكولاً جديداً ولم يعلن نجاح نشر تجاري. سجّل فجوة تاريخية: كانت آليات IntServ وDiffServ والسياسة وهندسة الحركة تتقدم، بينما بقي إطار إدارة الخدمة الذي يحيط بها غير مكتمل.

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

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

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

في القلب تقع هندسة الحركة، وإعداد الأجهزة، والإبلاغ عن الموارد، وكشف الأعطال والاستعادة. ناقش RFC 3387 حساباً أكثر مركزية لأن القرار قد يحتاج معلومات لا يملكها موجه منفرد. لكنه لم يجعل المركزية قدراً؛ بل سأل إن كانت فائدتها تبرر التعقيد وخطر زعزعة الشبكة.

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

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

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

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

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

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

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

المصادر