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

📅 آخر تحديث: ٤ أغسطس ٢٠٢٦
✍️ نُشر في: ٤ أغسطس ٢٠٢٦
الموسوعة الحرة

بروتوكول حجز الموارد ( RSVP ) هو بروتوكول طبقة نقل [ 1 ] مصمم لحجز الموارد عبر الشبكة باستخدام نموذج الخدمات المتكاملة . يعمل RSVP عبر IPv4 أو IPv6، ويوفر إمكانية إعداد حجز الموارد من قِبل المُستقبِل لتدفقات البيانات متعددة البث أو أحادية البث . لا ينقل RSVP بيانات التطبيقات، ولكنه يُشبه بروتوكولات التحكم، مثل بروتوكول رسائل التحكم في الإنترنت (ICMP) أو بروتوكول إدارة مجموعات الإنترنت (IGMP). تم وصف RSVP في RFC 2205 ، ويحمل رقم بروتوكول الإنترنت 46. 

يمكن استخدام بروتوكول RSVP من قِبل المضيفين والموجهات لطلب أو توفير مستويات محددة من جودة الخدمة (QoS) لتدفقات بيانات التطبيقات . يحدد RSVP كيفية قيام التطبيقات بحجز الموارد وكيفية إلغائها عند انتهاء الحاجة إليها. تؤدي عمليات RSVP عمومًا إلى حجز الموارد في كل عقدة على طول المسار. لا يُعد RSVP بروتوكول توجيه، ولكنه صُمم ليتوافق مع بروتوكولات التوجيه الحالية والمستقبلية.

في عام 2003، تم تحويل جهود التطوير من بروتوكول RSVP إلى بروتوكول RSVP-TE لهندسة حركة الاتصالات . وكان بروتوكول Next Steps in Signaling (NSIS) بديلاً مقترحاً لبروتوكول RSVP.

السمات الرئيسية

  1. يطلب بروتوكول RSVP موارد لتدفقات أحادية الاتجاه : وهي عبارة عن تدفق بيانات في اتجاه واحد فقط من المرسل إلى واحد أو أكثر من المستلمين. [ 2 ]
  2. بروتوكول RSVP ليس بروتوكول توجيه ولكنه يعمل مع بروتوكولات التوجيه الحالية والمستقبلية.
  3. يُعتبر بروتوكول RSVP موجهاً نحو المتلقي بمعنى أن متلقي تدفق البيانات يبدأ ويحافظ على حجز الموارد لهذا التدفق.
  4. يحافظ بروتوكول RSVP على حالة مرنة (يحتاج الحجز في كل عقدة إلى تحديث دوري) لحجوزات موارد المضيف والموجهات، وبالتالي يدعم التكيف التلقائي الديناميكي مع تغييرات الشبكة.
  5. يوفر نظام RSVP عدة أنماط للحجز (مجموعة من خيارات الحجز) ويسمح بإضافة أنماط مستقبلية في مراجعات البروتوكول لتناسب التطبيقات المتنوعة.
  6. يقوم برنامج RSVP بنقل وصيانة معلمات التحكم في حركة المرور والسياسات التي تكون غير شفافة بالنسبة لبرنامج RSVP.

تم اقتراح المفاهيم الأساسية لـ RSVP في الأصل في عام 1993. [ 3 ]

تم وصف بروتوكول RSVP في سلسلة من وثائق RFC الصادرة عن IETF:

  • RFC 2205 : تم وصف المواصفات الوظيفية للإصدار الأول في RFC 2205 (سبتمبر 1997) من قِبل فريق هندسة الإنترنت (IETF ). يصف الإصدار الأول واجهة التحكم في الوصول (حركة البيانات) التي تعتمد "فقط" على توافر الموارد. وفي وقت لاحق ، وسّع RFC 2750 دعم التحكم في الوصول. 
  • تحدد RFC 2210 استخدام بروتوكول RSVP مع خدمات التحكم في جودة الخدمة (QoS) ذات الحمل المُتحكم به (RFC 2211) والمضمونة (RFC 2212). لمزيد من التفاصيل، راجع قسم الخدمات المتكاملة . كما تحدد RFC 2205 استخدام وتنسيق بيانات الكائنات (التي تحمل معلومات حجز الموارد) المُعرّفة بواسطة RSVP. 
  • يحدد RFC 2211 سلوك عنصر الشبكة المطلوب لتقديم خدمات الحمل المتحكم فيه. 
  • يحدد RFC 2212 سلوك عنصر الشبكة المطلوب لتقديم خدمات جودة الخدمة المضمونة. 
  • يصف RFC 2750 امتدادًا مقترحًا لدعم التحكم في القبول القائم على السياسات العامة في RSVP. يتضمن الامتداد مواصفات لكائنات السياسة ووصفًا لكيفية التعامل مع أحداث السياسة. (يناير 2000). 
  • RFC 3209 ، "RSVP-TE: ملحقات RSVP لأنفاق LSP" (ديسمبر 2001). 
  • RFC 3473 ، "امتدادات بروتوكول حجز موارد الإشارة لبروتوكول تبديل الملصقات متعدد البروتوكولات المعمم (GMPLS) - هندسة حركة المرور (RSVP-TE)" (يناير 2003). 
  • RFC 3936 ، " إجراءات تعديل بروتوكول حجز الموارد ( RSVP ) " ( أكتوبر 2004)، يصف أفضل الممارسات الحالية ويحدد إجراءات تعديل RSVP. 
  • RFC 4495 ، "امتداد بروتوكول حجز الموارد (RSVP) لتقليل عرض النطاق الترددي لتدفق الحجز" (مايو 2006)، يوسع RSVP لتمكين تقليل عرض النطاق الترددي للحجز الحالي بدلاً من إلغاء الحجز. 
  • RFC 4558 ، "بروتوكول حجز الموارد القائم على معرف العقدة (RSVP) Hello: بيان توضيحي" (يونيو 2006). 

المفاهيم الأساسية

المفهومان الرئيسيان لنموذج حجز RSVP هما flowspec و filterspec .

فلو سبيك

يحجز بروتوكول RSVP موارد لتدفق البيانات. يُعرَّف تدفق البيانات بعنوان الوجهة، ومعرّف البروتوكول، ومنفذ الوجهة (اختياريًا). في تقنية تحويل الملصقات متعددة البروتوكولات (MPLS)، يُعرَّف تدفق البيانات كمسار مُحوَّل الملصقات (LSP). لكل تدفق، يُحدِّد RSVP أيضًا جودة الخدمة (QoS) المطلوبة. تُسمى معلومات جودة الخدمة هذه " مواصفات التدفق" ، ويُمرِّرها RSVP من التطبيق إلى المضيفين والموجهات على طول المسار. تُحلِّل هذه الأنظمة مواصفات التدفق لقبول الموارد وحجزها. تتكون مواصفات التدفق من:

  1. فئة الخدمة
  2. مواصفات الحجز - تحدد جودة الخدمة
  3. مواصفات حركة البيانات - تصف تدفق البيانات

مواصفات المرشح

تحدد مواصفات التصفية مجموعة الحزم التي ستتأثر بمواصفات التدفق (أي حزم البيانات التي ستتلقى جودة الخدمة المحددة في مواصفات التدفق). وعادةً ما تختار مواصفات التصفية مجموعة فرعية من جميع الحزم التي تعالجها عقدة ما. ويمكن أن يعتمد هذا الاختيار على أي سمة من سمات الحزمة (مثل عنوان IP الخاص بالمرسل ومنفذه).

أنماط حجز RSVP المحددة حاليًا هي:

  1. فلتر ثابت - يحجز الموارد لتدفق محدد.
  2. مشاركة صريحة - تحجز الموارد لعدة تدفقات وتتشارك جميعها في هذه الموارد
  3. فلتر الأحرف البديلة - يحجز الموارد لنوع عام من التدفقات دون تحديد نوع التدفق؛ وتتشارك جميع التدفقات في هذه الموارد.

يتكون طلب حجز RSVP من مواصفات التدفق ومواصفات التصفية ، ويُطلق على هذا الزوج اسم واصف التدفق . تحدد مواصفات التدفق معلمات مُجدول الحزم في العقدة، بينما تحدد مواصفات التصفية المعلمات في مُصنف الحزم.

رسائل

يوجد نوعان رئيسيان من الرسائل:

  • رسائل المسار ( المسار )
يتم إرسال رسالة المسار من المضيف المرسل على طول مسار البيانات وتخزين حالة المسار في كل عقدة على طول المسار.
تتضمن حالة المسار عنوان IP الخاص بالعقدة السابقة، وبعض كائنات البيانات:
  1. قالب المرسل لوصف تنسيق بيانات المرسل في شكل Filterspec [ 4 ]
  2. يُستخدم مُرسِل tspec لوصف خصائص حركة البيانات.
  3. adspec الذي يحمل بيانات الإعلان (انظر RFC 2210 لمزيد من التفاصيل).
  • رسائل الحجز ( resv )
تُرسل رسالة الحجز من المُستقبِل إلى المُرسِل عبر مسار البيانات العكسي. عند كل عقدة، يتغير عنوان IP الوجهة لرسالة الحجز إلى عنوان العقدة التالية على المسار العكسي، ويتغير عنوان IP المصدر إلى عنوان العقدة السابقة على المسار العكسي.
تتضمن رسالة resv كائن بيانات flowspec الذي يحدد الموارد التي يحتاجها التدفق.

يمكن إرسال عناصر البيانات في رسائل تأكيد الحضور (RSVP) بأي ترتيب. للاطلاع على القائمة الكاملة لرسائل تأكيد الحضور وعناصر البيانات، راجع RFC 2205.

عملية

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

يرسل الراغبون في الاستماع إلى هذه الرسائل رسالة حجز ( resv )، والتي بدورها تتعقب المسار وصولاً إلى المرسل. تحتوي رسالة الحجز على مواصفات التدفق (flowspec ). كما تحتوي على كائن مواصفات التصفية (filterspec )؛ الذي يحدد الحزم التي ستتلقى جودة الخدمة المطلوبة والمحددة في مواصفات التدفق. يمكن أن تكون مواصفات التصفية البسيطة عنوان IP الخاص بالمرسل، بالإضافة إلى منفذ UDP أو TCP الخاص به (اختياريًا). عندما يستقبل جهاز التوجيه رسالة الحجز (resv) الخاصة ببروتوكول RSVP، فإنه يقوم بما يلي:

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

إذا لم يتم تلقي أي رد لفترة زمنية محددة، فسيتم إلغاء الحجز تلقائيًا. يحل هذا الإجراء المشكلة في حال تعطل جهاز الإرسال أو جهاز الاستقبال أو إيقاف تشغيلهما دون إلغاء الحجز مسبقًا.

ميزات أخرى

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

RFCs

مراجع

  1. ↑ غاريت، أڤيڤا؛ درينان، غاري؛ موريس، كريس (2002). دليل جونيبر نتوركس الميداني والمرجعي . أديسون-ويسلي بروفيشنال. ص 583. ISBN  9780321122445.
  2. ↑ "بروتوكول حجز الموارد في الأنظمة الآنية" . GeeksforGeeks . 2020-01-16 . تم الاطلاع عليه بتاريخ 2025-01-23 .
  3. ↑ تشانغ، ل.، ديرينغ، س.، إسترين، د.، شينكر، س.، وزابالا، د.، "RSVP: بروتوكول جديد لحجز الموارد"، شبكة IEEE، سبتمبر 1993
  4. ↑ ليكسيا، تشانغ؛ ستيف، بيرسون؛ شاي، هيرتسوغ؛ سوغيه، جامين (سبتمبر 1997). بروتوكول حجز الموارد (RSVP) - الإصدار 1: المواصفات الوظيفية . IETF . ص 19. doi : 10.17487/RFC2205 . RFC 2205 . 
  5. ↑ رسائل تشخيص RSVP . IETF . doi : 10.17487/RFC2745 . RFC 2745 .
  • جون إيفانز؛ كلارنس فيلسفيلز (2007). نشر بروتوكول الإنترنت (IP) وبروتوكول MPLS لجودة الخدمة في الشبكات متعددة الخدمات: النظرية والتطبيق . مورغان كوفمان. ISBN 978-0-12-370549-5.
  • بروتوكول حجز الموارد . سيسكو. مؤرشف من الأصل بتاريخ 2017-07-05 . تم الاطلاع عليه بتاريخ 2011-02-16 .
  • نافين جوي (17 يونيو 2002). "خدمة RSVP توفر جودة عالية" . عالم الشبكات . مؤرشف من الأصل بتاريخ 29 يونيو 2013. تم الاطلاع عليه بتاريخ 14 فبراير 2012 .
  • مشروع "RSVP" . معهد علوم المعلومات بجامعة جنوب كاليفورنيا. مؤرشف من الأصل بتاريخ 27-04-2017.