تطبّق شبكاتُ الوصول المتعدد، مثل شبكة إيثرنت، البثَّ المتعدد في العتاد. ولكن هناك تطبيقات تحتاج إلى قدرة بثٍ متعدد أوسع تكون فعالةً على شبكة بحجم شبكة الإنترنت. يجب إرسال نفس البيانات إلى جميع المضيفين عندما تبث محطة راديو بثًا إذاعيًا broadcast عبر الإنترنت على سبيل المثال، حيث يضبط المستخدم هذه المحطة. ويكون الاتصال وفق علاقة واحد إلى متعدد one-to-many في هذا المثال. تتضمن الأمثلة الأخرى لتطبيقات واحد إلى عدّة إرسالَ نفس الأخبار أو أسعار الأسهم الحالية أو تحديثات البرامج أو القنوات التلفزيونية إلى عدة مضيفين، ويُطلَق على المثال الأخير اسم IPTV.
هناك أيضًا تطبيقات يكون اتصالها متعدد إلى متعدد many-to-many، مثل مؤتمرات الوسائط المتعددة عن بعد أو الألعاب متعددة اللاعبين عبر الإنترنت أو عمليات المحاكاة الموزعة. حيث يتلقى أعضاء المجموعة بيانات من عدة مرسلين في مثل هذه الحالات، عادةً من بعضهم بعضًا، ويتلقون جميعًا نفس البيانات من أي مرسل معين.
لا تناسب اتصالات IP العادية، والتي يجب فيها توجيه كل رزمةٍ وإرسالها إلى مضيف واحد، لمثل هذه التطبيقات. إذا كان التطبيق يحتوي على بياناتٍ لإرسالها إلى مجموعة، فسيتعين عليه إرسال رزمةٍ منفصلة بها البيانات المتطابقة إلى كل عضوٍ في المجموعة. يستهلك هذا التكرار حيز نطاقٍ تراسلي أكثر من اللازم. ولا تُوزَّع حركة المرور الزائدة بالتساوي بل تُركّز على المضيف المرسل، وقد تتجاوز بسهولة سعة المضيف المرسل والشبكات والموجّهات القريبة.
يوفر بروتوكول IP بثًا متعددًا على مستوى بروتوكول IP ومشابهًا للبث المتعدد على مستوى الرابط الذي توفره شبكات الوصول المتعدد مثل شبكة الإيثرنت من أجل دعم الاتصال متعدد إلى متعدد many-to-many ومن واحد إلى متعدد one-to-many. نحتاج أيضًا، بعد أن قدمنا مفهوم البث المتعدد لبروتوكول IP، إلى مصطلح لخدمة واحد إلى واحد one-to-one التقليدية لبروتوكول IP، حيث يشار إلى هذه الخدمة على أنها بث أحادي unicast.
نموذج بث IP المتعدد الأساسي هو نموذج عدة إلى عدة معتمد على مجموعات البث المتعدد، حيث يكون لكل مجموعة عنوان IP متعدد البث خاص بها. يتلقى المضيفون الذين هم أعضاء في مجموعة نسخًا من أي رزم تُرسَل إلى عنوان البث المتعدد لتلك المجموعة. يمكن أن يكون المضيف في مجموعات متعددة، ويمكنه الانضمام إلى المجموعات وتركها بحرية عن طريق إخبار موجهه المحلي باستخدام بروتوكول سُيناقش قريبًا. وبالتالي فإن عناوين البث المتعدد مرتبطة بمجموعة مجردة تتغير عضويتها ديناميكيًا بمرور الوقت، بينما نفكر في عناوين البث الأحادي باعتبارها مرتبطةً بعقدةٍ أو واجهة. يسمح نموذج خدمة البث IP المتعدد الأصلي لأي مضيف بإرسال حركة مرور متعددة البث إلى مجموعة، أي ليس من الضروري أن يكون عضوًا في المجموعة، وقد يكون هناك أي عدد من هؤلاء المرسلين لمجموعة معينة.
يرسل المضيف نسخةً واحدة من الرزمة موجهة إلى عنوان البث المتعدد للمجموعة باستخدام بروتوكول IP متعدد البث لإرسال الرزمة المتطابقة إلى كل عضو في المجموعة. لا يحتاج مضيف الإرسال إلى معرفة عنوان IP الأحادي البث لكل عضو في المجموعة لأن هذه المعرفة تُوزَّع بين الموجهات في الشبكة المتشابكة internetwork كما سنرى. وبالمثل، لا يحتاج مضيف الإرسال إلى إرسال نسخٍ متعددة من الرزمة لأن الموجهات ستنشئ نسخًا كلما كان عليها تمرير الرزمة عبر أكثر من رابطٍ واحد. يكون البث المتعدد لبروتوكول IP أكثرَ قابلية للتوسع لأنه يزيل حركة المرور (الرزم) الزائدة التي كان من الممكن إرسالها عدة مرات عبر نفس الروابط، وخاصة تلك القريبة من المضيف المرسل، مقارنة باستخدام بروتوكول IP أحادي البث لتقديم نفس الرزم إلى العديد من أجهزة الاستقبال.
اُستكمِل البث المتعدد الأصلي متعدد إلى متعدد many-to-many الخاص ببروتوكول IP بدعم شكلٍ من أشكال البث المتعدد من واحد إلى متعدد. يحدّد مضيف الاستقبال كلًا من مجموعة البث المتعدد ومضيف الإرسال المحدّد في هذا النموذج من البث المتعدد من واحد إلى متعدد، المسمّى البث المتعدد المحدّد بالمصدر Source-Specific Multicast أو اختصارًا SSM. سيتلقى المضيف المستقبل بعد ذلك البث المتعدد الموجَّه إلى المجموعة المحددة، ولكن فقط إذا كانت من المرسل المحدّد. تتلاءم العديد من تطبيقات البث المتعدد للإنترنت (مثل البث الإذاعي الراديوي) مع نموذج SSM. يُشار أحيانًا إلى نموذج IP الأصلي متعدد إلى متعدد باسم البث المتعدد لأي مصدر Any Source Multicast أو اختصارًا ASM.
يشير المضيف إلى رغبته في الانضمام إلى مجموعة البث المتعدد أو تركها من خلال الاتصال بالموجه المحلي الخاص به باستخدام بروتوكول خاص لهذا الغرض فقط. هذا البروتوكول في الإصدار IPv4 هو بروتوكول إدارة مجموعات الإنترنت Internet Group Management Protocol أو اختصارًا IGMP، أما في الإصدار IPv6، فهو اكتشاف المستمع المتعدد Multicast Listener Discovery أو اختصارًا MLD، ثم يتحمّل الموجه بعد ذلك مسؤولية جعل البث المتعدد يتصرف بصورة صحيحة فيما يتعلق بهذا المضيف. يستطلع الموجهُ الشبكةَ دوريًا لتحديد المجموعات التي لا تزال ذات أهمية للمضيفين المرتبطين بالشبكة، نظرًا لأن المضيف قد يفشل في ترك مجموعة البث المتعدد في الوقت المناسب (بعد حدوث عطل أو فشل آخر على سبيل المثال).
عناوين البث المتعدد Multicast Addresses
يحتوي بروتوكول IP على مجالٍ فرعي subrange محجوز لعناوين البث المتعدد. تُسنَد هذه العناوين في الإصدار IPv4 في حيز عناوين الصنف D، ويحتوي الإصدار IPv6 أيضًا على جزءٍ من حيز العناوين المحجوز لعناوين مجموعة البث المتعدد. بعض المجالات الفرعية لنطاقات البث المتعدد محجوزةٌ للبث المتعدد داخل النطاق intradomain، بحيث يمكن إعادة استخدامها بشكل مستقل عن طريق النطاقات المختلفة.
هناك 28 بتًا من عناوين البث المتعدد المحتملة في الإصدار IPv4 عندما نتجاهل البادئة المشتركة بين جميع عناوين البث المتعدد. يمثل هذا مشكلة عند محاولة الاستفادة من البث المتعدد للعتاد على شبكة محلية LAN. لنأخذ حالة شبكة الإيثرنت، حيث تحتوي عناوين البث المتعدد للإيثرنت على 23 بتًا فقط عندما نتجاهل بادئتها المشتركة، أي يتعين على بروتوكول IP ربط عناوين بث IP المتعدد المؤلَّفة من 28 بتًا مع عناوين بث الإيثرنت المتعدد ذات 23 بتًا للاستفادة من البث المتعدد عبر شبكة الإيثرنت. يُطبَّق ذلك عن طريق أخذ 23 بت ذات الترتيب المنخفض لأي عنوان IP متعدد البث لاستخدامها كعنوان إيثرنت متعدد البث وتجاهل 5 بتات عالية الترتيب. وبالتالي تُربَط 32 ( أو25) عنوان IP مع كل عنوان من عناوين الإيثرنت.
اقتباسنستخدم شبكات الإيثرنت في هذا القسم كمثالٍ قياسي لتقنية الشبكات التي تدعم البث المتعدد في العتاد، ولكن ينطبق الأمر نفسه أيضًا على شبكات PON "الشبكات الضوئية غير الفعالة Passive Optical Networks"، وهي تقنية شبكة الوصول التي تُستخدم غالبًا لإيصال الألياف إلى الشقق fiber-to-the-home. يُعَد بروتوكول IP متعدد البث عبر شبكة PON طريقةً شائعة لإيصال تقنية IPTV إلى المنازل.
يضبط المضيفُ على شبكة إيثرنت المُنضَم إلى مجموعة IP متعددة البث واجهةَ الإيثرنت الخاصة به لتلقي أي رزمٍ مع عنوان بث الإيثرنت المتعدد المقابل. يتسبب هذا بأن المضيف المستقبل لن يتلقى فقط حركة مرور البث المتعدد التي يريدها ولكن أيضًا حركة المرور المرسلة إلى أيٍّ من مجموعات البث المتعدد 31 الأخرى التي تُربَط مع عنوان الإيثرنت نفسه، إذا وُجِّهت إلى شبكة الإيثرنت هذه. لذلك يجب على بروتوكول IP في المضيف المستقبل فحصَ ترويسة IP لأي رزمةٍ متعددة البث لتحديد ما إذا كانت الرزمة تنتمي حقًا إلى المجموعة المطلوبة. إن عدم تطابق أحجام عناوين البث المتعدد يعني أن حركة مرور البث المتعدد قد تضع عبئًا على المضيفين الذين لا يهتمون حتى بالمجموعة التي أُرسِلت حركة المرور إليها. يمكن تخفيف هذه المشكلة لحسن الحظ في بعض شبكات التبديل switched networks، مثل شبكة الإيثرنت المبدَّلة، عن طريق المخططات حيث تتعرف المبدّلات switches على الرزم غير المرغوب فيها وتتجاهلها.
أحد الأسئلة المحيّرة هو كيف يتعرف المرسلين والمستقبلين على عناوين البث المتعدد التي يجب استخدامها في المقام الأول. يُتعامل مع هذا عادةً عن طريق وسائل خارج النطاق out-of-band means، وهناك بعض الأدوات المتطورة للغاية لتفعيل الإعلان عن عناوين المجموعات على الإنترنت.
التوجيه متعدد البث باستخدام بروتوكولات DVMRP وPIM وMSDP
تشير جداول تمرير البث الأحادي الخاصة بالموجّه، بالنسبة لأي عنوان IP، إلى الرابط الواجب استخدامه من أجل تمرير رزمة البث الأحادي unicast. يجب أن يحتوي الموجه أيضًا، لدعم البث المتعدد، على جداول تمرير البث المتعدد التي تشير، استنادًا إلى عنوان البث المتعدد، إلى الروابط (ربما أكثر من رابط) لاستخدامها لتمرير رزمة بث متعدد (يكرر الموجّه الرزمة في حالة مُرِرت عبر روابط متعددة). وبالتالي تحدد جداولُ تمرير البثِ الأحادي بصورة جماعية مجموعةً من المسارات، وتحدد جداولُ تمرير البث المتعدد بصورة جماعية مجموعةً من الأشجار هي: أشجار توزيع البث المتعدد multicast distribution trees. ولدعم البث المتعدد الخاص بالمصدر ولبعض أنواع أي مصدرٍ متعدد البث Any Source Multicast أيضًا، يجب أن تحدّد جداولُ تمرير البث المتعدد الروابطَ الواجب استخدامها بناءً على مجموعة عناوين البث المتعدد وعنوان IP (أحادي البث) الخاص بالمصدر، وتحدد مجموعةً من الأشجار أيضًا.
توجيه البث المتعدد هو العملية التي تُحدَّد من خلالها أشجار توزيع البث المتعدد، أو بصورة أكثر تحديدًا هي العملية التي تُنشَأ من خلالها جداول تمرير البث المتعدد. لا يكفي أن "يعمل" بروتوكول توجيه البث المتعدد كما هو الحال مع التوجيه الأحادي، أي يجب أيضًا أن يتوسّع على نحوٍ معقول مع نمو الشبكة، ويجب أن يستوعب استقلالية نطاقات domains التوجيه المختلفة.
بروتوكول DVMRP
يمكن توسيع توجيه متجّه المسافة Distance-vector المستخدَم في البث الأحادي لدعم البث المتعدد. يُطلق على البروتوكول الناتج اسم بروتوكول توجيه متجه المسافة متعدد البث Distance Vector Multicast Routing Protocol أو اختصارًا DVMRP. كان بروتوكول DVMRP أول بروتوكول توجيه متعدد البث مستخدمٍ على نطاق واسع.
تذكّر أنه في خوارزمية متجه المسافة، يحتفظ كل موجهٍ بجدول Destination وCost وNextHop، ويتبادل قائمة أزواج (Destination وCost) مع جيرانه المتصلين مباشرة به. توسيع هذه الخوارزمية لدعم البث المتعدد هو عملية من مرحلتين: أولًا، ننشئ آلية بث تسمح بتمرير الرزمة إلى جميع الشبكات على الإنترنت. ثانيًا، نحن بحاجة إلى تحسين هذه الآلية بحيث تعمل على تقليم prune الشبكات التي لا تحتوي على مضيفين ينتمون إلى مجموعة البث المتعدد، وبالتالي يُعَد بروتوكول DVMRP أحد بروتوكولات توجيه البث المتعدد الموصوفة ببروتوكولات الإغراق والتقليم flood-and-prune.
يعرف كل موجهٍ أن أقصر مسار حالي إلى وجهة destination معينة يمر عبر موجّه القفزة التالية NextHop بالنظر إلى جدول توجيه أحادي البث. وبالتالي يمرر الموجه، الذي تلقّى رزمة بث متعدد من المصدر S، الرزمة على جميع الروابط الصادرة (باستثناء تلك التي وصلت عليها الرزمة) إذا وفقط إذا وصلت الرزمة عبر الرابط الموجود في أقصر مسار إلى المصدر S (مثل وصول الرزمة من موجّه القفزة التالية NextHop المرتبطة بالمصدر S في جدول التوجيه). تغرق floods هذه الإستراتيجية بفعالية الرزم خارج المصدر S ولكنها لا تعيد الرزم مرةً أخرى نحوه.
هناك نوعان من أوجه النقص الرئيسية لهذا النهج. أولًا، هو أنه يغرق الشبكة حقًا، أي ليس لديه شرطٌ لتجنب الشبكات المحلية التي ليس لها أعضاء في مجموعة البث المتعدد، حيث سنعالج هذه المشكلة لاحقًا. وثانيًا هو أنه سيُمرر رزمةٍ معينةٍ عبر شبكة LAN بواسطة كل من الموجهات المتصلة بهذه الشبكة المحلية، ويرجع ذلك إلى استراتيجية التمرير المتمثلة في إغراق الرزم على جميع الروابط بخلاف تلك التي وصلت عليها الرزمة، بغض النظر عما إذا كانت هذه الروابط جزءًا من أقصر مسار شجرة جذرها في المصدر أم لا.
يكمن حل وجه النقص الثاني في التخلص من رزم البث الإذاعي broadcast المكرَّرة التي تُنشَأ عند توصيل أكثر من موجهٍ بشبكة LAN معينة. تتمثل إحدى طرق القيام بذلك في تخصيص موجهٍ كموجّه أب parent لكل رابط له صلةٌ بالمصدر. حيث يُسمح فقط للموجه الأب بتمرير رزم البث المتعدد من ذلك المصدر عبر الشبكة المحلية. يُحدَّد الموجه الذي يحتوي على أقصر مسار إلى المصدر S على أنه الموجه الأب، أي سيُكسر التعادل بين موجهين وفقًا لأي موجه يحتوي على أصغر عنوان. يمكن لموجهٍ معين معرفة ما إذا كان هو الموجه الأب للشبكة المحلية (بالنسبة لكل مصدر محتمل) بناءً على رسائل متجه المسافة التي يتبادلها مع جيرانه.
لاحظ أن هذا التحسين يتطلب أن يحتفظ كل موجه، لكل مصدر، لوقت إضافي بكل من الروابط الخاصة به والتي تشير إلى ما إذا كان هو الموجه الأب لزوج المصدر / الرابط أم لا. ضع في بالك أن المصدر هو عبارة عن شبكة وليس مضيفًا في إعدادات الإنترنت، نظرًا لأن موجه الإنترنت مهتم فقط بتمرير الرزم بين الشبكات. تسمى الآلية الناتجة أحيانًا بث المسار العكسي إذاعيًا Reverse Path Broadcast أو اختصارًا RPB أو تمرير المسار العكسي Reverse Path Forwarding أو اختصارًا RPF. المسار عكسي لأننا نفكر في أقصر مسارٍ نحو المصدر عند اتخاذ قرارات التمرير، مقارنةً بتوجيه البث الأحادي، الذي يبحث عن أقصر مسار إلى وِجهةٍ معينة.
تطبّق آليةُ RPB البثَّ الإذاعي لأقصر مسارshortest-path broadcast. نريد الآن تقليم مجموعة الشبكات التي تتلقى كل رزمة موجهة إلى المجموعة G لاستبعاد تلك التي ليس لديها أعضاء مضيفون في المجموعة G. يمكن تحقيق ذلك على مرحلتين: أولًا، نحتاج إلى التعرّف على الحالات التي لا تحتوي فيها الشبكة الطرفية أو التي تكون عبارةً عن ورقة في الشجرة leaf network على أعضاء مجموعة. يُعَد تحديد أن الشبكة عبارة عن شبكةٍ طرفية leaf أمرًا سهلًا. فإذا كان الموجه الأب هو الموجه الوحيد على الشبكة، فإن الشبكة تكون عبارةً عن شبكةٍ طرفية. يُحدَّد ما إذا كان أي من أعضاء المجموعة واقعًا على الشبكة من خلال جعل كل مضيفٍ عضوٍ في المجموعة G يعلن دوريًا عن هذه الحقيقة عبر الشبكة. ثم يستخدم الموجه هذه المعلومات ليقرر ما إذا كان سيمرر رزمة البث المتعدد الموجّهة إلى المجموعة G عبر شبكة LAN هذه أم لا.
تتمثل المرحلة الثانية في نشر معلومات "لا يوجد أعضاء من المجموعة G هنا" إلى شجرة أقصر مسار. يحدث ذلك عن طريق جعل الموجه يزيد من أزواج (Destination, Cost) التي يرسلها إلى جيرانه من خلال المجموعات التي تهتم الشبكة الطرفية بتلقي رزم البث المتعدد منها. يمكن بعد ذلك نشر هذه المعلومات من موجهٍ لآخر، بحيث يعرف الموجّهُ المجموعاتِ الواجب تمرير رزم البث المتعدد إليها وذلك من أجل كل رابطٍ من روابطه.
لاحظ أن تضمين كل هذه المعلومات في تحديث التوجيه يُعَد أمرًا مكلفًا إلى حدٍ ما. ولا يحدث تبادل هذه المعلومات من الناحية العملية إلا عندما تبدأ بعض المصادر في ارسال رزمٍ إلى تلك المجموعة. تستخدم هذه الإستراتيجية آلية RPB، التي تضيف مقدارًا صغيرًا من الحِمل الزائد إلى خوارزمية متجه المسافة الأساسية، حتى يصبح عنوان البث المتعدد المحدَّد نشطًا. تصرّح الموجهات غير المهتمة بتلقي الرزم الموجّهة إلى تلك المجموعة عن ذلك، وتُنشر هذه المعلومات إلى الموجّهات الأخرى.
بروتوكول PIM-SM
طُوِّر بروتوكول البث المتعدد المستقل Protocol Independent Multicast، أو PIM، استجابةً لمشاكل التوسع لبروتوكولات توجيه البث المتعدد السابقة. وخصوصًا عند ملاحظة أن البروتوكولات الحالية لم تتسّع جيدًا في البيئات التي ترغب فيها نسبة صغيرة نسبيًا من الموجّهات في تلقي حركة مرور لمجموعة معينة. فلا يُعَد الاستمرار في بث حركة المرور إذاعيًا إلى جميع الموجهات إلى أن تطلب صراحةً إزالتها من ذلك التوزيع اختيارًا جيدًا للتصميم في حال لم تُرِد معظم الموجّهات استقبال حركة المرور في المقام الأول. هذا الموقف شائع جدًا بحيث يقسّم بروتوكول PIM المشكلة إلى الوضع المتناثر sparse mode والوضع الكثيف dense mode، حيث يشير مصطلحا المتناثر والكثيف إلى نسبة الموجهات التي تريد البث المتعدد. يستخدم وضع بروتوكول PIM الكثيف PIM-DM خوارزمية الإغراق والتقليم flood-and-prune مثل بروتوكول DVMRP ويعاني من نفس مشكلة قابلية التوسّع. أصبح وضع بروتوكول PIM المتناثر PIM-SM هو بروتوكول توجيه البث المتعدد المهيمن وهو محور مناقشتنا هنا. يشير الجزء "البروتوكول المستقل protocol independent" في PIM إلى حقيقة أنه، على عكس البروتوكولات السابقة مثل بروتوكول DVMRP، لا يعتمد بروتوكول PIM على أي نوعٍ معين من التوجيه أحادي البث unicast، ولكن يمكن استخدامه مع أي بروتوكول توجيه أحادي البث، كما سنرى لاحقًا.
تنضم الموجّهات صراحةً إلى شجرة توزيع البث المتعدد في الوضع PIM-SM باستخدام رسائل بروتوكول PIM المعروفة باسم رسائل الانضمام Join. لاحظ الاختلاف مع أسلوب بروتوكول DVMRP في إنشاء شجرة بث أولًا ثم تقليم الموجّهات غير المهتمة. السؤال الذي يطرح نفسه هو مكان إرسال رسائل الانضمام لأنه يمكن لأي مضيف (وأي عددٍ من المضيفين) إرسالها إلى مجموعة البث المتعدد. لمعالجة هذا الأمر، يخصّص الوضع PIM-SM لكل مجموعة موجهًا خاصًا يُعرَف باسم نقطة الالتقاء rendezvous point أو اختصارًا RP. تُضبَط عدة موجّهات في النطاق كنقاط RP مرشَّحة، ويحدِّد الوضع PIM-SM مجموعةً من الإجراءات التي يمكن من خلالها لجميع الموجهات في نطاقٍ ما الاتفاق على الموجه لاستخدامه كنقطة RP لمجموعة معينة. هذه الإجراءات معقدة نوعًا ما، حيث يجب أن تتعامل مع مجموعة متنوعة من السيناريوهات، مثل فشل نقطة RP مرشحة وتقسيم النطاق إلى شبكتين منفصلتين بسبب عدد من حالات فشل الرابط أو العقدة. افترض أن جميع الموجّهات في نطاقٍ ما تعرف عنوان IP أحادي البث الخاص بنقطة RP لمجموعةٍ معينة في بقية هذه المناقشة.
أُنشئت شجرة تمرير البث المتعدد كنتيجة لإرسال الموجهاتِ رسائلَ الإنضمام Join إلى نقطة RP. يسمح الوضع PIM-SM بإنشاء نوعين من الأشجار: شجرة مشتركة shared tree، يستخدمها جميع المرسلين، وشجرة خاصة بالمصدر source-specific tree، والتي يستخدمها فقط مضيف إرسال محدد. يُنشئ وضعُ العملية العادي الشجرةَ المشتركة أولًا، متبوعةً بشجرة واحدة أو أكثر من الأشجار الخاصة بالمصدر إذا كان هناك حركة مرور كافية لضمان ذلك. من المهم والمفترض وجود شجرة واحدة فقط للمجموعة، وليس شجرة واحدة لكل مرسلٍ إلى مجموعة، نظرًا لأن بناء الأشجار يثبّت الحالة في الموجّهات على طول الشجرة.
تُرسَل رسالة الإنضمام Join التي يرسلها موجهٌ إلى نقطة RP لمجموعة G باستخدام بث IP أحادي عادي. هذا موضح في القسم (أ) من الشكل السابق، حيث يرسل الموجه R4 رسالة Join إلى نقطة التقاء بعض المجموعات. رسالة الانضمام الأولية هي "wildcarded"، أي أنها تُطبَّق على جميع المرسلين. يجب أن تمر رسالة الإنضمام بوضوح عبر تسلسلٍ معين من الموجّهات قبل الوصول إلى نقطة RP (الموجّه R2 مثلًا). ينظُر كلُّ موجهٍ على طول المسار إلى رسالة Join وينشئ مدخلة جدول تمرير للشجرة المشتركة، تسمى مدخلة (* , G) (حيث * تعني "جميع المرسلين"). وينظر إلى الواجهة التي وصلت عليها رسالة Join لإنشاء مدخلة جدول التمرير، ويضع علامةً على تلك الواجهة كواجهةٍ يجب تمرير رزم البيانات لهذه المجموعة عليها. ثم يحدّد الواجهة المُستخدمة لتمرير رسالة Join نحو نقطة RP. حيث ستكون هذه الواجهة الوحيدة المقبولة للرزم الواردة المرسَلة إلى هذه المجموعة. ثم يمرر رسالة Join نحو نقطة RP. تصل الرسالة إلى نقطة RP في النهاية، لتكمل بناء فرع الشجرة. تظهر الشجرة المشتركة التي أُنشئت على هذا النحو كخطٍ مستمر من نقطة RP إلى الموجه R4 في القسم (أ) من الشكل السابق.
بما أن المزيد من الموجهات ترسل رسائل انضمام Join إلى نقطة RP، فإنها تتسبب في إضافة فروع جديدة إلى الشجرة، كما هو موضح في القسم (ب) من الشكل السابق. لاحظ أنه تحتاج رسالة Join فقط إلى الذهاب إلى الموجه R2 في هذه الحالة، والذي يمكنه إضافة الفرع الجديد إلى الشجرة ببساطة عن طريق إضافة واجهة صادرة جديدة إلى مدخلة جدول التمرير التي أُنشئت لهذه المجموعة. لا يحتاج الموجه R2 لتمرير رسالة Join إلى نقطة RP. لاحظ أيضًا أن النتيجة النهائية لهذه العملية هي بناء شجرة يكون جذرها نقطة RP.
افترض مثلًا أن مضيفًا يرغب في إرسال رسالة إلى المجموعة. للقيام بذلك، ينشئ رزمةً بعنوان مجموعة البث المتعدد المناسب كوجهة لها ويرسلها إلى موجهٍ معروفٍ باسم الموجه المكلَّف designated router أو اختصارًا DR على شبكته المحلية. افترض أن الموجه DR هو الموجه R1 في الشكل السابق. لا توجد حالة لمجموعة البث المتعدد هذه بين الموجّه R1 ونقطة RP في هذه المرحلة، لذا يمرر الموجه R1 رزمة البث المتعدد إلى نقطة RP من خلال نفق tunnel بدلًا من مجرد تمريرها. أي أن الموجه R1 يغلّف رزمة البث المتعدد داخل رسالة Register الخاصة بالبروتوكول PIM التي يرسلها إلى عنوان IP أحادي البث الخاص بنقطة RP. تتلقى نقطة RP الرزمة الموجهة إليها تمامًا مثل نقطة نهاية نفق IP، وتنظر في حمولة رسالة Register، فتجد في الداخل رزمة IP موجَّهةً إلى عنوان البث المتعدد لهذه المجموعة. تعرف نقطة RP ما يجب فعله بمثل هذه الرزمة بالطبع، فهي ترسلها إلى الشجرة المشتركة التي تكون نقطة RP هي جذرها. هذا يعني أن نقطة RP ترسل الرزمة إلى الموجه R2، في مثال الشكل السابق، القادر على تمريرها إلى الموجهَين R4 وR5. يظهر التسليم الكامل للرزمة من الموجه R1 إلى الموجهَين R4 وR5 في الشكل الآتي. نرى انتقال الرزمة الممرَّرة عبر نفق من الموجه R1 إلى نقطة RP مع ترويسة IP إضافية تحتوي على عنوان نقطة RP أحادي البث، ثم تصنع رزمة البث المتعدد الموجَّهة إلى المجموعة G طريقها على طول الشجرة المشتركة إلى الموجهَين R4 وR5.
قد نميل إلى إعلان النجاح عند ذلك، حيث يمكن لجميع المضيفين الإرسال إلى جميع المستقبلين بهذه الطريقة. ولكن هناك بعض عدم الكفاءة في حيز النطاق التراسلي bandwidth وتكلفة المعالجة في تغليف وفك تغليف الرزم في الطريق إلى نقطة RP، لذلك تفرض نقطةُ RP المعرِفةَ حول هذه المجموعة في الموجهات المتداخلة بحيث يمكن تجنب الأنفاق. حيث ترسل رسالة انضمام Join إلى المضيف المرسل (القسم (ج) من الشكل السابق). تتسبب رسالة الانضمام Join في أن تتعرف الموجهات على طول المسار (الموجه R3) على المجموعة نظرًا لأن هذه الرسالة تنتقل نحو المضيف، بحيث يمكن للموجه المكلَّف designated router أو اختصارًا DR إرسال الرزمة إلى المجموعة كرزم متعددة البث أصلية native، أي ليست ممرَّرة عبر نفق tunneled على سبيل المثال.
من التفاصيل المهمة الواجب ملاحظتها في هذه المرحلة أن رسالةَ الانضمام Join التي أرستلها نقطة RP إلى المضيف المرسل خاصةٌ بهذا المرسل، بينما تنطبق الرسائل السابقة المرسَلة بواسطة الموجهَين R4 و R5 على جميع المرسلين. وبالتالي فإن تأثير رسالة الإنضمام الجديدة هو إنشاء حالة خاصة بالمرسل sender-specific state في الموجهات بين المصدر المحدَّد و نقطة RP. يُشار إلى ذلك بالحالة (S , G)، نظرًا لأنها تنطبق على مرسلٍ واحد لمجموعةٍ واحدة، وتتناقض مع الحالة (G , *) التي جرى تثبيتها بين أجهزة الاستقبال و نقطة RP التي تنطبق على جميع المرسلين. وهكذا نرى في القسم (ج) من الشكل السابق مسارًا خاصًا بالمصدر من الموجه R1 إلى نقطة RP (يشار إليه بالخط المتقطع في الشكل) وشجرةً صالحةً لجميع المرسلين من نقطة RP إلى المستقبلين (يشار إليها بالخط المستمر في الشكل) .
التحسين التالي المحتمل هو استبدال الشجرة المشتركة بالكامل بشجرة خاصة بالمصدر. وهذا أمرٌ مرغوب فيه لأن المسار من المرسل إلى المستقبل عبر نقطة RP قد يكون أطول بكثير من أقصر مسارٍ ممكن. من المحتمل أن يُعاد تشغيل هذا التحسين مرةً أخرى بسبب معدل بيانات مرتفع يُلاحَظ من بعض المرسلين. يرسل الموجه الموجود في نهاية الشجرة، كالموجه R4 في مثالنا، رسالة Join خاصةً بالمصدر نحو المصدر في هذه الحالة. إن الموجهات على طول الطريق تنشئ حالة (S , G) لهذه الشجرة نظرًا لأن الموجه الموجود في نهاية الشجرة يتبع أقصر مسار نحو المصدر، والنتيجة هي شجرة جذورها في المصدر، بدلًا من نقطة RP. سننتهي بالشجرة الموضحة في القسم (د) من الشكل السابق بافتراض تبديل كلٍ من الموجهَين R4 و R5 إلى الشجرة الخاصة بالمصدر. لاحظ أن هذه الشجرة لم تعد تتضمن نقطة RP على الإطلاق. لقد أزلنا الشجرة المشتركة من هذه الصورة لتبسيط الشكل، ولكن يجب أن تظل جميع الموجّهات التي تحتوي على مستقبلي مجموعةٍ ما على الشجرة المشتركة في حال ظهور مرسلين جُدد.
يمكننا الآن أن نرى لماذا بروتوكول PIM بروتوكول مستقل independent. حيث تستفيد جميع آلياته الخاصة ببناء الأشجار وصيانتها من توجيه البث الأحادي دون الاعتماد على أي بروتوكول توجيه أحادي البث. يُحدَّد تشكيل الأشجار بالكامل من خلال المسارات التي تتبعها رسائل الانضمام، والتي يحددها اختيار أقصر المسارات التي يجريها توجيه البث الأحادي. وبالتالي فإن بروتوكول PIM هو "بروتوكول توجيهٍ مستقل أحادي البث" مقارنةً ببروتوكول DVMRP. لاحظ أن بروتوكول PIM مرتبط إلى حد كبير ببروتوكول الإنترنت، فهو ليس بروتوكولًا مستقلًا بالنسبة لِبروتوكولات طبقة الشبكة.
يوضّح تصميم الوضع PIM-SM التحديات في بناء شبكات قابلةٍ للتوسّع وكيف تُوضَع أحيانًا قابلية التوسع مقابل نوعٍ من التحسين. من المؤكد أن الشجرة المشتركة قابلة للتوسع أكثر من الشجرة الخاصة بالمصدر، بمعنى أنها تقلل من الحالة الإجمالية في الموجهات لتكون بترتيب عدد المجموعات بدلًا من عدد المرسلين المضروب بعدد المجموعات. ويمكن أن تكون الشجرة الخاصة بالمصدر ضرورية لتحقيق التوجيه الكُفُؤ والاستخدام الفعال لحيز نطاق الرابط التراسلي.
البث المتعدد بين النطاقات Interdomain Multicast
يعاني الوضع PIM-SM من بعض أوجه النقص المهمة عندما يتعلق الأمر بالبث المتعدد بين النطاقات. فإن وجود نقطة RP واحدة لمجموعةٍ ما يتعارض مع مبدأ أن النطاقات مستقلة. تعتمد جميع النطاقات المشاركة على النطاق الذي توجد فيه نقطة RP بالنسبة لمجموعة بثٍ متعدد معينة. إذا كان هناك مجموعة بثٍ متعددة معينة يتشارك فيها المرسل وبعض المستقبلين بنطاقٍ واحد، فلا يزال يتعين توجيه حركة مرور البث المتعدد مبدئيًا من المرسل إلى المستقبلين عبر أي نطاق يحتوي على نقطة RP لمجموعة البث المتعدد هذه. وبالتالي لا يُستخدَم بروتوكول PIM-SM عادةً عبر النطاقات، ولكن يُستخدَم داخل النطاق فقط.
وُضِع بروتوكول اكتشاف مصدر البث المتعدد Multicast Source Discovery Protocol أو اختصارًا MSDP لتوسيع البث المتعدد عبر النطاقات باستخدام الوضع PIM-SM. يُستخدَم بروتوكول MSDP لربط النطاقات المختلفة، حيث يشغّل كلٌّ منها وضع PIM-SM داخليًا، مع نقاط RP الخاصة به، عن طريق توصيل نقاط RP الخاصة بالنطاقات المختلفة. تحتوي كل نقطة RP على واحد أو أكثر من نقاط التقاء MSDP النظيرة peer لها في النطاقات الأخرى. يُجرى توصيل كل زوج من نظراء MSDP عن طريق اتصال TCP الذي يُشغَّل بروتوكول MSDP من خلاله. يشكّل كل نظراء MSDP لمجموعة معينة من البث المتعدد شبكةً واسعة loose mesh تُستخدم كشبكة بثٍ إذاعي broadcast network. تُبَث رسائل MSDP إذاعيًا عبر شبكةٍ من نظراء نقاط RP باستخدام خوارزمية بث المسار العكسي إذاعيًا Reverse Path Broadcast algorithm التي ناقشناها في سياق بروتوكول DVMRP.
ما هي المعلومات التي يبثها بروتوكول MSDP إذاعيًا عبر شبكة نقاط RP؟ من المستبعد أن تكون معلومات عضوية المجموعة، لأن أقصى تدفقٍ للمعلومات هو نقطة RP الخاصة بنطاق المضيف المنضَم إلى مجموعة. بل هي معلومات المصدر أي المُرسل متعدد البث. تعرف كلُّ نقطة RP المصادرَ الموجودة في نطاقها الخاص لأنها تتلقى رسالة تسجيل Register كلما ظهر مصدرٌ جديد. تستخدم كلُّ نقطة RP دوريًا بروتوكولَ MSDP لبث رسائل المصدر النشط Source Active إلى نظرائها، مع إعطاء عنوان IP المصدر وعنوان مجموعة البث المتعدد وعنوان IP الخاص بنقطة RP الأصلية.
إذا كان لدى نظير نقطة التقاء RP بروتوكول MSDP، والذي يتلقى إحدى رسائل البث الإذاعي هذه، مستقبلين نشطين لمجموعة البث المتعدد هذه، فإنه يرسل رسالة انضمام Join خاصةٍ بالمصدر إلى مضيف المصدر نيابةً عن نقطة RP نفسها، كما هو موضح في القسم (أ) من الشكل السابق. تنشئ رسالة الانضمام فرعًا من الشجرة الخاصة بالمصدر إلى نقطة RP هذه، كما هو موضح في القسم (ب) من الشكل السابق. والنتيجة هي أن كل نقطة RP تمثّل جزءًا من شبكة MSDP ولديها مستقبلون نشطون لمجموعة معينة من البث المتعدد تضاف إلى شجرة المصدر المحددة للمصدر الجديد. تستخدم نقطة RP شجرتها المشتركة لتمرير البث المتعدد إلى المستقبلين في نطاقها عندما تتلقى بثًا متعددًا من المصدر.
البث المتعدد المحدد بالمصدر Source-Specific Multicast
كان نموذج الخدمة الأصلي لبروتوكول PIM، مثل بروتوكولات البث المتعدد السابقة، نموذج متعدد إلى متعدد. حيث انضم المستقبلون إلى مجموعة، ويمكن لأي مضيف الإرسال إلى هذه المجموعة. ولكن اُعترِف في أواخر التسعينات بأنه قد يكون من المفيد إضافة نموذج واحد إلى متعدد one-to-many. الكثير من تطبيقات البث المتعدد لها مرسلٌ واحد فقط مسموحٌ به، مثل المتحدث في مؤتمرٍ عبر الإنترنت. لقد رأينا بالفعل أن بروتوكول PIM-SM يمكنه إنشاء شجرات بأقصر مسار مُحدَّد بالمصدر مثل تحسينٍ بعد استخدام الشجرة المشتركة في البداية. كان هذا التحسين غير مرئي للمضيفين في تصميم بروتوكول PIM الأصلي، حيث انضمت الموجهات فقط إلى الأشجار المحددة بالمصدر. ولكن تقرَّر جعل قدرة التوجيه المُحدَّد بالمصدر في بروتوكول PIM-SM متاحًا بصورةٍ صريحة للمضيفين، بمجرد إدراك الحاجة إلى نموذج خدمة واحد إلى متعدد. اتضح أن هذا يتطلب بصورة أساسية تغييراتٍ في بروتوكول IGMP ونظيره في الإصدار IPv6، الذي هو بروتوكول MLD، بدلًا من بروتوكول PIM نفسه. تُعرف القدرة المكتشفة حديثًا باسم PIM-SSM، بث PIM المتعدد المحدّد للمصدر PIM Source-Specific Multicast.
يقدم بروتوكول PIM-SSM مفهومًا جديدًا، وهو القناة channel، والتي هي مزيج من عنوان المصدر S وعنوان المجموعة G. يبدو عنوان المجموعة G تمامًا مثل عنوان IP متعدد البث العادي، وقد خصص كل من IPv4 و IPv6 مجالاتٍ فرعية من حيز عناوين البث المتعدد لمفهوم SSM. يحدِد المضيف كلًا من المجموعة والمصدر في رسالة تقرير عضوية IGMP إلى موجهه المحلي من أجل استخدام بروتوكول PIM-SSM. يرسل هذا الموجه بعد ذلك رسالة انضمام محددةٍ بمصدر PIM-SM إلى المصدر، وبالتالي يضيف فرعًا لنفسه في الشجرة المحدَّدة بالمصدر، تمامًا كما في بروتوكول PIM-SM "العادي"، ولكن مع تجاوز مرحلة الشجرة المشتركة بأكملها. يمكن فقط للمصدر المحدد إرسال رزمٍ على تلك الشجرة، نظرًا لأن الشجرة التي تظهر نتائجها محددةٌ بالمصدر .
قدّم إدخال مفهوم PIM-SSM بعض الفوائد المهمة، نظرًا لوجود طلبٍ مرتفع نسبيًا على البث المتعدد من واحد إلى متعدد one-to-many multicasting، وهذه الفوائد هي:
- تنتقل رسائل البث المتعدد مباشرةً إلى المستقبلين بصورة أكبر.
- عنوان القناة هو عنوان مجموعة بث متعدد إضافةً إلى عنوان المصدر. لذلك يمكن لنطاقاتٍ متعددة استخدام نفس عنوان مجموعة البث المتعدد بصورة مستقلة ودون تعارض طالما أنها تستخدمه فقط مع المصادر في النطاقات الخاصة بها، نظرًا لأنه سيُستخدَم مجالٌ معين من عناوين مجموعة البث المتعدد لمفهوم SSM حصريًا.
- بما أنه يمكن للمصدر المحدد فقط الإرسال إلى مجموعة SSM، فهناك مخاطر أقل للهجمات القائمة على المضيفات الضارة التي تغمر الموجهات أو المستقبلين بحركة مرور متعددة البث وزائفة.
- يمكن استخدام بروتوكول PIM-SSM عبر النطاقات تمامًا كاستخدامه داخل النطاق، دون الاعتماد على أي شيء آخر كبروتوكول MSDP.
لذلك يعد مفهوم SSM إضافةً مفيدة إلى حدٍ ما إلى نموذج خدمة البث المتعدد.
الأشجار ثنائية الاتجاه Bidirectional Trees مثل بروتوكول BIDIR-PIM
نختم مناقشتنا للبث المتعدد بتحسينٍ آخر لبروتوكول PIM يُعرف باسم PIM ثنائي الاتجاه Bidirectional. بروتوكول BIDIR-PIM هو بروتوكول حديث ومختلف عن بروتوكول PIM-SM وهو مناسب تمامًا للبث المتعدد بنمط متعدد إلى متعدد داخل النطاق، خاصة عندما يكون المرسلين والمستقبلين لمجموعة ما متماثلين، كما هو الحال في مؤتمر الفيديو متعدد الأطراف على سبيل المثال. ينضم المستقبلون المحتملون إلى المجموعات عن طريق إرسال رسائل تقرير عضوية IGMP (والتي يجب ألا تكون محددة المصدر) كما هو الحال في بروتوكول PIM-SM، وتُستخدَم شجرة مشتركة جذرها في نقطة RP لتمرير رزم البث المتعدد إلى المستقبلين. إن الشجرة المشتركة لها أيضًا فروعٌ إلى المصادر، على عكس بروتوكول PIM-SM، حيث لن يكون هذا منطقيًا مع شجرة PIM-SM أحادية الاتجاه unidirectional، أما أشجار BIDIR-PIM ثنائية الاتجاه، فيمكن للموجه الذي يتلقى رزمة بثٍ متعدد من الفرع السفلي تمريرها إلى أعلى الشجرة وأسفل الفروع الأخرى. يذهب المسارُ المتّبع لتسليم رزمةٍ إلى أي مستقبل معين فقط إلى أعلى الشجرة حسب الضرورة قبل النزول أسفل الفرع إلى ذلك المستقبل. شاهد مسار البث المتعدد من الموجه R1 إلى الموجه R2 في القسم (ب) من الشكل الآتي كمثال. يمرر الموجه R4 رزمة البث المتعدد لأسفل الشجرة إلى الموجه R2 بنفس الوقت الذي يمرر فيه نسخةٍ من نفس الرزمة لأعلى الشجرة إلى الموجه R5.
أحد الجوانب المدهشة في بروتوكول BIDIR-PIM هو أنه لا داعي لوجود نقطة RP بالفعل. فكل ما هو مطلوب هو عنوان قابل للتوجيه، والذي يُعرف باسم عنوان RP على الرغم من أنه لا يلزم أن يكون هذا العنوان هو عنوان نقطة RP أو أي شيء على الإطلاق. كيف يمكن أن يحدث هذا؟ تُمرر رسالة الإنضمام Join من جهاز مستقبل إلى عنوان نقطة RP حتى يصل إلى موجهٍ له واجهةٌ على الرابط حيث يوجد عنوان RP، وعندها ينتهي الانضمام. يظهر القسم (أ) من الشكل الآتي رسالة Join تبدأ من الموجه R2 وتنتهي عند الموجه R5، ورسالة Join تبدأ من الموجه R3 وتنتهي عند الموجه R6. يتدفق تمرير رزمة البث المتعدد للأعلى نحو عنوان RP حتى تصل إلى موجهٍ له واجهةٌ على الرابط حيث يتواجد عنوان RP، ولكن بعد ذلك يمرر الموجه رزمة البث المتعدد إلى هذا الرابط كخطوة أخيرة للتمرير للأعلى، متأكدًا من أن جميع الموجهات الأخرى الموجودة على هذا الرابط تتلقى هذه الرزمة. يوضح القسم (ب) من الشكل التالي تدفق حركة البث المتعدد الناشئة في الموجّه R1:
لا يمكن حتى الآن استخدام بروتوكول BIDIR-PIM عبر النطاقات. ولكن لديه العديد من المزايا التي تتفوق على بروتوكول PIM-SM من أجل البث المتعدد بنمط متعدد إلى متعدد داخل النطاق، وهذه المزايا هي:
- لا توجد عملية تسجيل registration للمصدر حيث تعرف الموجهات بالفعل كيفية توجيه رزمة البث المتعدد نحو عنوان RP.
- المسارات مباشرةٌ أكثر من تلك التي تستخدم شجرة PIM-SM المشتركة لأنها تذهب فقط إلى أعلى الشجرة حسب الضرورة، وليس على طول الطريق إلى نقطة RP.
- تستخدم الأشجار ثنائية الاتجاه حالة أقل بكثير من الأشجار المحدَّدة بالمصدر في بروتوكول PIM-SM لأنه لا توجد أبدًا أية حالةٍ محدَّدةٌ بالمصدر. لكن ستكون المسارات أطول من مسارات الأشجار المحددة بالمصدر.
- لا يمكن أن تكون نقطة RP عنق زجاجة bottleneck أو نقطة اختناق، وليست هناك حاجة فعلية لنقطة RP.
أحد الاستنتاجات الممكن استخلاصها من حقيقة أن هناك العديد من الأساليب المختلفة للبث المتعدد خلال بروتوكول PIM فقط هو أن البث المتعدد يمثل مجالًا لمشكلةٍ صعبة يمكن إيجاد الحلول المثلى فيها. تحتاج إلى تحديد المعايير التي تريد تحسينها (استخدام حيز النطاق التراسلي، وحالة الموجه، وطول المسار وغير ذلك) ونوع التطبيق الذي تحاول دعمه (واحد إلى متعدد، متعدد إلى متعدد وهلم جرا) قبل اتخاذ قرار الاختيار "لأفضل" اوضاع مهمة البث المتعدد.
ترجمة -وبتصرّف- للقسم Multicast من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.