تقنية الـ SDN : بروتوكول الـ OpenFlow

في الجزء الثالث من سلسلة الـ SDN سوف نبدأ ربط بعض النقاط التاريخية التى تحدثنا عنها في المقالات السابقة المدخل إلى الـ SDN والفرق بين الـ Control Plane و الـ Data Plane ووضعنا التعريف الأساسي لعالم الـ SDN واليوم نصل معكم إلى الجزء الذي يتحدث عن الـ OpenFlow.

في الجزء الثاني من السلسلة تعرفنا على آلية عمل  الروترات التقليدية وتعلمنا ايضا أن أي روتر أو سويتش يعمل على مستويين أثنين المستوى الذكي Control Plane المسؤول عن الأدارة والتحكم واعطاء الاوامر فقط والمستوى الغبي Data Plane وهو المسؤول عن تنفيذ الأوامر وتمرير الداتا ومابين هذين الأثنين ظهرت لنا تقنية الـ SDN التى تعتمد فكرتها الأساسية على عزل المستويين الأثنين عن بعضهما البعض وتحويل الروتر إلى مستوى واحد فقط وهو مستوى تنفيذ الأوامر فقط وتجميع الـ Control Plane إلى مركز عمليات واحد ومشترك لجميع الأجهزة الموجودة في الشبكة نطلق عليه الـ SDN Controller والتى سوف تضع حد لتطور أجهزة الشبكات الغير مجدي والمكلف جداً ولو عدنا بالزمن قليلاً لوجدنا ان هذا السيناريو كان موجود مع أجهزة الكمبيوتر فالعتاد والمعالجات والرامات تتطور بشكل كبير وأنظمة التشغيل وصلت إلى كفايتها ولم تعد بحاجة إلى هذا الكم الهائل من العتاد وهو ما أدى إلى ظهور الـ Virtualization التى منحتنا أمكانية الأستفادة الكاملة من جميع العتاد الموجود وتوظيفها على أنظمة تشغيل وهمية وفي نفس الهاردوير أما في عالم الشبكات الوضع مختلف قليلاُ فالعتاد القوي مطلوب والزيادة فيه ضرورة لابد منها وخصوصا في الرامات التى سوف تحمل الـ TCAM Table التى بدورها تحمل الـ Forwarding Information وبالتالي تكاليف مرتفعة لتأمين رامات زيادة في كل مرة تتطور فيها الشبكات وتزداد كماً وعدداً. 

وبالعودة مرة آخرى لموضوعنا الرئيسي وهو الربط بين المستويين من خلال جعل هذه العملية ممكنة كان لابد من خلق بروتوكول يقوم بعملية الأتصال بينهما وبدأت الأبحاث عام 2007 وبعد اربع سنوات وفي 28 فبراير 2011 تم أعتماد النسخة الأولى من بروتوكول أطلق عليه OpenFlow v1.1.

ماهو الـ OpenFlow ؟

يعتبر الـ OpenFlow هو المقياس Standard الأول في عالم الـ SDN والكثير من الباحثين يعتبروا أن الـ SDN هو نفسه الـ OpenFlow فكل فكرة أو نظرية جديدة مالم تجد الوسيلة للتنفيذ تبقى بلا فائدة والـ SDN بدون وسيلة التواصل بينها وبين المستويين لا فائدة منه, وهنا يأتي دور هذا البروتوكول الذي يقوم بتأمين الاتصال المباشر بين الـ SDN Controller وبين أجهزة الشبكة من روترات وسويتشات وحتى أجهزة الوايرليس وليس فقط الهاردوير منها وبل السوفتوير أيضا أي الـ Hypervisor Router, وهو يعتبر من عائلة الـ TCP ويستخدم البورت 6653 منذ عام 2013 وقبل هذا التاريخ كان يعمل مع البورت 6633 وآخر أصدار للبروتوكول يحمل الرقم 1.5.0 تم اصداره عام 2014.

يعمل البوتوكول على الطبقة الثالثة ووظيفته نقل أوامر التوجيه وتحديد المسارات من وإلى الـ SDN Controller وهذه الاوامر تشمل أضافة مسار او التعديل عليه او حذف مسار وبتعريف عام ينقل الـ Rules or Actions إلى مستوى الـ Data Plane ويقوم بعكس الوظيفة أيضا من خلال نقل اي متطلبات يحتاجها الـ Data Plane إلى مركز القيادة ونقصد بهذا الأمر الـ Unmatched Packet التى تصل إلى الروتر ولاتملك مسار معروف وفي الصورة القادمة سوف نتعرف على نوعية الأدخالات التى يرسلها مركز المتحكم إلى الـ Data Plane

ثلاثة أقسام رئيسية للـ Data Flow Table Entry

الـ Rule وهو كما تلاحظوا يتألف من قسمين الـ Layer 2 والـ Layer 3 والتى سوف نبني عليها المسارات ونحدد من أين وإلى أين سوف تتم عملية التوجيه.

الـ Action وهو الأمر الذي يجب تنفيذه كتمرير الباكيت أو تجاهلها أو ارسالها إلى المتحكم من خلال الـ Data Plane والآخيرة سوف اشرحها لاحقاً.

الـ Stats الأحصائيات وهي مهمة لمتابعة آخر المستجدات ووضع الـ Dead Line للمدخلات الموجودة على الـ Table (اي لو في حال لم يتم عمل اي Match لباكيت منذ فترة طويلة فسوف يتم حذفها من الـ Flow Table)

وهذه بعض الأمثلة للـ Flow Table وطريقة تعاملها

إذا ماذا سوف يحصل وكيف تتم العملية بين السويتش وبين الـ SDN Controller ؟

عندما يبدا السويتش بالعمل وعندما تصل أول باكيت للسويتش يقوم السويتش بعمل انكبسوليت له ويرسلها عبر ممر أمن للـ Controller ليقوم الآخير بتحديد أو تقرير إلى اين يجب على هذه الباكيت أن تتوجه وبالتالي يرسل Entries أو مدخل جديد للـ Flow Table يعلمه كيفية التعامل مع هذه الباكيت وقد يمنحها اولوية معينة Priority يتم حسبانها من قبل السويتش, وبعدها يبدا السويتش بالتعامل معها وفقاً للجدول والأولوية التى لديه. فقد يممرها مباشرة او يؤخرها بحسب الأولوية أو يقوم بعمل Drop لها لو في حال كان هناك هجوم ما.

Flow-Table Pipeline

في الأصدار الأول من بروتوكول الـ OpenFlow كان يملك جدول واحد فقط لكن في الأصدار 1.1 المحدث أصبح هناك أمكانية ان يكون هناك أكثر من جدول Pipeline Made والذي قد يعقد الأمور قليلاً لكن سوف يزيد من المرونة في التعامل مع أمكانيات الهاردوير المتاحة في السويتش, وفي الصورة القادمة سوف تتوضح الصورة التى يتبعها السويتش عندما تصل إليه باكيت معينة

إلى هنا نكون قد أنتهينا من بروتوكول الـ OpenFlow والذي هو ABC ولمن يرغب بالتوسع أكثر فعليه بتحميل الكتاب الموجود على الرابط التالي والذي يحوي كل التحديثات والمعلومات التى تحتاج أن تتعلمها وتستوعبها لتكون صورة أكبر عن البروتوكول وربما في الأيام القادمة سوف نخصص مقالات متنوعة تتحدث عن مفاهيم مختلفة في البروتوكول أتمنى ان تكونوا قد أستفدتوا من معلومات اليوم وإلى لقاء جديد والذي ربما سوف يكون عن الـ SDN Controller وإلى حينها لاتنسونا من دعواتكم ودمتم بود.