لكي تقوم الروترات بتمرير الترافيك الخاص بي الـ Multicast إلى الشبكات المتصلة معها تحتاج هذه الروترات أن تعرف من هي الأجهزة أو الـ Client التى ترغب بهذا الترافيك لذا حديثنا اليوم سوف يكون عن البروتوكول المسؤول عن إدارة هذه العملية وهو الـ IGMP والذي يتم من خلال إرسال العميل طلب إلى الروتر بواسطة هذا البروتوكول لكي يصل إليه ترافيك الـ Multicast .
مقدمة
الـ IGMP أو Internet Group Management Protocol أول من طور هذا البروتوكول هو Steve Deering عام 1986 في الـ RFC 988 وبعدها خضع هذا البروتوكول لعدة تطويرات وتحديثات على يد نفس الشخص ليقوم أولا بتطويره إلى الـ IGMPv1 في الـ RFC 1112 وبعدها إلى الـIGMPv2 في الـ RFC 2236 وآخيرا الصيغة الآخيرة منه الـ IGMPv3 في الـ RFC 3376 كما يعد Steve Deering أحد مطوري بروتوكول الـ IPv6 والذي ألتحق عام 1996 بشركة سيسكو للعمل فيها وهذه صورة له
لنتحدث الآن بعمق أكثر عن البروتوكول وعن وظيفته
لكي يصل الترافيك الخاص من المصدر إلى الأجهزة يحتاج هذا الأمر إلى وجود مجموعة تضم الأجهزة والسيرفر الذي يولد هذا الترافيك والتى يعبر عنها بأحد أيبيات الملتي كاست والتى نعرفها بأنها تنتمي للكلاس D والتى قامت الأيانا بحجز نطاق من الأبيبي خاص بها يبدأ بي 224.0.0.0 ويبنتهي 239.255.255.255
ولكي تضمن هذه الاجهزة وصول الترافيك تحتاج أن ترسل طلب إلى الروتر الذي يمثل الـ Gateway الخاص بها مخبرة أياه بأنها تريد الأنضمام إلى هذه المجموعة وبالتالي يقوم الروتر بتمرير هذا الترافيك إليها ولكن السؤال الذي يطرح نفسه كيف يتم إرسال هذا الطلب ؟ لكي تضمن هذه الأجهزة الأنضمام إلى هذه المجموعة تحتاج أولا إلى برنامج خاص يثبت على أجهزة العملاء وهو عادة أما يكون برنامج عرض فيديو أو برنامج صوتي من أجل الراديو مثلا والتى عادة ماينحصر أستخدام الملتي كاست فيها (فيديو أو راديو عبر الشبكة) وفيها يقوم البرنامج باخبار كرت الشبكة NIC برقم المجموعة الذي ينتمي إليها والذي يعبر دائما برقم الأيبي ملتي كاست وعندما يستلم كرت الشبكة رقم الأيبي يقوم أوتماتيكيا بأرسأل الطلب إلى الروتر مستخدما بروتوكول الـ IGMP وهذه صورة توضح الفكرة
خلاصة هذا الكلام : يستخدم الـ IGMP في تسجيل الـ Client إلى الروتر وهذا يشمل عملية الـ Joining وعملية الـ Leaving الخاصة بي الـ Multicast Group لذا إستخدامه ينحصر فقط بين العميل والروتر.
وكما أوضحت في بداية التدونية أن لهذا البروتوكول 3 إصدارات مختلفة وهي
IGMPv1
يملك هذا الأصدار نوعان أثنان من الرسائل فقط
الأول : Membership Query وهي ترسل من خلال الروتر فقط وكل 60 ثانية وهي من اجل إعلام الأجهزة أو العملاء بوجود Multicast Traffic داعيا أياهم للانضمام إليها وهي ترسل على العنوان 224.0.0.1 ومن خلال كل منفذ أو Segment موجودة
الثاني : Membership Report يتم إرسالها من خلال العميل فقط ومن أجل الأنضمام إلى المجموعة فبعد وصول الرسالة الأولى من الروتر يقوم العميل بأرسال Report على الأيبي الذي قام بأرسال الـ Membership Query مخبرا أياه برقم المجموعة التى يريد الأنضمام إليها وهي عادة تكون موجودة داخل الـ Header الخاص بي الـ IGMP وهذه صورة توضح الـHeader الخاص بي الـ IGMPv1
وكما تشاهدون أغلب الخانات مفهومة ماعدا خانة الـ Type والتى تحدد نوعية الرسالة Query or Report وهي أما أن تكون ox11 من أجل الـ Query أو ox12 وهي من أجل الـ Report أما خانة الـ Address Group فهي من أجل إرسال رقم المجموعة التى يرغب العميل بالأنضمام إليها
IGMPv2
في الـ V2 تم إضافة نوع ثالث من الرسائل وهو الـ Leave Group Message وهي ترسل فقط من خلال العملاء على الأيبي 224.0.0.2 الخاص بكل الروترات الموجودة على الشبكة وفيها يخبر الروتر بأنه يريد أن يغادر المجموعة وبدوره الروتر يوقف إرسال الترافيك إليه من خلال إعادة إرسال Query Message إلى كل الأجهزة الموجودة حتى يعلم من منهم مازال يريد التواصل مع المجموعة ومن منهم يريد التوقف والتى ترد عليها الأجهزة التى مازالت تستمع لهذا الترافيك من خلال رسالة الـ Report وهي الميزة الأولى بين الأثنان أما الميزة الثانية فهي تتمثل في قدرة الروتر على إرسال صنفان من الـ Query Message فلو فرضنا أن الروتر إستلم طلب مغادرة من أحد العملاء وكما أوضحنا سابقنا بأن الروتر يرد على هذا النوع من الرسائل بأرسال Query Message إلى كل العملاء الموجودين ومن هنا وجدت الميزة الثانية فعوضا عن إرسال Query إلى كل العملاء وبغض النظر عن المجموعة التى ينتمي إليها هؤلاء العملاء يمكن إرسال Specific Query أي خاص بمجموعة معينة فقط وليس إلى كل الأجهزة الموجودة مع العلم أن الطريقتان متاحتان على البروتوكول أما الميزة الثالثة قسوف تتضح معنا بعد الأطلاع على الـ Header الخاص بي الـ IGMPv2 :
وكما يتضح هنا بعض التغييرات في الـ Header فقد تم أضافة خانة جديدة وهي Max response time وهي من أجل أخبار العميل بالمدة الزمنية التى يجب أن يرد عليها أثناء أرسال الـ Query وهي عادة تكون ثانية واحدة , أما الميزة الرابعة فهي من أجل تحديد الروتر المسؤول عن عملية إرسال الـ Query وفيها يقوم الروتر الذي يملك أيبي أعلى بأرسال الـQuery بينما يتوقف الثاني عن الأرسال.
النقطة الآخيرة التى أحب أن أشير إليها وهي خانة الـ Type في IGMPv2 وهي كالآتي Query=ox16, Report=ox11, Leave=ox17 .
IGMPv3
يعد هذا الأصدار هو تحديث فقط للأصدار الثاني وفيه تم أضافة ميزة جديدة تدعم عمل Filtering للـ Source Multicast وبكلام آخر تتيح للعميل تحديد الـ Source IP Address الذي يريد أن يستلم منها الترافيك الخاص بالملتي كاست.
هذا مالدي لكم اليوم ولي عودة لكي أتكلم عن بروتوكولات التوجية الخاصة بي الـ Multicast في المستقبل القريب إن شاء الله ولاتنسونا من دعواتكم ودمتم بود
