الخلاصة

  • وضعت RFC 1070 وحدات بيانات طبقة الشبكة في OSI كاملةً داخل رزم IP. أتاح ذلك اختبار توجيه OSI بين مواقع متباعدة من دون تركيب بروتوكولات غير ناضجة في بوابات الإنترنت القائمة.
  • لم تجعل قابلية الوصول عبر IP الجهاز عضواً أو جاراً في EON. فقد عبّرت عناوين NSAP وملفات core.EON وذاكرة SNAcP وأدوار ES/IS وتبادل رسائل التوجيه عن حالات مستقلة يمكن أن تختلف في الوقت نفسه.

تضع RFC 1070، الصادرة في فبراير/شباط 1989، تحذيرها قبل تفاصيل التصميم: تصلح الوسائل المقترحة لتجربة محدودة فقط، ولا تصلح لبيئة تشغيلية. كانت بروتوكولات طبقة الشبكة في OSI موزعة بين معيار مكتمل ومقترحات لم تنضج بعد. وكان اختبارها يحتاج إلى طوبولوجيا واسعة ومتنوعة ومتغيرة، لكن إدخالها في عدد كبير من بوابات IP المستخدمة فعلاً كان قد يجعل الإنترنت نفسها تتكبد أخطاء التجربة.

اختار المقترح استعمال الاتصال الموجود من دون تغيير تلك البوابات. على الوصلة المحلية تعمل بروتوكولات OSI مباشرة. وعندما يفصل بين الموقعين جهاز بوابة IP، توضع وحدة CLNP أو ES-IS أو IS-IS بكاملها داخل رزمة IP. سمّيت البنية السفلى في الوثيقة «IP subnet»، أما الشبكة المنطقية المبنية فوقها فسميت EON، أي Experimental OSI-based Network.

أعطى الغلاف عنواناً للإرسال، لا دوراً للمستقبِل

في EON المباشرة حمل حقل البيانات في رزمة IP الـISO-gram، وأخذ حقل Protocol القيمة 80. فضّل المصممون أن تجزّئ طبقة OSI وحداتها حتى تكون آلية التجزئة جزءاً من الاختبار. إلا أن IP قد يجزّئ الغلاف في الطريق أيضاً، ولذلك وجب على الوجهة إعادة التجميع في الطبقة السفلى.

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

استند تنسيق NSAP إلى RFC 1069، ووضع بايتات عنوان الإنترنت الأربعة قرب نهايته قبل selector. أمكن بذلك اشتقاق عنوان SNPA في IP subnet خوارزمياً. أسندت IANA رقم نطاق التوجيه، وبدأ حقل المنطقة المحلية بقيمة صفر.

يجيب هذا الاشتقاق عن سؤال: إلى أي عنوان IP تُرسل الرزمة الخارجية؟ ولا يجيب إن كان النظام النهائي ES أو النظام الوسيط IS أو الاثنين معاً. سمحت التجربة بتغيير هذا الدور والعلاقة المنطقية من دون تغيير الاتصال المادي بالإنترنت. كما استبعدت استعمال خوارزميات توجيه IP لتوجيه ISO-grams بين المشاركين، واستبعدت نطاق الإنتاج وبوابة IP-to-CLNP. بقي توجيه OSI هو الشيء المراد اختباره.

صنع SNAcP البث من نسخ أحادية

افترض ES-IS وIS-IS وجود معنى «كل الأنظمة النهائية» و«كل الأنظمة الوسيطة» على شبكة بث. لم تقدّم IP subnet هذا المعنى مباشرة. لذلك وضعت RFC 1070 بروتوكول وصول صغيراً بين OSI CLNL وIP اسمه SNAcP.

احتفظ كل SNAcP بذاكرة لعناوين الإنترنت التي يعدّها النظام المحلي قابلة للوصول في قفزة ISO 8473 واحدة. إن كانت الوجهة فردية أرسل نسخة واحدة. وإن كانت كل ES أو كل IS أو بثاً عاماً، نسخ الـISO-gram لكل SNPA في الذاكرة. حمل ترويسه القصير رقم الإصدار ومعنى العنوان وchecksum من نوع Fletcher.

عند الاستقبال يقبل SNAcP الرسالة الفردية والبث العام، لكنه يقرر قبول all-ES أو all-IS وفق دور الجهاز المضبوط محلياً. وهكذا يختار مرسلٌ جمهورَه من ذاكرته، ويختار كل مستقبل ما يناسب دوره. لا يثبت وصول النسخ أن قائمة المرسل كاملة، ولا يثبت قبول جهاز لرسالة all-IS أن الآخرين تعلّموا دوره الجديد.

كانت إشارات ICMP تحتاج هي الأخرى إلى تفسير محلي. اقترحت الوثيقة أن تجعل destination unreachable أو parameter problem أو time exceeded عنواناً في الذاكرة غير صالح للاستعمال، وأن يفعل source quench ذلك مؤقتاً. أما «إبلاغ إدارة الشبكة» فقد يعني رسالة في الطرفية أو عداداً أو سجلّاً أو عملية محلية، وقد يعني ألا يحدث شيء. عند البث المحاكى يتجاوز SNAcP العنوان غير الصالح، وعند الإرسال الفردي يعيد خطأً إلى OSI CLNL. لم يتحول عطل الناقل إلى حالة في الشبكة العليا إلا بواسطة سياسة محلية.

لم تكن قائمة البدء دليلاً على وظيفة الجهاز

يحتاج النظام عند الإقلاع إلى مخاطبين أوليين قبل أن يتعلم غيرهم من بروتوكولات التوجيه. لذلك كان على IANA حفظ core.EON لتجربة IP المباشرة وcore.EON-UDP لتجربة UDP. تحتوي كل قائمة عناوين SNPA التي ينبغي للأنظمة الأساسية الأخرى عدّها على بعد قفزة OSI منطقية واحدة.

إلى جانبهما جاءت hosts.EON وhosts.EON-UDP لأسماء الأنظمة النهائية، كي تستعملها التطبيقات والبشر. نصت RFC على أن OSI CLNL لا يستخدم هاتين القائمتين. وحتى سطر core.EON لا يجعل صاحبه بوابةً أو IS؛ فقد يكون ES أو IS أو يجمع الوظيفتين. ويمكن لنظام أساسي جديد أن يبدأ المشاركة قبل نشر عنوانه، لكن الأنظمة التي تقلع من القائمة القديمة لن تعرف أن عليها إرسال ESH أو ISH إليه.

يشرح مثال Fordor الافتراضي معنى التأخر. كان 192.5.2.1 في البداية نظاماً وسيطاً وعضواً أساسياً، وكان 192.5.2.2 نظاماً نهائياً. يتبادل الجهازان الدورين من دون أن يتغير اتصالهما بالإنترنت. إذا لم تُحدّث قائمة IANA فوراً، يستمر الآخرون في إرسال رسائل الإعداد إلى .1، فيجيب الآن بصفته ES. ولا يعرفون أن عليهم بدء الاتصال مع IS الجديد .2، فيبدو هذا الأخير غير قابل للوصول داخل EON على الرغم من أن IP يصل إليه.

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

فتحت UDP تجربة موازية لا بوابة تلقائية

لم تسمح بعض الأنظمة للمبرمج بالوصول المباشر إلى IP، لكنها أتاحت UDP. وضعت EON-UDP وحدة OSI في المنفذ 147، وجعلت SNAcP بين UDP وISO 8473. تشابهت بقية القواعد، لكن RFC قالت إن EON وEON-UDP لا تتخاطبان مباشرة. يمكن تصور بوابة بينهما، إلا أن بنائها وتوجيهها خارج نطاق المقترح. ولهذا امتلكت التجربتان قوائم core وhosts منفصلة.

ويفصل موضع التجربة في المكدس بينها وبين الوثائق القريبة. وفرت RFC 1006 خدمة نقل OSI فوق TCP كي تعمل طبقة الجلسة وما فوقها. أما RFC 1070 فحملت طبقتي الشبكة والنقل في OSI عبر internetwork يعمل بـIP. واستعملت RFC 1069 توجيه الإنترنت وعنونة الإنترنت في بوابة CLNP، بينما أرادت RFC 1070 استعمال توجيه OSI وعنونة OSI واختبارهما.

المصادر والحدود

تصف RFC 1070 اتفاقاً تجريبياً وسيناريو افتراضياً. لا تثبت انتشار EON أو استخدامها في الإنتاج أو كونها أصلاً مباشراً لشبكة overlay معاصرة. Fordor مثال تعليمي وليس حادثة. وتقدّم RFC 994 وRFC 995 مواصفات CLNP وES-IS في ذلك الزمن، ولا تشهدان بصحة تطبيق معين.

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