الخلاصة

  • تشير القيمة 0xcf إلى PPP بعد ترويسة Q.922، لكن القيمة الأخرى لا تُقرأ كبروتوكول PPP مضغوط إلا إذا كان PFC مفعلاً وكان NCP المرتبط قد جرى التفاوض عليه.
  • قد تكشف ردود متعددة تحمل LCP Identifier نفسه وتأتي من framing addresses مختلفة اتصالاً متعدد النقاط بالخطأ؛ وظهور تغليف مكافئ بعد نجاح NCP يعيد الوصلة إلى Link Establishment.

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

نُشرت RFC 1973 في يونيو 1996 لوصف PPP داخل دارة Frame Relay مهيأة كنقطة إلى نقطة. توفر PPP بروتوكول LCP وبروتوكولات NCP والمصادقة والضغط، وهي قدرات تفترض علاقة بين طرفين. أما Frame Relay فيوفر دوائر افتراضية ويمكن أن يظهر أيضاً في بنية متعددة النقاط. لذا كان على التغليف أن يحمي آلة حالة ثنائية من طبقة أدنى لا تثبت وحدها عدد المشاركين.

إطاران لم يستطيعا التعايش

استخدمت PPP عادة framing شبيهاً بـHDLC ومبنياً على ISO 3309. كان هناك أمل في تشغيله مع Frame Relay على الوصلة نفسها. سجلت RFC 1973 سبب استبعاد ذلك: توسع Q.922 العنوان من بايت واحد إلى بايتين أو أربعة، ولا يمكن دائماً تمييز بنية حقول DLCI الفرعية من طريقة ISO 3309. عندما لا يستطيع المستقبل تحديد نهاية العنوان بصورة قاطعة، يصبح التعايش تخميناً.

جاء البديل بترتيب صريح: Flag بقيمة 0x7e، ثم Q.922 Address وControl، ثم NLPID بقيمة 0xcf، ثم PPP Protocol، وبعدها Information وPadding. ينتمي العنوان والتحكم إلى سياق Frame Relay؛ تختار 0xcf محلل PPP؛ ويختار الحقل التالي LCP أو NCP أو بروتوكول الشبكة المحمول. كل حقل يحدد بناءً، ولا يثبت هوية المرسل.

لهذا مُنع التفاوض على Address-and-Control-Field-Compression. في PPP الشبيه بـHDLC يمكن حذف قيم ثابتة. هنا لا تكون قيم Address وControl ثابتة، وقد تعدلها شبكة التحويل أثناء النقل. حذفها كان سيزيل سياق توصيل متغيراً.

المعنى الذي يحتاج إلى ذاكرة

يختلف Protocol-Field-Compression. فهو يختصر PPP Protocol من بايتين إلى بايت واحد. وتلاحظ الوثيقة أن إزالة NLPID مع الضغط تجعل Information مصطفاً على حد 32 بت، ولذلك توصي بالتفاوض على PFC عندما يحسن الأداء.

عند الاستقبال يُفحص أول بايت بعد الترويسة. إذا كان صفراً، يُفترض تنسيق RFC 1490. إذا كان 0xcf، يكون NLPID الخاص بـPPP صريحاً. أما القيمة غير الصفرية والمختلفة عن 0xcf فلا يُتوقع أن تكون PPP Protocol مضغوطاً إلا إذا كان PFC مفعلاً وكان NCP المناسب قد اكتمل. من دون الشرطين يجب العودة إلى تفسير RFC 1490.

إذن لا يحمل البايت معناه منفرداً؛ تستكمله حالة محلية محفوظة. حُجزت قيمة PPP Protocol 0x00cf لتجنب الغموض عند الضغط. قد تُعامل كإشارة إلى أن حزمة PPP Protocol أخرى تتبعها، لكنها ليست إيصالاً لقبول الشبكة. وما زالت سجلات IANA تفصل بين NLPID 0xCF وقيمة PPP 00cf المحجوزة.

عندما يجيب أكثر من طرف

تحمل حزم LCP الأولى بعد الترويسة التسلسل cf-c0-21: NLPID الخاص بـPPP ثم LCP Protocol غير المضغوط c021. يؤدي التعرف على LCP Configure-Request إلى دخول Link Establishment. لا يعني ذلك أن LCP أصبح Opened، ولا أن المصادقة أو NCP قد اكتمل.

ثم تقدم الوثيقة علامة طوبولوجية. إذا وُصل feed يفترض أنه نقطة إلى نقطة بشبكة multipoint أو multicast group عن طريق الخطأ، فقد تجيب عقد عدة. ينبغي أن تؤدي استجابات متعددة للطلب نفسه، تحمل Identifier ذاته وتصل من framing addresses مختلفة، إلى إظهار سوء تهيئة.

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

تغليف مكافئ يكشف فقدان الحالة

في مرحلة Link Establishment لا يجوز إرسال حزم ذات NLPID أخرى، ويجب إسقاط ما يصل منها بصمت حتى مرحلة Network-Layer Protocol. لا يسمح ذلك لبناء مختلف بأن يسبق اكتمال حالة PPP.

بعد نجاح تفاوض NCP لبروتوكول معين، تتغير دلالة التغليف المكافئ وفق RFC 1490. وصوله قد يعني أن الطرف فقد حالة PPP. عندئذ يجب أن تعود الوصلة إلى Link Establishment وترسل LCP Configure-Request جديداً. وإلا استمرت جهة وفق اتفاق لم تعد الجهة الأخرى تتذكره، فتحول المرور إلى ثقب أسود.

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

يأتي بعد الفشل خيار محلي. إذا كانت تهيئة PPP أو ميزة متفاوض عليها مثل المصادقة مطلوبة، يجوز الدخول في Termination. وإلا، عند بلوغ Max-Configure، يجب إرسال إطارات RFC 1490 وحدها. التوقف لحماية خاصية، والاستمرار بعد التخلي عنها، نتيجتان مختلفتان.

حدود صنعتها المعدات

يجب أن تكون الوصلة full-duplex، دائمة أو مبدلة. يمكن لإشارات تحكم Frame Relay أن تولد حدثي Up وDown لـLCP، لكن فشلها لا يجوز أن يعطل عمل PPP الصحيح. توصي الوثيقة بـMagic Number وPFC. قيمة MRU الأولية 1600 بايت؛ وينبغي ألا يتجاوز MTU في طبقة الشبكة 1500 ما لم يُتفاوض صراحة على MRU للطرف يبلغ 2048 أو أكثر.

كانت بعض المحولات لا تقبل إلا إطارات بحجم 262 بايت. لذلك وجب أن تستطيع التطبيقات تقييد حزم LCP إلى 259 بايت قبل إكمال التفاوض، تاركة مكاناً لـNLPID وProtocol. لا يُطلب XID ولا Inverse ARP لهذه وصلات PPP لأن تفاوض NCP يقدم الوظيفة. هذا حكم محدود بالتركيب المحدد.

حلت RFC 2427 لاحقاً محل RFC 1490 وRFC 1294 في التغليف العام متعدد البروتوكولات، لا محل RFC 1973. تثبت الوثائق والأرقام صيغة وتخصيصاً، ولا تثبت انتشاراً حالياً أو إعداد شركة مصنعة أو حادثاً أو نتيجة خدمة. وتقول RFC 1973 إن مسائل الأمن لم تُناقش؛ فلا يمنح framing مصادقة أو سلامة أو سرية من تلقاء نفسه.

المصادر