الخلاصة

  • أبقت TUBA على TCP وUDP وعلى كثير من تطبيقات الإنترنت، لكنها اقترحت استبدال IPv4 ببروتوكول CLNP وعناوين NSAP ذات البنية الهرمية.
  • لم يكن دعم الموجّهات كافياً: احتاج الانتقال أيضاً إلى مضيفين وDNS محدثين، وإلى التعامل مع التطبيقات التي تضمّن عناوين IPv4، وإلى اتفاق بشأن سلطة تعديل CLNP.

ما الذي بقي وما الذي تغيّر؟

في يونيو 1992، نشر Ross Callon RFC 1347، مقترحاً أطلق عليه TUBA: «TCP and UDP with Bigger Addresses». عالج النص ضغطين متداخلين: محدودية عناوين IPv4 ذات 32 بت، والزيادة السريعة في معلومات التوجيه داخل الشبكات الأساسية. لم يكن المقترح توسيعاً لحقل IPv4. كان تغييراً لطبقة الشبكة نفسها: تشغيل TCP أو UDP فوق بروتوكول CLNP عديم الاتصال من منظومة ISO، واستخدام عناوين NSAP بدلاً من عناوين IP.

كان الوعد بالاستمرارية محدداً. يستطيع المتصفح أو برنامج البريد أو نقل الملفات مواصلة استخدام TCP أو UDP ما دام بروتوكول التطبيق لا يعتمد داخلياً على عنوان IPv4. أما أسفل النقل، فشكل الحزمة والعنوان وطريقة الإيصال كانت ستتغير. رأى Callon أن CLNP يوفر خدمة حزم بيانات، وأنه موجود بالفعل في بعض الشبكات الإقليمية والأساسية على الإنترنت؛ لذلك يمكن أن يقلل إعادة الاستخدام مقدار العمل اللازم لبناء طبقة جديدة واختبارها ونشرها.

لم تطلب TUBA انتقال الإنترنت كله إلى بروتوكولات OSI. كان نطاقها أضيق: استبدال IP والإبقاء على TCP وUDP وكثير من تطبيقات الإنترنت. وقد حددت RFC 1561، وهي مذكرة تجريبية صدرت في ديسمبر 1993، ملفاً تشغيلياً لـ CLNP في بيئات TUBA. وأوضحت أن خدمتي IP وCLNP متقاربتان لكنهما غير متطابقتين، وأن بعض دلالات المعلومات المتوقعة في بروتوكولات الإنترنت تحتاج إلى حفظها.

كان DNS والمضيفون جزءاً من الانتقال

تخيلت RFC 1347 تعايش المضيفين القدامى والمحدثين. يستعلم المضيف المحدث من DNS: إذا تلقى عنوان IP عادياً لجهاز قديم، يستخدم المكدس القديم؛ وإذا تلقى عنوان NSAP أطول لجهاز يدعم TUBA، يرسل TCP أو UDP عبر CLNP. ولذلك كان DNS بحاجة إلى سجل جديد باسم «long-address». وعلى الموجّهات تمرير حزم IP وCLNP، إما بواسطة أجهزة متعددة البروتوكولات أو مجموعات منفصلة. وكان العنوان الذي يعيده DNS يحدد طبقة الشبكة؛ فلم تكن الخطة تتطلب ترجمة كل حزمة أو تغليفها بين البروتوكولين.

أمكن لهذا الترتيب أن يبدأ تدريجياً، لكنه لم يلغِ الاعتماد المتبادل. قد يعمل مضيف محدث داخل شبكة لا تنقل إلا IP. وبعض استخدامات FTP وNFS تضع عناوين IP في بيانات التطبيق؛ لذا لا يكفي بقاء TCP لإبقاء تلك الاستخدامات كما هي. احتاج مضيفو الإنترنت ومشغلو DNS والشبكات إلى تنسيق خطواتهم. كما أن العنوان الأطول لا يضمن تجميع المسارات: ينبغي أن تراعي تخصيصات NSAP بنية الشبكة كي يستطيع الموجّه جمع الإعلانات.

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

إعادة استخدام البروتوكول حملت سؤالاً عن سلطة إدارته

سجلت RFC 1752 اعتراضات على محاذاة حقول CLNP، والتوجيه من المصدر، ورسائل الأخطاء، واستخدام NSAP لتجميع المسارات. وقد تتطلب معالجة بعض المشكلات تعديل CLNP أو ملفه التشغيلي. هنا ظهر خلاف معياري داخل مجتمع TUBA: هل يستطيع IETF تعديل مواصفات CLNP الأساسية أم يجب أن تمر التغييرات عبر ISO؟ أثرت الإجابة في سرعة إصلاح العيوب وفي الجهة المسؤولة عن طبقة ستعتمد عليها الإنترنت.

لم تمحُ توصية IPng مساهمة TUBA. بعد نقاش ومراجعة مرشحين عدة، أوصت RFC 1752 بالنسخة المعدلة من SIPP أساساً لـ IPng. كما وصفت حصيلة تجمع أعمالاً متعددة: قدم SIPP معظم الأساس، بينما أثرت TUBA في التهيئة الآلية وآليات الانتقال. لم يحل CLNP محل IP في الإنترنت، لكن وصف TUBA بأنها فكرة خاسرة بلا أثر يتجاهل ما انتقل من عملها إلى التصميم اللاحق.

تقدم Note:64 اللاحقة لـ Heng Lu عدسة تحليلية بأثر رجعي، لا دليلاً تاريخياً عن التسعينيات: ما الحد الأدنى من القواعد المشتركة للاتصال، وما الخيارات التي يمكن تركها للمطبقين، وما الدليل على التبني؟ تظهر TUBA أن إعادة استخدام بروتوكول قد تقلل الاختراع من جديد، لكنها لا تحدد وحدها من يصونه، ولا أي مضيفين يشغلونه، ولا أي شبكات تنقله فعلاً.

المصادر