بروتوكول معلومات التوجيه

من أرابيكا، الموسوعة الحرة
(بالتحويل من RIP)
اذهب إلى التنقل اذهب إلى البحث

بروتوكول معلومات التوجيه (بالإنجليزية: Routing Information Protocol)‏ هو بروتوكول توجيه، داخليّ، وأحد أقدم البروتوكولات العاملة بخوارزميّة شُعاع المسافة، وهو يُستخدم عدد القفزات كوسيلة لحساب وزن المسار أو كلفته. يمنع البروتوكول من تشكل الحلقات من خلال تطبيق يحدد عدد القفزات المسموحة بين المصدر والوجهة من أجل كل مسار. يستخدم البروتوكول عدد من الآليّات لمنع انتشار معلومات التوجيه غير الصحيحة وهي، تحديد الأفق (Split Horizon) وتسميم المسار (Route Poisoning) ومؤقت الانتظار.

هناك ثلاث إصدارات من بروتوكول معلومات التوجيه، وهي الإصدار الأول (RIPv1) وهو موصوف بوثيقة طلب التعليقات (RFC 1058)،[1] والإصدار الثاني وهو موصوف بالوثيقة (RFC 2453)،[2] وهما يدعمان الإصدار الرابع من بروتوكول الإنترنت (IPv4)،[3] وإصدار الجيل التالي (RIPng) وهو موصوف في الوثيقة (RFC 2080)،[4] وهو يدعم الإصدار السادس من بروتوكول الإنترنت (IPv6).[5]

يعمل بروتوكول معلومات التوجيه في طبقة التطبيق في حزمة بروتوكولات الإنترنت،[6] وهو يعتمد على بروتوكول حزم بيانات المستخدم (UDP) في طبقة النقل، وقد تم تخصيص رقم المنفذ (520) له في الإصدارين الأول والثاني ورقم المنفذ (521) في إصدار الجيل التالي.[7]

نبذة تاريخية

بروتوكول معلومات التوجيه هو بروتوكول توجيه داخلي عامل بخوزاميّة شعاع المسافة، يستخدم عدد القفزات للتعبير عن وزن المسار، ويُرسل كامل جدول التوجيه في رسائل التحديث. يتعامل البروتوكول مع كامل طوبولوجيا الشبكة دفعة واحدة، ولكنّه لا يدعم المسارات بطول أكبر من (15) قفزة، ويحتاج لعدّة دقائق لإنجاز عمية إعادة الحساب.

بدأ العمل على تطوير البروتوكول في مركز أبحاث زيروكس في بالو أيلتو في السبعنيات من القرن العشرين، وسُمي في البداية بروتوكول معلومات البوابة (Gateway Information Protocol GWINFO). في عام 1982م، ظهرت أول نسخة من البروتوكول في توزيعة برمجيات بيركلي (BSD)، ثُمّ تحوّل بحكم الأمر الواقع إلى معيار لبروتكولات التوجيه الداخليّة.[8]

بسبب عدم وجود معيار مُشترك بدأت بعض المشاكل المُتعلقة بالتوافقية والتشغيل المشترك بالظهور، ولهذا قامت مجموعة مهندسي شبكة الإنترنت بإعداد وثيقة طلب تعليقات خاصة بهذا البروتوكول هي الوثيقة (RFC 1058)، المُعنونة: بروتوكول معلومات التوجيه، والتي أصبحت المعيار الرسمي للإصدار الأول من البروتوكول.[1]

واجه الإصدار الأول من البروتوكول العديد من التحدّيات خاصة مع تطور المفاهيم المتعلقة بحزمة بروتوكولات الإنترنت (TCP/IP) وظهور العنونة الغير قياسية (VLSM)،[9] فابتدأ العمل على تطوير نسخة جديدة البروتوكول في مطلع التسعينات، وحملت وثيقة طلب التعليقات (RFC 1388) المُعنونة «الإصدار الثاني من بروتوكول معلومات التوجيه حمل معلومات إضافيّة» أول ذكر للإصدار الثاني،[10] ثُمّ حُدثت بالوثيقة (RFC 1723)،[11] وانتهى الأمر بالوثيقة (RFC 2435) في العام 1998م،[2] وهي المعيار النهائي للإصدار الثاني من بروتوكول معلومات التوجيه.

في نفس الوقت الذي كان يتم فيه تطوير الإصدار الثاني من بروتوكول معلومات التوجيه، كان العمل جاريّاً لتقديم إصدار جديد من البروتوكول مُشابه للإصدارين السابقين ولكنه مُستقل عنهما، وذلك لضمان استمرار عمل بروتوكول التوجيه مع الإصدار السادس من بروتوكول الإنترنت (IPv6)، على أيّ حال، انتهت هذه الجهود في العام 1997م بتطوير إصدار الجيل التالي من بروتوكول معلومات التوجيه (RIPng).[4]

محددات البروتوكول

خوارزمية التوجيه

المقالة الرئيسية: خوارزمية بلمان-فورد

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

بشكلٍ عام، تعمل الخورازمية لتحقيق هدفين، الأول هو بناء جدول التوجيه في العقدة التي تُشغّل البروتوكول، والثاني هو تعقّب التغيرات الحاصلة في طوبولوجيا الشبكة وتحديث جدول التوجيه بشكلٍ مُتوافق معها. لتحقيق الهدف الأول، يجب على كل موجه يُشغّل البروتوكول أن يتبادل المعلومات الخاصّة بالتوجيه مع جيرانه من العقد الأخرى التي تُشغّل البروتوكول، أما تحقيق الهدف الثاني فيحصل بشكلين، إمّا عن طريق تبادل رسائل التحديث الدوريّة وملاحقة التغيرات الحاصلة في الطوبولوجيا من خلالها، أو من خلال التجاوب مع نوع خاص من رسائل التحديث، يُسمّى رسائل التحديث المُحفّزة (Triggered Updated)، وهي رسائل تحديث غير دورية تُرسل للإبلاغ عن رصد تغيير ما في الطوبولوجيا.

وزن المسار

المقالات الرئيسية: وزن (شبكات) وقفزة (شبكات)
مشكلة الاعتماد على عدد القفزات تجعل اختيار أفضل المسارات غير دقيق، فالبروتكول سيختار دوماً المسار الأقصر على حساب الأسرع أو الأقل ازدحاماً. في هذا المثال يختار البروتوكول المسار المباشر الذي يربط بين الموجهين (R2) و(R1) لأن وزنه هو (1)، على الرغم من المسار غير المباشر، عبر المُوجّه (R3) أفضل بكثير من حيث معدل النقل، لكن وزنه هو (2).

يُستعمل وزن المسار من أجل إيجاد طريقة للمُقارنة بين المسارات المختلفة واختيار الأفضل، ويعتبر البروتوكول بأنّ المسار الأفضل الذي يصل بين نُقطتين هو المسار صاحب الوزن الأقل. لكل مسار وزن، إذا كانت الشبكة متصلة بشكل مباشر مع العقدة، فإن وزن المسار إليها من تلك العقدة هو (0).

يعتمد بروتوكول معلومات التوجيه على قيمة الوزن التراكمي للمسار لتحديد مدى جودته، ولحساب هذا الوزن يتم إيجاد مجموع أوزان الوصلات التي تشكل المسار بين المصدر والوجهة، ولكن وزن كل وصلة هو (1) بشكل افتراضي، وبالتالي فإنّ مجموع الأوزان يتحول إلى عدد الوصلات التي تشكل المسار، وبصورة أدق إلى عدد القفزات على طول المسار. من حيث المبدأ هناك إمكانية لتعديل أوزان الوصلات، ولكن ذلك غير مُستحسن. يعتمد الوزن بشكل أساسي على طول المسار، وليس على معدل نقل البيانات في وصلاته، أي أن البروتوكول سيختار المسار الأقصر على حساب المسار الأسرع وبسبب ذلك فقد وجّهت انتقادات لطريقة تعريف البروتوكول «لأفضل» مسار.

إنّ أعظم وزن ممكن للمسار هو (15)، أما القيمة (16) فهي تُعبّر عن الوزن اللانهائي، ويكون وزن المسار لا نهائياً عندما يكون الوصول إليه غير ممكناً. يضيف ذلك قيداً على تشغيل البروتوكول في الشبكات الكبيرة الحجم، التي قد يزيد طول المسار فيها عن (15) قفزة.

رسائل التحديث

تستعمل رسائل التحديث لنشر المعلومات المرتبطة بالتوجيه بين العقد التي تُشغل البروتوكول. في بروتوكول معلومات التوجيه تحتوي رسائل التحديث على معلومات مأخوذة من جدول التوجيه، يختلف محتوى الرسالة بحسب إصدار البروتوكول المستعمل، ولكنها، وبشكل عام، تحتوي على عناوين وجهات وأوزان أفضل المسارات إليها. بالإضافة لذلك، يختلف عدد المسارات التي يُمكن لرسالة التحديث الواحدة أن تحملها باختلاف الإصدار، على أيّة حال، من الممكن أن يتمّ توزيع المعلومات على أكثر من رسالة تحديث في حال لم تكفِ رسالة واحدة.

في الإصدار الأول من بروتوكول معلومات التوجيه كانت رسائل التحديث تُرسل كرسائل بث عام، ولكن ذلك يؤدي إلى استهلاك عرض النطاق في الشبة، لذلك أصبحت الرسائل ترسل بشكل بث مجموعاتي إلى عناوين خاصة، في الإصدار الثاني هو (224.0.0.9) والذي يُمثل عنوان مجموعة كل الموجهات التي تُشغّل الإصدار الثاني من البروتوكول، أما في إصدار الجيل التالي فإن عنوان المجموعة هو (FF02::9).

هناك نوعين من رسائل التحديث التي يدعمها البروتوكول، الأول هو رسائل التحديث الدوريّة، وترسل هذه الرسائل بشكل دوري بفواصل زمنية ثابتة يُحددها مُؤقّت التحديث، وتضمّ معلومات عن كامل جدول توجيه العقدة، أما النوع الثاني، فهو رسائل التحديث المُحفّزة، وهي تُرسل كرد فعل على اكتشاف تغيير في طوبولوجيا الشبكة، وذلك بهدف نشر المعلومات عن التغيير الحاصل بأسرع ما يمكن منعاً لتشكل الحلقات.

يخضع انتشار رسائل التحديث لقاعدة تحديد الأفق (Split Horizon)، وذلك تلافياً لمشكلة العدّ إلى اللانهاية ولمنع تشكل الحلقات.

المؤقتات

مخطط انتقال الحالة للمسار في بروتوكول معلومات التوجيه، يمكن ملاحظة تحكّم مُؤقّتي المهلة والانتظار بالانتقال بين حالات المسار المُحتلفة.

في الأصل، كان كل مُوجّه يُرسل معلومات عن كامل جدول توجيهه كل (30) ثانية، ففي التطبيقات الأولى كانت جداول التوجيه صغيرة الحجم بحيث لا يؤثر إرسالها بهذا الشكل على حركة البيانات، لكن مع توسّع الشبكات، أصبح من الواضح أن هناك زيادة مفاجئة في حركة البيانات كل (30) ثانية، حتى لو تمّ بدء تشغيل المُوجّهات بأوقات عشوائيّة، أي لم يتمّ إقلاعها بنفس الوقت، حيث كان الاعتقاد السائد أن ذلك سوف يسبب جعل إرسال جداول التوجيه مُبعثراً زمنياً، لكن التطبيق العملي أثبت عكس ذلك. أظهرت دراسة لاحقة في العام 1994م،[12] أنه بدون توزيع عشوائي مُحكم، فإنّ مُؤقّتات التحديث تتزامن مع بعضها بشكل آليّ مع مرور الوقت. يُشغل البروتوكول ثلاث أنواع من المؤقتات، يرتبط النوع الأول برسائل التحديث، أما النوعين الثاني والثالث، فمها زوج من المؤقتات يخصصات لكل مسار، ويلعبات دوراً أساسياً في دورة حياة المسار. بشكل عام، المؤقتات التي يُشفلها البروتوكول هي كالتالي:

  • مُؤقّت التحديث (Update timer): وهو مؤقت يحدد الزمن الفاصل بين التحديثات الدوريّة التي يُرسلها الموجه على المنافذ التي تمّ تفعيل البروتوكول عليها، بشكلٍ افتراضيّ تكون قيمته (30) ثانية.
  • مُؤقّت المهلة (Timeout timer): وهو مؤقّت خاصّ مرافق لكل مسار موجود في جدول التوجيه. يُحدد هذا المؤقّت صلاحيّة البند في جدول التوجيه، إذا نفذت قيمة المؤقت فالبند غير صالح ولا يُؤخذ به. تضبط قيمة المؤقت إلى القيمة (180) ثانية بشكل افتراضي عند إضافة المسار لجدول التوجيه أوّل مرة، ويتمّ إعادة ضبط المؤقت في كل مرة يتم فيها استقبال رسالة تحديث تحتوي على بند مُطابق للبند الموجود في جدول التوجيه.
  • مُؤقّت الانتظار (Garbage-collection timer): قيمته الافتراضيّة (120) ثانية، وهو يحدد الزمن الذي يظل فيه المسار غير الصالح موجوداً في جدول التوجيه، يتمّ تفعيل هذا المؤقت فور اعتبار أحد المسارات غير صالحاً. في حال نفذ هذا المُؤقّت، بدون استقبال أي رسالة تحديث تحتوي معلومات عن المسار، فإنّ المسار يُحذف بشكلٍ نهائيّ من جدول التوجيه، أمّا في جال استقبالها فيُعاد المسار ليكون صالحاً ويحافظ على موقعه في جدول التوجيه.

آلية العمل

خوارزمية تحديث جدول التوجيه في بروتوكول معلومات التوجيه.

يقوم بروتوكول معلومات التوجيه بمهمتين أساسيتين، الأولى هي تعريف كل عقد الشبكة التي تشغله على أفضل المسارات نحو كل الوجهات المُتاحة، بشكل أدق، ملء جداول التوجيه في هذه العقد، وتحصل هذه العملية اعتماداً على آليتين، الأولى هي التعرّف على الشبكات المتصلة بشكل مباشر مع كل عقدة، والثانية هي الإعلان عنها إلى جميع العقد الأخرى، بحيث تتنشر هذه المعلومات لتصل إلى كل عقد الشبكة.

تحصل عملية تفعيل البروتوكول على مرحلتين، في المرحلة الأولى يتم تفعيل البروتوكول في العقدة ككل، بعد ذلك يتم تفعيله على منافذ العقدة بحسب التصميم الموضوع. بغض النظر عن الإصدار، يُعرّف بروتوكول معلومات التوجيه، نوعين من الرسائل التي يتمّ تبادلها بين العقد التي تُشغله، هذان النوعان هما:[13]

  1. رسائل الطلب.
  2. رسائل الرد.

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

عندما يستقبل الموجه رسالة تحديث تحتوي على جدول توجيه، فإنّه يُعالج كل بند فيه بحسب الخوارزميّة التاليّة:[14]

  1. إذا كان البند يحتوي مساراً نحو وجهة جديدة، غير معروفة بالنسبة للبروتوكول في الموجه، فإنه يقوم بإضافتها بشكلٍ فوريّ إلى جدول التوجيه مع المعلومات المرافقة لها.
  2. إذا كان البند يحتوي مساراً نحو وجهة موجودة، ولكن بوزن أقل من الوزن المعروف بالنسبة للبروتوكول في الموجه، فإنّه يقوم بتحديث قيمة الوزن بشكلٍ مُباشر.
  3. إذا كان البند يحتوي مساراً نحو وجهة موجودة، ولكن بوزن أكبر من الوزن المعروف، فيتمّ تحديث وزن المسار إلى القيمة اللانهائية، وتشغيل مؤقّت انتظار. لحين نفاذ مؤقت الانتظار فإنّ المُوجّه يستخدم المسار نفسه لتوجيه الرزم. بعد نفاذ مؤقت الانتظار، يتفحّص البروتوكول قيمة وزن المسار في رسالة التحديث التالية، إذا كانت القيمة الجديدة ما تزال نفسها، أيّ القيمة الجديدة التي كانت أكبر من الوزن المعروف، فأنّه يقوم بتعديلها في جدول توجيهه، الهدف من الانتظار قبل زيادة وزن مسار معروف، وإلا فإنه يعتبر بأنّ وزن المسار لانهائي وبأنه لا يُمكن الوصول للوجهة، إن سبب استعمال مؤقت الانتظار هو لتجنب مشكلة العدّ إلى اللانهاية.[15]

بعد ذلك ترسل رسائل التحديث بشكل دوري، ويُنظّم مؤقت التحديث ذلك، أو بشكل مُحفّز، وتسمى رسائل التحديث المحفّزة (Triggerd Update Message)، وهي تُرسل عند اكتشاف حصول تغيير في وزن أحد المسارات، فيتم تحفيز رسالة تحديث خاصّة بالمسار، عوضاً عن الانتظار لنفاذ مؤقّت التحديث، والهدف من ذلك هو نشر التحديث عبر الشبكة بأسرع ما يُمكن منعاً لتشكل الحلقات.

الإصدرات

هناك 3 إصدارات لبروتوكول معلومات التوجيه هي: الإصدار الأول، والإصدار الثاني وإصدار الجيل التالي.

الإصدار الأول من بروتوكول معلومات التوجيه

بروتوكول معلومات التوجيه (الإصدار الأول)
الوظيفة بروتوكول توجيه داخلي
المُطوِّر زيروكس بارك
تاريخ التطوير يونيو 1988 (تاريخ إصدار المعيار)
طبقة نموذج OSI طبقة التطبيق
منافذ 520
وثيقة طلب التعليقات RFC RFC 1058
تعديل مصدري - تعديل  طالع توثيق القالب

الإصدار الأول من البروتوكول هو الإصدار الأصلي، وهو موصوف في وثيقة طلب التعليقات (RFC 1058)،[1] التي نُشرت في العام 1988م، وهو بروتوكول توجيه، داخليّ، قياسيّ أي أنّه لا يدعم تجزئة الشبكات ولا عناوين الشبكات غير القياسيّة (VLSM).

يستخدم البروتوكول خوارزمية بلمان-فورد لحساب أوزان المسارات، حيث يعتمد على عدد القفزات لحساب الوزن، لذلك فهو يُعدّ بروتوكول توجيه يعمل بخوزازميّة شعاع المسافة، مع طول أعظمي للمسار هو (15) قفزة فقط، ما يحدّ من قدرة البروتوكول على العمل في الشبكات الكبيرة. بحسب حزمة بروتوكولات الإنترنت (TCP/IP)، يعمل البروتوكول في طبقة التطبيق، ويعتمد على بروتوكول حزم بيانات المستخدم (UDP) في نقل بياناته، وقد تمّ تخصيص رقم المنفذ (520) من أجل حزم بيانات هذا البروتوكول.

يُرسل الإصدار الأول من البروتوكول رسائل التحديث على شكل رسائل بث عام، إلى العنوان (255.255.255.255)، وهو ما يُرهق عرض النطاق في الشبكة، خاصة أن كل مُوجّه في الشبكة سيقوم بإعادة إرسال الرسالة عند استقبالها عبر كل منافذه، سواء كان يدعم هذا البروتوكول أو لا. من سلبيات هذا الإصدار أيضاً عدم وجود آليّة للمصادقة، وقد شكل هذا ثغرة أمنية في الشبكة، حيث يستقبل الموجه الذي يشغل البروتكول رسائل التحديث من أي مصدر، ويعدّل جدول توجيهه على أساسه، وهذا ما جعل الموجهات التي تستخدم البروتكول عرضة لهجمات حجب الخدمة وهجوم الوسيط.

ترويسة الإصدار الأول من بروتوكول معلومات التوجيه (RIPv1).

عرّف الإصدار الأول من البرتوكول ترويسة خاصّة مكونة من ثلاث حقول رئيسيّة، هي:[1]

  1. حقل الأمر، بطول (1) بايت، وهو لتحديد نوع الترويسة، وهناك 4 أنواع هي: ترويسة الطلب، ترويسة الرد، وترويستي تفعيل وتعطيل التعقب، اللتان أخرجتا من الخدمة ولا يوجد استخدام لهما.
  2. حقل الإصدار، ، بطول (1) بايت، لتمّيز ترويسة الإصدار الأول.
  3. حقل معلومات الشبكة، وهو بطول متغير، يضم معلومات من جدول التوجيه، على شكل بنود، حجم كل منها (20) بايت، نظريّاً يمكن أن تحمل رسالة البوتوكول معلوماتٍ عن 25 مساراً، في كل منها عنوان الوجهة ووزن المسار، بالإضافة لحقل لعائلة عنوان المسار، ولا يوجد تراميز إلا لعائلة واحدة هي عناوين الإصدار الرابع من بروتوكول الإنترنت.

يُعرّف الإصدار الأول من البروتوكول ثلاث مؤقتات، الأول هو مُؤقّت التحديث، وهو يستخدم لضبط الفترة الزمنية الفاصلة بين كل رسالتي تحديث يقوم المُوجّه الذي يُشعل البروتوكول بإرسالهما، ومؤقتي النفاذ والانتظار وهما مرافقان لكل مسار يتمّ إضافته لجدول التوجيه، ويحددان على التوالي صلاحية المسار في جدول التوجيه، وزمن الاحتفاظ بالمسار غير الصالح في الجدول قبل التخلص منه.

الإصدار الثاني من بروتوكول معلومات التوجيه

بروتوكول معلومات التوجيه (الإصدار الثاني)
الوظيفة بروتوكول توجيه داخلي
المُطوِّر مجموعة مهندسي شبكة الإنترنت
تاريخ التطوير يوليو 1998
طبقة نموذج OSI طبقة التطبيق
منافذ 520
وثيقة طلب التعليقات RFC RFC 2453
تعديل مصدري - تعديل  طالع توثيق القالب

عملت مجموعة مهندسي شبكة الإنترنت على تطوير الإصدار الثاني من بروتوكول معلومات التوجيه، وهو موصوف في وثيقة طلب التعليقات (RFC 2453)، التي نُشرت في العام 1998م، وهو بروتوكول توجيه، داخليّ، غير قياسيّ أي أنّه يدعم تجزئة الشبكات وعناوين الشبكات غير القياسيّة (VLSM)، بالإضافة لأنه جاء متوافقاً مع الإصدار الأول.

عمل الإصدار الثاني من البروتوكول بحسب خوارزمية بلمان-فورد أيضاً من أجل حساب أوزان المسارات، لذلك فهو يُعدّ بروتوكول توجيه يعمل بخوزازميّة شعاع المسافة، مع طول أعظمي للمسار هو (15) قفزة فقط. بدعم بروتوكول الإصدار الثاني من بروتوكول معلومات التوجيه رزم الإصدار الرابع من بروتوكول الإنترنت (IPv4)، وبشكل مشابه للإصدار الأول، فقد اعتمد الإصدار الثاني على على بروتوكول حزم بيانات المستخدم (UDP) في نقل بياناته، مع حجز رقم المنفذ (520) من أجل حزم بياناته.

لحل المشكلة الأمنية التي واجهت الإصدار الأول، دعم الإصدار الثاني عملية مصادقة بين المُوجهات التي تشغله، إما بتبادل كلمة مرور صريحة، أو مشفرة باستخدام خوارزمية هضم الرسالة الخامسة (MD5)، وقد خصصت الوثيقة (RFC 2082) المعنونة: «المصادقة باستخدام خوارزميّة هضم الرسالة الخامسة في الإصدار الثاني من بروتوكول معلومات التوجيه» (RIPv2 MD5 Authentication).

لا يُعرّف البروتوكول ترويسة خاصة من أجل عملية المُصادقة، وإنّما تستخدم أحد بنود رسالة لتحديث المُخصصة للإعلان عن مسار ما لتوضع فيها حقول ميّزة المُصادقة، وهذا يُخفض عدد المسارات التي يمكن لرسالة تحديث واحدة أن تحمله في حال تشغيل ميّزة المُصادقة إلى 24 مساراً بدلاً من 25.

يعتمد الإصدار الثاني على تقنية البث المجموعاتي عند إرسال رسائل التحديث، حيث تُرسل جميع الرسائل إلى العنوان (224.0.0.9) الذي يُمثل مجموعة كل الموجهات التي تشغل الإصدار الثاني من بروتوكول معلومات التوجيه.

إصدار الجيل التالي من بروتوكول معلومات التوجيه

بروتوكول معلومات التوجيه (إصدار الجيل التالي)
الوظيفة بروتوكول توجيه داخلي
المُطوِّر مجموعة مهندسي شبكة الإنترنت
تاريخ التطوير يناير 1997
طبقة نموذج OSI طبقة التطبيق
منافذ 521
وثيقة طلب التعليقات RFC RFC 2080
تعديل مصدري - تعديل  طالع توثيق القالب


مع ظهور الإصدار السادس من بروتوكول الإنترنت (IPv6)، بدأ العمل على إصدار بروتوكولات متوافقة معه، وجاء إصدار الجيل التالي من بروتوكول معلومات التوجيه، الموصوف بالوثيقة (RFC 2080) ليحقق ذلك في شهر يناير من العام 1997م. فهو بروتوكول توجيه، داخليّ، لرزم الإصدار السادس من بروتوكول الإنترنت، وهو غير مُتوافق مع الإصدارين السابقين من البروتوكول من حيث بنية الرسائل المُستعملة.

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

يعتمد البروتوكل على نفس مجموعة المؤقتات التي يدعمها الإصدار الثاني، وهي مؤقت التحديث ومؤقتا النفاذ ووهما زوج مرافق لكل مُسار يُضاف إلى جدول التوجيه، وتعمل هذه المؤقتات بحسب إصدار الجيل التالي بنفس الآلية التي تعمل فيها في الإصدار الثاني. وتجدر الإشارة لإلى أن محددات البروتوكول أشارت إلى عملية تزامن مؤقتات التحديث في المُوجّهات التي تشغل البروتوكول، والتي ينتج عنها غمر الشبكة برسائل التحديث بوقت واحد ما يُسبب استهلاك عرض النطاق المُتاح، وقدّمت المحددات زوجاً من الحلول لتلافي حصول هذه المشكلة.

بالإضافة لذلك، فإنّ هذا الإصدارمن البروتوكول يدعم آليّات العد إلى اللانهاية، وتسميم المسار، وتحديد الأفق، كآليّة لمواجهة مُشكلة تشكل الحلقات.

دعم إصدار الجيل التالي مجموعة الخيارات الأمنية الخاصّة ببروتوكول الإنترنت (IPSec)، وذلك لإنجاز عملية المصادقة، بالإضافة لاعتماده على بنية ترويسة مغايرة تماماً للإصدارين السابقين، ورقم منفذ آخر هو 521، وعنوان بث مجموعاتي هو (FF02::9) ليمثل مجموعة كل الموجهات التي تُشغّل الإصدار التالي من بروتوكول معلومات التوجيه.

انظر أيضاً

مراجع

  1. ^ أ ب ت ث Hedrick, C. (Jun 1988). "RFC 1058, Routing Information Protocol". The Internet Society (بEnglish). Archived from the original on 2018-03-25. Retrieved 2017-07-31.
  2. ^ أ ب Malkin, G. (Nov 1998). "RFC 2453, RIP Version 2". The Internet Society (بEnglish). Archived from the original on 2020-09-01. Retrieved 2017-09-30.
  3. ^ Postel, J. (سبتمبر 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (بEnglish). Archived from the original on 6 أغسطس 2019. Retrieved 13 يوليو2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  4. ^ أ ب Minnear, R. (Jan 1997). "RFC 2080, RIPng for IPv6". The Internet Society (بEnglish). Archived from the original on 2019-12-13. Retrieved 2017-09-30.
  5. ^ Deering, S.; Hinden, R. (Jul 2017). "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society (بEnglish). Archived from the original on 2019-06-26. Retrieved 2017-07-31.
  6. ^ Socolofsky, T.; Kale, C. (يناير1991). "RFC 1180, A TCP/IP Tutorial". The Internet Society (بEnglish). Archived from the original on 21 سبتمبر 2019. Retrieved 14 يوليو 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)
  7. ^ "Service Name and Transport Protocol Port Number Registry". Internet Assigned Numbers Authority (IANA) (بEnglish). Archived from the original on 2013-09-26.
  8. ^ "RIP Overview, History, Standards and Versions". Charles M. Kozierok (بEnglish). Archived from the original on 18 سبتمبر 2017. Retrieved 6 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  9. ^ Pummill, T.; Manning, B. (ديسمبر 1995). "RFC 1878, Variable Length Subnet Table For IPv4". The Internet Society (بEnglish). Archived from the original on 12 يناير 2017. Retrieved 7 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  10. ^ Malkin, G. (يناير 1993). "RFC 1388, RIP Version 2 Carrying Additional Information". The Internet Society (بEnglish). Archived from the original on 25 مارس 2018. Retrieved 7 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  11. ^ Malkin, G. (نوفمبر 1994). "RFC 1723, RIP Version 2 Carrying Additional Information". The Internet Society (بEnglish). Archived from the original on 7 نوفمبر 2008. Retrieved 7 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  12. ^ Floyd، S.؛ Jacobson، V. (أبريل 1994). "The synchronization of periodic routing messages" (PDF). IEEE/ACM Transactions on Networking. IEEE. ج. 2 ع. 2: 122-136. DOI:10.1109/90.298431. مؤرشف من الأصل (PDF) في 2017-07-05.
  13. ^ "RIP General Operation, Messaging and Timers". Charles M. Kozierok (بEnglish). 20 سبتمبر 2005. Archived from the original on 27 سبتمبر 2017. Retrieved 3 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  14. ^ "RIP Algorithm". Baylor® University (بEnglish). Archived from the original on 22 سبتمبر 2017. Retrieved 4 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)
  15. ^ Abdelshkou, Maher (11 أغسطس 2013). "RIP". Cisco Systems Inc (بEnglish). Archived from the original on 27 سبتمبر 2017. Retrieved 3 أوكتوبر 2017. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ الوصول= (help)[وصلة مكسورة]

وصلات خارجية

مجلوبة من «https://3rabica.org/index.php?title=بروتوكول_معلومات_التوجيه&oldid=1713640»