الدارة المضمونة بدأت برسالة بلا ضمان

الخلاصة

• أوصت RFC 2379 بأن تنتقل رسائل تحكم RSVP عبر مسار البيانات القائم بنمط أفضل جهد، حتى حين يكون الغرض منها إنشاء دارات ATM افتراضية منفصلة ذات معايير صريحة لجودة الخدمة.
• الرسالة PATH أو RESV، وحالة RSVP، وقرار القبول، والدارة المهيأة، والأداء المرصود إيصالات متتابعة؛ لا يثبت واحد منها السلسلة كلها.

طلب الضمان عبر طريق لا يَعِد به

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

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

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

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

لكل حجز دارة مستقلة

كان جمع جلسات RSVP متعددة على دارة واحدة ممكناً من حيث المبدأ، وقد يوفر موارد ATM. لكن التجميع ظل موضوعاً بحثياً. لذلك أوصت RFC 2379 بدارة افتراضية مستقلة لكل حجز RSVP.

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

وزعت الوثائق المصاحبة الوظائف عمداً. حددت RFC 2380 متطلبات التنفيذ؛ وربطت RFC 2381 خدمتي controlled-load وguaranteed في Integrated Services بقدرات ATM؛ وقدمت RFC 2382 الإطار الأشمل. هذا التقسيم يمنع إشارة ناجحة واحدة من تمثيل نجاح كل المراحل.

الاختصار يرث نقطة النهاية

كان اختصار ATM يستطيع تجاوز حدود شبكات IP المنطقية، فتتخذ رسائل PATH وRESV مسارات غير متناظرة. اعتمدت RFC 2379 على سلوك RSVP القائم—كائن NHOP وتمرير الرسائل التي وصلت إلى واجهة غير صحيحة—لاستيعاب هذا اللاتناظر.

أما القاعدة الأهم فتتعلق بسلطة اختيار النهاية. لا ينبغي لاختصار QoS أن يكتشف وجهته بصورة مستقلة. إذا كان مرور أفضل جهد قد اختار نقطة نهاية لاختصار، وجب أن تستخدم دارة QoS التي يطلقها RSVP النقطة نفسها. وبموجب النموذج الموصى به، إذا لم ينشأ اختصار أفضل جهد فلن ينشأ اختصار QoS عابر للشبكات أيضاً.

لم يمنع ذلك دارات QoS قفزة بعد قفزة. كان القيد على أصل قرار النهاية: سياق التوجيه العادي يختار أولاً، ثم يتبعه بناء QoS. الدارة الناتجة دليل على تهيئة، لا برهان رجعي على نجاح الاكتشاف أو القبول أو التسليم.

لم يكن للبث المتعدد قالب واحد

في جلسة بث متعدد يمكن لمستقبلين مختلفين طلب مستويات QoS مختلفة، ويمكن لآخرين ألا يطلبوا شيئاً. وصف الإطار المصاحب نماذج غير متجانسة بالكامل، ومحدودة التباين، ومتجانسة، ومتجانسة معدلة. لم تعلن RFC 2379 نموذجاً صالحاً لكل حالة؛ بل طلبت دعماً للتباين المحدود أو التجانس المعدل على الأقل، وفضلت كليهما مع آلية للاختيار.

لهذا التحفظ قيمة تاريخية. لم تمحُ الممارسة الجيدة اختلاف التشغيل كي يصبح الرسم أبسط؛ بل وضعت حداً أدنى قابلاً للتنفيذ وأبقت اختلاف المستقبلين ظاهراً.

أربعة إيصالات منفصلة

تقتضي القراءة المنضبطة فصل أربعة سجلات: مسار أفضل جهد الذي حمل التحكم؛ حالة RSVP وتحديثاتها؛ نتيجة القبول ودارة ATM المهيأة؛ ثم العدادات ومشاهدات التطبيق التي تكشف الخدمة المستلمة.

إرسال PATH لا يثبت عودة RESV. وRESV لا يثبت القبول. والدارة الحية لا تثبت صحة التصنيف. وملصق QoS ليس قياساً للتأخير أو الفقد أو الوصول. ربطت البنية هذه الطبقات من دون أن تجعلها شيئاً واحداً.