الخلاصة

  • يتيح PPPMuxCP للمستقبل أن يعرض، في كل اتجاه على حدة، قبول إطارات PPP متعددة الحزم. نجاح التفاوض يسمح للمرسل باستخدام الصيغة ولا يلزمه بإرسال إطار متعدد واحد.
  • يحدد PID الافتراضي كيف يعيد المستقبل معرف بروتوكول محذوفاً. لا يثبت الاتفاق أن PFF صار صفراً أو أن الحقل حُذف أو أن بايتاً قد وُفر.
  • تقاسم الغلاف الخارجي قد يقلل الكلفة لكل حزمة، لكنه قد يضيف انتظاراً ويجمع آثار الخطأ في إطار واحد. القدرة والتنفيذ والاستعادة والقياس ونتيجة التطبيق إيصالات مستقلة.

كانت الكلفة في الغلاف الذي يتكرر حول كل حزمة صغيرة

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

اقترح RFC 3153 وضع عدة حزم PPP بوصفها إطارات فرعية داخل إطار PPP خارجي واحد. يسبق كل إطار فرعي فاصل قصير يبين وجود معرف البروتوكول وطول المحتوى. لا يضغط الأسلوب بيانات التطبيق؛ بل يجعل عدة حزم تتقاسم الغلاف الخارجي.

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

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

العرض صدر ممن سيفك الإطار، لا ممن أراد إرساله

يعمل PPPMuxCP في مرحلة NCP. يعرض المستقبل أنه يستطيع استقبال الصيغة متعددة الحزم، ولا يجوز للمرسل أن يستخدمها قبل هذا العرض. والتفاوض مستقل في كل اتجاه؛ قبول A لما يرسله B لا يعني أن B قبل ما يرسله A.

حتى بعد اكتمال Configure وAck يبقى قرار التنفيذ عند المرسل. يجوز له اختيار بعض حزم PPP للضم، أو إرسال الحزم المؤهلة منفردة. يقول RFC بوضوح إن نجاح PPPMuxCP لا يلزم النظير بإرسال إطارات متعددة.

لهذا تكون خانة «مفعّل» غامضة. قد تعني أن العرض وصل، أو أن حالة التحكم فتحت، أو أن سياسة محلية حملت، أو أن بيانات 0x0059 ظهرت فعلاً. السجل المنضبط يحفظ الاتجاه والوقت ويربط تبادل التحكم بإطار البيانات اللاحق.

التفاوض يثبت لغة يستطيع المستقبل قراءتها. ولا يثبت أن المرسل نطق بها.

الاتفاق على PID افتراضي لم يحذف الحقل من تلقاء نفسه

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

لكنه ليس مضطراً إلى ذلك. يمكن أن يبقي الحقل صريحاً حتى عندما يكون الحذف صحيحاً. يثبت PID المتفق عليه قاعدة تفسير مشروطة، لا مقداراً محققاً من التوفير.

في الإطارات الفرعية اللاحقة، يحمل PFF=1 معرفاً جديداً ويحدث Last_PID لدى المرسل وLast_rcvd_PID لدى المستقبل. أما PFF=0 فيعيد استخدام آخر قيمة صريحة. يبدأ الطرفان بالقيمة الافتراضية قبل أول تحديث.

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

كان MRU سقفاً للصحة لا هدفاً لملء الإطار

يجمع الفاصل PFF مع LXT وLEN. يحدد LXT ما إذا كان حقل الطول قصيراً أم ممتداً، بينما يحدد LEN حدود الإطار الفرعي. يستخدم إجراء الإرسال التوضيحي MAX_SF_LEN محلياً لقبول المرشحين، ولا يسمح للمجموع بتجاوز MRU المتفاوض عليه في LCP.

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

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

يجب لهذا تسجيل MRU وMAX_SF_LEN والمؤقت كلّاً على حدة: الأول حد استقبال، والثاني سياسة أهلية، والثالث ثمن انتظار محلي.

إعادة الأجزاء لم تسمح بتغيير ترتيبها

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

يحظر وضع إطار متعدد داخل آخر، كما يحظر إدخال إطارات LCP. ولا يجوز للمرسل أو المستقبل إعادة ترتيب الحزم بسبب انتقال بعضها منفرداً وبعضها داخل غلاف مشترك.

لا يثبت عداد «ثلاث حزم مستعادة» حفظ الترتيب مع الإطارات المنفردة المجاورة. ينبغي حفظ تسلسل الوصول الخارجي والحدود الداخلية وترتيب التسليم بعد الفك.

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

كان موضع PPPMux بين MP وCCP وECP جزءاً من التوافق

في حزمة Multilink PPP، يجري تفاوض PPPMux على مستوى الحزمة لا على كل وصلة عضو. ينفذ المرسل التعدد قبل تغليف MP، فيكون رأس MP خارج رأس PPPMux. ولا يجوز وضع إطار Multilink داخل إطار متعدد.

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

قائمة قدرات تضم التعدد وMultilink والضغط والتشفير لا تثبت ترتيبها. موضع كل عملية يحدد البايتات التي تراها، وموضع الالتقاط يحدد الشيء الذي نراقبه. كما أن Ack في ECP لا يثبت أن إطاراً معيناً شُفر فعلاً.

هنا أيضاً تحتاج القدرة إلى إيصال تنفيذ مستقل.

عدم إضافة اعتبار أمني لم يكن إضافة حماية

يقول RFC 3153 إنه لا يفرض اعتبارات أمنية إضافية تتجاوز PPP وأساليب ضغط الرؤوس فوقه. هذه عبارة عن نطاق الوثيقة، لا خاصية مصادقة أو سلامة أو سرية أو منع إعادة.

قد يظل طول مشوه أو اختلاف في المحلل أو انحراف في حالة PID سبباً لفشل تشغيلي. وقد تُفك الحزمة بصورة صحيحة من نظير لم تثبت هويته، أو تؤدي لاحقاً إلى قرار غير آمن.

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

وضعت القاعدة المشتركة حد الإذن وتركت الاستخدام محلياً

حدد RFC 3153 ما يجب أن يكون مشتركاً بدقة: العرض السابق، وقيم البروتوكول، ومعاني الأعلام والأطوال، واستعادة PID، والترتيب، والموقع بين وظائف PPP. وبعد ذلك بقي قرار ضم الطابور الحالي لدى المرسل.

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

وتتبع الأدلة الترتيب نفسه. يثبت Configure-Ack الإذن. يثبت 0x0059 الاستخدام. تثبت PFF/LXT/LEN الترميز. يثبت سجل المستقبل الاستعادة. تثبت المقارنة البايتات والزمن. ويثبت التطبيق وحده نتيجته.

القيمة التاريخية لـRFC 3153 ليست فقط أن عدة حزم دخلت غلافاً واحداً. بل إنه فصل بدقة بين قول المستقبل «أستطيع القراءة» وقرار المرسل «سأستخدمها الآن» وسؤال الشبكة «هل أفاد ذلك فعلاً؟»

المصادر