ترجمه مقاله امکان پذیری نوآوری در شبکه های پردیس

OpenFlow: امکان پذیری نوآوری در شبکه های پردیس

OpenFlow Enabling Innovation in Campus Networks

 

 

چکیده: این مقاله به معرفی OpenFlow می پردازد که روشی برای محققان است تا پروتکل های تجربی را در شبکه ای که هرروزه استفاده میکنند اجرا نمایند. OpenFlow مبتنی بر سوییچ اترنت با جدول جریان داخلی و واسط استاندارد برای اضافه و حذف ورودی های جریان است. هدف ما تشویق ارائه کنندگان شبکه بندی به اضافه کردن به سوییچ هایشان به منظور توسعه در شبکه پردیس دانشگاهی و سیم کشی دیوارهاست. ما براین باوریم که OpenFlow یک توافق علمی است، از سوی دیگر به محققان نیز اجازه کسب تجربه بر سوییچ های ناهمگن را به روشی مشابه در نرخ خطی و با تراکم بالای پورت می دهد. درحالیکه از سوی دیگر ارائه کنندگان نیاز به افشای عملکرد داخلی سوییچ هایشان ندارند. OpenFlow علاوه بر مجاز کردن محققان به ارزیابی ایده هایشان در محیطی با تنظیمات ترافیک واقعی، به عنوان یک جز مهم در پردیس در زمینه آزمون بزرگ مقیاس پیشنهادی مثل GENI حساب می شوند. دو ساختمان در دانشگاه استانفورد ، از شبکه های OpenFlow با استفاده از سوییچ های اترنت تجاری و روترها استفاده بهره برداری کردند. ما برای تشویق سایر کارمندان در سایر دانشکده ها تلاش میکنیم و نیز شما را به بررسی کاربرد OpenFlow در شبکه دانشگاهتان فرامیخوانیم.

 

سفارش ترجمه تخصصی مهندسی کامپیوتر

 

 

اصطلاحات عمومی

آزمایش، طراحی

 

کلمات کلیدی

سوییچ اترنت، مجازی سازی، مبتنی بر جریان

 

 

نیاز به شبکه های قابل برنامه نویسی

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

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

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

این مقاله روی برنامه کوتاه مدت و تقریبا خانگی تمرکز دارد: ما به عنوان محقق، چگونه می توانیم آزمایشات خود را در شبکه پردیس انجام دهیم. اگر به چگونگی آن برسیم، به زودی شروع میکنیم و تکنیک های سایر پردیس ها را برای رساندن سود آن به کل جامعه توسعه می دهیم.

برای بررسی این مسئله، به چندین سوال باید پاسخ داده شود: در روزهای اولیه، چگونه مسئولین شبکه دانشگاه ها ، تجهیزاتی را که راحتی آنها را فراهم میکند (سوییچ، روتر، نقاط دسترسی و غیره) را وارد شبکه میکنند؟ محققان چگونه قسمتی از شبکه خود را به روشی کنترل میکنند که اشخاص دیگری که از این شبکه استفاده میکنند را اذیت نکنند؟ و دقیقا چه عملیات هایی در سوییچ های شبکه لازم است تا آزمایشات انجام شوند؟ هدف ما در اینجا پیشنهاد ویژگی سوییچ چدیدی است که بتوان توسعه قابلیت برنامه نویسی در سیم کشی پردیس دانشگاهی را به آن افزود

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

پلتفرم های نرم افزاری کمی هم اکنون وجود دارد اما دارای کارآیی یا تراکم پورت مورد نیاز نیستند. ساده ترین جز، یک PC با چندین واسط شبکه و سیستم عامل است. همه سیستم عاملهای رایج از مسیریابی بسته ها بین واسط ها و پیاده سازی متن باز پروتکل های مسیریابی موجود پشتیبانی میکنند (مثلا بعنوان قسمتی از توزیع لینوکس یا از XORP) و در اکثر موارد ، تغییر سیستم عامل برای پردازش بسته ها در هر وضعیتی (مثلا با استفاده از کلیک) امکانپذیر است. مطمئنا مشکل این است که یک PC نه میتواند از تعداد پورتهای مورد نیاز در سیم بندی شبکه دانشکده پشتیبانی کند (بیش از 100 پورت در هر جعبه نیاز است) و نه کارآیی آن در پردازش بسته (پردازش سوییچ های سیمی با 100 گیگابیت در ثانیه است، درحالیکه یک PC معمولی به بیش از 1 گیگابیت در ثانیه نمی رسد و شکاف این دو زیاد است.) کافی است.

پلتفرمهای موجود با سخت افزار خاص پردازش نرخ خطی ، مناسب جعبه سیم بندی دانشکده نیست. مثلا یک روتر قابل برنامه نویسی مجازی مبتنی بر ATCA که پلتفرم Supercharged PlanetLab درحال توسعه در دانشگاه واشنگتن است و می تواند از پردازنده های شبکه برای پردازش بسته ها از واسط های زیادی با نرخ خطی استفاده کند. این روش در بلند مدت امید بخش است اما از وارد کردن آنها در مراکز سوییچینگ زمان بر است و توسعه جهانی آنها در تجهیزات سیمی دانشکده ها هزینه بر است. مورد دیگر، NetFPGA است که هدف ان استفاده در آموزش و آزمایش های تحقیقاتی است. NetFPGA یک کارت PCI ارزان با FPGA قابل برنامه نویسی برای کاربر در پردازش بسته هاست و 4 پورت اترنت گیگابیت دارد. NetFPGA فقط چهار واسط شبکه دارد که در برای سیم کشی کافی نیست.

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

قابلیت پیاده سازی کم هزینه با کارآیی بالا

قابلیت پشتیبانی از حجم عظیمی از تحقیقات

تضمین ترافیک آزمایشی ایزوله از ترافیک تولید شده

سازگاری با نیازهای ارائه کنندگان در پلتفرمهای بسته

 

سفارش ترجمه تخصصی مهندسی کامپیوتر

شکل 1: سوییچ OpenFlow ایده آل. جدول جریان ، با کنترلر دور به وسیله کانال منبع کنترل شده است

 

این مقاله سوییچ OpenFlow را که اولین تلاش برای رسیدن به این چها هدف است بررسی می کند.

 

2. سوییچ OpenFlow

ایده اصلی ساده است. ما از این حقیقت استفاده میکنیم که اکثر سوییچ ها و روترهای مدرن اترنت جدولهای جریانی دارند (معمولا از TCAM ساخته شده) که با نرخ خطی برای پیاده سازی دیواره آتش، NAT، کیفیت خدمات و برای جمع آوری داده های علمی اجرا می شوند. با اینکه هر جدول جریان ارائه کننده، متفاوت است، یک مجموعه از توابع را تشخیص داده ایم که در سوییچ ها و روترهای زیادی اجرا می شوند. OpenFlow از یان مجموعه از توابع استفاده میکند.

OpenFlow یک پروتکل باز برای برنامه هایی با جدول جریان در سوییچ ها وروترهای مختلف ارائه میکند. مسئول شبکه می تواند ترافیک را به جریان های تحقیقاتی و تولیدی تقسیم کند. محققان می توانند جریان های خودشان را با انتخاب مسیر جریان بسته ها و پردازش انجام شده، کنترل کند. به این ترتیب می تواند پروتکل های مسیریابی جدید، مدلهای امنیتی، طرح آدرس دهی و حتی روشهای جایگزین IP را بسنجند. در این شبکه ها تولید ترافیک ایزوله است و به روش مشابه امروزی پردازش می شود.

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

یک سوییچ OpenFlow از حداقل سه قسمت تشکیل شده است 1) جدول جریان که به هر ورودی جریان یک عمل اختصاص داده شده تا به سوییچ بگوید که آنرا چطور پردازش کند 2)  کانال امنی که سوییچ را به فرآیند کنترل دور (که کنترلر نامیده می شود) متصل کند که به دستورات و بسته ها اجازه ارسال بین کنترلر و سوییچ را می دهد 3) پروتکل OpenFlow که یک روش باز و استاندارد برای کنترلرهاست تا با سوییچ ارتباط برقرار کنند. با مشخص کردن یک واسط استاندارد (پروتکل OpenFlow) که از طریق آن، ورودیهای جدول جریان را به بتوان به صورت خروجی تعریف کرد ، سوییچ OpenFlow نیازی ندارد که محقق ، برایش برنامه نویسی کند.

تقسیم بندی سوییچ ها به سوییچ های OpenFlow کار مفیدی است که از پردازش های عادی لایه 2 و لایه 3 پشتیبانی نمیکند و پروتکل های OpenFlow و واسطهای آن به عنوان یک ویژگی جدید به سوییچ ها و روترهای اترنت تجاری که دارای قابلیت OpenFlow اضافه شده اند.

سوییچ های اختصاصی OpenFlow: یک سوییچ اختصاصی OpenFlow ، یک عنصر پایگاه داده ایست که بسته ها را به همان شکلی که در فرآیند کنترل دور بیان شده، بین پورت ها ارسال میکند. شکل 1 مثالی از سوییچ OpenFlow را نشان می دهد.

در اینجا جریانها به صورت وسیعی تعریف شده اند و فقط، محدودیت های پیاده سازی خاصی از جدول جریان باعث محدودیت آنها می شود. مثلا یک جریان می تواند یک اتصال TCP باشد یا اینکه همه بسته ها از آدرس MAC خاص یا آدرس IP خاصی باشند یا اینکه با تگ VLAN مشابه باشند یا از یک پورت سوییچ باشند. در آزمایشاتی که بسته های غیر IPv4 را هم شامل می شوند، جریان باید همه بسته هایی را که با هدر خاص (نه استاندارد خاص) تطابق دارند در بر بگیرد.

برای هر ورودی  جریان یک عمل ساده وجود دارد ، سه مورد اصلی (که همه سوییچ های OpenFlow باید از آن پشتیبانی کنند) اینها هستند

ارسال این بسته های جریان به پورت (یا پورتهای) داده شده، که به بسته ها امکان ارسال شدن در شبکه را می دهد. در اکثر سوییچ ها این رویه به صورت نرخ خطی اتفاق می افتد

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

حذف این بسته های داده. از آنها می توان در امنیت، درحملات انکار خدمات یا کاهش ترافیک اکتشافی برتر از میزبان نهایی استفاده کرد.

 

یک مدخل در جدول جریان سه فیلد دارد 1) هدر بسته که جریان را تعریف میکند 2) عمل که چگونگی پردازش بسته را تعریف میکند 3) آمار که تعداد بست ها و بایت های هر جریان و زمانی که آخرین بسته با جریان تطابق داشته را برای کمک به حذف جریان های غیرفعال نگه می دارد.

در اولین نسل سوییچ های نوع صفر، هدر جریان یک تاپل 10 تایی بود که در جدول 1 نشان داده شده است. جریان TCP می توانست با همه فیلدها مشخص شود درحالیکه ممکن بود جریان IP ، پورتهای ارسال را در تعریف خود نداشته باشد. هر فیلد هدر می تواند یک نشانگر عمومی برای تراکم جریان ها نظیر جریانهایی که در آنها فقط VLAN ID تعریف شده داشته باشد که در همه ترافیک یک VLAN خاص اعمال می شوند.

نیازهای جزیی سوییچ OpenFlow با مشخصات سوییچ OpenFlow تعریف می شوند

 

سوییچ هایی با قابلیت OpenFlow. برخی از سوییچ ها، روتر ها و نقاط دسترسی تجاری، با ویژگی OpenFlow و با اضافه کردن جدول جریان ، کانال امن و پروتکل OpenFlow (برخی از مثالها در لیست 5 آمده است) تقویت می شوند.

 

 

شکل 1: فیلدهدر در سوییچ OpenFlow نوع صفر

 

معمولا جدول جریان از سخت افزارهای موجود دوباره مثل TCAM استفاده خواهد کرد. کانال امن و پروتکل برای اجرای سیستم عامل سوییچ، پورت دهی می شوند. شکل 2 شبکه ای از سوییچ ها و نقاط دسترسی با قابلیت OpenFlow را نشان می دهد. در این مثالهای همه جدولهای جریان، با کنترلر خاصی مدیریت می شوند، پروتکل OpenFlow به سوییچ اجازه کنترل شدن با دو یا چند کنترلر را به منظور افزایش کارآیی و استحکام می دهد.

هدف ما ایجاد امکان آزمایش در تولیدات موجود با ترافیک پشت سر هم و منظم است. بنابراین، سوییچ های OpenFlow برای دادن اعتماد به نفس به مسئولین شبکه باید ترافیک آزمایشی (راکه با جدول جریان پردازش می شوند) از ترافیک تولیدی که با پایپلاین لایه 2 و 3 سوییچ پردازش می شوند جدا کند. دو روش برای این جدا سازی وجود دارد. یکی اضافه کردن عمل چهارم است:

ارسال این بسته های جریان از طریق پایپلاین پردازش عادی سوییچ

روش دیگر، تعریف مجموعه جداگانه ای از VLAN ها برای  ترافیک تولیدی و آزمایشی است. هر دو روش امکان تولید ترافیک نرمال را که قسمتی از تجربیات عادی در سوییچ نیست فراهم میکنند. همه سوییچ های OpenFlow نیاز به پشتیبانی از یکی از این روشها دارند و برخی از آنها از هر دو پشتیبانی مکنند.

ویژگی های اضافی. اگر سوییچی از فرمت هدر و چهار عمل مبنایی که دربالا بیان شد (و در بخش مشخصات سوییچ OpenFlow با جزییات آمده) پشتیبانی کند آن را سوییچ نوع صفر می نامیم. انتظار داریم که بسیاری از سوییچ ها از کارهای بیشتری نظیر بازنویسی قسمتی از هدر بسته (مثلا NAT یا آدرس های مبهم لینک های میانی) و نگاشت بسته ها به یک کلاس اولویت پشتیبانی کنند. مشابه این برخی جدولهای جریان قادر به تطابق فیلدهای اختیاری در هدر بسته ها هستند که امکان آزمایش با پروتکل های غیرIP جدید را فراهم میکند. با پدیدار شدن مجموعه جدیدی از ویژگی ها ، سوییچ نوع 1 را تعریف میکنیم

کنترلرها. یک کنترلر جریانهای ورودی از جدول جریان را در نیمی از آزمایشات اضافه و کم میکند. مثلا ممکن است یک کنترلر ایستا یک برنامه کاربردی ساده باشد که در یک PC برای ایجاد جریانهای ایستا برای اتصال مجموعه از کامپیوترها در مدت آزمایش استفاده شده باشند. در این مورد ، جریانی که VLAN ها را در شبکه کنونی را شبیه سازی میکنند ، مکانیزم ساده ای برای جدا کردن ترافیک آزمایشی از شبکه تولیدی دارند. با این روش OpenFlow یک نسخه عمومی از VLAN است.

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

 

شکل 2: مثالی از شبکه سوییچ ها و روترهای تجاری با قابلیت OpenFlow

 

3. استفاده از OpenFlow

بعنوان مثال ساده ای از چگونگی استفاده از سوییچ OpenFlow فرض کنید که محققی به اسم Amy یک Amy-OSPF را بعنوان یک پروتکل جدید برای جایگزین کردن OSPF ایجاد کند. او میخواهد پروتکلش را در شبکه ای از سوییچ های OpenFlow و بدون تغییر نرم افزار میزبان انتهایی بسنجد. Amy-OSPF در کنترلر اجرا خواهد شد، هر زمان که جریان کاربردی خاصی شروع شود، Amy-OSPF مسیری از یک سری از سوییچ های OpenFlow ایجاد کرده و ورودی جریان را در هر سوییچ قرار می دهد. او در آزمایشاتش تصمیم به استفاده از Amy-OSPF برای ترافیک ورودی شبکه OpenFlow از PC میزی خودش می شود به این ترتیب در شبکه سایرین اختلالی ایجاد نمیکند. برای این کار جریانی که همه ترافیک ورودی از سوییچ OpenFlow را به پورت سوییچ روی PC متصل به آن هدایت میکند و یک ورودی جریان با کار کپسوله بندی و ارسال بسته ها به کنترلر ایجاد میکند. زمانی که بسته هایش به کنترلر رسسیدند، پروتکل جدیدش مسیری را انتخاب کرده و یک ورودی جریان جدید (برای جریان کاربردی) به هر سوییچ در مسیرانتخاب شده اضافه میکند. زمانی که بسته ها به سوییچ می رسند، به سرعت به وسیله جدول جریان پردازش می شوند (با نرخ خطی) .

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

 

3.1. آزمایش شبکه تولیدات

امی در حال بررسی پروتکل جدیدش در شبکه ای است که افراد دیگری هم از آن استفاده میکنند. بنابراین می خواهیم شبکه دو ویژگی دیگر نیز داشته باشد

بسته های متعلق به کاربری غیر از امی باید با استافده از پروتکل های مسیریابی تست شده و استاندارد سوییچ یا روتر از ارائه کننده آن برند منتقل شوند.

امی نباید قادر به اضافه کردن ورودی های جریان در ترافیک خود یا در ترافیکی که مسئول شبکه امکان کنترل ان را به او داده باشد.

ویژگی اول در سوییچ هایی با قابلیت OpenFlow وجود دارد. در آزمایشات امی، رویه عادی این است که همه بسته هایی که از PC امی نمی آیند باید از پایپلاین پردازشی عادی ارسال شوند. بسته های امی ، مستقیما به پورت خروجی و بدون پردازش شدن با پایپلاین عادی، ارسال می شوند.

ویژگی دوم به کنترلر بستگی دارد. کنترلر باید پلتفرمی در نظر گرفته شود که محقق را قادر به پیاده سازی آزمایشات مختلف میکند و با استفاده درست از ویژگی 2 می توان توان محققین را برای کنترل ورودی های جریان را محدود کرد. ماهیت این مکانیزمهای مجوز مانند ، به چگونگی پیاده سازی کنترلر بستگی دارد. انتظار داریم که انواعی از کنترلر ها وجود داشته باشد. برخی محققان برای استفاده درست از کنترلر، درحال کار روی کنترلری هستند که NOX نامیده می شوند ودنباله کارهای اتان است. ممکن است با توسعه نرم افزار مدیریت GENI در شبکه های OpenFlow به کنترلرهای کاملا متفاوتی دست یابیم

 

3.2. مثالهای بیشتر

در هر پلتفرم آزمایشی یک مجموعه از آزمایش ها انجام می شود که به نظر میرسد از حد و مرزها تجاوز کرده اند، و بیشتر آزمایشاتی که در OpenFlow انجام می شوند از این نوعند. در اینجا مثالهایی از چگونگی استفاده از شبکه هایی با قابلیت OpenFlow را در معماری ها و برنامه های کاربردی شبکه ارائه میکنیم.

مثال 1: مدیریت شبکه و کنترل دسترسی . ما از کار اتان به عنوان اولین مثالمان استفاده میکنیم چراکه OpenFlow از آن ایده گرفته است. در حقیقت یک سوییچ OpenFlow می تواند یک نمونه توسعه یافته از سوییچ مسیر داده اتان محسوب شود. اتان از پیاده سازی خاصی در کنترلر استفاده کرد که مناسب مدیریت و کنترل شبکه بود که کنترل و مسیریابی داده ها را مدیریت میکرد. ایده اصلی اتان ، دادن این امکان به مدیر شبکه است که سیاست های کلی شبکه را در کنترلر مرکزی تعریف کند که توانایی اعمال کنترل مستقیم را با توجه به تصمیم گیری های مسئول شبکه برای هر جریان جدید دارد. کنترلر ، دوباره جریان جدید را با توجه به قوانینی نظیر اینکه "میهمانان می توانند با استفاده از HTTP ارتباط برقرار کنند اما فقط با پروکسی وب" یا "تلفن های VoIP مجاز به ارتباط با لبتاب ها نیستند" را بررسی میکند. کنترلر با مدیریت همه ارتباطات میان نامها و ادرسها ، فرستنده را مشخص میکند که الزاما روی DNS، DHCP انجام شده و همه کاربران را در زمان ورود آنها بررسی میند و اینکه به کدام پورت سوییچ یا کدام نقطه دسترسی متصل اند را دنبال میکند. می توان تصور کرد که توسعه روش اتان که در آن سیاست ها به صورتی است که جریان خاصی به فرآیند درون کنترلر ارسال می شود ، بنابراین اجازه پردازشهای تحقیقاتی خاص را در شبکه می دهد.

 

مثال 2: VALN. OpenFlow می تواند به سادگی کاربرانی با شبکه ایزوله مخصوص خودشان ایجاد کند، درست همانند آنچه VLAN ها انجام می دهند. ساده ترین روش تشخیص آماری جریانهایی است که پورت های قابل دسترسی در ترافیکی با VLAN ID خاص را مشخص میکند. ترافیکی از یک کاربر می اید (مثلا از پورت های سوییچ خاصی یا آدرسهای MAC) با سوییچها (یک عمل) با VLAN ID مناسب برچسب زده می شوند

روش پویاتر می تواند استفاده از کنترلری برای مدیریت احرازهویت کاربران و استفاده از اطلاعات موقعیت کاربر برای برچسب زدن ترافیک در زمان اجرا باشد.

مثال 3: مشتری های VOIP بیسیم متحرک. برای این مثال آزمایش مکانیزم جدید تلفن هایی با قابلیت WiFi را در نظر بگیرید. در آزمایش VOIP، مشتریان یک اتصال جدید روی شبکه هایی که قابلیت OpenFlow دارند ایجاد میکنند. از کنترلر برای دنبال کردن مکان کاربر ، مسیریابی مجدد مشتریان با برنامه نویسی جدول داده، به شکل حرکت کاربران در شبکه استفاده می شود که اجازه واگذاری یک نقطه دسترسی را به دیگری می دهد.

مثال 4. یک شبکه غیرIP. تاکنون مثالهای ما یک شبکه IP را تصور میکردند اما OpenFlow تا وقتی که جدول جریان قادر به انطباق هدر بسته ها باشد نیاز به بسته هایی در هیچ فرمتی ندارد. این امکان آزمایش با نام گذاری جدید، آدرس دهی و طرح های مسیریابی را می دهد. روشهایی برای پشتیبانی سوییچ های دارای قابلیت OpenFlow از ترافیک غیرIP وجود دارد. مثلا جریان ها می توانند با استفاده از هدر اترنت (آدرس مبدا و مقصد MAC) ، یک مقدار جدید برای EtherType یا در سطح IP، با یک شماره IP ورژن جدید ارسال شوند. در کل، امیدواریم که سوییچ های آینده به کنترلر اجازه ایجاد یک ماسک عمومی (آفست+مقدار + ماسک) را برای مجاز کردن بسته ها به پردازش به شکل مد نظر محقق را بدهد.

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

دو روش اصلی برای پردازش بسته ها در یک شبکه با قابلیت OpenFlow وجود دارد. اول و ساده ترین، مجبور کردن همه بسته های جریان برای گذر از یک کنترلر است. برای این کار، کنترلر ورودی جریان جدیدی را به سوییچ جریان اضافه نمیکند، که این در کل اجازه ارسال هر بسته به کنترلر سوییچ را می دهد.

 

شکل 3: مثالی از بسته های پردازشی در وسیله پردازش بسته با نرخ خطی خارجی مانند یک مسیریاب قابل برنامه نویسی NetFPGA

 

روش دوم پردازش بسته ها، ارسال آنها از یک سوییچ قابل برنامه نویسی است که پردازش بسته را انجام می دهد مثلا یک مسیریاب قابل برنامه نویسی NetFPGA. مزیت آن این است که بسته ها می توانند با نرخ خطی به روش تعریف شده کاربر پردازش شوند. شکل 3 نشان دهنده مثالی از چگونگی انجام این کار است که سوییچی با قابلیت OpenFlow مانند یک پنل پچ برای رساندن بسته ها برای رسیدن به NetFPGA عمل کنند. در برخی موارد، ممکن است برد NetFPGA (یک برد PCI که به PC لینوکس وصل میشود) در سیم کشی در سوییچی با قابلیت OpenFlow یا در احتمالا در یک آزمایشگاه قرار داشته باشد.

 

4. کنسرسیوم OpenFlow

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

عضویت در آن برای هر مدرسه، دانشکده، دانشگاه یا آژانس دولتی آزاد است. کنسرسیوم OpenFlow از حضور اشخاصی که تحت استخدام شرکت ها نیستند و سوییچ ها و روترهایا نقاط دسترسی اترنت نمی فرشند استقبال میکند (زیرا می خواهیم این کنسرسیوم را عاری از تاثیر فروشندگان نگه داریم).

وبسایت کنسرسیوم مشخصات سوییچ OpenFlow را ارائه میکند، لیستی از اعضای کنسرسیوم ، و پیاده سازی های اصلی سوییچ های OpenFlow نیز در آنجا وجود دارد.

 

مدل مجوز دهی: مشخصات سوییچ OpenFlow در همه کاربردهای تجاری و غیرتجاری آزاد است. (کلمه صحیح آن وبسایت است) سوییچ های تجاری و مسیریاب ها ادعا دارند که باید قابلیت OpenFlow در آنها وجود داشته باشند و باید با نیازهای سوییچ OpenFlow نوع صفر که در مشخصات سوییچ OpenFlow وجود دارد، تطابق داشته باشد.

 

پیاده سازی سوییچ های OpenFlow

ما باورداریم که فرصت تجاری زیادی برای ارائه کنندگان تجهیزات شبکه ای برای فروش سوییچهایی با قابلیت OpenFlow در محیط تحقیقاتی وجود دارد. همه ساختمانها در دانشکده ها و دانشگاه هایی که دارای سیم کشی با سوییچ و روتر های اترنت و نقاط دسترسی سیمی هستند در پردیس منتشر می شوند.

ما با تولید کننده های سوییچ و روترهایی که امکان پیاده سازی جدول جریان را در سخت افزار کنونی شان دارند، یعنی به هیچ سخت افزار اضافی نیاز ندارد، به شکل فعالی کار میکنیم. سوییچ ها ، نرم افزار کانال امن را روی پردازنده کنونی شان اجرا میکنند.

ما ارائه کنندگان خدمات شبکه را پیدا کردیم که تمایل به اضافه کردن ویژگی های  OpenFlow دارند. اکثر ارائه کنندگان تمایل به پشتیبانی از جامعه تحقیقاتی، بدون تغییر کارکردن تولیداتشان دارند.

ما در حال توسعه شبکه های OpenFlow هستیم در دپارتمان علوم کامپیوتر و مهندسی الکترونیک دانشگاه استانفورد هستیم. شبکه های این دو ساختمان با سوییچ هایی که OpenFlow را اجرا میکنند جایگزین می شوند. در نهایت همه ترافیکی روی شبکه OpenFlow با تولید ترافیک اجرا خواهد شد ترافیک آزمایشی در VLAN های مختلف و تحت کنترل مسئولین شبکه است. محققان ترافیک خود را کنترل کرده و قادر به اضافه یا حذف کردن ورودی های جریان اند

همچنین انتظار داریم که سوییچ های OpenFlow مختلفی توسط جامعه تحقیقاتی ایجاد شود. وبسایت OpenFlow ، طراحی مرجع نوع صفر را در پلتفرمهای مختلف نظیر لینوکس (نرم افزار) ، OpenWRT (نرم افزاری برای نقاط دسترسی) و NetFPGA (سخت افزار، 4 پورت یک گیگااترنت) ارائه کرده است. اگر طراحی های بیشتری توسط این جامعه ارائه شود آنها را منتشر میکنیم.

همه پیاده سازی های مرجع سوییچ های OpenFlow در وب سایت، متن باز بوده و برای کاربردهای تجاری و غیرتجاری، رایگان اند.

 

نتیجه گیری

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

سفارش ترجمه تخصصی مهندسی کامپیوتر

سفارش ترجمه تخصصی مهندسی کامپیوتر

 

منابع

[1] Global Environment for Network Innovations. Web site http://geni.net.

[2] Mark Handley Orion Hodson Eddie Kohler. “XORP: An Open Platform for Network Research,” ACM SIGCOMM Hot Topics in Networking, 2002.

[3] Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti, and M. Frans Kaashoek. “The Click modular router,” ACM Transactions on Computer Systems18(3), August 2000, pages 263-297.

 

 [4] J. Turner, P. Crowley, J. Dehart, A. Freestone, B. Heller, F. Kuhms, S. Kumar, J. Lockwood, J. Lu, M.Wilson, C. Wiseman, D. Zar. “Supercharging PlanetLab - High Performance, Multi-Application, Overlay Network Platform,” ACM SIGCOMM ’07, August 2007, Kyoto, Japan.

[5] NetFPGA: Programmable Networking Hardware. Web site http://netfpga.org.

[6] The OpenFlow Switch Specification. Available at http://OpenFlowSwitch.org.

[7] Martin Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, Nick McKeown, Scott Shenker. “Ethane: Taking Control of the Enterprise,” ACM SIGCOMM’07, August 2007, Kyoto, Japan.

 [8] Natasha Gude, Teemu Koponen, Justin Pettit, Ben Pfaff, Martin Casadao, Nick McKeown, Scott Shenker, “NOX: Towards an Operating System for Networks,