الخلاصة

  • حسم BACP تعارض الطلبات المتزامنة، وفرض BAP استجابة قبل الفعل، ثم أبلغ Call-Status نتيجة محاولة الاتصال وخطة إعادة المحاولة.
  • أثبت Request-Ack أن الأمر صالح ومستلم، لا أن الخط قائم أو أن الرزم عبرته. وبسبب محولات ISDN التي تعترض التحكم، كان يجب أن يبقى مخطط BAP الكامل بلا ضغط ولا تشفير.

لم يبدأ RFC 2125 من افتراض أن الطرفين يقيسان الحمل بالطريقة نفسها. بدأ من سؤال أضيق: كيف يتعاون طرفان مستقلان حين يقرران تغيير عدد الخطوط في اللحظة نفسها؟

كان RFC 1990 قد عرّف حزمة Multilink وإعادة تركيب شظاياها. وأضاف RFC 2125 في مارس 1997 بروتوكولي BACP وBAP للتحكم في العضوية. وتحفظ سجلات RFC Editor وضعه القياسي، بينما تسجل IANA رقمي البروتوكولين.

الرقم الأصغر لا يمنح هوية

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

حل ذلك سباقا واحدا. لم يصادق هوية الطرف، ولم يقرر أن مقياسه للحمل أصح، ولم يمنحه ملكية الخط أو سلطة عامة على الحزمة.

قبول الطلب يسبق التنفيذ

يرسل الطرف Call-Request قبل أن ينشئ خطا، أو Callback-Request إذا أراد من ندّه أن يتصل. احتاج كل Request أو Indication إلى Response قبل الفعل. دل Request-Ack على أمر صالح مستلم؛ وRequest-Nak على رفض مؤقت؛ وRequest-Rej على عدم دعم؛ وRequest-Full-Nak على بلوغ حد أدنى أو أقصى متاح.

بعد كل محاولة اتصال، وجب إرسال Call-Status-Indication. حملت الرسالة نجاح المحاولة أو فشلها، وعند الفشل هل ستكون هناك إعادة. وكل إعادة احتاجت إلى نتيجة جديدة. استُخدم Identifier الطلب الأصلي لربط الإذن بالنتيجة مع إبقائهما سجلين مختلفين.

يتدرج الدليل إذن من BACP مفتوح، إلى فائز Favored-Peer، إلى Ack، إلى Call-Status، ثم إنشاء العضو أو إنهاؤه عبر LCP، ثم شظايا Multilink المرصودة، وأخيرا نتيجة التطبيق. لا يثبت الدرج الأدنى كل ما فوقه.

الانخفاض بسبب الاستخدام يختلف عن سحب مورد محلي

إذا نشأ إسقاط الخط من مراقبة الاستخدام، وجب إرسال Link-Drop-Query. يجيب الطرف الآخر بحسب ما يراقبه، ولا يعتمد على حركة الاستقبال وحدها. يبقى الخط ما دام أحد الطرفين المراقبين يراه ضروريا.

أما الحاجة المحلية إلى منفذ أو قناة B فتسمح بإرسال Terminate-Request من LCP مباشرة. ويمكن أن يصبح الإنهاء القسري إجراء استعادة بعد استنفاد إعادة المحاولة من دون رد. فصل RFC 2125 بين تحسين تعاوني وحيازة محلية لمورد مادي.

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

التوافق أبقى رسالة التحكم مكشوفة

كانت بعض محولات ISDN تدير Multilink نيابة عن عميل لا يفهمه. لكي تعترض الرسائل، منع RFC 2125 ضغط مخطط BAP الكامل أو تشفيره؛ وظل ضغط بعض حقول PPP مسموحا بعد التفاوض. ثم قالت فقرة Security Considerations إن قضايا الأمن غير مناقشة.

لذلك لا يثبت فتح BACP أو Ack أو Call-Status ناجح السرية أو الهوية أو موافقة المستخدم أو ثبات السعة أو وصول حمولة التطبيق.

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

المصادر