يشير مصطلح الخدمات المتكاملة أو اختصارًا IntServ، إلى مجموعةٍ من الأعمال التي أنتجتها منظمة IETF في الفترة ما بين عامي 1995-1997، حيث طوَّرت مجموعة عمل IntServ مواصفات عددٍ من فئات الخدمة المصمَّمة لتلبية احتياجات بعض أنواع التطبيقات الموضحة أعلاه، كما حددت كيفية استخدام بروتوكول RSVP لإجراء حجوزات باستخدام فئات الخدمة هذه، وستقدم الفقرات التالية لمحةً عامة عن هذه المواصفات والآليات المستخدَمة لتطبيقها.
فئات الخدمة
صُمِّمت إحدى فئات الخدمة من أجل التطبيقات غير المتسامحة، حيث تتطلب هذه التطبيقات عدم وصول الرزمة في وقتٍ متأخر أبدًا، ويجب أن تضمن الشبكة أن الحد الأقصى للتأخير الذي ستشهده أي رزمة له قيمةٌ محددة، كما يمكن للتطبيق بعد ذلك ضبط نقطة التشغيل الخاصة به، بحيث لا تصل أي رزمةٍ بعد وقت التشغيل. سنفترض أنه يمكن دائمًا معالجة الوصول المبكر للرزم عن طريق التخزين المؤقت، ويشار إلى هذه الخدمة باسم الخدمة المضمونة guaranteed service.
نظرت منظمة IETF في العديد من الخدمات الأخرى، بالإضافة إلى الخدمة المضمونة، لكنها استقرت في النهاية على خدمةٍ لتلبية احتياجات التطبيقات المتسامحة والتكيفية، والتي تُعرف باسم الحِمل المُتحكَّم به controlled load، وقد كان الدافع وراء ذلك هو ملاحظة أن التطبيقات الحالية من هذا النوع تعمل جيدًا على الشبكات غير المحمَّلة بصورةٍ كبيرة، وتعدّل تطبيقات الصوت على سبيل المثال نقطة التشغيل الخاصة بها، مع اختلاف تأخير الشبكة وتنتج جودة صوت معقولة طالما تبقى معدلات الفقد في حدود 10% أو أقل.
يُعَد الهدف من خدمة الحِمل المُتحكَّم به، هو محاكاة شبكةٍ محمَّلة بصورةٍ خفيفة لتلك التطبيقات التي تطلب الخدمة، على الرغم من أن كل الشبكة قد تكون في الواقع محمَّلة بصورةٍ كبيرة، وتتمثل الحيلة في ذلك في استخدام آلية أرتال مثل آلية WFQ لعزل حركة مرور الحِمل المتحكَّم به عن حركة المرور الأخرى، وأحد أشكال التحكم في القبول للحد من إجمالي حركة مرور الحِمل المُتحكَّم به على رابطٍ بحيث يظل الحِمل منخفضًا بصورةٍ معقولة. سنناقش التحكم في القبول admission control بمزيدٍ من التفاصيل أدناه.
من الواضح أن هاتين الفئتين من الخدمات تمثلان مجموعةً فرعيةً من جميع الأصناف التي قد يجري توفيرها، فقد حُدِّدت الخدمات الأخرى ولكنها لم تُوحَّد على أنها جزءٌ من عمل IETF، وقد أثبتت الخدمتان الموصوفتان أعلاه حتى الآن جنبًا إلى جنب مع خدمة أفضل جهد التقليدية أنهما مرنتان بما يكفي لتلبية احتياجات مجموعةٍ واسعة من التطبيقات.
نظرة عامة على الآليات
لقد عززنا الآن نموذج الخدمة الأفضل جهدًا لدينا مع بعض فئات الخدمة الجديدة، ولكن السؤال التالي هو كيف ننفذ شبكةً توفر هذه الخدمات للتطبيقات؟ يوضح هذا القسم الآليات الرئيسية، لهذا ضع في الحسبان أثناء قراءة هذا القسم أن الآليات الموصوفة لا تزال قيد التطوير بواسطة مجتمع تصميم الإنترنت، وأن الشيء الرئيسي الذي يجب استبعاده من المناقشة هو الفهم العام للأجزاء المتضمنة في دعم نموذج الخدمة الموضح أعلاه.
أولًا، يمكننا مع خدمة أفضل جهد فقط، إخبار الشبكة بالمكان الذي نريد أن تذهب إليه رزمنا ونتركها عند هذا الحد، ولكن الخدمة في الوقت الحقيقي ستتضمن إخبار الشبكة بشيءٍ أكثر عن نوع الخدمة التي نطلبها، فقد نعطيها معلوماتٍ نوعية مثل "استخدام خدمة حِملٍ متحكَّمٍ به"، أو معلوماتٍ كمية مثل "أحتاج إلى تأخير 100 ميلي ثانية بحدٍ أقصى"، وسنحتاج إلى إخبار الشبكة بشيءٍ حول ما سنحقنه فيها، بالإضافة إلى وصف ما نريده، نظرًا لأن تطبيق حيز النطاق التراسلي المنخفض سيتطلب موارد شبكةٍ أقل من تطبيق حيز النطاق التراسلي العالي. يُشار إلى مجموعة المعلومات التي نقدمها للشبكة باسم flowspec، ويأتي هذا الاسم من تسمية مجموعة الرزم المرتبطة بتطبيقٍ واحد، والتي تشترك في المتطلبات المشتركة باسم التدفق flow.
وفي خطوة ثانية، يجب أن تقرر الشبكة ما إذا كان يمكنها في الواقع تقديم خدمةٍ معينة عندما نطلب من الشبكة تزويدنا بها، فإذا طلب 10 مستخدمين على سبيل المثال خدمةً يستخدم فيها كل منهم 2 ميجابت في الثانية من سعة الرابط باستمرار وكلهم يشتركون في رابطٍ بسعة 10 ميجابت في الثانية؛ فسيتعين على الشبكة أن تقول لا لبعضهم، و تسمى عملية تحديد الوقت المناسب لقول "لا" بالتحكم بالقبول admission control.
سنحتاج في الخطوة الثالثة إلى آليةٍ يتبادل من خلالها مستخدمو الشبكة ومكونات الشبكة نفسها المعلومات، مثل طلبات الخدمة وflowpecs وقرارات التحكم في القبول؛ ويسمى ذلك أحيانًا بإصدار إشارات signalling، ولكن نظرًا لأن هذه الكلمة لها عدة معانٍ، فإننا سنشير إلى هذه العملية على أنها حجز للموارد resource reservation، حيث تُحقَّق باستخدام بروتوكول حجز الموارد.
أخيرًا، ستحتاج مبدلات وموجّهات الشبكة إلى تلبية متطلبات التدفقات عند وصف التدفقات ومتطلباتها، واتخاذ قرارات التحكم في القبول. ويتمثل جزءٌ أساسي من تلبية هذه المتطلبات، في إدارة طريقة وضع الرزم في الرتل وجدولتها للإرسال في المبدلات والموجهات، وتُسمَّى هذه الآلية الأخيرة بجدولة الرزم packet scheduling.
معلومات Flowspecs
يمكن فصل flowspec إلى قسمين، بحيث يصف القسم الأول خصائص حركة التدفق ويُسمى TSpec، والقسم الآخر هو الذي يصف الخدمة المطلوبة من الشبكة RSpec، وهي خدمةٌ محددةٌ للغاية ويسهل وصفها نسبيًا، حيث تُعَد RSpec بسيطةً وبديهيةً مع خدمة الحِمل المُتحكَّم به، إذ يطلب التطبيق خدمة حِمل متحكم به فقط دون معلاملاتٍ إضافية، ويمكنك هنا تحديد هدف أو حد تأخير مع خدمةٍ مضمونة. وبطبيعة الحال لن نحدّد التأخير في مواصفات الخدمة المضمونة لمنظمة IETF، بل كميةً أخرى يمكن من خلالها حساب التأخير.
أما TSpec فهي أعقد بعض الشيء، حيث سنحتاجُ إلى تزويد الشبكة بمعلوماتٍ كافيةٍ حول حيز النطاق التراسلي الذي يستخدمه التدفق من أجل السماح باتخاذ قراراتٍ ذكية للتحكم في القبول، علمًا أن حيز النطاق التراسلي ليس رقمًا واحدًا بالنسبة لمعظم التطبيقات، فهو شيءٌ يتغير باستمرار، حيث يولّد تطبيق الفيديو على سبيل المثال المزيد من البتات في الثانية عندما يتغير المشهد بسرعةٍ أكبر مما كان عليه. إن مجرد معرفة متوسط حيز النطاق التراسلي طويل المدى لا يُعَد كافيًا كما يوضح المثال التالي: افترض أن لدينا 10 تدفقات تصل إلى مبدلٍ على منافذ إدخال منفصلة، وأن جميعها متصلة على نفس الرابط ذو 10 ميجابت في الثانية، وبفرض أنه من المتوقع ألا يرسل كل تدفقٍ أكثر من 1 ميجابت في الثانية خلال فاصلٍ زمني طويل مناسب. قد تعتقد أن هذا لا يمثل مشكلة، ولكن إذا كانت هذه تطبيقاتٌ ذات معدل بت متغير مثل الفيديو المضغوط، فإنها ترسل أحيانًا أكثر من متوسط معدلاتها، فإذا أرسلت مصادرٌ كافية بمعدلاتٍ أعلى من المتوسط، فإن المعدل الإجمالي الذي تصل به البيانات إلى المبدل سيكون أكبر من 10 ميجابت في الثانية. ستُوضَع هذه البيانات الزائدة في رتلٍ قبل إرسالها على الرابط، وسيطول الرتل كلما طالت هذه الحالة. قد يتعين إسقاط الرزم، وحتى إن لم يحدث ذلك، فستتأخر البيانات الموجودة في الرتل؛ وإذا تأخرت الرزم لفترةٍ كافية، فلن تُوفَّر الخدمة المطلوبة.
سنناقش فيما يلي كيفية إدارة الأرتال تمامًا للتحكم في التأخير وتجنب إسقاط الرزم. لاحظ هنا أننا بحاجة إلى معرفة شيءٍ ما حول كيفية اختلاف حيز نطاق المصادر التراسلي مع مرور الوقت، حيث يُطلق على إحدى الطرق لوصف خصائص حيز نطاق المصادر التراسلي؛ اسم مرشح حاوية الرمز المميز token bucket filter. يُوصَف هذا المرشح بواسطة معاملين، هما معدل الرمز token rate وهو r، وعمق الحاوية bucket depth وهو B، حيث يعمل هذا المرشح على النحو التالي: يجب أن يكون لديك رمزٌ مميز لكي تتمكن من إرسال بايت، ونحتاج إلى n رمز مميز لإرسال رزمة بطول n، وستبدأ بدون رموزٍ مميزة وتُراكِمها بمعدل r في الثانية، ولا يمكنك تجميع أكثر من B رمزٍ مميز، وهذا يعني أنه يمكنك إرسال رشقةٍ تصل إلى بايتٍ في الشبكة بأسرع ما تريد، ولكن لا يمكنك إرسال أكثر من r بايت في الثانية خلال فترةٍ زمنيةٍ طويلة بما فيه الكفاية. اتضح أن هذه المعلومات مفيدة جدًا لخوارزمية التحكم في القبول عندما تحاول معرفة ما إذا كان يمكنها استيعاب طلبٍ جديد للخدمة.
يوضح الشكل السابق كيفية استخدام حاوية الرمز المميز لتوصيف متطلبات حيز نطاق التدفق التراسلي. افترض للتبسيط أن كل تدفقٍ يمكنه إرسال البيانات على هيئة بايتاتٍ فردية وليس رزمًا، حيث يولّد التدفق A البيانات بمعدلٍ ثابت يبلغ 1 ميجابايت في الثانية، لذلك يمكن وصفها بواسطة مرشح حاوية الرمز المميز بمعدلٍ r يساوي 1 ميجابايت في الثانية وعمق حاوية يبلغ 1 بايت، وهذا يعني أنه يتلقى الرموز بمعدل 1 ميجابايت في الثانية، ولكن لا يمكنه تخزين أكثر من رمزٍ واحد، فهو يستهلكها على الفور.
يرسل التدفق B أيضًا بمعدلٍ يبلغ متوسطه 1 ميجابايت في الثانية على المدى الطويل، ولكنه يفعل ذلك بإرسال 0.5 ميجابايت في الثانية لمدة ثانيتين، ثم بسرعة 2 ميجابايت في الثانية لمدة ثانية واحدة. يمكن وصف التدفق B بواسطة حاوية رموز بمعدل 1 ميجابايت في الثانية، نظرًا لأن معدل حاوية الرمز المميز r هو متوسط المعدل طويل الأجل، ولكن يحتاج التدفق B على عكس التدفق A إلى عمق حاويةٍ B لا يقل عن 1 ميجابايت، بحيث يمكن للتدفق B تخزين الرموز المميزة عندما يرسل بسرعةٍ أقل من 1 ميجابايت في الثانية لاستخدامها عند الإرسال بسرعة 2 ميجابايت في الثانية. يتلقى التدفق B الرموز بمعدل 1 ميجابايت في الثانية لأول ثانيتين في هذا المثال، ولكنه يستهلكها عند 0.5 ميجابايت في الثانية فقط، لذلك يمكنه توفير ما يصل إلى 2 × 0.5 = 1 ميجابايت من الرموز، والتي يستهلكها بعد ذلك في الثانية الثالثة مع الرموز الجديدة التي تستمر في التراكم في تلك الثانية لإرسال البيانات بسرعة 2 ميجابايت في الثانية. يبدأ التدفق B في حفظ الرموز المميزة مجددًا بإرسال 0.5 ميجابايت في الثانية مرةً أخرى في نهاية الثانية الثالثة بعد إنفاق الرموز المميزة الزائدة.
من المثير للاهتمام ملاحظة أنه يمكن وصف التدفق المنفرد بواسطة العديد من مجموعات الرموز المختلفة، حيث يمكن بمثالٍ بسيط وصف التدفق A بنفس حاوية الرموز المميزة للتدفق B، وبمعدل 1 ميجابايت في الثانية وعمق حاوية 1 ميجابايت. ليست حقيقة أن التدفق A لا يحتاج فعليًا إلى تجميع الرموز المميزة وصفًا خاطئًا، ولكنه يعني أننا فشلنا في نقل بعض المعلومات المفيدة إلى الشبكة، فالتدفق A متناسبٌ للغاية مع احتياجات حيز النطاق التراسلي، ولذلك من الجيد أن نكون صريحين بشأن احتياجات حيز النطاق التراسلي لتطبيقٍ ما قدر الإمكان لتجنب الإفراط في تخصيص الموارد في الشبكة.
التحكم في القبول
تُعَد الفكرة وراء التحكم في القبول بسيطة، فعندما يريد التدفق الجديد تلّقي مستوىً معين من الخدمة، فسينظر التحكم في القبول إلى TSpec وRSpec للتدفق، ويحاول تحديد ما إذا كان يمكن توفير الخدمة المطلوبة لهذا المقدار من حركة المرور بالموارد المتاحة حاليًا، وذلك دون التسبب في تلّقي أي تدفق مقبولٍ مسبقًا لخدمةٍ أسوأ مما قد طلب، فإذا كان بإمكانه تقديم الخدمة فيُقبَل التدفق، وإذا لم يكن كذلك فسيُرفَض، والجزء الصعب هنا هو معرفة متى تقول نعم ومتى تقول لا.
يعتمد التحكم في القبول كثيرًا على نوع الخدمة المطلوبة، وعلى نظام الرتل المُستخدَم في الموجّهات، كما سنناقش الموضوع الأخير لاحقًا في هذا القسم، حيث يجب أن تكون لديك خوارزميةٌ جيدةٌ لاتخاذ قرارٍ نهائي بنعم أو لا، وذلك للحصول على خدمةٍ مضمونة. يكون القرار واضحًا إلى حدٍ ما عند استخدام رتلٍ عادلٍ وموزون في كل موجّه، وقد يعتمد على الاستدلال heuristics بالنسبة لخدمة الحِمل المُتحكم به، مثل "في آخر مرة سمحتَ فيها بالتدفق باستخدام TSpec إلى هذه الفئة، تجاوزت التأخيراتُ الخاصة بالفئة الحدَّ المقبول، لذلك من الأفضل أن تقول لا"، أو "تأخيراتيك الحالية هي حتى الآن ضمن الحد بحيث يجب أن تكون قادرًا على قبول تدفقٍ آخر دون صعوبة".
لا ينبغي الخلط بين التحكم في القبول ووضع السياسات policing، فالتحكم في القبول هو قرارٌ لقبول تدفقٍ جديد أم لا، أما السياسة فهي وظيفة مُطبَّقة على أساس كل رزمةٍ للتأكد من أن التدفق يتوافق مع TSpec المُستخدَم لإجراء الحجز، فإذا لم يتوافق التدفق مع TSpec الخاص به على سبيل المثال لأنه يرسل ضعف عدد البايتات في الثانية، فمن المحتمل أن يتداخل مع الخدمة المقدَّمة للتدفقات الأخرى، ولا بد هنا من اتخاذ بعض الإجراءات التصحيحية. هناك العديد من الخيارات والخيار الواضح هو إسقاط الرزم المخالفة، بينما يتمثّل الخيار الآخر في التحقق من تداخل الرزم فعليًا مع خدمة التدفقات الأخرى؛ فإذا لم تتداخل، فيمكن إرسال الرزم بعد تمييزها بعلامة تقول "هذه رزمة غير متوافقة، أسقطها أولًا إذا كنت بحاجة إلى إسقاط أي رزم".
يرتبط التحكم في القبول ارتباطًا وثيقًا بأمرٍ مهم هو السياسة policy، فقد يرغب مسؤول الشبكة على سبيل المثال في السماح بقبول الحجوزات التي أجراها الرئيس التنفيذي لشركته، مع رفض الحجوزات التي أجراها الموظفون الأقل شأنًا، وقد يستمر فشل طلب الحجز المقدّم من الرئيس التنفيذي في حالة عدم توفُّر الموارد المطلوبة، لذلك نرى أنه يمكن معالجة مشكلات السياسة وتوافر الموارد عند اتخاذ قرارات التحكم في القبول. ويُعَد تطبيق السياسة على الشبكات مجالًا يحظى باهتمامٍ كبير في وقت كتابة هذا الكتاب -بنسخته الأصلية-.
بروتوكول الحجز
لقد احتاجت الشبكات الموجَّهة بالاتصال دائمًا إلى نوعٍ من بروتوكول الإعداد لإنشاء حالة الدارة الافتراضية الضرورية في المبدلات، ولكن لا تملك الشبكات عديمة الاتصال connectionless مثل شبكة الإنترنت هكذا بروتوكولات، ومع ذلك نحتاج إلى توفير الكثير من المعلومات لشبكتنا عندما نريد منها خدمةً في الوقت الحقيقي. توجد عدة بروتوكولات إعداد مقترحةٍ للإنترنت، ولكن البروتوكول الذي يركّز عليه معظم الاهتمام الحالي؛ هو بروتوكول RSVP؛ الذي يختلف اختلافًا كبيرًا عن بروتوكولات إصدار الإشارات signalling التقليدية للشبكات الموجّهة بالاتصال.
أحد الافتراضات الرئيسية الكامنة وراء بروتوكول RSVP هو أنه لا ينبغي أن ينتقص من المتانة التي نجدها في الشبكات عديمة الاتصال اليوم. تعتمد الشبكات عديمة الاتصال على حالةٍ قليلة أو معدومة مُخزَّنة في الشبكة نفسها، وبالتالي من الممكن أن تتعطل الموجّهات ويعاد تشغيلها، بحيث ترتفع الروابط لأعلى ولأسفل مع استمرار الاتصال من طرفٍ إلى طرف. سيحاول بروتوكول RSVP الحفاظ على هذه المتانة باستخدام فكرة الحالة اللينة soft state في الموجّهات، حيث لا تحتاج الحالة اللينة على عكس الحالة الصلبة hard state الموجودة في الشبكات الموجَّهة بالاتصال إلى حذفها صراحةً عند عدم وجود حاجةٍ إليها، وبدلًا من ذلك تنتهي مهلتها بعد فترةٍ قصيرة إلى حدٍ ما بحدود دقيقة واحدة مثلًا، عند عدم تحديثها دوريًا.
من خصائص بروتوكول RSVP المهمة الأخرى، هي أنه يهدف إلى دعم تدفقات البث المتعدد بنفس فعالية تدفقات البث الأحادي، وهذا ليس مفاجئًا، لأن العديد من التطبيقات الأولى التي قد تستفيد من جودة الخدمة المحسّنة قد كانت أيضًا تطبيقات متعددة البث مثل أدوات مؤتمرات الفيديو. تتمثل إحدى الأفكار الثاقبة لمصممي بروتوكول RSVP في أن معظم تطبيقات البث المتعدد لديها مستقبلين أكثر بكثير من المرسلين، مثل وجود جمهورٍ كبير ومتحدثٍ واحد في المحاضرة، وقد تكون للمستقبلين أيضًا متطلبات مختلفة؛ فقد يرغب أحد المستقبلين في تلقي البيانات من مرسلٍ واحد فقط على سبيل المثال، في حين قد يرغب الآخرون في تّلقي البيانات من جميع المرسلين. من المنطقي السماح للمستقبِلين بتتبع احتياجاتهم الخاصة بدلًا من جعل المرسلين يتتبعون عددًا كبيرًا محتملًا من المستقبلين، وهذا يشير إلى النهج الموجَّه بالمستقبِل الذي يعتمده بروتوكول RSVP.
تترك الشبكات الموجَّهة بالاتصال أمورَ حجزَ الموارد للمرسل، تمامًا كما هو الحال عندما يتسبب منشئ مكالمةٍ هاتفية في تخصيص الموارد في شبكة الهاتف. وتعطي الحالة اللينة والطبيعة الموجَّهة بالمستقبل لبروتوكول RSVP عددًا من الخصائص الجيدة، حيث تتمثل إحدى هذه الخصائص في أنه من السهل جدًا زيادة أو تقليل مستوى تخصيص الموارد المقدَّم إلى المستقبِل، وبما أن كل مستقبِل يرسل رسائل تحديثٍ دوريًا للحفاظ على الحالة اللينة في مكانها؛ فمن السهل إرسال حجزٍ جديد يطلب مستوىً جديدًا من الموارد. ستتعامل الحالة اللينة بتسامحٍ مع إمكانية فشل الشبكة أو العقدة، حيث سينهي المضيف في حالة تعطله مهلة الموارد المخصصة للتدفق بصورةٍ طبيعية ثم يحرَّرها.
نحتاج إلى إلقاء نظرةٍ عن كثب على آليات إجراء الحجز، لمعرفة ما يحدث في حالة فشل الموجّه أو الرابط، لهذا ضع في حساباتك في البداية حالة مرسلٍ ومستقبلٍ يحاولان الحصول على حجزٍ لحركة المرور المتدفقة بينهما، إذ هناك شيئان يجب حدوثهما قبل أن يتمكن المستقبِل من إجراء الحجز، وهما:
- يحتاج المستقبل إلى معرفة حركة المرور التي من المحتمل أن يرسلها المرسل حتى يتمكن من إجراء الحجز المناسب، أي أنه بحاجةٍ إلى معرفة TSpec المرسل.
- يحتاج المستقبل إلى معرفة المسار الذي ستتبعه الرزم من المرسل إلى المستقبل حتى يتمكن من إنشاء حجز موردٍ في كل موجهٍ على المسار.
يمكن تلبية هذين المطلبين عن طريق إرسال رسالةٍ من المرسل إلى المستقبل تحتوي على TSpec، وبالتالي سيعرف المستقبل TSpec. الشيء الآخر الذي سيحدث هو أن كل موجّهٍ ينظر إلى هذه الرسالة التي تُسمى PATH أثناء مرورها، ويحدد المسار العكسي الذي سيُستخدَم لإرسال الحجوزات من المستقبل إلى المرسل، في محاولةٍ لإعطاء الحجز لكل موجّهٍ على المسار. تُبنى شجرة الإرسال المتعدد في المقام الأول من خلال آليات مثل تلك الموضحة سابقًا في فصلٍ آخر.
يرسِل المستقبل حجزًا احتياطيًا لشجرة الإرسال المتعدد في رسالة RESV بعد تلقي رسالة PATH، حيث تحتوي هذه الرسالة على TSpec للمرسل، وRSpec الذي يصف متطلبات هذا المستقبل. وينظر كل موجّهٍ على المسار في طلب الحجز ويحاول تخصيص الموارد اللازمة لتلبية ذلك، فإذا كان من الممكن إجراء الحجز، فسيُمرَّر طلب RESV إلى الموجه التالي، وإذا لم يكن الأمر كذلك، فستُرجَع رسالة خطأ إلى المستقبل الذي قدم الطلب، فإذا سارت الأمور على ما يرام، فسيثبَّت الحجز الصحيح في كل موجهٍ بين المرسل والمستقبل، وطالما أن المستقبل يريد الاحتفاظ بالحجز، فإنه يرسل نفس رسالة RESV مرةً واحدة كل 30 ثانية.
يمكننا الآن رؤية ما يحدث عند فشل الموجّه أو الرابط، حيث تتكيف بروتوكولات التوجيه مع الفشل وتنشئ مسارًا جديدًا من المرسل إلى المستقبل، وتُرسَل رسائل PATH كل 30 ثانية تقريبًا، كما قد تُرسَل في وقتٍ أقرب إذا اكتشف الموجّه تغييرًا في جدول التمرير الخاص به، وبالتالي ستصل الرسالة الأولى بعد استقرار المسار الجديد إلى المستقبل عبر المسار الجديد. ستتبع رسالة RESV التالية للمستقبل المسارَ الجديد، وإذا سارت الأمور على ما يرام، فأنشِئ حجزًا جديدًا على المسار الجديد؛ وفي الوقت نفسه ستتوقف الموجّهات التي لم تعد على المسار عن تلقي رسائل RESV، وستنتهي مهلة هذه الحجوزات وستُحرَّر. وبالنتيجة سيتعامل بروتوكول RSVP جيدًا مع التغييرات في مخطط الشبكة، طالما أن تغييرات التوجيه ليست متكررة كثيرًا.
الشيء التالي الذي نحتاج إلى مراعاته هو كيفية التعامل مع البث المتعدد multicast، حيث قد يكون هناك عدة مرسلين إلى مجموعة مستقبلين ومستقبلين متعددين، وهذا الموقف موضحٌ في الشكل السابق. دعنا أولًا نتعامل مع مستقبلين متعددين لمرسلٍ واحد، فعندما تنتقل رسالة RESV إلى أعلى شجرة الإرسال المتعدد من المحتمل أن تصطدم بجزءٍ من الشجرة حيثما أُنشئ بالفعل حجزٌ لبعض المستقبلين الآخرين، ولكن قد تكون الموارد المحجوزة في أعلى هذه النقطة كافيةً لخدمة كلا المستقبلين، وإذا أجرى المستقبل A حجزًا يوفّر تأخيرًا مضمونًا بأقل من 100 ميلي ثانية فعليًا، وكان الطلب الجديد من المستقبل B بتأخيرٍ أقل من 200 ميلي ثانية؛ فلا حاجة لحجزٍ جديد. وإذا كان الطلب الجديد يتعلق بتأخيرٍ أقل من 50 ميلي ثانية، فسيحتاج الموجّه أولًا إلى معرفة ما إذا كان يمكنه قبول الطلب؛ أما إذا كان الأمر كذلك فسيُرسَل الطلب إلى الأعلى. لن يحتاج الموجّه إلى تمرير هذا الطلب في المرة التالية التي يطلب فيها المستقبل A تأخيرًا لا يقل عن 100 ميلي ثانية. ويمكن عمومًا دمج الحجوزات بهذه الطريقة لتلبية احتياجات جميع المستقبلين في أدنى نقطة الدمج.
إذا كان هناك أيضًا عدة مرسلين في الشجرة، فيجب على المستقبلين جمع TSpecs من جميع المرسلين وإجراء حجزٍ كبير بما يكفي لاستيعاب حركة المرور من جميع المرسلين، ولكن قد لا يعني هذا أن هناك حاجةً إلى إضافة TSpecs؛ فعلى سبيل المثال ليست هناك فائدةٌ كبيرةٌ في تخصيص موارد كافية لنقل 10 تدفقات صوتية في مؤتمرٍ صوتي مع 10 مكبرات صوت، وذلك نظرًا لأن نتيجة تحدُّث 10 أشخاص في وقتٍ واحد ستكون غير مفهومة، وبالتالي يمكننا أن نتخيل حجزًا كبيرًا بما يكفي لاستيعاب متحدثَين اثنين وليس أكثر من ذلك. إن حساب TSpec الإجمالي الصحيح من كل TSpecs الخاصة بالمرسلين أمرٌ خاصٌ بالتطبيق، فقد نكون مهتمين فقط بالاستماع إلى مجموعةٍ فرعية من جميع المتحدثين المحتملين، بحيث يحتوي بروتوكول RSVP على أنماط حجزٍ مختلفة للتعامل مع خياراتٍ مثل "حجز الموارد لجميع المتحدثين" و"حجز الموارد لأي n متحدث " و"احتفظ بالموارد للمتحدثَين A وB فقط".
تصنيف الرزم وجدولتها
بعد وصف حركة المرور الخاصة بنا وخدمة الشبكة المطلوبة لدينا، وتثبيت حجزٍ مناسب على جميع الموجّهات على المسار؛ فإن الشيء الوحيد المتبقي هو أن تسلّم الموجّهات فعليًا الخدمة المطلوبة إلى رزم البيانات. وهناك شيئان يجب فعلهما:
- ربط كل رزمةٍ بالحجز المناسب حتى يمكن التعامل معها بصورةٍ صحيحة، وهي عملية تُعرف باسم تصنيف الرزم.
- إدارة الرزم في الأرتال بحيث يتلقون الخدمة المطلوبة، وهي عملية تُعرف باسم جدولة الرزم.
يُنفَّذ الجزء الأول من خلال فحص ما يصل إلى خمسة حقول في الرزمة، هي عنوان المصدر source address، وعنوان الوجهة destination address، ورقم البروتوكول protocol number، ومنفذ المصدر source port، ومنفذ الوجهة destination port. يمكن استخدام حقل FlowLabel في ترويسة IPv6 لتفعيل البحث بناءً على مفتاحٍ واحدٍ أقصر، كما يمكن وضع الرزمة بناءً على هذه المعلومات في الصنف المناسب، حيث يمكن تصنيفها في أصناف الحِمل المُتحكَّم به على سبيل المثال، أو قد تكون جزءًا من تدفقٍ مضمون يحتاج إلى التعامل معه بصورةٍ منفصلةٍ عن جميع التدفقات المضمونة الأخرى. هناك ربطٌ mapping من المعلومات الخاصة بالتدفق في ترويسة الرزمة مع معرّف صنفٍ واحد يحدد كيفية معاملة الرزمة في الرتل، وقد يكون هذا ربطًا واحدًا لواحد one-to-one mapping بالنسبة للتدفقات المضمونة، بينما بالنسبة للخدمات الأخرى، فقد يكون متعددًا لواحد many to one. ترتبط تفاصيل التصنيف ارتباطًا وثيقًا بتفاصيل إدارة الأرتال.
يجب أن يكون واضحًا أن شيئًا بسيطًا مثل رتل FIFO في الموجّه لن يكون مناسبًا لتوفير العديد من الخدمات المختلفة ومستوياتٍ مختلفة من التأخير داخل كل خدمة، وقد نوقشت العديد من تخصصات إدارة الرتل الأكثرتعقيدًا في قسمٍ سابق، ومن المحتمل استخدام مزيجٍ منها في الموجّه.
لا ينبغي تحديد تفاصيل جدولة الرزم بصورةٍ مثالية في نموذج الخدمة، فهذا مجالٌ يمكن أن يحاول فيه المنفِّذون فعل أشياء إبداعية لتحقيق نموذج الخدمة بكفاءة، فقد ثبُت أن نظام أرتال عادلٍ موزون في حالة الخدمة المضمونة، والذي يحصل فيه كل تدفقٍ على رتلٍ فردي خاصٍ به مع حصةٍ معينة من الرابط؛ سيوفر حد تأخيرٍ مضمون من طرفٍ إلى طرف يمكن حسابه بسهولة. ويمكن استخدام مخططاتٍ أبسط للحِمل المتحكَّم به، كما سيشمل أحد الاحتمالات معالجة كل حركة مرور حِملٍ متحكَّمٍ به على أنها تدفقٌ واحد مجمَّع مع الاهتمام بآلية الجدولة، وتحديد وزن هذا التدفق بناءً على الحجم الإجمالي لحركة المرور المقبولة في صنف الحِمل المتحكَّم به. تزداد المشكلة صعوبةً عند التفكير في احتمالية توفير العديد من الخدمات المختلفة بصورةٍ متزامنة في موجهٍ واحد، وكل خدمةٍ من هذه الخدمات قد تتطلب خوارزمية جدولةٍ مختلفة، وبالتالي هناك حاجةٌ إلى خوارزمية إدارة رتلٍ شاملة لإدارة الموارد بين الخدمات المختلفة.
مشاكل قابلية التوسع
على الرغم من أن معمارية الخدمات المتكاملة وبروتوكول RSVP يمثلان تحسينًا كبيرًا لنموذج خدمة أفضل جهد لبروتوكول IP، إلا أن العديد من مزودي خدمة الإنترنت شعروا أنه لم يكن النموذج المناسب للنشر، ويرجع سبب هذا التحفُّظ إلى أحد أهداف التصميم الأساسية للملكية الفكرية، وهو قابلية التوسع scalability. تخزّن الموجهات في الإنترنت في نموذج الخدمة الأفضل جهدًا حالةً قليلةً أو معدومةً بشأن التدفقات الفردية التي تمر عبرها، وبالتالي مع نمو الإنترنت، فإن الشيء الوحيد الذي يتعين على الموجّهات فعله لمواكبة هذا النمو هو نقل المزيد من البتات في الثانية، والتعامل مع جداول التوجيه الأكبر حجمًا، ولكن بروتوكول RSVP يثير احتمالًا بأن يكون لكل تدفقٍ يمر عبر موجهٍ حجزًا مقابلًا لهذا التدفق. لفهم مدى خطورة هذه المشكلة، افترض أن كل تدفق على رابط OC-48 أو 2.5 جيجابت في الثانية، سيمثل تدفقًا صوتيًا بسرعة 64 كيلوبت في الثانية، حيث أن عدد هذه التدفقات يساوي:
2.5 × 109 / 64 × 103 = 39,000
يحتاج كلٌّ من هذه الحجوزات إلى قدرٍ من الحالة التي يجب تخزينها في الذاكرة وتحديثها دوريًا، ويحتاج الموجه إلى تصنيف كلٍّ من هذه التدفقات ووضع سياسات عليها، ووضعها ضمن رتل، حيث يجب اتخاذ قرارات التحكم في القبول في كل مرةٍ يطلب فيها هذا التدفق حجزًا، وهناك حاجةٌ إلى بعض الآليات "للرد push back" على المستخدمين، مثل فرض رسوم على بطاقات الائتمان الخاصة بهم، بحيث لا يجرون حجوزاتٍ كبيرة عشوائيًا لفتراتٍ زمنية طويلة.
لقد أدت مخاوف قابلية التوسع هذه إلى الحد من انتشار IntServ على نطاقٍ واسع، لذلك طُوِّرت مناهجٌ أخرى لا تتطلب الكثير من الحالات "لكل تدفق"، وسيناقش المقال التالي عددًا من هذه الأساليب.
ترجمة -وبتصرّف- للقسم Quality of Service من فصل Congestion Control من كتاب Computer Networks: A Systems Approach.
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.