الخلاصة

  • منعت RFC 1220 تبادل حركة LAN قبل فتح Bridge Network Control Protocol. أثبتت حالة Open أن آلة البروتوكول سمحت ببدء فئة من الحركة، لا أن إطارًا بعينه خرج إلى الشبكة البعيدة أو وصل إلى تطبيق.
  • بقي نجاح الجسر معتمدًا على MRU مناسب، وحفظ الترتيب عند استخدام عدة وصلات، وتوافق أنواع MAC، واتجاه ضغط tinygram، وسياسة LAN ID، وحالة spanning tree وسلوك المستقبل.
  • كان CRC الخاص بإطار PPP وLAN FCS سجلين مستقلين. صحة الحمل على الوصلة التسلسلية لم تكن برهانًا على حفظ الإطار الأصلي أو على نتيجة نهائية.

الإشارة الخضراء جاءت قبل أصعب جزء

صدرت RFC 1220، وعنوانها Point-to-Point Protocol Extensions for Bridging، في أبريل 1991 بتحرير F. Baker. يسجلها RFC Editor وIETF Datatracker بوصفها Proposed Standard من مسار IETF، ويشيران إلى أنها أصبحت متقادمة وحلت محلها RFC 1638. يثبت السجل هوية الوثيقة ووضعها، ولا يثبت تنفيذها في جهاز أو شبكة.

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

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

لكن Open أجاب عن سؤال واحد: هل تسمح حالة التحكم الآن بهذه الحركة؟ لم يجب عن الإطار الذي أُرسل، ولا عن منفذ الخروج الذي اختارته قاعدة التمرير، ولا عن وجود الوجهة، ولا عن استلام تطبيق لبيانات نافعة. بوابة البروتوكول ونتيجة الخدمة سجلان مختلفان.

صمت الجار لم يكن تفويضًا مفتوحًا

في transparent bridging، افترضت RFC 1220 أن الجسر مسموح على الوصلة إذا استقبل الجار BPDUs من IEEE 802.1 ولم يرد بحزمة PPP Protocol-Reject. وهكذا أعطت لغياب الرفض معنى محددًا داخل نموذج البروتوكول.

لم يتحول ذلك إلى موافقة إدارية عامة. لا يكشف الصمت هوية مشغل، ولا يثبت تماثل إعداد الطرفين، ولا يحدد جذر spanning tree، ولا يسجل أن منفذًا صار في حالة forwarding. ويمكن لمدير الشبكة أصلًا أن يفصل الوصلة إلى نطاقين مختلفين للشجرة، لكن عليه أن يضبط الطرفين كي لا يتبادلا BPDUs. وإذا وصل BPDU إلى جسر مضبوط بهذه الطريقة، فعليه إسقاطه بصمت.

لذلك قد يشبه القبولُ المقيد الفصلَ المقصود أو العطلَ أحادي الاتجاه من الخارج. أوصت الوثيقة بقوة بكشف loopback عبر Magic Number وبمراقبة جودة الوصلة لأن حركة spanning tree في الوضع المعتاد كانت في معظمها أحادية الاتجاه من الجذر نحو الأوراق. الطريق العكسي الهادئ لم يكن طريقًا سليمًا بالضرورة.

الخيارات قيدت القدرة ولم تضمن استعمالها

شملت خيارات BNCP أنواع MAC وضغط tinygram وLAN Identification وأرقام ring/bridge. كان إعلان نوع MAC يقول ما يستعد المستقبل لاستلامه وخدمته. إذا أعلن مجموعة، وجب إسقاط الأنواع غير المدرجة. وإذا لم يعلن شيئًا، أمكن للطرف الآخر افتراض دعم واسع، مع بقاء حق المستقبل في إسقاط نوع لا يفهمه.

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

أما tinygram فكان اتجاهيًا. قد يقبل طرف فك الضغط ولا يقبله الآخر، وعدم التفاوض يعني عدم الضغط. لذلك لا تكفي عبارة «الضغط مفعل» من دون تحديد الاتجاه. وكان LAN Identification استشاريًا ومعطلًا افتراضيًا. التفعيل يعني احتمال وجود شبكات موسومة خلف الجار واستعداده لخدمتها؛ والتعطيل يعني إسقاط الحركة الموسومة. لا يثبت الحقل انتماءً تنظيميًا ولا يقوم مقام التحكم في الوصول.

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

قد يكون الإطار قانونيًا وأكبر من الطريق

نبهت RFC 1220 إلى أن MRU المتفاوض عليه يجب أن يتسع لأنواع MAC المدعومة. لم توفر صيغة الجسر تجزئة وإعادة تجميع، وحتى إطار Ethernet قد يزيد على MRU الافتراضي في PPP البالغ 1500 octet. وهكذا يستطيع BNCP أن يكون Open بينما لا تتسع الوصلة لإطار صحيح في الشبكة المحلية.

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

ثم يأتي فصلا السلامة. يحمي CRC الخاص بـ PPP الإطار خلال الوصلة نقطة إلى نقطة. أما LAN FCS الاختياري فهو القيمة التي حسبتها، أو يبدو أنها حُسبت من، المحطة الأصلية. وصفتهما الوثيقة بأنهما منفصلان وغير مرتبطين. إذا غاب FCS المضمن، يستطيع الجسر أن يسبب حساب FCS جديد عند إخراج الإطار إلى LAN. نجاح فحص الوصلة، وحفظ الإطار الأصلي، والتسليم النهائي ثلاث دعاوى مختلفة.

تنسيق الحزمة وصف احتمالًا لا واقعة

خصصت الصيغة أعلامًا لوجود FCS وLAN ID وضغط الأصفار وpadding نهاية الوصلة، وحدد نوع MAC كيفية تفسير البايتات التالية. يستطيع المحلل أن يعرف ما قال المرسل إنه أدرجه. لا يستطيع من ذلك وحده إثبات إدخال في forwarding database، أو حالة منفذ في spanning tree، أو خروج الإطار، أو استقبال المضيف النهائي.

ولا تحتوي المصادر على إعداد مشغل، أو capture لتفاوض BNCP، أو جدول تمرير، أو trace للحزم، أو سجل تطبيق. وتقول RFC 1220 إن قضايا الأمن غير مناقشة. لذلك لا تثبت المصادقة أو التفويض أو السرية أو النشر أو الرجوع الآمن أو أي نتيجة تشغيلية.

القيمة التاريخية لحالة Open أنها كانت محددة، لا أنها كانت ضعيفة. قالت متى يستطيع نوع من الحركة أن يبدأ. أما تحويلها إلى دليل أن «الشبكة الممتدة تعمل» فيحتاج إلى وقائع لم تضعها حزمة التحكم داخلها.

المصادر