بخشی از مقاله
چکیده - پروتکل ARP با ایجاد پیام های همهپخشی موجب کاهش عملکرد شبکه می شود. تا کنون روش هایی برای کاهش ترافیک ARP با استفاده از یک جدول سراسری ARP که در یک کنترلر مرکزی نگهداری می شود، و شامل پاسخ های ARP پیشین برای استفاده های بعدی میباشد، پیشنهاد شده اند. با این حال، در شبکه هایی که میزبان ها دائما در حال ورود و خروج از شبکه هستند، مثل شبکه های محلی بی سیم در فرودگاه ها، هتل ها، فروشگاه ها و رستوران ها، جداول سراسری ARP به علت غیر معتبر شدن پاسخ های پیشین، کارآمد نیستند.
در این مقاله برای حل مشکل چنین شبکه هایی با استفاده از امکان کنترل متمرکز که شبکه سازی نرم افزار محور در اختیار ما قرار می دهد، جدول سراسری نگاشت های DHCP تشکیل و استفاده شده است. با استفاده از این روش، پیام های همهپخشی ناشی از ARP حذف می شوند و ترافیک ARP می تواند تا حدود 10 درصد کاهش پیدا کند. با کاهش ترافیک ARP، ظرفیت کانال میتواند برای ارسال داده های واقعی شبکه استفاده شود.
-1 مقدمه
برای آن که بسته های ارسالی از سوی یک میزبان مبداء به میزبان مقصد انتقال یابد، میزبان مبداء باید بتواند آدرس لایه شبکه - آدرس - IP که از مقصد در اختیار دارد را به آدرس لایه لینک - آدرس مک - تبدیل کند و در هدر پیام قرار دهد. برای تبدیل آدرس IP به آدرس مک از پروتکل ARP استفاده میشود. به این صورت که مبداء باید یک پیام درخواست ARP را برای آدرس IP مورد نظرش در شبکه همهپخشی کند؛ به این معنی که کدام یک از میزبان های شبکه دارای این آدرس IP هستند.
این درخواست به تمامی میزبان های درون شبکه فرستاده می شود. اگر آدرس IP میزبانی که پیام درخواست ARP را دریافت می کند، مطابق آدرس ذکر شده در پیام باشد، یک پاسخ ARP شامل آدرس مک خود، به آدرس مک فرستنده پیام درخواست ارسال می کند و به این طریق میزبان مبداء آدرس مک مطابق با آدرس IP مورد نظرش را پیدا می کند و می تواند پیامش را به میزبان مقصد ارسال کند.
پیام های ARP بزرگ نیستند ولی تعداد زیاد آن ها در شبکه در عملکرد شبکه تاثیر منفی می گذارد و حتی زمانی که برای انجام آن به هدر می رود، بیشتر از زمانی است که برای جستجوی یک جدول نگاشت مستقیم برای تبدیل آدرس لازم است. یکی دیگر از مشکلات این مکانیزم سربار پیام های همهپخشی است که برای درخواست ARP ارسال می شود و این بدین معنی است که همه دستگاه های درون شبکه باید برای بررسی محتوای هر پیام همهپخشی شده، CPU اختصاص دهند. شرایط هنگامی بدتر می شود که این مکانیزم در شبکه های بی سیم به کار گرفته شود.
در شبکه های بی سیم، پیام ها در تمامی جهات پخش می شوند تا به نقطه دسترسی یا میزبان مورد نظر خود برسند و این باعث افزایش احتمال تداخل و کاهش عملکرد شبکه می شود. طبق مطالعه [1] بسته های ARP در شبکه های محلی بی سیم 10 درصد ظرفیت کانال را به خود اختصاص می دهند. در ادبیات این موضوع، تلاش هایی برای کاهش ترافیک ARP در محیط های مختلف صورت گرفته است.
به عنوان مثال روش [2] برای کاهش ترافیک در شبکه های ATM، [3] و [4] در شبکه های IP کنونی، [5] در نقاط تبادل اینترنتی و [6] و [7] در شبکه های محلی بی سیم، یک سطح کنترلی متمرکز با در نظر گرفته اند و در آن یک جدول ARP سراسری تشکیل داده اند و با پاسخ به درخواست های ARP از طریق این جدول، سربار ARP را کاهش داده اند.
استفاده از جدول ARP سراسری می تواند باعث کاهش چشم گیری در ترافیک ARP شود، اما برای شبکه هایی که میزبان ها دائما در حال تغییر هستند، همچون شبکه های محلی بی سیم هتل ها یا فرودگاه ها، جدول ARP ممکن است پاسخگو نباشد، چرا که هر سطر جدول ARP زمان انقضایی دارد و متناوبا به روز می شود، در صورتی که یک میزبان پس از مدتی از شبکه خارج شود، سطر مطابق آی پی او پس از مدتی از بین می رود و اگر آدرس آی پی مورد نظر در جدول نباشد، سطح کنترلی با رسیدن درخواست ARP، آن را همهپخشی کند، درست مانند حالتی که هیچ جدول ARP سراسری وجود ندارد.
این مقاله در نظر دارد با استفاده از شبکه سازی نرم افزار محور، یک سطح کنترلی ایجاد کرده، و به جای استفاده از جدول ARP سراسری، نگاشت های DHCP را نگهداری کرده و آن ها را به روز می کند و از آن ها برای پیدا کردن پاسخ ARP استفاده می کند. با این کار تغییرات شبکه - ورود/خروج دائم میزبان ها - نیز باعث کاهش عملکرد ناشی از سربار ARP نخواهد شد.
هدف اصلی شبکهسازی نرم افزار محور، جداسازی سطح داده از سطح کنترلی می باشد. یک کنترلر به صورت متمرکز تمامی جریان های شبکه را کنترل می کند به این صورت که هر جریانی که برای اولین به سوییچ های شبکه میرسد، به کنترلر ارسال می شود، کنترلر برای آن تصمیم می گیرد، و تصمیم خود را برای سوییچ می فرستد. سوییچ بر اساس آن تصمیم عمل می کند. در صورتی که قبلا برای جریانی توسط کنترلر تصمیمی روی سوییچ موجود باشد، دیگر نیازی به ارجاع پیام به کنترلر وجود ندارد.
راهکار پیشنهادی این مقاله شامل یک کنترلر متمرکز SDN است که تمامی پیام های میزبان ها به او فرستاده می شود. این کنترلر ییک جدول DHCP در خود نگهداری می کند. در صورتی که پیام دریافت شده، درخواست ARP باشد، و سطری برای آی پی مورد نظر در جدول سراسری DHCP کنترلر وجود داشته باشد، آدرس مک نگاشت شده به آدرس آی پی به عنوان پاسخ ARP از کنترلر به سوییچ و نهایتا به میزبان مبداء فرستاده می شود.
در ادبیات موضوع، تنها روش [5] و [7] از شبکه سازی نرم افزار محور استفاده می کنند. با این حال، این دو راه حل از جدول سراسری ARP استفاده می کنند و نتایج نگاشت های DHCP را ذخیره و استفاده نمی کنند. به همین علت در شبکه های با میزان بالای ورود و خروج میزبان، دچار مشکل خواهند بود. استفاده از جدول نگاشت سراسری DHCP باعث می شود ما نگاشت آدرس مک به آدرس آی پی برای هر میزبانی که در شبکه وجود دارد را داشته باشیم و کاهش پیام های همهپخشی نسبت به حالتی که از جدول ARP سراسری استفاده می شود، بسیار بیشتر خواهد شد. در ادامه، در بخش 2 به ارائه روش پیشنهادی می پردازیم و سپس در بخش 3 نتایج حاصل از انجام آن را بررسی خواهیم کرد.
-2 روش پیشنهادی
همانطور که در بخش پیشین ذکر شد، روش های مبتنی بر جدول سراسری ARP ممکن است در شرایطی که میزبان های شبکه به طور دائم در حال تغییر هستند، مثلا در هتل ها، فروشگاه ها، فرودگاه ها، رستوران ها و غیره، پاسخگو نباشد. در این مقاله، برای حل این مشکل، از جدول سراسری DHCP استفاده می کنیم، با تغییرات شبکه - ورود و خروج مداوم میزبان ها - به طور حتم آن ها نیاز به آدرس IP خواهند داشت که توسط DHCP به هر آدرس مک اختصاص داده می شود.
در روش های معمول جدول DHCP نگهداری نمی شود، چرا که ممکن است چند سرور DHCP به صورت توزیع شده وجود داشته باشند و واحدی متمرکز برای یکپارچه کردن جداول آن ها وجود ندارد و بنابراین مدیریت این جداول به شکل کارا ممکن نخواهد بود. در روش پیشنهادی ما، تنها یک سرور DHCP وجود دارد و نگاشت های مک به آی پی در آن نگهداری می شود تا در صورت نیاز با جستجو در این جدول، مک مطابق با آی پی مورد نظر پیدا شود و پاسخ ARP ارسال شود.
راهکار مورد نظر شامل یک کنترلر SDN و تعدادی سوییچ است که با کنترلر ارتباط دارند. هر سوییچ دارای یک جدول جریان است که مشخص می کند با هر نوع جریان - دسته ای از پیام ها - چگونه باید رفتار شود. هر پیامی که به سوییچ می رسد،در صورتی که برای آن در جدول جریان سطری وجود نداشته باشد، به کنترلر فرستاده می شود.
کنترلر در مورد آن تصمیم می گیرد و قاعده ای به سوییچ می فرستد تا آن را در جدول جریان خود جای دهد. همانطور که در شکل - 1 - مشاهده می شود، کنترلر SDN خود به عنوان سرور DHCP عمل می کند و نگاشت های مک به آی پی اختصاص داده شده را در جدول سراسری DHCP نگهداری می کند. هنگامی که یک پیام درخواست ARP به سوییچ می رسد، سوییچ آن را به کنترلر منتقل می کند، سپس:
- جدول سراسری DHCP از ابتدا جستجو می شود تا جایی که مک موردنظر برای آی پی مورد جستجو یافته شود. سپس آن را در پیام پاسخ ARP قرار می دهد.
- در غیر این صورت، پیام درخواست ARP همهپخشی می شود تا مک پیدا شود و در پیام پاسخ ARP قرار گیرد.
- پیام پاسخ ARP به سوییچ مورد نظر فرستاده می شود تا به میزبان درخواست کننده اطلاع دهد.
-3 نتایج
برای پیاده سازی راهکار مورد نظر از شبیه ساز - Emulator - مینینت [8] استفاده شده است. شبیه ساز مینینت یک شبکه کامل از میزبانها، لینکها، و سوییچها را در یک ماشین ایجاد میکند. این شبیهساز برای توسعه تعاملی، ارزیابی و ایجاد دموی سیستمها، به ویژه آنهایی که از SDN و یکی از مهم ترین پروتکل های آن به نام اوپنفلو استفاده میکنند، مناسب است. کنترلرهای شبکه مبتنی بر اوپنفلو که در مینینت توسعه داده شدهاند، با تغییرات اندک می توانند روی سختافزار پیاده شوند.
سوییچها در مینینت، سوییچهای مبتنی بر نرمافزار مانند Open vSwitch یا سوییچ مرجع اوپنفلو [9] هستند. لینکها زوجهای اترنت مجازی هستند که در کرنل لینوکس قرار دارند و سوییچهای شبیهسازی شده ما را به میزبانها - فرایندها - ی شبیهسازی شده متصل میکنند. توپولوژی شبکه مورد نظر، توپولوژی درختی شامل یک سوییچ اصلی، دو سوییچ تجمعی و پنج سوییچ لبه به جای با 11 میزبان متصل به آنها، در یک فایل پایتون به عنوان ورودی به شبیهساز داده و اجرا شد. از سوی دیگر برنامه مورد نظر را برای مدیریت نگاشت های DHCP و کنترل ARP به عنوان یک ماژول کنترلر [10] POX اجرا می کنیم تا توپولوژی اجرا شده را کنترلر کند.
ابتدا شیوه به کارگیری شده در مقاله [7] و کارهای مشابه، شبیه سازی، و با روش معمول مقایسه شد. در روش معمول، پیغام های درخواست ARP بدون وساطت هیچ کنترلی به کل شبکه همهپخشی می شوند و هیچ جدول سراسری ARP ی وجود ندارد. در روش مقاله [7] و کارهای مشابه، از یک جدول سراسری ARP استفاده می شود تا پیش از همهپخشی کردن درخواست ARP، آن جدول چک می شود تا تنها در صورتی که آی پی مورد نظر در جدول نبود، پیغام درخواست همهپخشی شود.
در هر دو حالت، ابتدا از میزبان 1، میزبان 11 را پینگ میکنیم. مشاهده میکنیم که پاسخ اولین پینگ چندبرابر دیرتر از پاسخ پینگهای دیگر می رسد و این به دلیل آن است که میزبان 1، آدرس مک میزبان 11 را نمی داند و درخواست ARP می فرستند و تاپاسخ آن را بگیرد، نمیتواند پیام خود را بفرستد. پاسخ بقیه پینگها زودتر می رسند، چرا که پس از دریافت پاسخ ARP در اولین پینگ، این پاسخ در جدول ARP میزبان 1 ذخیره میشود. برای امتحان مجدد، این بار میزبان 11 را از میزبان 2 پینگ می کنیم. همانطور که در شکل - - 2 مشاهده می شود، شرایط در دو حالت زیر متفاوت خواهد بود:
- الف - بدون جدول سراسری :ARP خط قرمز که نشان دهنده پیغام ARP در شبکه است، هنگام پینگ دوم نیز غیر صفر است. به این معنا که مجددا نیاز به پیغام های ARP برای یافتن آی پی میزبان 11 وجود دارد.
- ب - با جدول سراسری :ARP چون درخواست ARP اولین پینگ به کنترلر رفته و کنترلر پاسخ پینگ را ذخیره می کند، پس از پینگ از میزبان 2 ، دیگر نیازی به همهپخشی کردن درخواست ARP نمی باشد. بنابراین اضافه کردن جدول سراسری ARP در کنترلر SDN باعث کاهش ترافیک ARP در شبکه شده است.
