الخلاصة

  • أعطت RFC 892 اتصال النقل مرجعين يختارهما الطرفان، فصار له تعريف محلي مستقل عن Network Connection التي تحمل رزم بروتوكوله.
  • سمح multiplexing لعدة اتصالات نقل بأن تشترك في اتصال شبكة واحد، بينما أتاح splitting في الفئة المحددة اتصال نقل واحداً فوق عدة اتصالات شبكة.
  • لم يكن الفصل مطلقاً؛ فقد قيدته جودة الشبكة والوظائف pervasive ونتيجة تفاوض الفئة وقواعد التعافي أو الارتباط المباشر بعمر الحامل.

تشترط RFC 892 إسناد Transport Connection إلى Network Connection قبل استخدامها، أو إلى أكثر من واحدة عند تشغيل splitting. وقد تكون الشبكة الحاملة موجودة سلفاً أو تنشأ لهذا الغرض. معنى ذلك أن الإسناد قرار في التوصيل، لا الدليل الوحيد على هوية حالة النقل.

وصلت الوثيقة إلى سلسلة RFC بصفتها مادة معلوماتية من ISO، وصرحت بأنها لا تضع معياراً لـ ARPA Internet. وبعد أشهر جاءت RFC 905 بنسخة أحدث من ISO DP 8073 لتحل محل RFC 892، مع الحد المؤسسي نفسه. وجود النص في الأرشيف لا يثبت أن الإنترنت اعتمد بنية OSI ذات الفئات الخمس.

كل طرف اختار الرقم الذي سيستعمله الطرف الآخر

يرسل المبادر Connection Request TPDU، أي CR، وفيه source reference اختاره محلياً. ويرد الطرف الآخر بـ Connection Confirm، أي CC، وفيه مرجعه. بعد ذلك يستخدم كل طرف قيمة شريكه بوصفها destination reference.

المرجع حقل محلي من 16 بت. لا يجوز أن يكون صفراً أو مستخدماً أو ما زال مجمداً بعد اتصال قديم. ليس اسماً عالمياً ولا هوية قانونية ولا سراً. قوته آتية من جدول الطرف المستقبل الذي يربطه بحالة TC حية.

وصفت RFC 892 الآلية بأنها متناظرة؛ فلا تحتاج إلى تعيين master وslave، وتقلل مشكلة تصادم محاولتي اتصال متزامنتين من دون موزع مركزي. وبذلك عرّفت TC بصورة مستقلة عن NC.

لكن الرقم الصحيح لا يكفي وحده. يجب أن تصل TPDU على حامل مقبول وفي طور بروتوكولي صحيح وبين transport entities المتوقعة. المرجع يجيب عن «إلى أي حالة؟»، ولا يثبت «من الشخص؟» أو «هل يملك إذن التنفيذ؟».

الطلب حمل التفضيل، والتأكيد حمل الاختيار

عرّفت RFC 892 خمس فئات: class 0 البسيطة، class 1 للتعافي الأساسي، class 2 للمشاركة multiplexing، class 3 للتعافي والمشاركة، وclass 4 لاكتشاف فقدان الوحدات وتكرارها واضطراب ترتيبها وتلفها ثم التعافي.

يقترح المبادر preferred class وبدائل في CR، إلا إذا كان يفضل class 0 فلا بدائل. ويجوز أن يبدأ الوظائف على افتراض قبول اختياره. غير أن الافتراض مؤقت. يحمل CC الـ selected class، وعلى المبادر تعديل عمله إذا اختار المستجيب بديلاً مسموحاً.

ظل حجم TPDU موضوع تفاوض مستقل. يستطيع المستجيب قبول الحد المقترح أو خفضه ضمن القيم المسموحة. وتتحول proposed options إلى selected options. قيام NC وصحة صياغة CR ورغبة المبادر والعقد المؤكد أربع طبقات من الدليل.

للخدمة السفلية أثر في الاختيار أيضاً. صنفت الوثيقة الشبكات وفق الأخطاء المتبقية والأعطال المعلنة، وأضافت حاجة المستخدم والكلفة. قد تكون NC قابلة للوصول لكنها غير صالحة بسبب جودة أدنى من المطلوب أو تعارض وظيفة pervasive مستخدمة فيها مع الفئة الجديدة.

المشاركة فصلت الحالات وربطت مصيرها في الوقت نفسه

يسمح multiplexing لعدة TC بأن تستخدم NC واحدة. وتحمل كل TPDU destination reference كي يعيدها المستقبل إلى الحالة الصحيحة. الاشتراك في تكلفة الحامل لا يحول الحوارات إلى حوار واحد.

بعض الوظائف كانت pervasive: إذا استعملتها أول TC على NC وجب على كل TC أخرى فوق الحامل نفسه أن تستعملها طوال عمره. إذن لا يمنح الحامل هوية للحوار، لكنه يفرض قيداً جماعياً.

أما splitting and recombining فيعكس العلاقة: TC واحدة تستخدم عدة NC لزيادة المرونة أو throughput أو لسبب آخر. يحدد جدول الوظائف هذه القدرة في class 4، فلا يصح نسبتها إلى كل الفئات. القيمة التاريخية أن المواصفة استطاعت تمثيل حالة نقل واحدة فوق مجموعة حوامل.

يضيف reassignment استمرارية مشروطة. عند اختفاء NC تستطيع فئات التعافي التي تستدعي الآلية إسناد TC إلى حامل جديد ثم إجراء resynchronization. يتعرف الشريك إلى الإسناد من TPDU صحيحة تصل عبر عناوين تدل على transport entities نفسها ومعها المراجع القائمة.

Class 0 ترسم الحد المقابل. لا توجد فيها عملية مستقلة لتحرير TC، ويرتبط عمرها مباشرة بعمر NC. لم تعد المواصفة باستقلال موحد، بل وزعته كقدرات محددة لكل فئة.

صار TCP لاحقاً خدمة الشبكة التي تحت العقد

اقترحت RFC 983 تقديم واجهة ISO TSAP مع استخدام TCP/IP في الداخل، كي تعمل طبقات ISO الأعلى من دون معرفة التبديل. لكنها لم تدع أنها خطة كاملة للانتقال.

حلت RFC 1006 محل ذلك الاقتراح بالنسخة 3 ووضعت ISO transport class 0 فوق TCP. يقدم TCP stream متصلاً من octets، بينما تتوقع TP0 وحدات منفصلة. لذلك أحاطت كل TPDU بـ TPKT ذي طول معروف. أعاد الإطار حدود الرسالة، ولم يثبت الهوية أو السلامة التشفيرية.

أصبح TCP open هو إنشاء الخدمة السفلية، وTCP close هو disconnect. وبما أن النموذج class 0 فقد تقارب عمر TC من حاملها. ومع ذلك بقيت واجهة النقل ووحداتها فوق تقنية أدنى لم تكن هي NC الأصلية في نص 1983.

راجعت RFC 2126 النموذج ليعمل TCP فوق IPv4 أو IPv6، وحددت class 0 وclass 2. وحافظت على version 3 من TPKT لحماية قاعدة RFC 1006، وذكرت أن منفذ TCP 102 محجوز من دون إلزام كل اتصال به.

يسجل سجل IANA لأسماء الخدمات والمنافذ اسم iso-tsap على 102. هذا إثبات لتنسيق رقم، لا لتشغيل implementation أو نجاح تفاوض class أو وجود reference حية أو إنجاز التطبيق.

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

يعتمد المقال على RFC 892 وRFC 905 وRFC 983 وRFC 1006 وRFC 2126 وسجل IANA. تثبت هذه المصادر التصميم والمكانة النصية والربط فوق TCP. ولا تثبت انتشاراً حالياً أو تبني OSI في الإنترنت أو نسباً مباشراً إلى QUIC أو SCTP أو دعماً عاماً لـ splitting أو مصادقة الطرف أو سلوك منتج بعينه.