الخلاصة

  • اقترح RFC 1482 سجلاً يميّز بين البادئة وHome AS وكل Announcing AS والجيران المقصودين لكل إعلان. كان السجل يصف سياسة مرجوة، لا تحديثاً حياً تمت ملاحظته.
  • في التجميع بالنيابة، كان سماع مكوّن واحد من قائمة كافياً لإنشاء بادئة أكبر ونشرها. وجود البادئة الأكبر لم يثبت أن جميع الوجهات التي تغطيها قابلة للوصول.

الصفوف المتعددة حفظت أدواراً متعددة

يعرض RFC 1482 مثالاً لسجل تجميع تتكرر فيه البادئة نفسها. يظهر AS 100 بصفته Home AS، ثم تظهر الأنظمة AS 690 وAS 200 وAS 201 بوصفها جهات ستعلن البادئة إلى مجموعات مختلفة من الجيران.

Home AS هو المزود الذي يجمع قابلية الوصول إلى المكوّنات أولاً ويعلن الناتج إلى جيرانه. أما Announcing AS فهو نظام يتلقى ذلك الناتج ثم يمرره إلى جيرانه. وقائمة Neighbor AS تحدد جمهور خطوة بعينها.

لذلك لا يعني وجود AS 100 في خانة الموطن أن كل مراقب استلم الإعلان منه مباشرة. وقد يرى مراقب خلف AS 200 هذا النظام جاراً مباشراً، من دون أن يصبح AS 200 موطن التجميع. الصفوف كانت خريطة لمسؤوليات الانتشار المقصودة، لا لقطة موحدة من الشبكة.

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

التوقع في قاعدة البيانات سبق الحدث على الشبكة

قبل إضافة التجميع، كانت قاعدة التوجيه المبني على السياسة في NSFNET تربط رقم شبكة بأنظمة AS التي يُتوقع أن تأتي منها إعلاناته. ويورد RFC مثال الشبكة 35 مع مصادر أساسية وثانوية وإضافية.

هذه قائمة قبول مُعدّة مسبقاً. إدراج AS فيها لا يعني أنه أعلن المسار في لحظة محددة. كما أن استلام تحديث لا يعني اختياره، واختياره لا يعني تثبيته في جدول التحويل.

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

قدّمت الشبكات المتوسطة سياساتها إلى Merit، ثم أُدرجت في ملفات إعداد موجّهات ANSnet. بين الطلب والسلوك الفعلي كانت هناك قاعدة وتقارير وأدوات توليد وبرامج تحليل. كل نسخة احتاجت إلى وقت وهوية مستقلة.

الإعلان المباشر ليس التجميع بالنيابة

إذا كانت شبكة إقليمية تدعم CIDR، استطاعت إعلان بادئة مجمّعة مباشرة. وكانت القاعدة تحدد أنظمة AS المتوقعة كمصادر لذلك الإعلان.

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

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

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

لم يكن مطلوباً إعادة التفاصيل لكل جار

قالت الخطة الأولية إن NSFNET لن تفكك التجميعات إلى مسارات أكثر تحديداً عند الإعلان إلى الخارج. الجار الذي يريد معلومات كاملة كان عليه استخدام بروتوكول يدعم CIDR. أما من يعتمد مساراً افتراضياً فيمكنه إرسال الحركة نحو المجال المغطى من دون استلام قائمة المكوّنات.

إذن دقة الصورة عند المراقب كانت جزءاً من عقد التبادل. رؤية بادئة واسعة لا تثبت أن المصدر لا يعرف تفاصيل أدق. وامتلاك المصدر لتلك التفاصيل لا يثبت أنه أرسلها إلى كل جار.

شرح RFC 1338 ثم RFC 1519 ضغط النمو الذي دفع إلى تخصيص وتجميع بلا فئات. ووصف RFC 1771 لاحقاً سمات BGP-4 ومسار AS. وقدّم RFC 1786 لغة أغنى لسياسات سجل التوجيه. تساعد هذه الوثائق على تسمية الطبقات، لكنها لا تثبت بأثر رجعي تنفيذ كل صف أو مثال في RFC 1482.

السجل كان نية قابلة للتحويل، لا رصداً حياً

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

ذكر RFC أيضاً الفرق المفاهيمي بين rcp_routed وGateD. قد يكون السجل محدثاً بينما يعمل ملف قديم؛ وقد يُنشأ الملف ولا يُحمّل؛ وقد يستلم البرنامج مساراً ثم يرفضه عند الاختيار أو التصدير. السجل والملف والحالة التشغيلية نتائج مترابطة وليست شيئاً واحداً.

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

نسبة 33 في المئة لم تكن قياساً بعد التنفيذ

حسبت الوثيقة إمكان حذف 4,135 إعلاناً من أصل 12,348، أي 33 في المئة. ووصفت الرقم بأنه تقدير متفائل نتج من خوارزمية متشائمة، ونبهت إلى أن الوفر الحقيقي قد يختلف.

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

يصنف سجل RFC Editor الوثيقة اليوم على أنها Historic. قال النص إن التنفيذ جارٍ، مع بقاء التخطيط والنقاش والتصحيح والاستقرار وخوارزميات القرار ومعالجة الفجوات للعمل اللاحق. عبارة «جارٍ» لا تحدد جهازاً أو نسخة إعداد أو وقت تفعيل.

كلما اختصر المسار احتجنا إلى تاريخ أطول

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

يلزم حفظ حدود البادئة ومكوّناتها، Home AS، وكل جهة عبور، وجمهور كل جار، ونسخة السجل، والملف المولد والمثبت، والتحديث المستلم، والاختيار والتصدير، وجدول التحويل، ونتيجة الحزمة.

إذا بقيت البادئة النهائية وحدها، سنعرف أن غطاءً ظهر، لكننا لن نعرف أي مكوّن فعّل القاعدة، ومن كان يقصد مخاطبة من، وأي فجوة أخفاها الاختصار. تلك هي المفارقة التي حفظها RFC 1482: مقياس أكبر للشبكة يتطلب دقة أكبر في نسب الدليل.

المصادر