مشخصات SCTP

TSN ^[۹۱]

واحد داده در TCP بایت است. انتقال داده در TCP با بهره گرفتن از شماره‌گذاری بایت‌ها کنترل می‌شود. ولی در SCTP واحد داده chunk است. انتقال داده در SCTP با بهره گرفتن از شماره‌گذاری chunkها کنترل می‌شود. SCTP از TSN برای شماره‌گذاری chunkها استفاده می‌کند. طول TSN 32 بیت است که با یک عدد تصادفی بین ۰ و۱ - ۲^۳۲ مقداردهی اولیه می‌شود.

( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )

SI ^[۹۲]

در TCP به ازای هر ارتباط فقط یک جریان وجود دارد، در حالی که در SCTP ممکن است بیش از یک جریان در یک ارتباط وجود داشته باشد. برای تفکیک کردن جریان‌ها در SCTP از SI استفاده می‌شود. طول SI 16 بیت است که مقدار آن از صفر شروع می‌شود.

SSN ^[۹۳]

وقتی داده‌ها در گیرنده دریافت می‌شوند، هر chunk مربوط به جریان مربوطه باید در جای صحیح خود قرار گیرد. بدین منظور از SSN استفاده می‌شود. SSN شماره chunkها را در یک جریان مشخص می‌کند.
در SCTP، chunk، جریان و بسته وجود دارند. یک ارتباط ممکن است تعداد زیادی بسته ارسال کند. یک بسته ممکن است شامل چندین chunk و chunkها خود ممکن است متعلق به جریان‌های مختلف باشند. در شکل ‏۴‑۲ مثالی از این مفاهیم برای روشن‌تر شدن مطلب آورده شده است.
بسته ۲
بسته ۳
بسته ۱
بسته ۴
شکل ‏۴‑۲ بسته، chunk و جریان‌ها در SCTP ]۴۰[
جریان بسته‌ها از فرستنده به گیرنده

مشتقات SCTP

همان‌طور که اشاره شد SCTP یک پروتکل لایه انتقال، مطمئن و اتصال گراست که شامل ویژگی‌های جدیدی است که آن را برای طیف وسیعی از کاربردها مناسب می‌کند. SCTP می‌تواند هم انتقال مرتب شده و هم انتقال نامرتب را فراهم نماید. PR-SCTP ]۷[ پروتکلی مشتق شده از SCTP است که امکان انتقال نیمه مطمئن بسته‌ها را مهیا می‌کند. اگر در هر دو طرف ارتباط از PR-SCTP استفاده شود، فرستنده می‌تواند رفتار انتقال مجدد مربوط به هر پیام را انتخاب کند. سرویس نیمه مطمئنی که هم‌اکنون استفاده می‌شود اطمینان زمانی^[۹۴] نام دارد. اطمینان زمانی بدین شکل است که کاربر می‌تواند طول عمر پیام را مشخص کند. وقتی طول عمر پیام به اتمام برسد و هنوز پیام تصدیق آن نرسیده باشد، فرستنده ارسال مجدد این پیام را متوقف می‌کند.
تحقیقات فراوانی برای افزایش کیفیت انتقال ویدئو بر روی شبکه صورت گرفته است. پیش نویس اینترنت ]۸[ فرمت‌های جدید RTP payload را توضیح می‌دهد که امکان چندین انتقال مجدد را به صورت انتخابی در RTP فراهم می‌کند. این امکانات مخصوص محیط‌هایی است که از RTCP استفاده می‌کنند. این فرمت‌های payload جهت جداسازی جریان‌های مدیا بر اساس اولویت و وضعیت انتقال آن‌ ها (انتقال یا انتقال مجدد) مورد استفاده قرار می‌گیرند.
فیستر^[۹۵] ]۹[ محیطی جامع جهت آزمایش SR-RTP ^[۹۶] ارائه کرده است. او از RTP بر روی UDP به همراه تعمیمی برای فعال کردن بازخورد گرفتن از ارتباط بین سرور و مشتری، استفاده می‌کند. او برنامه‌ای برای انتقال ویدئو با کیفیت بالا توسعه داده است.
کار انجام شده توسط رامان^[۹۷] ]۱۰[ پیاده‌سازی و ارزیابی پروتکل ITP ^[۹۸] برای انتقال تصاویر بر روی شبکه‌های بی‌سیم است. او کیفیت ویدئو را در سطح فریم‌بندی کاربرد^[۹۹] بررسی می‌کند.
به منظور تمایز قائل شدن در اطمینان انتقال هر کدام از فریم‌ها در انتقال ویدئوی MPEG، ]۱۱،۱۲[ تعداد ارسال مجدد را برای انواع فریم‌ها را محدود می‌کند. به عنوان مثال فقط یک بار ارسال مجدد برای I-فریم‌ها و P-فریم‌ها مجاز است چرا که با گذشت زمان پخش دیگر نیازی به فریم‌های مربوط به GOPهای قبلی نیست. همچنین هیچ ارسال مجددی برای B-فریم در نظر گرفته نمی‌شود چرا که تأثیر زیادی بر روی ویدئوی دریافتی نمی‌گذارد.
همچون ]۱۱،۱۲[، Media-SCTP ]13[ نیز تعداد ارسال‌های مجدد را بر اساس فریم محدود می‌کند. Media-SCTP فرض می‌کند فریم‌هایی که به یک GOP تعلق دارند دارای مهلت پخش یکسان هستند. از آنجا که GOPها دارای تعداد یکسانی فریم هستند، در نتیجه مهلت‌های پخش با یک فاصله یکسان از هم قرار می‌گیرند. از آنجا که زمان ارسال مجدد تقریباً برابر است با ۰٫۵ RTT، اگر اختلاف زمان کنونی و مهلت پخش بیشتر ۰٫۵ RTT باشد، فرستنده مجاز خواهد بود تا مجدداً فریم مورد نظر را ارسال نماید. در غیر این صورت پنجره ارسال به جلو رانده شده و از آن فریم صرف‌نظر می‌شود.
Ahmed و همکارانش ]۱۴،۱۵[ زیر لایه‌ای بر روی RTP موسوم به MP-RTP ارائه داده‌اند. همچون Media-SCTP، در MP-RTP نیز گیرنده مسئول درخواست برای ارسال مجدد فریم‌های گمشده است با این تفاوت که فریم‌های با اولویت بالا به صورت همزمان از طریق تمام مسیرهای ممکن منتقل خواهد شد.
در TC-SCTP ]16[ نیازی به پیام‌های گیرنده برای ارسال مجدد نیست. این پروتکل بر اساس ویژگی‌های چندجریانی^[۱۰۰] قرار دارد. در این پروتکل ۴ کلاس صف در لایه TCSL (لایه بالای PR-SCTP) با اولویت‌های مختلف تعریف می‌شود. صف اول برای I-فریم‌ها، صف دوم برای P-فریم‌ها، صف سوم برای B-فریم‌ها و در نهایت صف چهارم برای پیام‌های کنترلی در نظر گرفته می‌شود. در شکل ‏۴‑۳ این صف‌ها به همراه تعداد ارسال‌های مجدد برای هر صف نشان داده شده است.
شکل ‏۴‑۳ صف‌های موجود و استراتژی هر کدام در TC-SCTP ]16[
نتایج آورده شده در این مقاله حاکی از آن است که این پروتکل دارای کیفیت ویدئوی دریافتی بالاتری نسبت به SCTP و PR-SCTP است. در شکل ‏۴‑۴ مقایسه PSNR بین SCTP، PR-SCTP و TC-SCTP آورده شده است.
شکل ‏۴‑۴ مقایسه PSNR پروتکل‌های SCTP، PR-SCTP و TC-SCTP ]16[

DCCP ^[۱۰۱]

یکی از مهم‌ترین ویژگی‌های پروتکل TCP، کنترل ازدحام آن است. تعداد زیادی کاربرد وجود دارد که از TCP استفاده نمی‌کند و یکی از دلایل مهم این امر، وجود مکانیسم‌های کنترل ازدحام شبه TCP است که مناسب این کاربردها نمی‌باشد.
در سال‌های اخیر شاهد افزایش کاربردهایی هستیم که دارای جریان‌های طولانی مدت هستند و اکثر این جریان‌ها تمایلی به استفاده از کنترل ازدحام ندارند. مثلاً کاربردهایی نظیر چندرسانه‌ای که از UDP استفاده می‌کنند. ولی عدم استفاده از مکانیسم‌های کنترل ازدحام باعث قرار گرفتن شبکه در وضعیت ازدحام شده و در شبکه‌هایی که جریان‌های TCP نیز وجود دارند باعث قحطی‌زدگی این جریان‌ها می‌شوند. DCCP پروتکلی است که با هدف ایجاد مکانیسم‌های کنترل ازدحام بر روی پروتکل غیرمطمئن مثل UDP بوجود آمد. یکی از اهداف DCCP ارائه گزینه‌ای جایگزین TCP با در نظر گرفتن عدم وجود اطمینان در انتقال داده‌ها می‌باشد.
کاربردهایی نظیر تلفن اینترنتی، جریان سازی ویدئو و بازی‌های آنلاین، جریان‌های طولانی مدت از بسته‌های UDP را بوجود می‌آورند که امکان بلادرنگ بودن را مقدم بر انتقال مطمئن داده‌ها می‌دانند. در این برنامه‌ها داده‌هایی که پس از مهلت مقررشان به مقصد برسند مفید نخواهند بود. TCP موجب بوجود آمدن تأخیرهای غیرقابل پیش‌بینی و بعضاً بسیار زیاد در انتقال داده‌ها می‌شود که این امر به دلیل تلاش برای مطمئن کردن انتقال داده‌هاست. در نتیجه کاربردهای ذکر شده استفاده از UDP که دارای انتقال غیرمطمئن است را ترجیح می‌دهند. عدم استفاده از مکانیسم‌های کنترل ازدحام شبکه را با خطر جدی مواجه خواهد کرد. با افزایش کاربردهای بلادرنگ، شبکه در مرز از کار افتادن قرار می‌گیرد.]۴۳[

CCID 2: کنترل ازدحام شبه TCP

DCCP مکانیسم کنترل ازدحام شبه TCP با نام CCID 2 را فراهم می کند. ولی بخاطر این‌که این مکانیسم بر روی محتویات با انتقال غیرمطمئن اعمال می‌شود، بسیاری از فریم‌های کنترل ازدحام آن با TCP متفاوت است. کنترل جریان استفاده شده در TCP، در DCCP مورد نیاز نیست. اگر n بسته دریافت شده باشد ولی هنوز توسط کاربرد خوانده نشده باشد، و سپس بسته‌های n + m دریافت شوند، DCCP می‌تواند از این n بسته‌ای که در بافر قرار دارد صرف‌نظر کرده و از فضای بافر جهت دخیره بسته‌های جدیدتر بهره گیرد. کنترل ازدحام DCCP نیز همچون TCP از پنجره ازدحام جهت نظارت بر انتقال بسته‌ها و تعیین دریافت شدن یا نشدن آن‌ ها می کند، ولی از تصدیق تجمعی نمی‌تواند برای این منظور استفاده کند. در نتیجه مکانیسم دیگری برای اطمینان از انتقال مطمئن بسته‌ها مورد نیاز است.
راه‌های زیادی برای تکمیل این کار در یک انتقال نامطمئن وجود دارد. یکی از این راه‌ها استفاده از مکانیسمی شبیه TCP Sack ]17[ است. گیرنده پیام‌های تصدیق را جهت اطمینان بیشتر چندین بار به فرستنده ارسال می‌کند. اگر فرستنده هیچ‌کدام از این پیام‌های تصدیق را دریافت نکند پنجره ازدحام را نصف می‌کند. این رویکرد همیشه مطمئن خواهد بود ولی ممکن است منجر به کاهش ارسال غیر ضروری شود.
گزینه دیگری که می‌توان در DCCP استفاده نمود انتقال مطمئن پیام‌های تصدیق با بهره گرفتن از Ack-vector و acks-of-acks می‌باشد. لزوماً گیرنده مکرراً به فرستنده اطلاع می‌دهد که k بسته رسیده است، تا زمانی که پیام Ack-vector دقیقاً مشخص می‌کند که کدام بسته‌ها دریافت شده‌اند و کدام بسته‌ها در شبکه بر چسب ECN خورده‌اند.
یکی از محدودیت‌های TCP این است که هیچ مکانیسم کنترل ازدحامی برای بسته‌های تصدیق وجود ندارند، چرا که ممکن است ازدحام در مسیر برگشت رخ داده باشد. بر خلاف TCP، DCCP با بهره گرفتن از شماره‌گذاری به ازای هر بسته، قادر به کشف ازدحام در مسیر برگشت بوده و می‌تواند متناسباً تصمیمات لازم را اتخاذ نماید.

CCID 3: کنترل ازدحام TFRC

کنترل ازدحام TFRC در CCID 3 دیدگاهی کاملاً متفاوت با کنترل ازدحام CCID 2 را استفاده می‌کند. بجای استفاده از پنجره ازدحام در CCID 3 فرستنده از نرخ ارسال استفاده می‌کند و گیرنده به صورت دوره‌ای گزارش‌هایی از بسته‌های گمشده محاسبه شده به فرستنده ارسال می‌کند. فرستنده با بهره گرفتن از این گزارش‌ها نرخ ارسال خود را تنظیم می‌کند. اگر فرستنده پس از مدتی هیچ گزارشی از گیرنده دریافت نکند نرخ ارسالش را نصف می‌کند. نکته کلیدی که باید بدان توجه داشت این است که اطلاعاتی که TFRC به عنوان بازخورد نیاز دارد بسیار متفاوت‌تر از چیزی است که در حالت استفاده از پنجره ازدحام استفاده می‌شد.]۴۳[

فصل پنجم:

مکانیسم‌های پیشنهادی

کنترل ازدحام

تحقیقات گسترده‌ای در زمینه فهم اثرات ازدحام و بهبود کنترل ازدحام و نتایج آن در کارایی شبکه صورت گرفته است ]۱۸،۱۹،۲۰،۲۱،۲۲،۲۳،۲۴،۲۵[. در اینجا مختصراً در مورد کارهای مشابه انجام شده توضیح می‌دهیم. خوانندگان علاقه‌مند می‌توانند برای مطالعات جامعتر در مورد کنترل ازدحام بر روی شبکه‌های بی‌سیم به ]۲۶[ مراجعه نمایند.
مطالعات اولیه بر روی بهبود کارایی TCP بر روی شبکه‌های بی‌سیم بر تمایز قائل شدن بین گمشدگی بسته بخاطر خطا در پیوند ارتباطی و گمشدگی در اثر ازدحام شبکه، صورت گرفته است ]۲۷،۲۸،۲۹[. برخی از مطالعات اخیر به کنترل ازدحام بر روی شبکه‌های موردی بی‌سیم پرداخته‌اند. یکی از کلاس‌های کاری انجام شده بر روی بهبود گذردهی TCP با بهره گرفتن از متوقف کردن الگوریتم کنترل ازدحام در زمان خطا در پیوند و بخصوص در هنگام عوض شدن مسیر، متمرکز شده است ]۱۸،۱۹،۲۰،۲۱،۲۲،۲۴[.
علاوه بر تلاش‌هایی که برای بهبود کنترل ازدحام پروتکل‌های TCP و DCCP صورت گرفته، پروتکل‌های مستقلی نیز برای کنترل ازدحام مؤثر در لایه انتقال طراحی شده‌اند. از جمله معروفترین این پروتکل‌ها می‌توان به SCTP ]30[، Fusion ]31[، CODA ]32[، PCCP ]33[ و DPCC ]34[ اشاره نمود. همه این پروتکل‌ها بر روی جلوگیری از ازدحام تمرکز دارند. از جدیدترین پروتکل‌های ارائه شده در این ردیف می‌توان UDDP ]35[ را نام برد. تفاوت UDDP با پروتکل‌های ذکر شده این است که بر خلاف دیگر پروتکل‌ها ویژگی‌های محتویات مالتی مدیا را در کنترل ازدحام لحاظ می‌کند و در نتیجه دارای عملکرد بهتری نسبت به دیگر پروتکل‌های ذکر شده می‌باشد. در جدول ‏۵‑۱ خلاصه‌ای از مقایسه مکانیسم‌های کنترل ازدحام ذکر شده آورده شده است.