الخلاصة

  • لا يعني وصول LCP إلى حالة Opened أن كل قيمة في حقل PPP Protocol مدعومة؛ فالقيمة المجهولة تستوجب Protocol-Reject بالرمز 8.
  • تحمل الرسالة Rejected-Protocol بطول بايتين وجزءاً من معلومات الحزمة لا يتجاوز MRU المتفق عليها، فتحدد موضع الخلاف من دون الادعاء بأنها نسخة كاملة من الإطار.
  • قد يكون رفض NCP حدثاً مقبولاً من نوع RXJ+، أما رفض LCP نفسه فهو RXJ- كارثي، لأن طبقة التحكم التي تحصر الخطأ تصبح هي موضوع الرفض.

بدأ الخلاف بعد أن فُتحت الوصلة

قدّم RFC 1134 عام 1989 بروتوكول PPP وسيلةً لحمل مخططات بيانات عدة بروتوكولات شبكية فوق وصلات نقطة إلى نقطة. تتولى LCP إنشاء الوصلة المشتركة وضبطها، بينما تتولى عائلة من بروتوكولات NCP إعداد كل بروتوكول من طبقة الشبكة. وهكذا لم تكن حالة الوصلة مرادفة لقائمة القدرات التي يملكها كل طرف.

تظهر الحالة الدقيقة حين تكون LCP مفتوحة، لكن حزمة تصل بقيمة Protocol لا يعرفها المستقبل. لم تجعل المواصفة هذا الاختلاف دليلاً تلقائياً على انهيار الوسط كله. أوجبت، في حالة LCP Open، إرسال حزمة LCP بالرمز 8، أي Protocol-Reject، مع تسمية القيمة التي لم يمكن التعامل معها.

فصل RFC 1331 عام 1992 بين حالتين متشابهتين ظاهرياً. إذا كان البروتوكول معروفاً لكن NCP المقابل لم يصل بعد إلى Opened، تُهمل الحزمة بصمت. وإذا كانت قيمة Protocol مجهولة، يصدر الرفض. الأولى مشكلة طور وترتيب؛ والثانية حد في قدرة التنفيذ.

لذلك لا يثبت الصمت أن البروتوكول مدعوم. قد تكون LCP في حالة أخرى، أو يكون NCP مغلقاً، أو تضيع الحزمة، أو يخالف التنفيذ المواصفة. ولا يثبت Code 8 أن الوصلة الفيزيائية انقطعت أو أن المصادقة فشلت. إنه دليل أضيق: بروتوكول بعينه غير مقبول داخل سياق LCP قائم.

عاد الدليل بحجم تسمح به الوصلة

ثبّت RFC 1661 بنية الرسالة. قيمة Code هي 8، ويجب تغيير Identifier مع كل Protocol-Reject جديد. ويبلغ حقل Rejected-Protocol بايتين، وينسخ حقل PPP Protocol من الحزمة المرفوضة.

يبدأ Rejected-Information من حقل Information في الحزمة الأصلية. لا يتضمن ترويسات طبقة الوصلة ولا FCS، ويجب تقصيره ليلتزم بوحدة الاستقبال القصوى MRU التي ثبتت للطرف المقابل. فلا تحصل رسالة الخطأ على حق تجاوز عقد الحجم الذي تعمل في داخله.

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

أبقى RFC 1548 الآلية في 1993، ثم رسّخها RFC 1661 في 1994. يثبت هذا الاستمرار نضج التصميم داخل المعيار، لا صحة كل تنفيذ ولا مدى انتشاره اليوم.

كان على المرسل أن يتوقف

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

يوضح RFC 1332 دور IPCP في إنشاء IP فوق PPP وضبطه، بينما يحدد RFC 5072 IPv6CP. وهما مثالان على عائلة NCP، لا برهان على استخدامهما في وصلة بعينها. إذا رُفض NCP، فلا يصبح ما يقابله من خدمة شبكية متاحاً لمجرد بقاء LCP مفتوحة. ولا يستمر بروتوكول آخر إلا إذا كان مدعوماً ومُعداً بصورة مستقلة.

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

غيّر البروتوكول المرفوض شدة الحدث

سمّى RFC 1331 الرفض المقبول RXJ+. ومن أمثلته Protocol-Reject لبروتوكول NCP. يقع الحدث ضمن التشغيل المعتاد: يتوقف النوع المخالف من الحزم، ويمكن لـLCP أن تبقى مفتوحة.

أما RXJ- فهو كارثي. إذا كان LCP نفسه هو البروتوكول المرفوض، عدّت المواصفة الخطأ غير قابل للاسترداد وأنهت الاتصال. لم يتغير شكل Code 8؛ الذي تغير هو الأساس المنفي. يمكن فقد NCP مع بقاء LCP لغةً تصف ما تعطل. فإذا أعلن الطرف أنه لا يعرف LCP، لم يعد هناك مستوى مشترك يضبط الوصلة أو يحصر الخلاف.

ومن ثم لا تكفي عبارة «الوصلة ما زالت مفتوحة» للحكم على الخدمة. قد تعتمد التطبيقات على NCP وحيد رُفض، فتكون النتيجة توقفاً كاملاً لها رغم استمرار LCP. بقاء الحامل وبقاء المنفعة مقياسان منفصلان.

يسمي السجل الأرقام ولا يثبت القدرات

يسجل جدول IANA لأرقام PPP الرمز 8 في LCP باسم Protocol-Reject وينشر تعيينات حقل Protocol. وهو مرجع لفك معنى الرقم، لا شهادة بأن جهازاً ينفذه أو بأن NCP مفتوح أو بأن شبكة تستخدمه الآن.

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

المصادر