الخلاصة

  • وضع RFC 877 الحد الأدنى للربط بين IP وX.25: بايتاً لتعريف البروتوكول، وتسلسلاً كاملاً من الحزم لكل رزمة بيانات، ومعلمات يمكن للمواقع التفاوض عليها.
  • تُفتح الدائرة عند الحاجة ويعتمد إغلاقها بعد الخمول على تكلفة إبقائها مفتوحة؛ ولم يخصص المعيار دائرة X.25 لكل اتصال TCP.

التحليل

للدائرة ساعة اقتصادية تخصها

في سبتمبر 1983 نشر J. T. Korb الوثيقة RFC 877 لشرح نقل رزم بيانات IP عبر شبكات بيانات عامة قائمة على X.25. وتقول المقدمة إن CSNET وVAN Gateway ومنظمات أخرى تبنت المعيار. إنها تسمي بعض الجهات المتبنية، ولا تقدم حصراً لجميع الشبكات.

كان المطلوب وصل نموذجين تشغيليين مختلفين: IP يرسل رزم البيانات، بينما توفر X.25 دوائر افتراضية عبر شبكة بيانات عامة. لم تحاول RFC 877 جعل دائرة الشبكة تشبه محادثة تطبيق. بل وضعت واجهة مشتركة صغيرة وأبقت خيارات تشغيلية مهمة لدى المواقع المتصلة.

بايت واحد للتعرّف على البروتوكول

يحدد الأوكتت الأول في حقل Call User Data ضمن طلب الاتصال عبر X.25 بروتوكول الشبكة؛ والقيمة 0xCC تعني IP. ثم تُرسل كل رزمة IP كسلسلة كاملة من حزم X.25: تبدأ الرزمة عند حد حزمة، وتشير بتة More إلى استمرارها إذا احتاجت إلى أكثر من حزمة. ولم تضف RFC ترويسة أخرى داخل حزم البيانات.

كان الحجم محدداً مع إمكان التفاوض. فمن دون اتفاق على حجم أكبر لحزمة X.25، لا تتجاوز رزمة IP مقدار 576 أوكتتاً. وتذكر الوثيقة 1,024 أوكتتاً مثالاً على حجم أكبر جرى التفاوض عليه. أمكن للمواقع الاتفاق على حجم الحزمة والنافذة وغيرها من التسهيلات، بدلاً من فرض ملف تشغيل واحد على الجميع.

اتصال TCP لا يحدد عمر الدائرة

للدائرة جدول زمني مختلف. تقول RFC 877 إن الدائرة الافتراضية تُفتح عند الطلب عندما تصل رزمة إلى واجهة الإرسال. ويمكن إغلاقها بعد مدة من الخمول، ويتوقف طول تلك المدة على تكلفة إبقاء الدائرة مفتوحة. كما تستطيع الواجهة إغلاق دائرة عند نفاد الدوائر المتاحة، ويستطيع أي من الموقعين إنهاءها.

وتفصل الوثيقة ذلك صراحة عن TCP: البروتوكولات الأعلى من IP لا تؤثر في هذا المعيار، ولا تفتح الواجهة دائرة X.25 مقابلة لكل اتصال TCP. لذلك لم يكن اتصال TCP طويل العمر وعداً ببقاء دائرة مخصصة له على شبكة البيانات العامة. كان المحول يدير مورداً للشبكة، بينما ظلت حالة اتصال TCP في طبقة أخرى.

والأثر الموثق محدد: إذا أُغلقت الدائرة أو أعيد ضبطها أثناء نقل رزمة، فستُفقد تلك الرزمة. لا تذكر RFC معدل حدوث ذلك ولا ما تراه التطبيقات بعده. واستجابة بروتوكول أعلى تقع خارج الأدلة التي تقدمها هذه الوثيقة.

التوصية لا تعني النشر في كل مكان

صنّف التقرير الرسمي لبروتوكولات ARPA-Internet لعام 1984، RFC 924، بروتوكول الإنترنت على شبكات X.25 بأنه Recommended وأحال إلى RFC 877 بوصفها مواصفته. وكانت هذه الفئة تشجع المضيفين على التنفيذ، لا تثبت أن كل مضيف نفذه. وفي 1992 وصفت RFC 1356 طريقة RFC 877 بأنها واسعة الاستخدام، ثم استبدلتها لمعالجة الغموض وتغير المتطلبات المتعلقة بحجم الرزم والحزم، وإدارة الدوائر، والربط بين بروتوكولات متعددة.

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

قراءة لاحقة عبر المذكرة 64

تقترح المذكرة 64 لهينغ لو مبدأ تصميمياً: تحديد الحد الأدنى من القواعد المشتركة اللازمة للتشغيل البيني، ثم ترك الخيارات اللاحقة للمشاركين الذين يشغلون النظام. وبوصفها عدسة تحريرية، تساعد هذه الفكرة على قراءة بنية RFC 877: القيمة 0xCC وحدود الحزم قواعد مشتركة، أما مدة الإغلاق عند الخمول والتسهيلات القابلة للتفاوض فلم تُحدد بقيمة عالمية واحدة.

هذه مقارنة بأثر رجعي. لا تشير RFC 877 إلى المذكرة 64، ولا تثبت المذكرة نية Korb. ما تثبته الوثيقة نفسها هو أن التعرف على IP فوق خدمة X.25 عامة لم يستلزم توحيد تكلفة كل دائرة أو عمرها.

المصادر