أساسيات الشبكات مشكلة التشفير (Encoding) ومشكلة التأطير (Framing) عند بناء الشبكات الحاسوبية

التشفير (Encoding)

تتمثّل الخطوة الأولى في تحويل العُقد (nodes) والرّوابط (links) إلى لبنات أساسيّة قابلة للاستخدام من خلال فهم كيفيّة توصيلها بطريقة يمكن بها نقل البتّات من عقدة إلى أخرى، حيث تنتشر الإشارات عبر الرّوابط الفيزيائية، وتُشفَّر البيانات الثنائية التي تريد العقدة المصدر إرسالها إلى إشارات تستطيع الرّوابط حملها، ثم يُفكّ تشفير الإشارة مرّةً أخرى إلى البيانات الثّنائية المقابلة في العقدة المستقبلّة، يمكن تجاهل تفاصيل التّعديل (modulation) وافتراض أنّك تعمل مع إشارتين منفصلتين: مرتفعة ومنخفضة، ولكن قد تتوافق هذه الإشارات من الناّحية العمليّة مع جهدين (voltages) مختلفين على رابط نحاسي، أو مستويين مختلفين من القدرة (power) على رابط ضوئيّ، أو سعتين (amplitudes) مختلفتين على الإرسال الراديوي، وتُنفَّذ معظم الوظائف الموجودة في هذا المقال بواسطة محوّل الشّبكة (network adaptor) الذي هو عبارة عن قطعة عتاد تصل بين عقدةٍ ورابط، ويحتوي محوّل الشّبكة على مكوّن إشارة (signalling component) يشفّر فعليًّا البتّات إلى إشارات عند عقدة الإرسال ويفكّ تشفير الإشارات إلى بتات في عقدة الاستقبال، حيث تنتقل الإشارات عبر رابط بين مكوّنَي الإشارة، وتتدفّق البتات بين محوّلات الشّبكة (network adaptors) كما هو موضّح في الشّكل التّالي:

بالعودة إلى مشكلة تشفير البتات إلى إشارات، فالشيء الواضح الذي يجب فعله هو ربط القيمة 1 بالإشارة المرتفعة (high signal) والقيمة 0 بالإشارة المنخفضة (low signal)، وهذا هو بالضّبط ما يستخدمه مخطّط تشفير (encoding scheme) مشفَّرٌ بدرجة كافية يدعى عدم العودة إلى الصّفر (non-return to zero ويختصر إلى NRZ)، ويوضّح الشّكل التّالي على سبيل المثال بيانيًّا إشارة NRZ المشفَّرة (في أسفل الشّكل) التي تقابل إرسال سلسلة محدّدة من البتات (في أعلى الشّكل):

تكمن مشكلة ترميز NRZ بوجود سلسلة واحدات متعاقبة والتي تعني بقاء الإشارة مرتفعة على الرّابط لمدّة طويلة من الزّمن، وبالمثل يشير وجود عدّة أصفار متعاقبة إلى بقاء الإشارة منخفضةً لمدّة طويلة. توجد مشكلتان أساسيّتان تسبّبهما سلاسل الواحدات أو الأصفار الطّويلة، حيث تؤدّي المشكلة الأولى إلى حالةٍ تدعى التجوّل الأساسي (baseline wander)، حيث يحتفظ المستقبِل على وجه التّحديد بمتوسّط الإشارة التي شاهدها حتى الآن، ثمّ يستخدم هذا المتوسّط للتّمييز بين الإشارات المنخفضة والمرتفعة، فيستنتج المستقبِل أنه قد رأى صفرًا للتّو عندما تكون الإشارة أقلّ بكثير من هذا المتوسط، وبالمثل تُفسَّر الإشارة التي تكون أعلى بكثير من المتوسّط على أنّها 1. تكمن المشكلة بالطبع في أن عددًا كبيرًا جدًا من الواحدات أو الأصفار المتعاقبة يتسبّب في تغيير هذا المتوسّط، مما يجعل اكتشاف تغيير كبير في الإشارة أمرًا صعبًا.

تتمثل المشكلة الثّانية في أنّ التّحولات المتكرّرة من الأعلى إلى الأسفل والعكس ضروريّة لتفعيل استعادة السّاعة (clock recovery)، فتتمثل مشكلة استعادة الساّعة في أن كلًا من عمليات التّشفير وفكّ التّشفير مُساقة بواسطة ساعة، حيث يرسل المرسل بتًا ويستقبل المستقبل بتًا في كل دورة ساعة. يجب أن تكون ساعات المرسل والمستقبل متزامنة بدقّة من أجل استعادة المستقبل لنفس البتات التي يرسلها المرسل، فإذا كانت ساعة المستقبل أسرع أو أبطأ قليلًا من ساعة المرسل، فلن يستطيع فكّ تشفير الإشارة بصورة صحيحة. يمكنك تخيل إرسال السّاعة إلى المستقبل عبر سلك منفصل، ولكن يجب تجنب ذلك إذ سيزيد من تكلفة توصيل الكابلات مرّتين، لذلك بدلًا من ذلك يستخرج المستقبل السّاعة من الإشارة المستقبلة حيث تدعى هذه العمليّة بعمليّة استعادة السّاعة، حيث يعرف المستقبل أنّه على حدود دورة ساعة عندما تتغيّر الإشارة كما هو الحال عند الانتقال من القيمة 1 إلى القيمة 0 أو من القيمة 0 إلى القيمة 1، وبالتالي يستطيع المستقبل إعادة مزامنة نفسه، ومع ذلك يؤدّي مرور فترة طويلة من الزّمن دون حدوث مثل هذا الانتقال إلى انجراف السّاعة (clock drift)، وبالتالي تعتمد استعادة السّاعة على وجود الكثير من الانتقالات في الإشارة بغضّ النّظر عن البيانات التي تُرسَل.

تجعل إحدى الطّرق التي تعالج هذه المشكلة المرسل ينتقل من الإشارة الحاليّة من أجل تشفير القيمة ،1 ويبقى عند الإشارة الحاليّة من أجل تشفير القيمة 0، وتدعى هذه الطّريقة عدم العودة إلى الصفر المعكوس (non-return to zero inverted ويُختصر إلى NRZI)، حيث تحلّ هذه الطّريقة مشكلة الواحدات المتعاقبة، ولكن من الواضح أنّها لا تفعل شيئًا بالنسبة للأصفار المتعاقبة، ويوضّح الشّكل التّالي ترميز NRZI. يوجد بديل يدعى ترميز مانشستر (Manchester encoding) الذي يقوم بأمرٍ أوضح لدمج السّاعة مع الإشارة خلال إرسال عمليّة "أو" المقصورة (exclusive OR أو اختصارًا XOR) لبيانات NRZ المشفَّرة والساعة.

يمكنك التّفكير بالسّاعة المحليّة كإشارة داخليّة تتناوب من المنخفض إلى المرتفع، حيث يُعدّ الزّوجُ (منخفض / مرتفع) دورةَ ساعةٍ واحدة. ويوضح الشّكل الآتي ترميز مانشستر أيضًا، حيث يُرمَّز ترميز مانشستر الذي ينتج عنه القيمة 0 على أنّه انتقالٌ من منخفض إلى مرتفع ويُرمَّز ترميز مانشستر الذي ينتج عنه القيمة 1 على أنّه انتقال من مرتفع إلى منخفض، ويمكن استعادة السّاعة بفعاليّة في المستقبل لأن كلًّا من القيمتين 0 و1 يسبّبان الانتقال إلى الإشارة. ويوجد أيضًا ترميز مغاير عن ترميز مانشستر، يُسمى تفاضل مانشستر (Differential Manchester)، حيث تساوي القيمةُ 1 المُشفَّرة مع النّصف الأوّل من الإشارة النصفَ الأخير من إشارة البت السابق، وتعاكس القيمةُ 0 المُشفَّرة مع النصف الأوّل من الإشارة النصفَ الأخير من إشارة البت السابق.

تكمن مشكلة مخطّط ترميز مانشستر في أنّه يضاعف معدّل انتقالات الإشارة على الرابط، مما يعني أنّه لدى المستقبل نصف الوقت لاكتشاف كلّ نبضة إشارة، ويُطلق على المعدّل الذي تتغيّر به الإشارة بمعدل الباود (baud rate) للرابط، ويكون معدّل البت في حالة ترميز مانشستر نصف معدّل الباود، لذلك يُعَد الترميز فعّالًا بنسبة 50% فقط. ضع في حساباتك أنه إذا كان المستقبل قادرًا على مواكبة معدّل الباود الأسرع الذي يتطلّبه ترميز مانشستر في الشّكل السابق، فيمكن لكلّ من ترميزَي NRZ وNRZI إرسال ضعف عدد البتّات في نفس الفترة الزمنيّة.

لاحظ أنه ليس بالضرورة أن يكون معدل البت أقل من معدّل الباود أو يساويه كما يوحي ترميز مانشستر، فإذا كان مخطّط التعديل قادرًا على استخدام (والتعرف على) أربع إشارات مختلفة بدلًا من اثنتين فقط (مرتفعة ومنخفضة على سبيل المثال)، فمن الممكن تشفير بتّين في كلّ فترة ساعة، مما ينتج عنه معدّل بت يعادل ضعف معدّل الباود. تعني القدرة على التعدّيل بين ثماني إشارات مختلفة القدرةَ على إرسال ثلاثة بتات لكلّ فترة ساعة، ومن المهمّ وضعك في بالك لوجود تعديلٍ مبسّط بإفراط، وهو أعقد من إرسال إشارات مرتفعة ومنخفضة، فمن المألوف تغيير مجموعة أطوار وسعات إشارة، مما يؤدي إلى تشفير 16 أو حتى 64 نمطًا مختلفًا، غالبًا رموز مظلمة (dalled symbols)، خلال كلّ فاصل زمنيّ على مدار السّاعة، حيث تعديل سعة التربيع (Quadrature Amplitude Modulation ويختصر إلى QAM) هو مثال مستخدم على نطاق واسع لمخطط التعديل هذا.

يحاول التّرميز النهائي المسمّى 4B / 5B، معالجة عدم كفاءة ترميز مانشستر دون المعاناة من مشكلة تمديد فترات الإشارات المرتفعة أو المنخفضة، وتتمثّل فكرة ترميز 4B / 5B في إدخال بتات إضافية إلى مجرى البتات لتفكيك سلاسل طويلة من الأصفار أو الواحدات، وتُشفَّر كل 4 بتات من البيانات الفعليّة في شيفرة مكوّنة من 5 بتات تُرسَل بعد ذلك إلى المستقبل، حيث جاء الاسم 4B / 5B من ذلك. تُحدَّد الشيفرات المكونة من 5 بتات بحيث لا يحتوي كلّ منها على أكثر من صفرٍ واحد في بدايتها ولا يزيد عن صفرين في النهاية، وبالتالي لا ينتج عن أيّ زوج من الشيفرات ذات 5 بتات إرسال أكثر من ثلاثة أصفار متعاقبة وذلك عند الإرسال بالتّتالي، ثم تُرسَل الشيفرات ذات الـ 5 بتات الناتجة باستخدام ترميز NRZI، وهذا ما يفسّر سبب اهتمام الشيفرة بالأصفار المتعاقبة فقط، حيث يحلّ ترميز NRZI مشكلة الوحدات المتعاقبة. لاحظ أنّ ترميز 4B / 5B ينتج كفاءةً بنسبة 80%. يعطي الجدول التّالي شيفرات 5 بتات التي تتوافق مع كلّ رمز من 16 رمزًا من بيانات ذات 4 بتات ممكنة:

لاحظ أن 5 بتّات كافية لترميز 32 شيفرة مختلفة حيث تُستخدم 16 شيفرة منها فقط للبيانات، فهناك 16 شيفرة متبقّية يمكن استخدامها لأغراض أخرى من بينها الشيفرة 11111 التي تُستخدم عندما يكون الخطّ خاملًا بدون عمل، وتقابل الشيفرة 00000 ما يشير إلى تعطُّل الخطّ (dead)، وتُفسَّر الشيفرة 00100 بأن الخطّ مقطوع (halt)، ويوجد 7 شيفرات من بين 13 شيفرةً متبقية غير صالحة لأنها تنتهك قاعدة وجود صفر واحد في البداية وصفرين في النهاية، وتمثل الـ 6 شيفرات الأخرى رموز تحكم مختلفة. تستخدم بعض بروتوكولات التأطير (framing protocols) الموضحة لاحقًا في هذا المقال رموز التحكم هذه.

التأطير (Framing)

فكّر في السيناريو الموجود في الشكل الآتي بعد معرفتك بكيفية نقل سلسلة من البتّات عبر رابط نقطة لنقطة أو من محوّل إلى محوّل، وتذكّر أننا نركز على شبكات تبديل الرّزم (packet-switched networks)، ممّا يعني أن كتل البيانات تسمى إطارات (frames) عند هذا المستوى، وليس مجرى بتات تتبادلها العُقد، حيث يمكّن محوّل الشبكة العُقد من تبادل الإطارات، وتخبر العقدة A محوّلها بإرسال إطار من ذاكرة العقدة عندما ترغب في إرسال إطار إلى العقدة B، فينتج عن هذا سلسلة من البتات تُرسَل عبر الرابط. ثم يجمع المحوّل الموجود على العقدة B سلسلة البتات الواصلة إلى الرابط معًا ويودِع الإطارَ المقابل في ذاكرة العقدة B، ويُعدّ التعرف على مجموعة البتات التي تشكّل إطارًا بالضبط، أي تحديد مكان بدء الإطار ونهايته، هو التّحدي الأساسي الذي يواجهه المحوّل.

توجد عدّة طرق لمعالجة مشكلة التأطير، حيث يستخدم هذا القسم ثلاثة بروتوكولات مختلفة لذلك. لاحظ أنه بينما نناقش مشكلة التأطير في سياق الرّوابط من نقطة لنقطة، فهذه المشكلة هي مشكلة أساسيّة ويجب معالجتها أيضًا في شبكات الوصول المتعدّد (multiple-access)، مثل: شبكات الإيثرنت، والشبكات اللّاسلكية.

البروتوكولات الموجّهة بالبايت (Byte-Oriented Protocols مثل بروتوكول PPP)

إحدى أقدم الطرق المستخدمة للتأطير والتي لها جذورها في توصيل الطرفيات بالحواسيب المركزيّة هي التي تَعدّ كل إطار على أنه مجموعة من البايتات أو الأحرف بدلًا من كونها مجموعة من البتات، ومن الأمثلة القديمة لهذه البروتوكولات الموجَّهة بالبايت بروتوكول الاتصال الثنائي المتزامن (Binary Synchronous Communication ويختصر إلى BISYNC) الذي طورته شركة IBM في أواخر الستينات، وبروتوكول رسائل اتصالات البيانات الرقمية (Digital Data Communication Message Protocol واختصارًا DDCMP) المستخدم في بروتوكولات DECNET التي أنشأتها شركة Digital Equipment Corporation، وبنت شركات الحواسيب الكبيرة، مثل: شركتي IBM، وDEC ذات مرّة أيضًا شبكاتٍ خاصةً لعملائها، وبروتوكول نقطة لنقطة (Point-to-Point Protocol واختصارًا PPP) المستخدم على نطاق واسع هو مثال حديث للطرق المستخدمة للتأطير.

توجد طريقتان للتأطير الموجّه بالبايت على مستوى عالٍ، الطريقة الأولى هي استخدام أحرف خاصّة معروفة باسم الأحرف الحارسة (sentinel characters) لتحديد مكان بدء الإطارات ونهايتها، والفكرة هي الإشارة إلى بداية الإطار عن طريق إرسال حرفٍ خاصّ بالتزامن هو SYN. ويُحتوى أحيانًا جزء البيانات من الإطار بين حرفين خاصّين آخرين هما: STX (بداية النصّ)، وETX (نهاية النصّ)، ويستخدم بروتوكول الاتصال الثنائي المتزامن BISYNC هذه الطّريقة، تكمن مشكلة طريقة الحارس (sentinel approach) في أن أحد الأحرف الخاصّة قد يظهر في جزء البيانات من الإطار، الطّريقة القياسيةّ للتغلّب على هذه المشكلة عن طريق تحويل هذا الحرف بوضع حرف تحويل رابط البيانات (data-link-escape أو اختصارًا DLE) قبله كلّما ظهر في جسم الإطار، حيث يجري تخطّي حرف DLE أيضًا (بوضع حرف DLE إضافي قبله) في جسم الإطار. قد يلاحظ مبرمجو لغة البرمجة C تشابه هذا مع الطريقة التي تحوَّل بها علامة الاقتباس (quotation mark) بواسطة الشرطة المائلة العكسيّة (backslash) عند ظهورها داخل سلسلة (string)، ويُطلق على هذا الأسلوب غالبًا حشو الأحرف (character stuffing) بسبب إدخال أحرف إضافيّة في جزء البيانات من الإطار.

بديل اكتشاف نهاية إطار باستخدام قيمة حارسة (sentinel value) هو تضمين عدد بايتات الإطار في بداية الإطار وتحديدًا في ترويسة الإطار، حيث يستخدم بروتوكول DDCMP هذه الطريقة، ويتمثّل أحد مخاطر هذه الطريقة ، في إمكانيّة إفساد خطأ الإرسال لحقل العدّ (count field)، وفي هذه الحالة لن يُكتشف نهاية الإطار بصورة صحيحة. توجد مشكلة مماثلة مع الطريقة القائمة على الحارس إذا فسد حقل ETX، فإذا حدث ذلك، فسيجمّع المستقبل عدد البايتات كما يشير حقل العدّ التالف، ثم يستخدم حقل اكتشاف الخطأ لتحديد تلف الإطار، ويسمى هذا أحيانًا بخطأ التأطير (framing error)، ثمّ سينتظر المستقبل حتّى يرى حرف SYN التالي ليبدأ بجمع البايتات التي تُشكّل الإطار التالي، لذلك من الممكن تسبب خطأ التأطير في تلقّي إطارات متتالية بصورة غير صحيحة، ويستخدم بروتوكول نقطة لنقطة (Point-to-Point Protocol أو اختصارًا PPP)، والذي يشيع استخدامه لنقل رزم بروتوكول الإنترنت (Internet Protocol) عبر أنواع مختلفة من روابط نقطة لنقطة، ولنقل الحرّاس (sentinels)، وحشو الأحرف (character stuffing). تجد صيغة إطار PPP في الشّكل التالي:

يعرض الشّكل السّابق الرّزمة مثل سلسلة من الحقول المصنَّفة، ويوجد فوق كلّ حقل رقمٌ يشير إلى طول هذا الحقل بالبتات، ولاحظ أنّ الرّزم تُرسَل بدءًا من الحقل الموجود في أقصى اليسار، فحرف بداية النصّ (start-of-text) الخاصّ الذي يُشار إليه على أنه حقل الراية Flag هو 01111110، ويحتوي حقلًا العنوان Address والتّحكم Control عادةً قيمًا افتراضية وبالتالي فهي غير مهمّة. ويُستخدم حقل البروتوكول (Protocol) لفكّ تعدُّد الإرسال، حيث يحدّد البروتوكول عالي المستوى مثل بروتوكول IP. يمكن التفاوض على حجم حِمل (payload) الإطار، ولكنّه يبلغ 1500 بايت افتراضيًا. يكون حقل المجموع الاختباري Checksum إمّا 2 (افتراضيًا) أو 4 بايتات. لاحظ أنه على الرّغم من الاسم الشائع لهذا الحقل إلا أنه في الواقع عبارة عن CRC، وليس checksum (كما سنوضّح لاحقًا).

تختلف صيغة إطار بروتوكول PPP في مسألة التفاوض على العديد من أحجام الحقول بدلًا من إصلاحها، حيث يُجرى هذا التفاوض بواسطة بروتوكول يُسمّى بروتوكول التحكّم بالرابط (Link Control Protocol ويختصر إلى LCP). يعمل كلّ من بروتوكولي PPP، وLCP جنبًا إلى جنب، فيرسل بروتوكول LCP رسائل تحكّم مغلَّفة ضمن إطارات بروتوكول PPP، ويشار إلى هذه الرسائل بواسطة معرّف LCP في حقل PPP (حقل Protocol)، ثم يغيّر بروتوكول LCP صيغة إطار PPP استنادًا إلى المعلومات الواردة في رسائل التحكم هذه، ويشارك بروتوكول LCP أيضًا في إنشاء رابط بين نظيرين (peers) عندما يكتشف كلا الجانبين أن الاتّصال عبر هذا الرّابط ممكن (عندما يكتشف كلّ مستقبل ضوئي إشارةً واردةً من الألياف التي يتّصل بها على سبيل المثال).

البروتوكولات الموجّهة بالبت (Bit-Oriented Protocols مثل بروتوكول HDLC)

لا تهتمّ البروتوكولات الموجّهة بالبتّ بحدود البايت على عكس البروتوكولات الموجّهة بالبايت، حيث تنظر البروتوكولات الموجّهة بالبتّ ببساطة إلى الإطار على أنه مجموعة من البتات، وقد تأتي هذه البتات من بعض مجموعات الأحرف كنظام ASCII، وقد تكون قيم بكسلات في صورة، كما قد تكون تعليمات ومُعامَلات من ملف تنفيذيّ. بروتوكول التّحكم في رابط البيانات المتزامن (Synchronous Data Link Control الذي يختصر إلى SDLC) الذي طوّرته شركة IBM هو مثال على بروتوكولٍ موجَّه بالبت. وحّدت منظّمة ISO لاحقًا بروتوكول SDLC مثل بروتوكول التحكم في رابط البيانات عالي المستوى (High-Level Data Link Control واختصارًا HDLC). وستجد صيغة إطار HDLC في الشّكل التالي:

يشير بروتوكول HDLC إلى بداية ونهاية الإطار مع سلسلة بتات مميّزة هي 01111110، وتُرسَل هذه السّلسلة أيضًا أثناء أيّ وقت يكون فيه الرّابط خاملًا بحيث يمكن للمرسل والمستقبل إبقاء ساعاتهما متزامنةً، باستخدام كلا البروتوكولين بهذه الطريقة طريقةَ الحارس (sentinel approach)، ونظرًا لأنّ سلسلة البتات هذه قد تظهر في أيّ مكان في جسم الإطار، فقد تعبر البتّات 01111110 حدود البايت، حيث تستخدم البروتوكولات الموجَّهة بالبتّ حرف DLE التناظري، وهي تقنيّة تُعرّف باسم حشو البتات (bit stuffing).

يعمل حشو البتات في بروتوكول HDLC على النحو التالي: تُرسل خمسة واحدات متعاقبة على جانب الإرسال في أيّ وقت من نصّ الرسالة (باستثناء عندما يحاول المرسل إرسال السلسلة المميزة 01111110)، ويحشو المرسل 0 قبل إرسال البتّ التالي؛ أمّا على الجانب المستقبل وفي حالة وصول خمسة واحدات متعاقبة، فيتّخذ المستقبل قراره بناءً على البتّ التالي الذي يراه (أي البت الذي يتبع الواحدات الخمسة)، فإذا كان البت التالي يساوي 0، فلابدّ أنّها محشوّة وبالتالي يزيلها المستقبل، وإذا كان البت التالي 1، فسيكون أحد الأمرين صحيحًا، فإمّا أن تكون هذه علامة نهاية الإطار، أوقد أُدخِل خطأٌ في مجرى البتات، ويمكن للمستقبل التمييز بين هاتين الحالتين بالنظر إلى البت التالي، فإذا شاهد 0 (أي أنّ آخر 8 بتات نظر إليها هي01111110) فهذا يعني أنهّا علامة نهاية الإطار، وإذا شاهد 1 (أي أن آخر 8 بتات نظر إليها هي01111111)، فلا بد من وجود خطأ ثم يتجاهل الإطار بأكمله. يتعيّن على المستقبل في الحالة الأخيرة انتظار السلسلة 01111110 التالية قبل بدئه في الاستلام مرّةً أخرى، ونتيجةً لذلك هناك احتمال فشل المستقبل في استلام إطارين متتاليين. ومن الواضح أنه لا تزال هناك طرق يمكن من خلالها عدم اكتشاف أخطاء التأطير، كما هو الحال عند إنشاء نمط نهاية الإطار الزائف بالكامل بسبب الأخطاء، ولكن هذه الإخفاقات غير مُرجّحة نسبيًّا، وستناقش الطرق القوية لاكتشاف الأخطاء في قسم لاحق.

من الخصائص المثيرة للاهتمام لحشو البتات، بالإضافة إلى حشو الأحرف، أن حجم الإطار يعتمد على البيانات التي تُرسَل في حِمل الإطار. في الواقع ليس ممكنًا جعل جميع الإطارات بنفس الحجم تمامًا، نظرًا لأن البيانات التي يمكن حملها في أي إطار عشوائية، ولإقناع نفسك بهذا، ضع في بالك ما يحدث إذا كان آخر بايت من جسم الإطار هو الحرف ETX. ستُشرح صيغة التأطير التي تضمن أن جميع الإطارات لها نفس الحجم في الفقرة التالية.

التأطير المعتمد على الساعة (Clock-Based Framing مثل معيار SONET)

يمثّل معيار الشّبكة الضوئيّة المتزامنة (Synchronous Optical Network أو اختصارًا SONET) الطريقةَ الثالثة للتأطير، ويشار إلى هذه الطريقة ببساطة على أنّها تأطير معتمد على الساعة لعدم وجود مصطلح عامّ مقبول على نطاق واسع. اقترحت أبحاث بيل للاتصالات (Bell Communications Research أو Bellcore) معيار SONET لأوّل مرّة، ثمّ طوّره المعهد القومي الأمريكي للمواصفات القياسيّة (American National Standards Institute وتُختصر إلى ANSI) للإرسال الرقمي عبر الألياف الضوئيّة، واعتمده الاتحاد الدولي للاتصالات ITU-T منذ ذلك الحين، وكان معيار SONET لسنوات عديدة هو المعيار المهيمن لنقل البيانات لمسافات طويلة عبر الشبكات الضوئيّة.

يجب توضيح نقطة مهمّة حول معيار SONET وهي أنّ مواصفاته الكاملة أكبر بكثير من هذا الكتاب، وبالتالي ستغطّي المناقشة التالية النقاط الهامّة للمعيار فقط. يعالج معيار SONET كلًا من مشكلة التأطير ومشكلة التشفير، كما أنه يعالج مشكلة مهمّةً جدًّا لشركات الهاتف وهي مشكلة دمج (multiplexing) عدّة روابط منخفضة السّرعة على رابطٍ واحد عالي السّرعة، يعكس تصميم هذا المعيار في الواقع حقيقة أنّ شركات الهاتف يجب عليها الاهتمام بدمج أعداد كبيرة من القنوات التي تبلغ سرعتها 64 كيلوبت في الثانية والتي تُستخدم تقليديًا للمكالمات الهاتفيّة.

يحتوي إطار SONET على بعض المعلومات الخاصّة التي تخبر المستقبل بمكان بدء الإطار ونهايته كما هو الحال مع مخطّطات الإطارات التي نوقشت سابقًا، ومع ذلك فهذا هو وجه التّشابه الوحيد بينهما، ومن الجدير بالذّكر أنه لا يستخدم حشو البتات، بحيث لا يعتمد طول الإطار على البيانات المرسلة، لذا فالسؤال الذي يجب طرحه هو كيف يعرف المستقبل أين يبدأ كلّ إطار وأين ينتهي؟ يُعدّ هذا السؤال مرتبطًا برابط SONET الأقلّ سرعةً، والذي يُعرف باسم STS-1 ويعمل بسرعة 51.84 ميجابت في الثانية، حيث يظهر إطار STS-1 في الشكل الآتي، وهو مُرتَّب على شكل 9 صفوف ويأخذ كل صفّ 90 بايتًا، وتكون البايتات الثلاثة الأولى من كلّ صفّ بايتات إضافيّة (overhead)، وتتاح باقي البايتات للبيانات المرسَلة عبر الرّابط. يحتوي البايتان الأوّليان من الإطار على نمط بت خاصّ، وهذه البايتات هي التي تُمكّن المستقبل من تحديد مكان بدء الإطار، ولا يوجد سبب لعدم ظهور هذا النّمط أحيانًا في جزء الحمولة (payload) من الإطار، نظرًا لعدم استخدام حشو البتات، لذلك يبحث المستقبل عن نمط البت الخاصّ باستمرار على أمل رؤيته مرةً واحدة كلّ 810 بايت، لأنّ كلّ إطار يبلغ طوله 9 × 90 = 810 بايتات، وبالتالي يستنتج المستقبل أنه متزامن ويمكنه بعد ذلك تفسير الإطار بصورة صحيحة عندما يظهر النمط الخاصّ في المكان المناسب مراتٍ كافية.

أحد الأشياء التي لن نشرحها بسبب تعقيد معيار SONET هو الاستخدام التفصيلي لجميع البايتات الإضافية (overhead) الأخرى، وقد يُعزى جزء من هذا التّعقيد إلى حقيقة أنّ معيار SONET يعمل عبر شبكة المشغّل الضّوئية، وليس عبر رابط واحد فقط، تذكّر أنّنا نتخلى عن حقيقة أنّ شركات الاتصالات تنفّذ شبكة، ونركز بدلًا من ذلك على حقيقة قدرتنا على استئجار رابط SONET منها، ثم استخدام هذا الرّابط لبناء شبكتنا الخاصّة ذات نوع تبديل الرّزم (packet-switched). يأتي تعقيدٌ إضافي من حقيقة أنّ هذا المعيار يوفّر مجموعة خدمات أكثر ثراءً من مجرد نقل البيانات، حيث تُخصَّص على سبيل المثال 64 كيلوبت في الثانية من سعة رابط SONET لقناةٍ صوتية تُستخدم للصيانة.

تُرمَّز بايتات إطار SONET الإضافية باستخدام ترميز NRZ، وهو التّرميز البسيط الذي نوقش سابقًا، حيث تكون سلسلة الواحدات مرتفعة وسلسلة الأصفار منخفضة، ويجب خلط (scrambled) بايتات الحِمل لضمان وجود الكثير من الانتقالات للسّماح للمستقبل باستعادة ساعة المرسل، حيث يتمّ ذلك عن طريق حساب عمليّة XOR للبيانات المراد إرسالها باستخدام نمط بتّات معروف. يحتوي نمط البت الذي يبلغ طوله 127 بتًّا على الكثير من الانتقالات من 1 إلى 0، لذلك من المحتمل أن ينتج عن عملية XOR لنمط البتّ مع البيانات المرسلَة إشارةٌ ذات انتقالات كافية لتفعيل استعادة الساعة.

يدعم معيار SONET دمج عدّة روابط منخفضة السرعة بالطريقة التالية: يعمل رابط SONET المحدّد بمعدّلٍ من مجموعة محدودة من المعدّلات المحتملة، والتي تتراوح من 51.84 ميجابت في الثانية (STS-1) إلى 39813120 ميجابت في الثانية (STS-768). لاحظ أنّ كلّ هذه المعدّلات عبارة عن مضاعفات STS-1 العددية الصحيحة. تكمن أهمية التأطير في أن إطار SONET الواحد قد يحتوي على إطارات فرعيّة لقنوات متعدّدة ذات معدّلات أقلّ؛ أمّا الميزة الثانية فهي أن كلّ إطار يبلغ طوله 125 ميكرو ثانية، وهذا يعني أنّ طول إطار SONET يبلغ 810 بايت في معدلات STS-1، بينما في معدلات STS-3 يبلغ طول كلّ إطار SONET حوالي 2430 بايت. لاحظ الارتباط بين هاتين الميزتين حيث: 3 × 810 = 2430، مما يعني تلاؤم ثلاثة إطارات STS-1 تمامًا مع إطار STS-3 واحد. ترمز STS إلى إشارة النقل المتزامن (Synchronous Transport Signal)، وهي الطريقة التي يتحدّث بها معيار SONET عن الإطارات، ويوجد مصطلحٌ موازٍ هو الناقل الضوئي (Optical Carrier واختصارًا OC) الذي يُستخدم للتّحدث عن الإشارة الضوئية الأساسيّة التي تحمل إطارات SONET. يمكن القول أنّ هذين المصطلحين متوازيان لأن STS-3 و OC-3 على سبيل المثال يشيران إلى معدّل إرسال يبلغ 155.52 ميجابت في الثانية. سنلتزم بـالمصطلح STS نظرًا لأنّنا نركّز على التأطير هنا، ولكن من المرجح أن تسمع شخصًا يشير إلى رابط ضوئي باسم OC.

يمكن القول بأنّ إطار STS-N يتكوّن من N إطار من النّوع STS-1، حيث تكون البايتات في هذه الإطارات متداخلة (interleaved)، أي يرسَل بايت من الإطار الأول، ثمّ يرسَل بايت من الإطار الثاني وهكذا. والسبّب في تداخل (interleaving) البايتات في كلّ إطار STS-N هو التأكّد من أنّ البايتات في كلّ إطار STS-1 موجودة بالتساوي، أي أنّ البايتات تظهر في المستقبل بسرعة تبلغ 51 ميجابت في الثانية بسهولة، بدلًا من تجميعها بالكامل خلال 1 / Nth من الفاصل الزّمني 125 ميكرو ثانية.

يمكن ربط حِمل إطارات STS-1 معًا لتكوين حِمل STS-N أكبر على الرّغم من صحّة افتراض أنّ إشارة STS-N تُستخدم لتجميع N إطار من النّوع STS-1، مثل الإشارة إلى هذا الرّابط باستخدام STS-Nc ،على التّسلسل (concatenated)، حيث يُستخدَم أحد الحقول الموجودة في القسم الإضافي للإطار لهذا الغرض. يبين الشّكل السّابق بيانيًا التسلسل (concatenation) في حالة ثلاثة إطارات STS-1 متسلسلة في إطار STS-3c واحد. تكمن أهميّة رابط SONET في كونه من النوع STS-3c بدلًا من النوع STS-3، فيمكن لمستخدم هذا الرّابط في الحالة الأولى مشاهدته على أنه أنبوب واحد بسرعة 155.25 ميجابت في الثانية، بينما يجب عرض الرابط STS-3 على شكل ثلاثة روابط بسرعة 51.84 ميجابت في الثانية تُستخدَم لمشاركة الألياف.

وأخيرًا، وصفُ معيار SONET السابق بسيطٌ جدًا فهو يفترض أنّ حِمل كلّ إطار موجود بالكامل داخل الإطار، إذًا لماذا لا يحدث ذلك؟ يجب في الواقع عرض إطار STS-1 الموصوف للتّو على أنه مجرّد عنصرٍ نائب للإطار، حيث قد يطفو الحمل الفعلي (actual payload) خارج حدود الإطار، ويوضح الشّكل السابق هذه الحالة، فيطفو هنا كلٌ من حِمل الإطار STS-1 بين إطاري STS-1 و يزيح الحِمل عددًا من البايتات إلى اليمين، وبالتالي تلتفّ هذه البايتات. يشير أحد الحقول الموجودة في قسم الإطار الإضافي إلى بداية الحِمل، فتكمن أهميّة هذه الإمكانية في أنها تبسّط مهمّة مزامنة الساعات المستخدمة عبر شبكات شركات الاتصالات، حيث تقضي شركات الاتصالات الكثير من وقتها قلقةً بشأن مزامنة الساعات.

ترجمة -وبتصرّف- للقسمين Encoding و Framing من فصل Direct Links من كتاب Computer Networks: A Systems Approach