الخلاصة

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

دخل الإعلان ولم يدخل جدول التمرير

قدمت RFC 1476 بروتوكول RAP بوصفه تجربة في التوجيه بمتجه المسافة، من الشبكات المحلية الصغيرة إلى شبكات الناقلين الدوليين. لم يفرض التصميم فاصلاً ثابتاً بين التوجيه الداخلي والخارجي؛ كان يمكن للسياسة الإدارية أن ترسم الحدود اللازمة.

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

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

القرار الأول قد يحذف ما يحتاجه المستقبل

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

تذكر RFC 1476 نتيجة زمنية مهمة. إذا فُتح المرشح لاحقاً، فقد لا تعود الطرق التي رُفضت من قبل؛ ربما أرسلها النظير مرة ولم يكررها. التهيئة الجديدة تعني «سأقبل الآن»، ولا تعني «العرض موجود الآن».

لاستعادة الحالة يلزم إعلان جديد، أو نسخة محفوظة قبل المرشح، أو آلية تحديث. تغيير القرار لا يعيد المدخل الذي زال.

القرار الثاني جعل الجهل ذا عواقب محددة

تزيد RAP المسافة، وتجمع التأخير والكلفة، وتأخذ أصغر MTU وأصغر عرض نطاق على الطريق. وقد تدفع سياسة مفهومة إلى رفض المسار. أما الخيار غير المفهوم فيحمل فئة تحدد التعامل معه.

الفئة 0 تسمح باستخدام المسار ونشره، مع إلزام إبقاء الخيار كما هو إذا نُشر. الفئة 1 تسمح بالاستخدام والنشر من دون الخيار. الفئة 2 تسمح بالاستخدام المحلي وتمنع النشر. الفئة 3 تسقط المسار كله. ولم تفرض المواصفة فهماً عاماً لأي خيار عدا مقياس المسافة في الرأس.

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

لا تعيد هذه المقالة قصة بتات خيارات IPv6 المجهولة ولا Partial في BGP. خصوصية RAP أن أثر الجهل يمتد داخل خط القرار كله: قد يبقى العرض محلياً، أو يعبر إلى جار، أو يختفي.

قيود المصدر وسياسة الاستخدام والوسط العام

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

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

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

القرار الثالث يبادل التفاصيل بالحجم

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

تقدم RFC 1338 سياق supernetting وضغط جداول التوجيه في ذلك الزمن. أضاف RAP سؤالاً عن المعلومة: هل يحتفظ الملخص بالفروق التي يحتاجها الجار لسياساته؟ من يستقبل الطريق المجمّع لا يستطيع افتراض أنه يعرف كل الطرق التي كونته.

القرار الرابع يختار ما يستطيع تحريك الحزم

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

كانت RFC 1058 مرجع متجه المسافة في RIP، بينما مثلت RFC 1247 OSPF وحالة الوصلة. أراد RAP العمل إلى جانبها، ولم يجعل التعلم من أي مصدر اختياراً تلقائياً.

وجود طريق في قاعدة RAP لا يثبت أنه دخل FIB. وحتى دخوله FIB لا يثبت أن حزمة بعينها طابقته أو خرجت من الواجهة أو وصلت إلى مقصدها.

القرار الخامس يصنع صورة مختلفة لكل جار

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

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

حياة TCP لا تثبت حياة RAP

فتح النظراء اتصال TCP متناظراً على المنفذ 38، وتبادلوا الأوامر في الاتجاهين من دون إقرار لكل أمر. أضافت Poll وNo Operation اختباراً في طبقة RAP نفسها.

لم تنصح الوثيقة بالاعتماد على TCP keepalive وحده. فهو يثبت أن TCP البعيد يقبل بيانات، لا أن عملية RAP حية. وعند انقطاع الاتصال كان على كل طرف إزالة كل الطرق التي قدمها الطرف الآخر. هذه قاعدة بروتوكول تحتاج إلى سجل تنفيذ كي تصبح واقعة تشغيلية.

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

قيمة التجربة في فصل الصلاحيات

تضع RFC 1475 وسجلها RAP داخل مشروع TP/IX. المقالة السابقة تملك موضوع معرّف المسار الخاص بالقفزة التالية وتوقيت Add/Purge. هذه المقالة لا تكرر ذلك؛ موضوعها هو سلسلة القرارات بعد وصول الإعلان.

تساعد RFC 2026 على فصل مصطلحات عملية المعايير عن إثبات الاعتماد. قد تحمل المواصفة التجريبية فكرة نافعة، ولا تتحول بذلك إلى تشغيل واسع.

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

المصادر