نشرت تحت تصنيف Wireless Multicast

Multicast Dense Mode 14



كما تري في الشكل يفترض بروتوكول Dense mode أن تطبيق جروب المالتيكاست بالشهرة الكافية بالشبكة بحيث ان كل جهاز يحتوي هذا التطبيق و ينتظر تلقي التدفقات من الجروب و لهذا فإن الراوتر سيقوم ببث التدفقات عبر جميع واجهاته interfaces التي تم تفعيل البروتوكول عليها مع بعض الإستثناءات لمنع looping و تتمثل بعض هذه الإستثناءات في منع التدفقات من البث عبر الواجهة التي أتت منها

الشكل السابق يبين راوتر واحد فقط و في حالة وجود أكثر من راوتر فإنه يكرر نفس العملية ببث التدفقات عبر جميع واجهاته عدا التي أتي منها

و رغم هذا فإن هذا ابروتوكول يسمح للراوتر الذي لا يريد تلقي هذه التدفقات بالإعتراض عليها و ذلك في هاتين الحالتين جميعا

  • إذا كان الراوتر غير مربوط براوتر آخر downstream routers مهتم بهذه التدفقات
  • اذا كان الراوتر لا يعرف أي من الجهزة المتصلة عليه

اذن ففي حال وجود هذين الشرطين فإن الراوتر يخبر الراوتر الأعلي الذي أرسل اليه التدفقات بوقفها و ذلك عبر رسالة Prune message

Reverse Path Forwarding Check


ذكرنا أن الراوتر سيقوم بمنع Loop في الشبكة و ذلك بحجب التدفقات من المرور من الواجهة التي أتت منها و هذا يسمي Reverse Path Forwarding Check

في الشكل السابق يقوم R3 بدور المحقق و الذي يختبر صلاحية الباكت القادم من R1 و R2 للمرور خلاله

أولا سيقوم الراوتر R3 بالتعرف علي العنوان المصدر source address للباكت القادم و هو 10.1.1.10 أي عنوان سيرفر الميديا

ثانيا سيقوم R3 بتحديد واجهة reverse path interface الخاصة بتدفقات 10.1.1.0/24 اي الواجهة التي تلقي منها التدفقات و طبقا لجدول التوجيه لديه ستكون الواجهة s0/1 هي واجهة RPF الخاصة بالعنوان 10.1.1.10 و سيمنع بالطبع من بث التدفقات عليها

ثالثا سيقوم علي أساس تحديد RFP ببث التدفقات القادمة من الواجهة s0/1 الي باقي الواجهات و باعكس أيضا سيقوم بمنع مرور التدفقات من العودة عبر s0/1 بالإضافة لمنع تلقي التدفقات من الواجهة الأخري s0/0 القادمة من R2 و ذلك لمنع Loop في الشبكة و معني هذا أن الراوتر يقوم بتلقي التدفقات القادمة من المسار الأقصر و حجب أو رد القادمة من المسار الطول لمنع انشغال الشبكة

يحتوي هذا البروتوكول علي عدة بروتوكلات فرعية مثل DVMRP, PIM-DM, MOSPF سنتكلم عن كل منهم بالتفصيل ان شاء الله و يعتبر PIM-DM أهمهم و الذي سنتكلم عنه بشيء أكثر من التفصيل و عموما فإن لكل منهم تعامل مختلف مع RFP check فمثلا

البروتوكول الأول و هو Distance Vector Multicast Routing Protocol (DVMRP) يتعامل مع جداول التوجيه الخاصة بالمالتيكاست و يستخدمها في RFP check

البروتوكول Protocol Independent Multicast (PIM) و Core-Based Tree (CBT) يستخدم جدول التوجيه unicast routing table لعمل RPF check و هو المستخدم في المثال السابق و من جهة اخري و بعيدا عن المثال السابق فإن البروتوكولين هذين يستخدمان أيضا جدول التوجيه DVMRP route table أو لـ Border Gateway Protocol (MP-BGP) route table لعمل RPF check

البروتوكول Multicast OSPF لا يستخدم RFP Check لأن يستخدم طريقة أخري تسمي Dijkstra algorithm

نادر المنسي

محاضرات في المالتيكاست


المعلق:

مهندس عربي يطمح و يساعد في الرقي بالمحتوي العربي للتكنولوجيا عبر ترجمة و اعداد مقالات و كتب علمية في مجال الشبكات و الإتصالات السلكية و اللاسلكية

اترك رد

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

شعار وردبرس.كوم

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   /  تغيير )

Google+ photo

أنت تعلق بإستخدام حساب Google+. تسجيل خروج   /  تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   /  تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   /  تغيير )

Connecting to %s