الخلاصة

  • أضاف RFC 3518 إلى PPP BCP خيار Bridge-Control-Packet-Indicator القابل للتفاوض. عند تفعيله وجب على المرسل تعليم إطارات BPDU ووحدات GARP المعروفة وتجنب إسقاطها أو تأخيرها تأخيراً كبيراً.
  • أثبت البت C تصنيفاً محلياً وقدرة مشتركة بين نظيرين. لم يصادق على BPDU، ولم يثبت قبولها لدى عملية التحكم المستقبلة، ولا تقارب الشجرة أو خلو الطوبولوجيا من الحلقات.

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

لم يبدأ الجسر عبر PPP في عام 2003. وصف RFC 1638 آلية مبكرة، ثم راجع RFC 2878 بروتوكول Bridging Control Protocol. استطاع طرفا الوصلة النقطية التفاوض على خصائص الجسر وتشغيل وحداتهما. أبطل RFC 3518 الوثيقة السابقة، لكنه لم يبتكر خوارزمية شجرة ممتدة جديدة.

عدّد قسم التغييرات نقطتين فقط: إضافة Bridge Control Packet Indicator إلى خيارات الإعداد، وتغيير معنى بت محجوز في حقل الأعلام. كشف التعديل فئة التحكم عند الموضع الذي تستطيع فيه قائمة الانتظار أن تمنحها معاملة مختلفة.

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

اعتمد التعرف على عناوين MAC للوجهة التي خصصها IEEE. ذكر RFC 3518 عنوان مجموعة الجسر المستخدم في STP وعنوان الإدارة وعناوين GMRP وGVRP. يقرأ مصنف المرسل هذه الدلالة ثم يكتب قراره في ترويسة إطار PPP المجبّر.

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

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

لكل إيصال سؤال مستقل. يثبت سجل IANA تخصيص الرقم 10. يثبت Configure-Request وConfigure-Ack القدرة المشتركة في الجلسة. يثبت الالتقاط قيمة C. بعد ذلك يلزم فحص عملية التحكم المستقبلة، وتغيرات الجذر وأدوار المنافذ، وسلوك مستوى البيانات قبل القول إن المسارات الزائدة حُجبت فعلاً.

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

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

لذلك أوصى RFC 3518 بمصادقة PPP أثناء بدء LCP حيث يحتمل جهاز غريب أو مخترق. يقوي CHAP في RFC 1994 التحقق من النظير بتحد واستجابة. إنه يحسن جواب «من في الطرف الآخر؟»، لكنه لا يثبت صحة إعداد الجسر أو حداثة BPDU أو تقارب النطاق.

تعمل آليات تعدد الوصلات في مستوى آخر. يجزئ RFC 1990 الحركة ويرتبها عبر عدة مكونات، ويضيف RFC 2686 فئات لتقليل تأخير أنواع معينة. قد يصل إطار التحكم أسرع، لكن السرعة لا تساوي قبول الخوارزمية ولا سلامة النتيجة.

احتفظ RFC 3518 أيضاً بصيغة قديمة لـ BPDU من أجل جسور BCP الأقدم، بينما تستخدم الحالة العادية صيغة مشتركة مع الحركة المجبّرة. حل الاستثناء قدرة الجار على القراءة، ولم يصف صحة النطاق خلفه.

وثق RFC 7042 لاحقاً حدود إدارة المعاملات بين IETF وIEEE 802، ولا يزال سجل PPP يحمل النوع 10. يثبت السجل سلطة تخصيص الرقم؛ لكنه لا يرى جلسة حية، ولا أصالة إطار أو توقيته أو أثره.

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

قد تكون BPDU مصنفة بدقة وسريعة الوصول، ومع ذلك قديمة أو صادرة عن نظير مخترق أو داخلة إلى نطاق خاطئ أو واصلة إلى جسور لم تتقارب. يخبر البت C كيف ينبغي نقل الإطار؛ ولا يخبر أن العالم الذي يصفه آمن.

المصادر