فریم بندی در شبکه – آموزش شبکه درس 24

فریم بندی در شبکه یکی از مفاهیم بنیادی در انتقال پیام است. در این درس قصد داریم به ابعاد مختلف فریم بندی در شبکه بپردازیم و راهکارهائی که برای این روند در نظر گرفته شده است را بررسی کنیم. در ادامه این درس نیز با چند پروتکل و روش فریم بندی آشنا خواهیم شد. این درس، نسبتا طولانی و بلند و نیز پر از ریزه کاری است که لازم است با دقت مطالعه شود.

فریم بندی در شبکه

اکنون که ما دیدیم چه چطور می‌توانیم توالی از بیت‌ها را با یک لینک نقطه به نقطه ارسال کنیم (یا در واقع از یک کارت شبکه به کارت شبکه دیگر)، اکنون ما باید به سناریویی بپردازیم که در تصویر 2.6 ارائه شده است. در بخش‌های قبلی گفتیم که تمرکز ما بر روی شبکه‌های سوئیچ شده بسته ای است که به معنای آن است که در این شبکه‌ها، بسته‌ها یا بلوک‌های داد (که در این سطح به آن فریم یا frame می‌گوئیم) جابجا می‌شوند و خبری از جریان‌ها بیتی نیست، و گره‌های شبکه از این فریم‌ها برای جابجای اطلاعات استفاده می‌کنند. در اینجا ما به یک آداپتور شبکه روبرو هستیم که گره‌ها را قادر می‌کند که به تبادل فریم‌ها بپردازند. هنگامی که یک گره A می‌خواهد یک فریم را به گره B انتقال دهد، لازم است که به آداپتور خودش بگوید که یک فریم را از حافظه خودش انتقال دهد. این کار سبب می‌شود که یک توالی از بیت‌ها بر روی لینک ارسال شود.

آداپتوری که بر روی گره B قرار گرفته است، تمامی توالی‌ها از بیت‌هایی که از لینک می‌رسند را دریافت می‌کند و آن‌ها را مطابق با فریمی که در حافظه B وجود دارد مرتبط می‌کند. در اینجا شناخت ساختاربندی مجموعه بیت‌های یک فریم، یکی از چالش‌هایی است که آداپتورها با آن روبرو هستید، که این موضوع در ابتدا و انتهای یک فریم مطرح می‌شود.

جریان بیت‌ها میان کارت‌ها، و فریم میان‌هاست‌ها

تصویر 2.6 جریان بیت‌ها میان کارت‌ها، و فریم میان‌هاست‌ها

ما چند راه برای شناخته مسئله فریم بندی داریم. این بخش از سه پروتکل متفاوت برای مشخص کردن نقطه‌های مختلف در فضای طراحی استفاده می‌کند. توجه کنید، در حالی که ما سعی به توضیح دادن فریم بندی در زمینه اتصال‌های نقطه به نقطه – Point to Point – می‌کنیم، اما این مسئله به صورت اساسی در شبکه‌های با دسترسی چندگانه مانند اترنت و Wi-Fi نیز وجود دارد.

پروتکل‌های بایت محور (PPP)

یکی از قدیمی ترین روش‌ها برای فریم بندی که ریشه در ترمینال‌های متصل به ماینفریم‌ها دارد، آن است که هر کدام از فریم‌ها را به جای آنکه یک مجموعه از بیت‌ها ببنیم، به عنوان یک مجموعه از بایت‌ها (کاراکترها) ببنیم. مثال اولیه در اینچنین پروتکل‌های بایت محوری پروتکل ارتباطات همزمان باینری (BISYNC) است، این پروتکل به وسیله شرکت IBM در اواخر دهه 1960 توسعه پیدا کرد، پروتکل دیگر در این میان پروتکل ارتباطات پیامی (DDCMP) است که توسط شرکت تجهیزات دیجیتالی DECNET توسعه داده شده است. (در زمان توسعه این پروتکل‌ها شرکت‌هایی مانند IBM و DEC به عنوان شرکت‌های بزرگ خصوص که در زمینه شبکه برای مشتریان خودشان کار می‌کردند، شناخته می‌شدند). پروتکل نقطه به نقطه (PPP) نیز یکی از روش‌هایی است که در همین اواخر از آن استفاده می‌شده است.

در سطح بالاتر در اینجا روش‌هایی برای فریم بندی بایت محور وجود دارد. اولین آن‌ها از کاراکترهای ویژه ای استفاده می‌کند که به عنوان کاراکترهای نگهبان (sentiel chracters) گفته می‌شود که می‌توانند مشخص کنند فریم‌ها در کجا شروع شده و در کجا خاتمه پیدا می‌کنند. ایده اصلی در اینجا آن است که بتوان ابتدا و انتهای فریم را به وسیله فرستادن کاراکترهای ویژه همزمان سازی (SYN) مشخص کرد. بخش داده از یک فریم گاهی از اوقات حاوی دو و یا چند کاراکتر ویژه است: STX (شروع نوشته- strat of text) و ETX (انتهای نوشته – end of text). پروتکل ارتباطات همزمان باینری (BISYNC) از این روش استفاده می‌کند.

مسئله که در روش کاراکترهای نگهبان وجود دارد، آن است که کاراکترهای ویژه ممکن است در بخش داده یک فریم نیز ظاهر شوند. راه استاندارد برای فائق آمدن بر این مسئله به وسیله «جداکردن- escaping» انجام می‌شود، در اینجا یک کاراکتر با یک DLE یا data link escape شروع می‌شود، این مسئله می‌تواند در هر جائی از بدنه باشد؛ کاراکتر DLE همچنین می‌تواند با با یک DLE در بدنه فریم مجزا شود. (برنامه نویسان زبان C ممکن است که این را مشابه با روشی ببینند که در آن ما از برخی از کاراکترها مانند بک اسلش و یا غیر در میانه یک رشته نوشتاری استفاده می‌کردیم تا بتوانیم برخی از کاراکترها را استفاده کنیم). این روش اغلب به نام «کاراکتر چاشنی – character stuffing» شناخته می‌شود، زیرا کاراکترهای اضافه را به درون بخش داده یک فریم وارد می‌کنیم.

روش دیگر برای مشخص کردن انتهای یک فریم با یک مقدار نگهبان است که شامل تعداد بیت‌های در فریم می‌شود و آن در ابتدای یک فریم یا همان هدر (header) فریم ارسال می‌شود. پروتکل ارتباطات پیامی (DDCMP) از این روش استفاده می‌کند. یکی از خطراتی که در این روش وجود دارد آن است که بروز خطا در انتقل می‌تواند سبب از بین رفتن فیلد تعداد کاراکتر شود، که در این صورت انتهای فریم به درستی مشخص نمی شود. (مشکلی به همین شکل نیز در روش‌های مبتنی بر کاراکتر نگهبان وجو دارد، اگر کاراکترهای ETX دچار آسیب شوند).

در صورتی که چنین اتفاقی بیفتد، در آن صورت ما با انبوهی از بایت‌ها روبرو هستیم که به صورت بد شمارش شده اند و در نتیجه به خاطر وجود خطاها ما نمی توانیم از فریم استفاده کنیم، برای همین باید از روشی برای تشخیص خطاها استفاده کنیم و راهی را به کار ببریم که به ظریق آن بتوانیم تعداد درست را بیابیم و فریم مشکل دار را تشخیص دهیم. این موضوع گاهی به عنوان «خطای فریم بندی – framing error» شناخته می‌شود. دریافت کننده کننده در اینجا باید تا زمانی که آن کاراکتر SYN بعدی را می‌بیند منتظر بماند و سپس مجموعه بعدی از کاراکترها را جمع آوری کند که برای ساختن فریم بعدی به کار می‌روند. به همین خاطر این احتمال وجود دارد که یک خطای فریم بندی سبب شود که فریم‌هایی که به صورت پی در پی ارسال شده اند به شکل نا درستی دریافت شوند.

پروتکل نقطه به نقطه (PPP) که به صورت معمول برای انتقال بسته‌ها و پروتکل‌های اینترنت با آرایش‌های مختلف بر روی لینک‌های نقطه به نقطه به کار می‌روند، از کاراکترهای نگهبان و یا چاشنی استفاده می‌کنند. فرمت برای فریم PPP در تصویر 2.7 نشان داده شده است.

فرمت فریم PPP

تصویر 2.7 فرمت فریم PPP

این تصویر اولین تصویر در این زمینه است که شما در طی این سری از پست‌ها مشاهده خواهید کرد و از آن برای مشخص کردن فریم و یا فرمت بسته‌ها استفاده می‌شود، در اینجا ما نیازمند تعداد واژه‌های کمی برای توضیح دادن این موضوع هستیم. ما در اینجا بسته‌ها را به صورت یک توالی از فیلدها برچسب خورده نشان داده ایم. بالای هر کدام از این فیلد‌ها عددی نشان داده شده است که نشان دهنده طول آن فیلد در واحد بیت است. توجه کنید، بسته‌ها از اولین بسته سمت چپ شروع به انتقال می‌کنند.

کاراکتر شروع نوشته در اینجا با فیلد Flag مشخص شده است که مقدار آن برابر با 01111110 است. فیلد‌های Address و Control معمولا حاوی مقدارهای پیش فرض است و بنابراین برای ما جذاب نیستند. فیلد Protocol برای دمالتی‌پلکسینگ به کار می‌رود؛ آن برای معرفی پروتکل‌های سطح بالا مانند IP به کار می‌رود. اندازه ظرفیت ترابری فریم قابل مذاکره است، اما آن به صورت پیش فرض 1500 بایت را به خود اختصاص داده است. فیلد Checksum نیز می‌تواند 2 (به صورت پیش فرض) و یا 4 بایت طول داشته باشد. نکته که در اینجا وجود دارد آن است که به رقم نام‌های معمول آن، این فیلم واقعا یک CRC است و نه یک فیلد برای چک خطا (که ما آن را به صورت دقیق در بخش‌های بعدی توضیح خواهیم داد).

فرمت فریم پروتکل نقطه به نقطه (PPP) به جای آنکه یک تعداد ثابت باشد، متشکل از چند فیلد با اندازه‌های متغیر تشکیل شده است. این قابلیت تغییر به وسیله پروتکلی به نام پروتکل کنترل لینک (LCP) قابل مذاکره و دستیابی است. پروتکل نقطه به نقطه (PPP) و پروتکل کنترل لینک (LCP) پشت سر هم کار می‌کنند: پروتکل کنترل لینک (LCP) پیام‌های کنترل کپسوله شده را در فریم‌های پروتکل نقطه به نقطه (PPP) ارسال می‌کند- اینچنین پیام‌هائی به وسیله یک شناسه پروتکل کنترل لینک (LCP) در فیلد Protocol پروتکل نقطه به نقطه (PPP) قرار می‌گیرد- و پس از ارسال و برگشت، فرمت فریم پروتکل نقطه به نقطه (PPP) مبتنی بر اطلاعاتی که در این پیام‌های کنترل قرار گرفته است، تغییر می‌کند. پروتکل کنترل لینک (LCP) همچنین در ایجاد لینک میان دو و یا چند همتا به کار می‌رود که هر دو طرف ارتباطات خودشان بر روی لینک در دسترس را مشخص می‌کنند (مانند زمانی که دریافت کننده‌های نوری، سیگنال‌های ورودی از طریق فیبری که به آن متصل هستند را مشخص می‌کنند).

پروتکل‌های بیت محور (HDLC)

بر خلاف پروتکل‌های بایت محور، یک پروتکل بیت محور به حاشیه و مرز بایت‌ها کار ندارد، آن به سادگی فریم را به عنوان یک مجموعه از بیتها در نظر می‌گیرد. این دسته از بیت‌ها متشکل از مجموعه ای از کاراکترها مانند ASCII هستند؛ آن‌ها احتمالا می‌توانند مقدار پیکسل به کار رفته در یک تصویر باشند، یا می‌تواند دستورالعمل‌هائی برای اجرای یک فایل برنامه نویسی و یا هرچیز دیگری باشند. پروتکل کنترل همزمان لینک داده (SDLC) به وسیله شرکت IBM توسعه داده شده است و یک مثال خوب برای پروتکل‌های بیت محور است. SDLC در همین اواخر به وسیله سازمان ISO به عنوان پروتکل کنترل لینک داده سطح بالا (HDLC) استاندارد سازی شده است. در بخش‌های بعدی ما از پروتکل کنترل لینک داده سطح بالا (HDLC) در یک مثال استفاده میکنیم، فرمت فریم این پروتکل در تصویر 2.8 ارائه شده است.

فرمت فریم HDLC

تصویر 2.8 فرمت فریم HDLC

پروتکل کنترل لینک داده سطح بالا (HDLC) هم ابتداو هم انتهای یک فریم را با استفاده از توالی بیت‌های قابل تمایز به صورت 01111110 مشخص می‌کند. این توالی در هر زمانی که لینک ارتباطی بیکار باشد، انتقال داده می‌شود، و به همین خاطر فرستند و دریافت کننده می‌توانند همزمان ساعت خودشان را با هم تنظیم کنند. در این روش، دو پروتکل لازم است که از روش نگهبان استفاده کنند. این موضوع به آن خاطر است که این توالی احتمالا می‌تواند در هر جائی از فریم ظاهر شود – در حقیقت، بیت‌های 01111110 می‌تواند در مرز بایت‌ها ظاهر شوند – پروتکل‌های بیت محور در اینجا از کاراکتر‌های DLE و تکنیک شناخته شده چاشنی بیتی استفاده می‌کنند.

چاشنی بیتی در پروتکل کنترل لینک داده سطح بالا (HDLC) به صورتی که در ادامه توضیح داده می‌شود کار می‌کند. در طرف ارسال کننده، در هر بار 5 توالی یک ثانیه از بدنه پیام (مانند زمانی که فرستنده در تلاش است که اقدام به ارسال توالی 01111110 قابل تمایز کند) را ارسال می‌کند، در اینجا دریافت کنده یک صفر را پیش از هر بیت ارسال شده بعد دریافت می‌کند. در طرف دریافت کننده، باید پنج توالی یک ثانیه ای دریافت شود، دریافت کننده مبتنی بر آن که درباره دریافت بیت‌های بعدی تصمیم گیری می‌کند (برای مثال منتظر بیت بعد از ثانیه پنجم می‌شود).

اگر بیت بعدی یک صفر باشد، می‌تواند یک بیت چاشنی باشد و بنابراین می‌تواند آن را حذف کند. اگر بیت بعدی در اینجا یک باشد، در آن صورت یکی از دو مورد درست است: یا آن یک علامت نشان دهنده اتمام فریم است و یا یک خطای است که در جریان بیت‌ها اتفاق افتاده است. به نگاه کردن به بیت بعدی، گیرنده می‌تواند تفاوت میان این دو مورد را تشخیص دهد. اگر آن یک صفر مشاهده کند (یعنی هشت بیت آخر 01111110 را مشاهده میکند) در آن صورت، آن نشان دهنده اتمام فریم هستند؛ اگر آن یک را مشاهده کند (به معنای آن است که بیت آخر 01111111 را مشاهده می‌کند) پس در اینجا باید یک خطا رخ داده باشد و کل فریم را باید نادیده گرفت. در مورد آخر، دریافت کننده باید برای 01111110 بعدی منتظر باشد تا بتواند دریافت را از سر بگیرد، و چون همه چیز به صورت یک توالی هستند، در اینجا این پتانسیل وجود دارد که گیرنده در دریافت دو فریم پی در پی دچار مشکل و یا شکست شود.

آنچه که مشخص این است که در اینجا، هنوز راه‌هایی وجود دارد که ممکن است خطاهای موجود در فریم بندی غیرقابل درک باشند، این موارد در زمانی هستند که یک الگوی انتهای فریم جعلی به وسیله خطاها ایجاد شود، اما این خطاها به نسبت بسیار کم هستند. راه‌های قوی برای تعیین خطاها را در پست‌های آینده برای شما توضیح خواهیم داد.

یک ویژگی مورد علاقه در زمینه روش چاشنی بیتی و نیز چاشنی کاراکتری، اندازه فریم است که مستقل از ظرفیت ترابری فریم قابل ارسال هستند. در حقیقت این امکان وجود ندارد که اندازه فریم‌ها یکسان باشند، و مقدار داده‌هایی که از طریق هر فریم می‌توانند انتقال پیدا کنند بسیار متفاوت هستند. (برای درک بهتر خودمان از این مطلب، فرض کنید چه اتفاقی می‌افتد اگر آخرین بیت بدنه فریم یک کاراکتر ETX باشد). یک فرم فرمت بندی آن است که مطمئن شوید که تمام فریم‌ها در اندازه‌های یکسان هستند، که این موضوع در بخش بعدی توضیح داده می‌شود.

در یک لایه چه چیزی وجود دارد؟

یکی از مهمترین مفاهیمی که در مدل مرجع OSI وجود دارد آن است که برخی از کلمات جدید را درباره پروتکل‌ها به کار می‌برد، و به شکل ویژه از لایه بندی پروتکل (Protocl layers) صحبت می‌کند. این کلمات جدید می‌تواند برای بسیاری از بحث‌ها برای مثال « پروتکل شما عملکرد X را در لایه Y انجام می‌دهند و مدل هفت لایه ای OSI می‌گوید که باید در لایه Z انجام شود و شما آن لایه را نقض کردید» مفید باشد. در حقیقت ساختار بندی دادن به لایه حقیق که باید یک عملکرد مشخص را انجام دهد کار بسیار سختی است، و استدلال‌هایی که به کار می‌رود بسیار پیچیده تر از این است که بگوئیم «مدل OSI چه می‌گوید؟» به همین خاطر ما سعی کرده ایم از به کار بردن روش محض لایه بندی در این سری از پست‌ها پرهیز کنیم. در عوض در اینجا ما به شما عملکرد‌های متنوعی را نشان می‌دهیم که شما برای کار با پروتکل‌ها و درک عملکرد آن‌ها نیاز دارید، و در نهایت با کمک آن‌ها می‌توانید این پروتکل‌ها را به صورت موفقیت آمیزی پیاده سازی کنید.

بر رقم روش غیرلایه بندی که در اینجا به کار برده ایم؛ برخی از اوقات ما نیازمند آن هستید که از روش‌های صحبت کنیم که درباره کلاس پروتکل‌ها صحبت می‌کند و نام لایه‌هائی مطرح می‌شوند که در آن‌ها این عملیات‌ها می‌توانند با موفقیت بیشتری پیاده سازی شوند و یا بهترین انتخاب باشند. به همین خاطر، برای مثال در این سری از پست‌ها ما تمرکز اصلی خودمان را بر روی پروتکل‌های لایه-لینک قرار داده ایم. (کدگذاری بیتی مورد بحث ما به عنوان یک عملکرد لایه-فیزیکی در نظر گرفته می‌شود). پروتکل‌های لایه-لینک می‌تواند به وسیله این حقیق معرفی شوند که آن‌ها می‌توانند بر روی یک لینک پیاده سازی شوند- نوع شبکه نیز در ادامه توضیح داده خواهد شد. در مقابل، پروتکل‌های لایه – شبکه بر روی شبکه‌های سوئیچ شده که محتوی تعداد زیادی از لینک‌ها که به وسیله سوئیچ‌ها و روتر‌ها با هم در ارتباط هستند، توضیح داده می‌شوند.

توجه داشته باشید که لایه‌های پروتکل در اینجا مفید هستند – آن‌ها می‌توانند راهی سودمند را به ما ارائه کنند که ما با استفاده از آن می‌توانیم درباره لایه پروتکل‌ها صحبت کنیم، و آن‌ها به ما کمک می‌کنند که بتوانیم مسئله ساخت شبکه در قالب زیر وظیفه‌های قابل مدیریت را تقسیم بندی کنیم. هرچند، این به معنای آن نیست که باید خودمان را به این دیدگاه محدود کنیم- حقیقت این است که گاهی از اوقات لایه بندی نقض می‌شود و ما به دنبال کاری می‌رویم کمه واقعا ارزش انجام دادنش را دارد. به عبارت دیگر لایه بندی یک خدمت کار خوب و یک ارباب ضعیف است.

فریم بندی مبتنی بر ساعت (SONET)

سومین روشی که ما می‌توانیم از آن استفاده کنیم تا فریم بندی را انجام دهیم آن است که از استاندارد شبکه نوری همزمان (SONET) استفاده کنیم. به خاطر این که این واژه به صورت عمومی کمتر پذیرفته شده است، ما این روش را به سادگی به عنوان فریم بندی بر اساس ساعت (clock based) می‌نامیم. روش استاندارد شبکه نوری همزمان (SONET) در اولین بار به شرکت تحقیقات ارتباطی Bell یا Bellcore ارائه شده است و پس از آن توسط انیستیتو استاندارهای ملی آمریکا (ANSI) برای انتقال داده‌های دیجیتال بر روی فیبر نوری توسعه داده شده است؛ پس از آن آن به وسیله ITU-T توسعه داده شده است. استاندارد شبکه نوری همزمان (SONET) سال‌ها است که به عنوان روش و استاندارد غالب در انتقال داده‌های فاصله دور (Long distance) در شبکه هیا فیبر نوری به کار گرفته می‌شود.

یک نکته مهم درباره استاندارد شبکه نوری همزمان (SONET) قبل از رفتن به بخش‌های بعد این است که تعریف کامل این استاندارد بسیار وسیع است و شاید به اندازه یک کتاب قطور باشد!. به همین خاطر ما در ادامه بحث‌های خودمان تنها درباره مواردی بحث خواهیم کرد که نیاز کارمان باشد و مطالعه کامل آن را بر عهده شما خواهیم گذاشت. همچنین استاندارد شبکه نوری همزمان (SONET) هم برای مسئله فریم بندی و هم برای مسئله کدگذاری به کار گرفته می‌شود. همچنین آن برای یکی از مسائل مهم شرکت‌های تلفن یعنی مالتی پلکسینگ چند لینک با سرعت کم در لینک‌های با سرعت بالا، به کار گرفته شده است. (در حقیقت، بسیاری از طراحی‌های استاندارد شبکه نوری همزمان (SONET) انعکاس دهنده نیازهای شرکت‌های تلفن برای مواجه با مالتی پلکسینگ تعداد زیادی از کانال‌های 64 کیلوبایتی است که به صورت سنتی برای تماس‌های تلفنی به خدمت گرفته می‌شدند). ما کار خودمان با استاندارد شبکه نوری همزمان (SONET) را در زمینه موضوع فریم بندی شروع می‌کنیم و موضوع بعدی را در ادامه توضیح خواهیم داد.

همانطور که ماپیش از این درباره طرح فریم بندی توضیح دادیم، یک فریم SONET اطلاعات ویژه ای را در اختیار گیرنده قرار می‌دهد که با کمک آن فریم شروع و خاتمه پیدا می‌کند؛ هرچند، تا اندازه ای همه چیز شبیه به روش‌های قبل از این است. نکته قابل توجه آن است، که در اینجا از هیچ روش چاشنی بیتی استفاده نشده است، بنابراین طول فریم‌ها وابسته به داده‌های ارسالی نیست. بنابراین سوالی که در اینجا باید پرسیده شود آن است که «چطور دریافت کننده می‌تواند شروع و خاتمه هر کدام از فریم‌ها را بفهمد؟» ما این پرسش را برای لینک‌ها سرعت پائین SONET بررسی کردیم که به عنوان STS-1 شناخته می‌شوند و می‌توانند برای سرعت 51.84 مگابیت بر ثانیه به کار برده شوند.

یک فریم STS-1 در تصویر 2.9 نشان داده شده است. آن به صورت 9 ردیف 90 بایتی آرایش یافته است و هر سه بایت اول از هر کدام از ردیف‌ها سرباره (overhead) هستند، بقیه بایت‌ها برای داده‌هایی که باید از طریق لینک ارسال شده، استفاده می‌شوند. دو بایت اول از هر فریم حاوی بیت‌هایی با پترن خاصی است، و این بیت‌ها گیرنده را قادر می‌کند که بتواند تعیین کند که فریم جدید استارت شده است. هرچند، به خاطر آنکه در اینجا از روش چاشنی بیتی استفاده نشده است، دلیلی هم نداشته است که این الگو در بخش ظرفیت ترابری از یک فریم قرار گیرد. برای جلوگیری از این موضوع، دریافت کننده به پترن‌های ویژه بیتی به صورت دائمی نگاه می‌کند، به این امید ک بتواند در هنگامی که 810 بایت (یعنی 9 ردیف 90 بایتی برابر است با 810 بایت) هنگامی که الگوهای ویژه در جای درست و زمان درست ظاهر شوند، دریافت کننده می‌فهمد که باید همزمانی را انجام داده و می‌تواند به درستی فریم را تفسیر کند.

یک فریم STS-1 از استاندارد شبکه نوری همزمان (SONET)

تصویر 2.9 یک فریم STS-1 از استاندارد شبکه نوری همزمان (SONET)

چیزهای دیگری نیز در اینجا وجود دارند که ما به خاطر پرهیز از پیچیدگی SONET از توضیح دادن آن پرهیز کردیم، آن‌ها جزئیاتی هستند که در بایت‌های سرباره به کار می‌روند. بخشی از این پیچیدگی می‌تواند به این خاطر باشد که SONET بر روی شبکه‌های نوری اجار می‌شود، و تنها بر روی یک لینک نیز به کار گرفته نمی شود. (در اینجا باید تکرار کنم که ما در حال بررسی کردن نحوه پیاده سازی محمل‌های داده در یک شبکه هستیم، و ما درعوض آن بر روی به کارگیری یک لینک SONET از مجموعه لینکهای موجود تمرکز کرده ایم زیرا این لینک می‌تواند شبکه سوئیچ شده بسته ای ما را ایجاد کند). پیچیدگی‌های بیشتر به این خاطر به وجود می‌آیند که SONET می‌تواند به جای آن که تنها یک انتقال دهنده داده باشد، مجموعه ای از سرویس‌ها را به ما ارائه کند. برای مثال، لینک 64 کیلوبایتی از SONET این ظرفیت را دارد که هم برای یک کانال صوتی جانبی در زمان نگهداری از شبکه، نیز به کار رود.

بایت‌های سرباره در یک فریم SONET با استفاده از روش غیربرگشت به صفر (NRZ) کدگذاری می‌شوند، که این روش کدگذاری در بخش قبلی توضیح داده شد، که در آن یک‌ها در باند بالائی و صفرها در باند پائینی قرار می‌گیرند. هرچند، برای اطمینان از آن که در اینجا تعداد زیادی از تراکنش‌ها میسر است، این اجازه به گیرنده داده شده است که بتواند ساعت فرستنده را بازیابی کند، بایت‌های در بخش ظرفیت ترابری نیز به هم ریخته و آشفته هستند. این کار به وسیله محاسبه دقیق نقیض OR یا XOR از داده‌های انتقال داده شده محاسبه می‌شود که آن‌ها نیز خود از الگوهای بیتی شناخته شده بهره می‌گیرند. الگوی بیتی، که 127 بیت درازا دارد، دارای تغییرات زیادی از یک به صفر است، بنابراین حالت نقیض سازی OR ان با داده‌های انتقال داده شده، احتمالا منجر به رسیدن به سیگنالی می‌شود که به اندازه کافی برای سرعت بازیابی قابل به کار گیری است.

SONET در اینجا می‌تواند از مالتی پلکسینگ در چند لینک با سرعت پائین به شیوه‌هایی که در ادامه گفته می‌شود پشتیبانی کند. یک لینک SONET در یکی از مجموعه‌های متناهی از نسبت‌های ممکن که از رنج 51.84 مگابیت بر ثانیه (یعنی STS-1) تا 39,813,120 مگابیت بر ثانیه (STS-768) را شامل می‌شود، اجرا می‌شود، توجه کمنید که تمام این نرخ‌ها به صورت ضریب‌های عدد صحیح از STS-1 هستند. نکته مهم برای فریم بندی در اینجا آن است که یک فریم SONET می‌تواند حاوی فریم‌های زیر مجموعه برای چند کانال با نرخ حداقلی (Lower Rate) باشد. ساختار ثانویه مرتبط در اینجا آن است که هر کدام از فریم‌ها دارای طولی برابر با 125 میکرو ثانیه هستند. این به معنای آن است که در نسبت‌های STS-1 یک فریم SONET دارای طولی به اندازه 810 بایت است، در حالی که در نسبت STS-3 هر کدام از فریم‌های SONET دارای طولی برابر با 2430 بایت است. به سینرژی (synergy) میان این دو ساختار دقت کنید: 3 × 810 = 2430، که به معنای آن است در اینجا سه فریم STS-1 به صورت دقیق در یک فریم STS-3 قرار می‌گیرند.

واضح است، در اینجا فیم STS-N می‌تواند از شامل N عدد فریم STS-1 باشد، که در آن بیت‌های این فریم‌ها به صورت لایه لایه هستند؛ بنابراین، ابتدا یک بایت از فریم اول ارسال شده، سپس یک بایت از فریم دوم انتقال داده می‌شود و این بازی به همین شکل تا آخرین بایت از آخرین فریم ادامه پیدا می‌کند. دلیل ارسال لایه به لایه یا مرحله به مرحله بایت‌های هر کدام از فریم‌های STS-N آن است که مطمئن شویم هر بایت که در فریم STS-1 قرار گرفته است، در نهایت انتقال داده می‌شود, که بر همین است، بایت به جای آن همگی در طول یکی از N مین لایه‌های به طول 125 میکرو ثانیه ارسال شوند، در اینجا باسرعت یکنواخت 51 مگابیت بر ثانیه ارسال می‌شوند.

سه فریم STS-1 به صورت مالتی پلکس شده در درون یک فریم STS-3c قرار گرفته است.

تصویر 2.10، سه فریم STS-1 به صورت مالتی پلکس شده در درون یک فریم STS-3c قرار گرفته است.

اگرچه دقیقتر آن است که یک سیگنال از STS-N به عنوان فریم N ام مالتی پلکس شده فریم STS-1 دیده شود، ظرفیت ترابری از این فریم‌های STS-1 می‌تواند با هم دیگر برای ایجاد یک ظرفیت ترابری STS-N ترکیب شوند؛ یک چنین لینکی به صورت STS-Nc (به معنای پیوسته concatenated) نشان داده می‌شود. یکی از فیلد‌های در قسمت سرباره برای این منظور در نظر گرفته شده است. تصویر 2.10 به صورت شماتیک پیوستگی در مورد سه فریم STS-1 را نشان می‌دهد که همگی در درون یک فریم STS-3c واحد به هم پیوسته اند. نکته مهم در زمینه یک لینک SONET آن است که آن‌ها به جای آن که به صورت STS-3 باشند به شکل STS-3c طراحی می‌شوند که در موردهای قبلی به آن اشاره شد، کاربر لینک می‌تواند آن را به صورت یک خط ارتباطی 155.25 مگابیت بر ثانیه در نظر بگیرد، درحالی که یک STS-3 به ندرت می‌تواند به صورت یک لینک با ظرفیت 51.84 مگابیت بر ثانیه در یک فیبر نوری مشترک در نظر گرفته شود.

فریم‌های خارج از فاز

تصویر 2.11 فریم‌های خارج از فاز08

در نهایت، بایت بگوئیم که توضیح SONET در اینجا بسیار ساده شده است، و فرض شده است که ظرفیت ترابری هر کدام از فریم‌ها کاملا در درون یک فریم جای می‌گیرد. (چرا نباید این طور باشد؟) در حقیقت، ما دیدیم که فریم STS-1 تنها به عنوان یک نگهدارنده فضا برای یک فریم به کار می‌رود، که ظرفیت بار می‌تواند در میان مرزهای آن فریم شناور باشد. این شرایط در تصویر 2.11 نمایش داده شده است. در اینجا ما دو ظرفیت ترابری STS-1 را مشاهده می‌کنیم که در میان دو فریم STS-1 قرار گرفته اند، و ظرفیت ترابری نسبت به تعداد بایت‌های سمت راست متغییر است و به همین خاطر، به دور آن پیچیده شده است. یکی از فیلد‌ها در سرباره اشاره به ابتدای ظرفیت ترابری فریم دارد. مقداری که در اینجا گنجانده شده است، می‌تواند وظیفه همگام سازی ساعت‌ها در میان محمل‌های شبکه را ساده کند، این موضوع گاهی از اوقات یکی از نگرانی‌هایی است که هر کدام از محمل‌های داده، زمان زیادی را برای حل آن خرج می‌کنند.

No votes yet.
Please wait...

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.

منو اصلی

question