الخلاصة

  • يسمح OpenFlow بإعادة ترتيب بعض الرسائل عند غياب الحاجز. وتعني Barrier Reply، داخل الاتصال نفسه، أن الرسائل السابقة عولجت بالكامل مع ردودها أو أخطائها قبل بدء الرسائل اللاحقة.
  • لا يشمل ذلك إثبات مرور الحزمة. فالمواصفة تنص على أن Packet-Out قد يُعالَج كاملاً ثم لا يغادر المبدّل بسبب الازدحام أو QoS أو منفذ محجوب أو غير صالح.
  • تكمن أهمية Nick McKeown هنا في مساهمته المشتركة مع سبعة مؤلفين أصليين ومع مجتمع لاحق في إظهار الحد بين قرار المتحكم وتنفيذ مستوى البيانات. التشغيل المنضبط يحافظ على إيصالات مستقلة للنية والترتيب والحالة والتطابق والخروج والمسار والنتيجة.

رد صحيح ونتيجة خاطئة

لنفرض أن سجل المتحكم يعرض FlowMod ثم Barrier Request ثم الرد المنتظر. يمكن مع ذلك أن تكون القاعدة في جدول غير مقصود، أو أن يحمل القناع خطأ، أو أن تسبقها قاعدة ذات أولوية أعلى. وقد يختار group مساراً آخر، أو يسقط meter الحزمة، أو يكون منفذ الخروج محجوباً. وربما يعمل المبدّل الأول بينما يفشل الجهاز التالي.

في جميع هذه الحالات تبقى Barrier Reply صحيحة ضمن معناها. الخطأ هو تحويلها إلى عبارة «اكتمل النشر».

تحدد مواصفة OpenFlow 1.3.5 دور الحاجز بدقة. من دونه يستطيع المبدّل إعادة ترتيب الرسائل لتحسين الأداء. وعلى اتصال واحد يجب أن تكتمل معالجة كل ما سبق Barrier Request، بما في ذلك الردود أو الأخطاء الناتجة؛ ثم يعالج الحاجز ويُرد عليه؛ وبعد ذلك فقط تبدأ الرسائل اللاحقة.

تورد المواصفة تبعيات عملية: إنشاء group قبل flow يشير إليه، وتعديل منفذ قبل أن يستخدمه Packet-Out، وإضافة flow قبل إرسال حزمة عبر الجدول. إذاً الحاجز سياج زمني في قناة التحكم، لا معاملة موزعة ولا إيصال تسليم للبيانات.

الحد الذي ساعد McKeown في جعله قابلاً للبرمجة

شارك Nick McKeown في ورقة OpenFlow الأصلية عام 2008 مع Tom Anderson وHari Balakrishnan وGuru Parulkar وLarry Peterson وJennifer Rexford وScott Shenker وJonathan Turner. اقترحت الورقة واجهة محدودة تتيح للمتحكم إضافة مدخلات جداول التدفق وحذفها في مبدّلات حقيقية، بينما تعالج الجداول الحزم اللاحقة بسرعة. وفي مثال Amy-OSPF يختار البرنامج المسار ثم يبرمج الأجهزة.

ينبغي وصف McKeown بأنه أحد منشئي OpenFlow والشبكات المعرفة برمجياً، لا المخترع الوحيد. كما أن دلالات Barrier اللاحقة نتاج عمل مجتمع النشر والمصنعين والباحثين وOpen Networking Foundation. صلته بهذه القصة معمارية: فصل القرار عن التنفيذ بما يسمح بتسمية حدود كل دليل.

يسجل تاريخ النشر الصادر عام 2014 أن الخبرة الميدانية ساهمت في إدخال أمر Barrier في OpenFlow 0.9. ويسجل أيضاً تفاوت أزمنة تثبيت التدفقات، وضعف معالجات بعض المبدّلات، ومشكلات التحكم داخل النطاق، وتشخيصاً يجمع آثار قناة التحكم مع RTT وحمل المعالج ومعدل التثبيت وقياسات التطبيق. ظهر الحاجز داخل مراقبة متعددة الطبقات، لا بديلاً منها.

عبارة «عولج بالكامل» تنتهي قبل السلك

تضع مواصفة 1.3.5 القيد الأوضح: معالجة Packet-Out بالكامل لا تضمن خروج الحزمة من المبدّل. قد يؤدي الازدحام أو QoS أو منفذ محجوب أو غير صالح إلى إسقاط صامت بعد معالجة OpenFlow. ويمكن أيضاً أن تضيع حزم موجهة إلى المتحكم تحت الضغط أو policing من دون Packet-In متوقعة.

ومدخل flow ليس حكماً على المسار. فهو يضم حقول التطابق والأولوية والعدادات والتعليمات والمهلات وcookie. تبدأ المعالجة من table 0 وقد تمر بجداول أخرى؛ ويفوز أعلى تطابق أولوية في كل جدول. يمكن للتعليمات تغيير metadata وaction set، واستدعاء group أو meter، ثم اختيار الخروج.

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

كذلك يقتصر الحاجز على اتصال بعينه. لا توفر OpenFlow مزامنة بين اتصالات مختلفة. فإذا مرت العملية التابعة عبر اتصال مساعد ومر الحاجز عبر الاتصال الرئيسي، لا يغطي الرد العمليتين. وبعد إعادة الاتصال يلزم التحقق من دور المتحكم وجيل الاتصال والحالة التي احتفظ بها المبدّل بالفعل.

اختبارات منفصلة لادعاءات منفصلة

في اختبار المطابقة Basic Single Table الخاص بـOpenFlow 1.3.4، تضاف حتى عشرة آلاف قاعدة ثم تحذف ويُرسل Barrier Request عبر اتصال تحكم واحد. ويجب ألا تصل Barrier Reply قبل كل إشعارات Flow-Removed المطلوبة. أما اختبار Packet-Out القريب منه فيستخدم اتصال بيانات منفصلاً ويفحص وصول الحزمة.

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

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

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

ثمانية إيصالات لا يجوز دمجها

يمكن ضبط النشر بهذه السلسلة:

  1. النية: سياسة ذات إصدار ومجموعة القواعد المطلوبة.
  2. النقل: Datapath ID ودور المتحكم والاتصال الصحيح.
  3. الترتيب: Barrier Reply على الاتصال ذاته مع تسوية الأخطاء السابقة.
  4. الحالة: قراءة الجداول والأولوية والقناع وcookie وgroup وmeter والمنفذ بعد الحاجز.
  5. التطابق: حزمة اختبار ممثلة تغير العدادات المقصودة.
  6. الخروج: دليل من المنفذ أو الطابور وعدم وجود سبب إسقاط محلي.
  7. المسار: رصد لاحق أو مسبار نشط يؤكد الطريق الفعلي.
  8. النتيجة: الطرف النهائي أو التطبيق يسجل المعاملة المتوقعة.

يجب ربطها بإصدار التغيير وهوية المبدّل وجيل الاتصال ومعرفات معاملات OpenFlow وcookie ورؤوس الاختبار والنافذة الزمنية. من دون ذلك يمكن ضم قراءة قديمة إلى مسبار جديد وبناء نجاح لم يقع قط.

المصادر