الخلاصة

  • في الحقلين الموروثين TCP_SPACE وNON_TCP_SPACE من RFC 2509، كان الصفر أكبر معرّف للسياق؛ لذا ظلّ المعرّف CID 0 متاحاً كسياق واحد.
  • أتاحت الخيارية الفرعية 3، بطول ثلاثة أوكتات، لـRFC 3544 أن يحدد صراحةً صفراً من سياقات TCP أو غير TCP، فيعطّل ضغط تلك الفئة.

مصدر الالتباس هو الاسم. فالحقلان TCP_SPACE وNON_TCP_SPACE لا يعدّان السياقات، بل يحددان أعلى معرّف في فضاء السياقات. وإذا كان الحد الأعلى صفراً، ظلّ CID 0 ضمن الفضاء. قد يناسب ذلك إعداداً بسيطاً، لكنه لا يتيح القول: «لا تضغط أي حزمة من هذه الفئة».

نُشر RFC 3544 في يوليو 2003 بوصفه Proposed Standard، وعدّل خيار التفاوض في PPP الذي قدمه RFC 2509 من دون تغيير دلالة الحقول القائمة. وجاءت الخيارية الفرعية 3 بالتمييز الناقص: النوع 3، والطول ثلاثة أوكتات، ومعامل من أوكت واحد. تعني القيمة 1 صفراً من سياقات TCP، وتعني القيمة 2 صفراً من سياقات غير TCP. وتتجاوز هذه الخيارية قيمة TCP_SPACE أو NON_TCP_SPACE المقابلة في خيار ضغط ترويسة IP. وإذا ورد المعاملان معاً، تعطّل الضغط عن جميع الحزم.

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

بروتوكولا تحكم وتفاوضان منفصلان

يفاوض PPP على معلمات الوصلة بواسطة بروتوكولات تحكم الشبكة. ويعرّف RFC 3544 تنسيق الخيار نفسه لكل من IPCP في IPv4 وIPV6CP في IPv6. يضبط كل بروتوكول ضغط الحزم التي تنتمي ترويستها الشبكية الخارجية إلى نسخته. لذلك فإن نجاح تفاوض ضغط IPv4 ونجاح تفاوض ضغط IPv6 نتيجتان منفصلتان في مستوى التحكم، لا مفتاحاً عاماً واحداً.

وهناك تفصيل إضافي: يتشارك IPv4 وIPv6 فضاء معرّفات السياق مع أن التفاوض على القيم مستقل. وإذا اختلفت القيم، وجب على محرك الضغط أن يخصّص المعرّفات من مجموعة مشتركة، وعلى مفكك الضغط أن يفحص حالة السياق ليحدد المعلمات المناسبة. أما TCP ومجموعة غير TCP/UDP/RTP فلا تتشارك فضاء السياق. هذه قيود تشغيل ينص عليها البروتوكول، لكنها لا تثبت أن نظيراً بعينه أعدّها أو استخدمها.

ويضيف RFC 3544 أيضاً خيارية RTP المحسّنة من النوع 2. يجري التفاوض عليها بدلاً من خيارية RTP القديمة من النوع 1، لا إلى جانبها. ومع قيم حقل بروتوكول PPP التسع، تساعد هذه الخيارات المتلقي في تصنيف الإطار وتحديد الصيغ التي أتاحها التفاوض. يؤدي حقل البروتوكول وظيفة فصل الأنواع؛ أما الخيارية فتعبر عن قصد التهيئة.

التفاوض ليس دليلاً على مسار البيانات

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

ويصرّح المعيار بموضع التباس مجاور: لا يوضح RFC 1332 ما إذا كان الخيار يصف قدرة المرسل أم المستقبل. ويقول RFC 3544 إنه يفترض، تمشياً مع الممارسة، أن طلب Config-Req يصف قدرة مفكك الضغط لدى النظير الذي أرسله. هذا افتراض معلن، لا توضيح معياري جديد لـRFC 1332. ومن شأن المبالغة في الجزم أن تمحو تحفظ النص نفسه.

ولمسار البيانات شرط آخر. يستخدم IPHC الترميز التفاضلي مع TCP وRTP، ولذلك تعتمد الحزم المضغوطة على سياق لدى الطرفين. لا يعيد PPP ترتيب الحزم بذاته؛ ولهذا تكون آليات الحماية من إعادة الترتيب معطلة افتراضياً. وإذا استُخدم Multi-Link PPP متعدد الفئات أو آلية أخرى قد تعيد الترتيب، فيجب ألا تتغير سلسلة الحزم التي تتشارك سياق الضغط. التفاوض على صيغة لا يلغي هذا القيد في النقل.

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

المصادر