الخلاصة

  • بقي نمط PPP المعتاد معتمداً على إطارات UI غير المرقمة. أما Numbered Mode في RFC 1663 فكان خياراً طوعياً تفاوض عليه طرفا وصلة واحدة، وأضاف نافذة محدودة وتسلسلاً وإقرارات ومؤقتات وطريق عودة معروفاً عند اختلاف الحالة.
  • جاز للطرفين إعلان نافذتين مختلفتين، لكن كان عليهما استخدام المقياس نفسه: modulo 8 للنافذة الأصغر من 8 وmodulo 128 لما عدا ذلك. اختار Magic-Number من يبدأ SABM أو SABME، ولم يكن وسيلة توثيق للهوية.
  • أثبت SABM أو SABME مع UA إنشاء إجراء الوصلة المرقمة فقط. وظلت المصادقة وتقييم جودة الوصلة وNCP والتوجيه ونتيجة التطبيق مطالب مستقلة تحتاج إلى أدلتها الخاصة.

حين كانت خسارة رزمة واحدة تفسد حالة مشتركة

استخدم PPP المعتاد فوق تأطير شبيه بـHDLC عنوان All-Stations وقيمة Unnumbered Information في حقل التحكم. وعوملت الرزم كداتاغرامات مستقلة؛ فإذا تلف إطار أمكن إسقاطه من دون وعد من طبقة الوصلة بإعادته إلى موضعه في تسلسل.

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

لم تجعل مجموعة عمل PPP في IETF هذه الحاجة الخاصة التزاماً على كل وصلة. نُشر RFC 1663 في يوليو 1994 وعرّف خيار LCP رقم 11، Numbered-Mode. كان على أحد الطرفين طلبه أثناء إنشاء الوصلة وعلى الآخر قبوله. ومن دون هذا الاتفاق ظل UI هو السلوك الافتراضي.

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

صار حقلا Address وControl يحملان الحالة

لم يستبدل Numbered Mode إطار PPP كله. احتفظت حقول Protocol وInformation وPadding وFCS والأعلام بوظائفها. وقع التغيير في Address وControl وفق إجراء LAPB المرقم من ISO 7776. وبعد دخول النمط وجب أن تستخدمه جميع إطارات الوصلة؛ لم يكن مزج UI والإطارات المرقمة خياراً انتقائياً.

لهذا السبب مُنع التفاوض على Address-and-Control-Field Compression. ففي النمط العادي أمكن حذف الزوج الثابت ff 03. أما في النمط المرقم فحمل الحقلان العنوان ومعلومات التحكم في التسلسل. وقد قدّم RFC 1662 القاعدة الأوسع: القيم المختلفة في Address أو Control تحتاج إلى تعريف أو اتفاق سابق ولا يجوز ضغطها كأنها القيم الافتراضية.

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

اختارت النافذة لغة التسلسل أيضاً

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

استخدمت النوافذ الأصغر من 8 modulo 8، واستخدمت النوافذ من 8 فما فوق modulo 128. جاز للطرفين تقديم قيمتين مختلفتين لأن سعة الذاكرة ليست بالضرورة متناظرة. ولم يجز لهما استخدام مقياسين مختلفين؛ فالعد في حلقة من ثلاث بتات وقراءة حلقة من سبع بتات ليس اختلافاً في الأداء، بل لغتان غير متوافقتين للبروتوكول.

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

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

حدّد Magic-Number من يتكلم أولاً

اشترط Numbered Mode نجاح التفاوض على Magic-Number. بعد قبول LCP، أرسل الطرف ذو الرقم الأصغر SABM مع modulo 8 أو SABME مع modulo 128، ورد الطرف الآخر بـUA. وهكذا استنتج الجاران صاحب المبادرة من قيم متاحة في التفاوض نفسه.

إذا ضاعت رسالة الإنشاء أو UA، حكم Restart Timer وعدّادات LCP المحاولة اللاحقة. لكن معنى UA ظل محدوداً: وافق الجار على إنشاء الإجراء المرقم. في معمارية PPP تأتي المصادقة وتحديد جودة الوصلة وإعداد NCP بعد إنشاء وصلة البيانات. لذلك لا يثبت UA قبول بيانات اعتماد، أو كفاية الجودة، أو إعداد IP، أو وجود مسار، أو تنفيذ خدمة بعيدة لطلب.

ولم يكن Magic-Number وثيقة هوية. ساعد في تمييز الطرفين وكشف الوصلة المعادة إلى نفسها، لكنه لم يكن توقيعاً أو تفويضاً. لم يناقش RFC 1663 مسائل الأمن. موثوقية التسليم إلى الجار والثقة في الجار مسألتان منفصلتان.

كان لفقدان الحالة مخرج مشترك

لا تكون إعادة الإرسال متوافقة ما لم يعرف الطرفان كيف يعترفان بانتهاء الحالة المشتركة. لذلك لم يترك RFC 1663 طرفاً مرقماً يتحدث إلى طرف عاد إلى UI إلى أجل غير معلوم.

بدأت إعادة التفاوض بينما ظل Numbered Mode مستخدماً. فإذا لم ينجح الخيار مرة أخرى، عادت الوصلة إلى UI قبل المصادقة وتقييم الجودة وNCP. وإذا استقبل نظام يدعم الترقيم لكنه في حالة UI إطاراً غير UI ذا FCS صحيح، رد بـDM وأعاد تشغيل LCP فوراً. وإذا استقبل طرف مرقم DM، عاد هو أيضاً إلى UI وأرسل Configure-Request جديداً.

لم يُعِد FCS الصحيح إحياء حالة قديمة وحده. جعل DM وبدء LCP من جديد اختلاف الحالة حدثاً قابلاً للرصد.

كانت المحاولات محدودة. حدّد T1 أقصى انتظار للرد على إطار معلومات قبل إعادة إرساله. أوصى النص بتكييفه مع زمن الذهاب والعودة المقاس في LAPB، ووضع حساباً احتياطياً يعتمد على حجم الإطار ومعدل البت وزمن المعالجة. دل T3 على خمول الوصلة ووجب أن يكون أكبر من T1. وحدد N2 عدد محاولات إطار واحد؛ وبعد تجاوزه ينبغي إنهاء الوصلة، وكانت القيمة الافتراضية الموصى بها 3.

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

لم تصبح الوصلات المتوازية حزمة تلقائياً

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

ذكر RFC 1663 آلية ISO Multi-Link، لكنه لم يوص بتنفيذها وأشار إلى عمل PPP Multilink الذي أصبح لاحقاً RFC 1990. رتّب Numbered Mode التسليم داخل وصلة عضو واحدة واستعاده. أما Multilink فأنشأ فضاء تسلسل على مستوى الحزمة لإعادة تجميع أجزاء عبر عدة وصلات. لا يثبت وجود أحدهما وجود الآخر.

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

كانت قيمة الإقرار في معرفته لحدوده

يسجل IANA أن Numbered-Mode هو خيار LCP رقم 11. يثبت ذلك مفردات مشتركة. ويثبت Configure-Ack قبول قيم محددة في جولة تفاوض. ويثبت SABM أو SABME مع UA إنشاء الإجراء المرقم. وتدعم سجلات التسلسل والإقرار وإعادة الإرسال قولاً عن إطارات تلك الوصلة. أما DM أو إعادة LCP أو نفاد N2 فتشير إلى فقدان الحالة.

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

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

المصادر