الخلاصة

  • أمكن لمعرّف الطرف المطلوب أن يختار PPP بين خدمات على منفذ ISDN واحد، لكنه لم يكن إذناً بتشغيل الخدمة ولا إثباتاً لهوية المتصل.
  • إذا لم يتلق LCP حدث Open الإداري وجب رفض المكالمة؛ وحظرت RFC 1618 قبولها ثم إغلاق الدارة أو تجاهل حزمها.
  • بقي الترميز والتأطير وUp وLCP Opened والتوثيق وNCP ونتيجة التطبيق إيصالات مستقلة بعد القبول.

الدارة التي وصلت قبل الإذن

نشرت RFC 1618 في مايو 1994 لوصف PPP فوق دوائر ISDN المحولة. لم تفترض شبكة عالمية متجانسة؛ فقد اختلفت المقاسم وسياسات الاشتراك والمعدات، فاختارت الوثيقة عدداً قليلاً من البدايات المشتركة من دون أن تجعل التنوع اختفاءً.

كانت قناة B حاملاً نقطة إلى نقطة مناسباً لـPPP، ويمكن لواجهة PRI تشغيل قنوات كثيرة معاً. أمكن لقناة D حمل PPP بتأطير مناسب، لكنها محدودة السعة وكثيراً ما تقف عند المقسم المحلي. توافر الحامل يثبت إمكانية تقنية، لا قرار الطرف بتقديم الخدمة.

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

إشارة أغنى لم تصل من طرف إلى طرف

بدا LLC Information Element مرشحاً ليعلن الترميز أو التأطير خارج النطاق. لكن الخبرة التي سجلتها RFC قالت إن المقاسم المتوافقة قليلة وسياسات مقدمي الخدمة متنوعة، فلا يصل العنصر بثقة من طرف إلى طرف. ولم تكن قيمة خاصة بـPPP قد خصصت له؛ أما القيم الأخرى فلا تصلح دليلاً على وصلة PPP، ولا ينبغي الاعتماد على العنصر لتحديد التأطير أو الترميز.

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

ثلاثة ألفاظ متشابهة وثلاث سلطات

حكم القبول صارم: إذا استُخدم معرّف الطرف المطلوب، أو وصلت مستقبلاً قيمة LLC لـPPP، ولم يحدث Open الإداري في LCP، فلابد من رفض المكالمة. لا قبول يعقبه إغلاق، ولا قبول يعقبه صمت.

تشرح RFC 1548 ثم RFC 1661 أن Open يعني سماح مسؤول الشبكة، إنساناً أو برنامجاً، بفتح الوصلة. أما Up فهو تقرير الطبقة الدنيا بأنها متاحة، وOpened حالة يصل إليها تفاوض LCP لاحقاً.

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

الكشف كان تجربة محدودة

بعد الإذن بقي تمثيل البتات مجهولاً أحياناً. فمن منظور PPP كانت قناة ISDN وصلة متزامنة مزدوجة الاتجاه، بينما جعلت RFC الترميز والتشويش من مسؤولية معدات DTE/DCE، وأوصت بـNRZ افتراضياً عند النقطة T، وبـNRZI بديلاً مضبوطاً، وأهملت NRZ المعكوس القديم.

لكشف عدة ترميزات بسيطة كان الحل الموثوق هو الدوران بينها. تُرسل LCP Configure-Request مرتين في كل نمط، ثم ينتظر الرد قبل الانتقال. يجب ألا تتجاوز المحاولات مجتمعة 59 ثانية، والأفضل حد الثلاثين ثانية المعتاد. لم يكن الكشف قراءة لحقيقة مخفية؛ كان اختباراً يستهلك وقتاً وقناة وله نهاية.

ومن دون ضبط سابق تبدأ قناة B بـHDLC متزامن البتات. يحتاج HDLC متزامن الثمانيات إلى حدود ثمانيات متاحة وضبط صريح. ولا ينبغي تشغيل أطر متعددة معاً ثم مطالبة PPP بالتخمين. تربط RFC 1549 استخدام NRZI بضعف بعض خصائص FCS ذي 16 بت وتوصي بالتفاوض على 32 بت.

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

الحزمة المنتظرة قد تصنع مكالمات جديدة

أوصت RFC بألا تتجاوز MTU في طبقة الشبكة 1500، إلا إذا جرى تفاوض صريح مع النظير على MRU لا تقل عن 2048. كما أوصت بتراجع أسي للمؤقت من 250 ملي ثانية إلى ثلاث ثوان وبحدود لإعادة الاتصال المستمر. وبعد فشل إنشاء الوصلة يمكن حذف صف الإرسال، فيزول مؤقتاً المحفز الذي يعيد الطلب.

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

كما فضلت الوثيقة PPP Multilink على BONDING ذي التهيئة المستقلة. ووصفت RFC 1990 لاحقاً تجميع عدة قنوات ISDN، لكن وجودها المادي لا ينشئ bundle تلقائياً؛ يلزم تفاوض خيار LCP.

القبول أول السلسلة لا آخرها

بعد قبول المكالمة يلزم تأطير وترميز متوافقان، ثم Up، ثم LCP Opened، وتوثيق إن اختير، وNCP مفتوح لكل بروتوكول شبكي. وبعد ذلك فقط تعبر الرزم، ولا يثبت عبورها نتيجة التطبيق.

يثبت سجل RFC Editor النشر والمؤلف وحالة Proposed Standard الحالية، لا نشر منتج أو ممارسة راهنة. وتقول الوثيقة إنها لا تناقش الأمن، فلا يجوز تحويل الرقم المطلوب إلى مصادقة للمتصل.

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

سمّى المقسم الخدمة، لكنه لم يستطع فتحها نيابة عن الطرف. وضعت RFC 1618 الرفض قبل الدارة المقبولة كي يظل القرار مرئياً ومنسوباً إلى صاحبه.

المصادر