الخلاصة

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

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

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

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

يوصي المستند باستخدام Generic Routing Encapsulation (GRE) لنقل أنواع مختلفة من الحزم الداخلية عبر IP. في الصيغة المعروضة، تصل رزمة IP خارجية إلى عنوان نقطة الإرسال ثنائي الاتجاه؛ ويحدد رأس GRE بروتوكول طبقة الوصلة في الوسيط الأحادي؛ أما الحمولة فتحمل إطار MAC الأصلي. يمكن اختيار نوع نفق آخر إذا اتفق الطرفان على معناه. تضبط RFC 3077 التكييف حول النفق، لكنها لا تجعل GRE آلية تفويض أو أمان.

أما كيفية معرفة المستقبل بنقطة الإرسال التي ينبغي أن ينفق إليها، فهي أقل بداهة. لا يستخدم بروتوكول Dynamic Tunnel Configuration Protocol (DTCP) مسار الإنترنت العائد للاكتشاف. تسير رسائل HELLO من نقاط الإرسال إلى المستقبلات عبر الوصلة الأحادية نفسها. تعلن JOIN أن نقطة الإرسال تعمل؛ ويمكن لـ LEAVE أن يعلن توقفها. وتحمل HELLO أيضاً فاصلاً زمنياً ورقم تسلسل ونوع النفق وعنواناً واحداً أو أكثر لواجهات IP ثنائية الاتجاه لدى نقطة الإرسال (FBIP). تستمع المستقبلات إلى إعلان DTCP متعدد الوجهات وتحفظ قائمة بالنقاط الفعالة ونهايات الأنفاق ومؤقتات الانتهاء.

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

يظل اختيار نقطة الإرسال محلياً. تختار كل مستقبلة نقطة افتراضية خاصة بها. وتذكر RFC أن زمن الذهاب والإياب الأقل مثال محتمل، لا قاعدة إلزامية موحدة. يستطيع المسؤول اختيار نهاية نفق معلنة أخرى إذا كانت أوصل. وحتى عنوان MAC لنقطة الإرسال على الوصلة الأحادية (FUMAC)، وهو ضروري للتشغيل، لا تحدد RFC طريقة عامة لاكتشافه. تنظم الصيغة المشتركة تبادل المعلومات؛ أما منفعة الطريق فتقررها الإعدادات المحلية.

قد تخفي كلمة «ثنائية الاتجاه» تكلفة التفاوت. فقد يضيف رابط قمر ثابت نحو 250 ميلي ثانية من التأخير في اتجاه واحد بحسب المثال الوارد في RFC، فيما يتغير زمن مسار العودة عبر الإنترنت أيضاً. وتحذر المواصفة من أن حل العناوين التفاعلي مثل ARP قد يجعل نقطة الإرسال تنتظر الرد بينما تتراكم الحزم، إلى أن تنفد الذاكرة المؤقتة وتسقط الحزم. هذا خطر هندسي توضحه المواصفة، وليس نتيجة قياس لخدمة مسماة. جُمعت الطريقان، لكنهما لم يصبحا متماثلين في التأخير أو السعة أو الجهة المسؤولة.

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

الثقة شأن منفصل. تحذر RFC من أن انتحال ARP أو IP قد يتيح لعقد غير مخولة دخول الخدمة. وتشير إلى إمكان مصادقة الأنفاق لكنها لا تحدد وسيلة لذلك. أما بروتوكولات التوجيه فوق الوصلة المحاكية فينبغي أن تستخدم وسائل المصادقة المتاحة لديها لمنع مستقبل غير مخول من بث مسارات زائفة. JOIN وعناوين نقاط النهاية في DTCP إعلانات، لا بيانات اعتماد.

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

المصادر الأساسية