بخشی از مقاله
چکیده
ایده شبکههای مبتنی بر نرمافزار1 با این هدف که کل شبکه به صورت یک موجودیت قابل برنامهریزی مدیریت شود، ارائه شده و در حال توسعه است. پروتکل OpenFlow بعنوان پروتکلی مطرح در این زمینه، با بهرهگیری از کنترلر متمرکز قابل برنامهریزی، به منظور پیادهسازی سیاستهای مدیریتی موردنظر، قوانین جدید هدایت بستهها را در مورد جریانهای متمایز بستهها تحت عنوان درایههای جریان2، در جدولهای جریان سوییچهای شبکه نصب میکند. جدول های جریان با وجود سرعت بالا ظرفیت محدودی دارند. بنابراین، مدت زمان نگهداری و نحوه جایگزینی درایههای مفیدتر، به چالشی مهم در این پروتکل تبدیل شده است.
در نتیجه ناکارآمدی سیاست جایگزینی درایههای جدول جریان، به دلیل عدم حضور درایههای جریان متناظر با بستههای ورودی در جدول جریان سوییچ، میزان مراجعات به کنترلر جهت جایگزینی درایههای مذکور و در نتیجه تاخیر هدایت بستهها افزایش مییابد. از همینرو، تمرکز اصلی این پژوهش، بر ارائه روشی آماری جهت جایگزینی درایههای جدول جریان است که بتواند سربار کنترلر را تا حد امکان کاهش دهد.
ایده کلیدی در روش پیشنهادی آن است که از ویژگیهای آماری جریانهای ترافیکی موجود در جدول جهت انتخاب جریان انتخابی برای جایگزینی استفاده شود. پیادهسازی الگوریتم پیشنهادی به کمک ابزار MiniNet و مقایسه نتایج آن با الگوریتمهای جایگزینی موجود، چون FIFO و Random نشاندهنده افزایش قابل توجه در نرخ برخورد در جدول جریان سوییچ Openflow بوده و برتری آن را در کاهش سربار کنترلر تایید مینماید.
مقدمه
اخیراً شبکههای مبتنی بر نرمافزار در میان پژوهشگران و صنعت محبوبیت زیادی پیدا کرده است. شکل 1، ساختار کلی از این شبکهها را نشان میدهد. مزیت اصلی این شبکهها انعطافپذیری آن به دلیل جدا بودن سطح کنترل3 از سطح داده4 است. با استفاده از شبکههای مبتنی بر نرمافزار کل شبکه و عناصر آن بصورت یک شبکه مجازی دیده میشود. این شبکهها با استفاده از نرمافزارها و رابطهای برنامهنویسی کاربردی طراحی شده، کنترل میگردد. بنابراین، در شبکههای مبتنی بر نرمافزار نیازمند یک پروتکل ارتباطی بین نرمافزارها و سختافزارها هستیم که بتواند کدهای نرمافزاری کنترلی را به تمامی ابزارهای گوناگون از تولیدکنندگان متفاوت اعمال کند.[1]
OpenFlow نام پروتکلی است که این کار را انجام میدهد. در معماری این پروتکل، که در شکل-2، نمایش داده شده است، هر سوئیچ OpenFlow که عملیات هدایت بستههای شبکه را انجام میدهد، شامل یک یا چند جدول و یک لایه انتزاعی میباشد. این لایه انتزاعی، برای ارتباط ایمن سوییچ با کنترلر از پروتکل OpenFlow استفاده میکند.[3] جدولهای جریان مقایسه میشود. در صورت تطبیق بسته با یکی از درایه-های جدول، سیاست مشخصشده در آن درایه جریان بر بسته مذکور اعمال میگردد. چنانچه بسته ورودی با هیچیک از درایههای جریان مطابقت نداشته باشد؛ پیامی به نام Packet_in جهت پردازش آن به کنترلر ارسال میگردد.
واضح است که در این حالت، زمان بیشتری برای پردازش بسته صرف میشود. در نتیجه، با افزایش تاخیر پردازش بستهها، بستههای متعلق به جریانهای ورودی در بافر سوییچ جمع شده و بافر سوییچ در نهایت پر میشود. این عملکرد منفی باعث میشود که بستههای جدید به هنگام ورود دور انداخته شوند. از آنجا که سوییچهای متعددی به کنترلر متصل است؛ بنابراین ارسال این پیامها به کنترلر باعث افزایش سربار ارتباطی بین کنترلر و سوییچ می-شود.
بنابراین، یکی از معیارهای مهم برای جایگزینی درایههای جریان، کاهش سربار کنترلر است. این موضوع انگیزه اصلی تحقیق انجام شده در این مقاله است. با توجه به اینکه کنترلر مسئول به روزآوری و جایگزینی درایه-های جدول جریان است، درصورت ناکارامد بودن سیاست کنترلر در جایگزینی درایههای جدول جریان ناپایدار شده و سربار محاسبات کنترلر افزایش مییابد. با استفاده از این نکته کلیدی، رویکرد پیشنهادی در این مقاله بر آن است که درایههای موجود در جدول جریان را بر اساس مشخصه-های آماری جریانهای متناظرشان به روز نماید.
در ادامه این مقاله در بخش دوم مروری بر کارهای گذشته ارائه شده و در آن مهمترین تحقیقاتی که در زمینه کاهش سربار کنترلر از طریق بهینهسازی الگوریتم جایگزینی درایههای جدول جریان انجام شده مرور شده است. در بخش بعدی پس از تعریف مشخصههای آماری جریانهای شبکه، الگوریتم پیشنهادی برای کاهش سربار کنترلر بیان میشود. بعد محیط پیاده سازی روش پیشنهادی و روشهای مورد مقایسه، معیارهای ارزیابی و مقایسه کارایی روشها و نتایج حاصله از شبیهسازی در بخش چهارم مقاله به تفصیل تشریح میشود. بخش پنجم نیز به نتیجهگیری از تحقیق و ارائه پیشنهادات جهت توسعه آن اختصاص داده شده است.
ساختار سوییچ [4] OpenFlow
مهمترین مولفههای هر سوییچ OpenFlow جدولهای جریان آن است. جدولهای جریان شامل درایههای جریان هستند، که هرکدام از این درایهها تعیین میکند که چطور بستههای متعلق به یک جریان باید پردازش و ارسال شوند. درایههای جریان توسط کنترلر در جدولهای جریان تعریف می-شوند.[4] این جدولها ظرفیت محدودی دارند. بنابراین، تعداد درایههای جریانی که در آنها میتوان ذخیره نمود مشخص و محدود است. جدولهای جریان از حافظههای تداعیگر سه وضعیتی5 ساخته شدهاند. حافظههای تداعیگر سهوضعیتی علاوه بر قیمت زیاد، مصرف انرژی بالایی دارد. بنابراین، افزایش اندازه جدولهای جریان هزینهبر بوده و همچنین مصرف انرژی را افزایش میدهد.
5] نحوه عملکرد جدولهای جریان به این صورت است که اطلاعات هریک از بستههای جریانهای ورودی با درایههای موجود د مروری بر کارهای انجام شده محققان راهحلهایی برای مقابله با این محدودیت جدول جریان اندیشیده-اند که عبارتند از: تکنیکهای خروج6 برای حذف درایهها از جدول جریان قبل از نصب درایههای جدید، تکنیکهای مبتنی بر فشردهسازی7 که این روشها افزونگی اطلاعات بین درایههای جریان موجود در جدولهای جریان را تا جای ممکن کاهش میدهند و تکنیکهای شکستن و توزیع 8 است که در این روشها سوییچها یک سیستم توزیع شده کلی میسازند که به هم وابسته هستند به جای اینکه مستقل از هم باشند. روشهای پیشنهادی مبتنی بر خروج شامل الگوریتمهای جایگزینی و مکانیزمهای مبتنی بر زمان انقضا است.
[6] الگوریتمهای جایگزینی که تاکنون در مقالات مختلف بکارگرفته شدهاند و قابل پیادهسازی در شبکه مبتنی بر نرمافزار بودهاند FIFO و Random و LRU بودهاند. Adam zarek از دانشگاه تورنتو در سال 2012 در مقالهای الگوریتمهای جایگزینی - LRU,FIFO,Random - را مقایسه کردهاند. به این صورت که جدول جریان به صورت یک cache در نظر گرفته شده و درایهها فقط زمانی حذف میشوند که جدول جریان پر باشد و بر اساس سیاستهای جایگزینی نامبرده شده درایه مورد نظر انتخاب و حذف میشود. با بررسی این الگوریتم-ها دریافتهاند که FIFO و Random تفاوت نسبتا کمی با هم دارند ولی FIFO بهتر از Random است. با این وجود Random نیز نمیتواند خوب باشد چرا که ممکن است درایههایی از جدول که ارجاع زیادی را دارند جهت جایگزینی انتخاب کند.
اما LRU بهتر از دو الگوریتم دیگر است و اندازه نرخ برخورد برای آن بیشتر است. ولی LRU در آن زمان قابل پیاده سازی در شبکههای مبتنی بر نرمافزار نبوده است. در پایان عملکرد ترکیب timeoutهای مختلف با الگوریتم جایگزینیLRU نیز بررسی شده است. طبق نتایج، زمانی که طول جدول کوچکتر از تعداد درایههای فعال است اندازه timeout تاثیر چندانی ندارد و هر بهبود عملکردی وابسته به الگوریتم جایگزینی استEun -Do Kim .[7] و همکارانش نیز در سال 2014، در مقالهای به منظور کاهش سربار کنترلر شبکههای مبتنی بر نرمافزار که بر اثر عدم برخورد - - table miss در جدول جریان به هنگام ورود جریانها ایجاد میشود، راهکاری را ارائه دادهاند.
در این کار، برای مدیریت جدول جریان از الگوریتمLRU در هنگام جایگزینی درایههای جریان، استفاده شده است و نتایج نشان داده که این الگوریتم بهتر از روشهای FIFO و Random عمل میکند، از مفهوم Vacancy که در OpenFlow1.4 است استفاده کرده-اند.[9 , 8] اما این روش در سوییچ OpenFlow پیادهسازی شده است در صورتی که در شبکه مبتنی بر نرمافزار کارهای کنترلی باید در قسمت کنترلر پیاده شود. پیادهسازی الگوریتم LRU در کنترلر نیازمند این است که کنترلر از آخرین درایهای که با جریانهای ورودی به سوییچ منطبق شده است مطلع باشد و این اطلاعرسانی به کنترلر خود بار زیادی بر کنترلر وارد میکند. از آنجا که در این مقاله الگوریتمهایی که در کنترلر قابل پیادهسازی و مبتنی بر شبکه مبتنی بر نرمافزار هستند ارزیابی شدهاند، لذا در این کار این الگوریتم مورد بررسی قرار نگرفته است.
با توجه به مطالعات پیشین در این زمینه و همچنین نوظهور بودن شبکههای مبتنی بر نرمافزار میتوان دید که تحقیقات در این زمینه کامل نمیباشد و از روشهای آماری در مدیریت جدول جریان که میتواند تاثیر جدی در میزان بهینهسازی مکانیزم مدیریتی درایههای جدول جریان داشته باشد، استفاده نشده است. بنابراین، هدف ما در این پژوهش برآن بوده است که با استفاده از یک ویژگی آماری یعنی تعداد تکرار نصب جریانها مکانیزم مدیریتی جدول های جریان را بهبود دهیم. در بخش بعدی راهکار پیشنهادی به طور کامل توضیح داده میشود. برای ارزیابی کارایی روش پیشنهادی در بخش پیادهسازی و ارزیابی، نتایج آن را با نتایج حاصل از الگوریتم Random و FIFO مقایسه مینماییم.
روش پیشنهادی
در نسخههای قبل از OpenFlow1,4 هنگام نصب یک درایه جریان جدید از سوی کنترلر در جدول جریان، اگر جدول پر بود پیغامی از سوی سوییچ به کنترلر ارسال میشد و پر بودن جدول و عدم نصب درایه را به کنترلر جهت گرفتن تصمیم خبر میداد. در نسخهOpenFlow 1,4 مفهوم جدیدی به نام Eviction اضافه شده است. اگر این ویژگی از سوی کنترلر فعال شود، هنگام نصب درایه جریان جدید در جدول جریان، اگر جدول پر باشد یکی از درایهها را بر اساس ویژگی اهمیت - Importance - درایهها جهت جایگزینی انتخاب میکند. درایهای که درجه اهمیت آن از همه پایینتر است برای جایگزینی انتخاب میشود. در روش پیشنهادی نیز از همین ویژگی استفاده شده است.
به اینصورت که ویژگی Importance را بر اساس تعداد دفعاتی که جریان باید در کنترلر نصب شود اختصاص میدهیم. در نتیجه هنگام پر شدن جدول جریان درایهای از جدول که کمتر مورد ارجاع و نصب قرار میگیرد از جدول حذف میشود. در شکل3، روندنمای روش پیشنهادی نشان داده شده است. در پروتکل OpenFlow رخدادی به نام flow_removed وجود دارد. زمانی که جریانی از جدول جریان حذف میشود، سوییچ با این رخداد، حذف شدنش را به کنترلر اطلاع میدهد. همانطور که در شکل3 مشخص است زمانی که یک درایه جریان به هر دلیلی از جدول جریان حذف میشود و رخداد flow_removed ارسال میشود اطلاعات مربوط به این جریان در کنترلر ذخیره و به تعداد تکرار جریان مذکور یکی اضافه میشود.
در میان جریانهای ورودی به سوییچ ممکن است جریانهایی وجود داشته باشد که در فواصل زمانی زیاد تکرار میشوند. اهمیت درایه جریان متناظر با چنین جریانهایی با نرخ کمتری کاهش مییابد. هنگام نصب یک جریان نیز ابتدا بررسی میشود که آیا این درایه قبلا در جدول جریان نصب شده یا خیر. این جستجوی سریع با یک جدول درهمسازی پیادهسازی شده است. چنانچه مشخص شود که جریان قبلا در جدول نصب شده importance آن برابر تعداد تکرار جریان میشود و در غیر اینصورت مقدار اولیه 1 را میگیرد.
