الخلاصة

  • تكيّف RFC 9507 traceroute مع CCNx وNDN؛ يسير Interest وفق اسم لا عنوان نهاية فريداً، وتعود Data عبر الحالة التي أنشأتها جداول Pending Interest Table على كل قفزة.
  • يمنع nonce تجميع مجسات التشخيص، وتفصل أربعة رموز بين قفزة واسم إداري وتطبيق محلي ونسخة مخبأة، ويمكن لـPath Label توجيه الطلب التالي إلى الفرع المرصود.
  • النتيجة دليل محدود على مسار إجابة في شروط محددة. لا تثبت المصدر الوحيد ولا كل المسارات ولا سلوك الطلب العادي ولا نتيجة التطبيق.

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

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

تضع RFC 9507 أداة لهذا الواقع. نُشرت في مارس 2024 بوصفها RFC تجريبية في مسار IRTF، وليست مواصفة Standards Track من IETF. تصف تنسيقات CCNx وNDN وعمل العميل والموجّه وتوجيه المسار والحدود الأمنية. هدفها اكتشاف مسار واحد أو أكثر نحو اسم، لا إعادة تعريف الاسم كعنوان مضيف.

الاسم يغير هندسة القياس

يرفع traceroute التقليدي قيمة TTL تدريجياً. عندما تنفد القيمة عند موجّه، يرسل ICMP Time Exceeded إلى عنوان المصدر. توجد قيود مثل عدم التناظر والحجب، إلا أن الإحداثي الأساسي يبقى عنوان وجهة.

لا يحمل Interest في ICN عنوان مصدر. يُمرر بحسب اسم هرمي، وتعود Data عبر حالة أنشأها الطلب في PIT على طول الطريق. يمكن أن يحمل عدة منتجين نسخاً من الاسم، ويمكن أن تجيب الذاكرة داخل الشبكة. ولهذا قد تمر طلبات متتالية للاسم نفسه بمسارات مختلفة وتصل إلى مصادر مختلفة.

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

تضيف RFC 9507 قيمة nonce إلى الاسم. يستخدم CCNx مقطع اسم من 64 بت، بينما تجمع صيغة NDN الهدف وnonce واللاحقة traceroute. يصبح كل مجس فريداً بالنسبة إلى PIT، ويطابق العميل الرد بالطلب الصحيح. وعند البحث في Content Store تُهمل قيمة nonce، كي يظل تطابق الكائن الأصلي ممكناً.

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

أربعة رموز لا تعني نجاحاً واحداً

يبدأ العميل بـHopLimit يساوي 1 ثم يزيده. يفحص الموجّه القيمة ويخفضها. ما دامت أكبر من صفر، يجري بحث الذاكرة وينشئ PIT ويطبق Longest Name Prefix Match وأي قيمة لتوجيه المسار. إذا غاب المسار التالي يعيد CCNx عبارة No Route أو يعيد NDN رسالة NACK شبكية.

عندما تبلغ HopLimit صفراً، يرسل الموجّه اسمه الإداري والرمز 4. وصل المجس إلى المسافة المختارة؛ لم يثبت وصول الكائن.

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

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

Path Label يثبت فرع التجربة لا خريطة الشبكة

يمكن لطلبات ذات HopLimit مختلف أن تختار فروعاً مختلفة. عند جمعها، قد يظهر مسار مؤلف من موجّهات لم تجتمع قط في رحلة واحدة. تستخدم RFC 9507 آلية Path Steering في RFC 9531.

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

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

الصياغة المنضبطة تقول إن جلسة محددة بالوقت والاسم وnonce والتسمية رأت هذه الإجابات وانتهت بهذا الرمز. أما قول «هذا مسار المحتوى» فيتجاوز الدليل.

نطاق التوقيع هو نطاق الثقة

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

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

ينبغي للسجل أن يذكر ما الذي وُقع، وأي مفتاح قُبل، وكيف جُلب، وهل تحقق توقيع الرسالة كاملة. عبارة «مسار موقع» لا تكفي.

الاسم المحلي يحتاج إلى جسر ظاهر

قد لا يكون namespace محلياً قابلاً للتوجيه من شبكة العميل. يقترح تصميم إرفاق NDN Link Object موقع يحوي بادئات قابلة للتوجيه حتى منطقة يعمل فيها الاسم. وتترك الوثيقة طريقة حصول العميل على ذلك الكائن خارج النطاق.

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

إذا احتفظ السجل بالاسم المحلي النهائي وحده، اختفى الجسر الذي جعل التتبع ممكناً. يجب حفظ Link Object وتوقيعه والبادئة الخارجية وحدود إعادة الكتابة والانتقال الإقليمي.

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

المصادر