آموزش شبکه: فناوری Software Defined Network) SDN) چیست؟

SDN از سال ۱۹۹۶ و برای ایجاد مدیریت کاربر روی ارسال و دریافت، در گره های شبکه بوجود آمد. برای تحقق بخشیدن به ایده SDN، دو عامل نیاز است. ابتدا باید یک معماری منطقی مشترک بین تمامی سوییچ ها، روترها و دیگر تجهیزات باشد، ثانیا یک پروتکل امن بین SDN و تجهیزات شبکه مورد نیاز است. برای این مفهوم پروتکل های مختلفی از جمله Ipsilon 1996 و IETF 2000 ، Ethan 2007 و OpenFlow 2008 مطرح شدند. هر دوی این نیازها توسط OpenFlow بر طرف شده است.

بنا بر نظر بنیاد شبکه‌های آزاد یا (Open Networking Foundation (ONF، شبکه مبتنی بر نرم‌افزار یا (Software Defined Networking (SDN یک معماری شبکه محسوب می گردد، که سطوح کنترل و داده (Control Plane, Data Plane) را از یکدیگر جدا کرده و صفحه‌ی کنترل (اطلاعات شبکه و سیاست‌گذاری) را به یک برنامه به نام کنترلر منتقل می‌نماید. سیسکو نگاه گسترده‌تری به مبحث SDN داشته و در آن علاوه بر مدل کنترلر/عامل یا به عبارتی Controller/Agent که ONF برای OpenFlow تعریف نموده، به معرفی مدل‌های دیگر برنامه‌نویسی شبکه ی نیز می پردازد.

ساختار شبکه‌های فعلی چگونه است؟

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

هر کامپوننت (مثلا سوئیچ در این شکل زیر) از دو بخش اصلی تشکیل می‌شود. بخشی برای فورواردینگ یک بسته از یک پورت به پورت دیگر و بخشی برای تعیین تنظیماتی که چگونگی هدایت بسته‌ها را مشخص می‌کند.

این یک توصیح ساده از شبکه فعلی (non-SDN) می‌باشد. بیایید کمی وارد جزییات شویم. برخی از ویژگی‌های شبکه‌های فعلی که قرار است در شبکه جدید تحت عنوان SDN بهبود یابد را بررسی می‌کنیم.

نبود دید انتزاعی در Control Plane: بدین معنا که کانفیگ/الگوریتم‌ها در control plane به صورت محلی و مختص یک سوئیچ/روتر است و ساختار عمومی و کلی نمی‌توان به همه سوئیچ‌ها/روترها اعمال کرد.

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

و اما در شبکه‌های فعلی (non-SDN) چگونه کانفیگ انجام می‌شود؟

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

در روش فعلی (non-SDN) مشکل چیست؟

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

• اگر بخواهیم چندین هزار و یا حتی بیشتر کامپوننت شبکه را کانفیگ کنیم چطور؟
• اگر نیاز به تغییرات کانفیگ در بازه‌های زمانی کوتاهتری باشیم؟ مثلا چندین بار در طور روز؟
• اگر بخواهیم از تجهیزات وندورهای مختلف استفاده کنیم چطور؟ (هر وندور روش کانفیگ مختص به خودش را دارد، پارامترهای متفاوتی باید تنظیم شود، ابزارهای مختلفی برای کانفیگ تجهیزات ممکن است وجود داشته باشد. پس ما نیاز به گروه‌های مختلفی از افراد متخصص برای تجهیزات هر وندور خواهیم داشت)

تغییرات در شبکه‌های SDN چگونه اعمال می‌شود؟

طبیعی است که یک سوال در ذهن شما ایجاد شده باشد که چگونه مشکلات بالا را حل می‌کنیم؟ فناوری جدیدی تحت عنوان SDN برای رفع مشکلات بالا وجود دارد. ایده اصلی SDN در شکل زیر آورده شده است. یک مرکز کنترل متمرکز که به همه کامپوننت‌های شبکه دید کلی داردو سپس می‌تواند به صورت ریموت (غیردستی) تک تک تجهیزات را کانفیگ کند.

 

مشخصات	معماری SDN	معماری کلاسیک
برنامه ریزی	✓
کنترل متمرکز	✓
پیکربندی خطا		✓
کنترل شبکه پیچیده		✓
انعطاف پذیری شبکه	✓
عملکرد بهبود یافته	✓
پیاده سازی آسان	✓
پیکربندی کارآمد	✓

 

فناوری Software Defined Network) SDN) چیست ؟

بطور سنتی سوییچ های Ethernet دارای واحد پردازشی بعنوان تصمیم گیرنده (Control Plane) و بخش دیگری بعنوان فرستنده داده (Data plane) هستند. هر تجهیز شبکه دارای سامانه پردازشی و ارسال بسته داده مستقل از یکدیگر است در تصویر پایین معماری پیشین تجهیزات شبکه نشان داده شده است. وقتی که شما دستگاه شبکه ای را پیکر بندی می کنید در واقع تعامل شما با Control plane امکان پذیر می شود. انجام پردازش های مربوط به چگونگی ارسال داده ها شامل Switching ،Routing ،QOS ،Access Control List و غیره در Control plane با استفاده پردازنده اصلی دستگاه و نرم افزار (IOS) بهینه شده صورت می پذیرد یکی از خصوصیات اصلی تجهیزات سخت افزاری شبکه این است که در کمترین زمان، پردازش های مورد نیاز را انجام می دهند در واقع یکی از چالش های رقابت بر انگیز میان سازندگان تجهیزات شبکه، ارائه تجهیزات سخت افزاری و روش های بهینه برای انجام سریع و موثر چنین پردازش های است. با نگاه به روند ارائه تجهیزات شبکه در ده سال اخیر می توان کاهش زمان لازم برای ارسال بسته داده (Switching Latency) و افزایش حجم ترافیک گذر دهی (Forwarding Throughput) را دید. برای مثال سوییچ های سری Cisco Catalyst 2960 از توان گذردهی 32Gbps به بیش از 200Gbps ارتقاء پیدا کرده اند و این روند همچنان ادامه دارد.

Control Plane

در Control Plane یک مجموعه از سرور های مدیریتی وجود دارد که با اجزای Data Plane ارتباط برقرار می کند و مشخص می سازد که در آن ثانیه داده چگونه در Data Plane حرکت کند. شما می توانید بگویید در این دقیقه تمام ترافیک برای SIP برود و ۲ دقیقه بعد تمام ترافیک برای FTP برود. شما می توانید در Control Plane کل شبکه را مدیریت کنید. شما در واقع اجزا مختلف شبکه را از هم جدا می کنید، تا بتوانید با آن ها جداگانه کار کنید.

Data Plane

Data Plane قسمتی است که تمام سویچ ها، روتر ها، فایروال ها … در آن قرار می گیرد، در data plane سرویس هایی مانند Firewall, Router, …. وجود دارد که قبلا آنها روی لایه فیزیکی بودند.

اینجا سوال پیش می آید که آیا می توان آن را جدا کرد؟ بله!! شما میتوانید آن را به یک سرور مجزا ببرید تا با آن عملکرد بهتری داشته باشید. شما یک قسمت مدیریتی دارید که control plane را مدیریت می کند. سیستم مدیریتی openflow مطمئن می شود کارش را درست انجام داده و مشکلی پیش نمی آید.

شما در صورتی که در زمینه SDN فعالیت داشته باشید با مفهومی بنام openflow آشنا می شوید. openflow یک پروتکل کنترلی است که به شما اجازه می دهد بقیه اجزا را در control plane کنترل کنید.

داستان اینجا است که شما باید با دستگاه های شبکه مانند پروتکل های روتر، سوئیچ و … در ارتباط باشید. اگر قرار است شما control plane را کنترل کنید و با data plane در ارتباط باشید شما یک پروتکل جدا نیز نیاز دارید که پروتکل کنترل است.

کنترلر Floodlight

برای توسعه بخش کنترلر شما گزینه‌های زیادی در پیش روی خود دارید. کنترلر Floodlight با Mailing list بسیار فعال خود و واسط گرافیکی کاربرپسند و همچنین مستندات کاملی که دارد، می‌تواند انتخاب مناسبی باشد. در نسخه جدید این کنترلر، امکان تنظیم نقش کنترلر و استفاده از چندین کنترلر توزیعی نیز فراهم شده که شما می‌توانید یک توپولوژی با چندین کنترلر که امکان Sync بین آن‌ها وجود دارد، ایجاد کنید.

شرکت‌های معتبر بسیاری از جمله Arista, Brocade, Citrix, Dell, Extreme Networks, Fujitsu, Google, HP, IBM, Intel, Juniper Networks and Microsoft از کنترلر Floodlight استفاده نموده‌اند.

از جمله موسسات معتبر دنیا که از این کنترلر در شبکه پروداکشن خود استفاده نموده‌اند، می‌توان به SRI International، Caltech / CERN، Radware، Firemon، WIND6 و Overture اشاره کرد که جالب است بدانید که موسسه CERN با استفاده از کنترلر Floodlight توانسته است صدها پتابایت (!!) دیتا را توزیع و پردازش کند. هسته اصلی کنترلر Floodlight و کنترلر قدرتمند شرکت Big Switch Networks مشابه می‌باشد و در واقع کنترلر Floodlight نسخه متن‌باز کنترلر Big Network Controller می‌باشد.

در شکل زیر شمای گرافیکی کنترلر Floodlight که با استفاده از REST API کار می‌کند را می‌بینید.

کنترلر OpenDaylight یا ODL

کنترلر ODL نیز در صنعت بسیار مورد توجه قرار گرفته و پروژه OpenDaylight توسط شرکت‌های معتبر حوزه IT و شبکه پشتیبانی می‌شود. جالب است که بدانید پایه کنترلرهای Cisco، HP، NEC و بسیاری از کنترلرهای تجاری دنیا همین کنترلر ODL می‌باشد.

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

در شکل زیر شمای واسط گرافیکی OpenDaylight را تحت عنوان DLUX مشاهده می‌کنید که در این قسمت توپولوژی شبکه نمایش داده شده است.

کنترلرهای POX و RYU

کنترلرهای POX و RYU نیز که به زبان پایتون نوشته شده اند گزینه‌های دیگر می‌باشند. متاسفانه کنترلر POX تا این زمان وعده ای در مورد فراهم نمودن نسخه‌های OpenFlow بالاتر از ورژن 1.0 نداده است و این کمی جای نگرانی برای برنامه نویسان شبکه دارد اما نکته قابل تامل در زمینه استفاده از این کنترلر سادگی آن می‌باشد و برای شروع کار استفاده از این کنترلر توصیه می‌شود. کنترلر RYU مشابه با Floodlight و OpenDaylight از ورژن‌های بالاتر OpenFlow و همچنین OpenStack پشتیبانی می‌کند ولی تاکنون گزارشی مبنی بر استفاده از این کنترلر در شبکه های پروداکشن ندیده‌ام و از نظر کارایی عملکرد بهینه‌ای ندارد.

کنترلر توزیعی چیست؟

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

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

تجهیزات روانه‌سازی – سوئیچ‌های SDN

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

یک دستگاه روانه‌سازی مبتنی بر پروتکل OpenFlow دارای خط لوله‌ای از جداول جریان (Flow Tables) است که هر مدخل (Entry) از این جداول شامل سه بخش می‌باشد:

1. یک قاعده انطباق (Matching Rule)
2. یک اقدام (Action) که برای بسته‌های انطباق‌یافته صورت می‌پذیرد
3. شمارنده‌هایی که آمار بسته‌های انطباق‌یافته را نگهداری می‌کنند

این مدل سطح بالا از OpenFlow در حال حاضر در ساخت و پیاده‌سازی بسیاری از دستگاه‌های صفحه داده‌ی SDN استفاده شده است.

در یک دستگاه OpenFlow، طرز رفتار با یک بسته توسط مجموعه‌ای از جدول ها جریان (Flow Tables) متوالی مشخص می شود. زمانی که یک بسته وارد می‌شود، یک فرآیند جستجو از اولین جدول شروع می‌شود و تا زمانی که یک انطباق اتفاق نیوفتد (Match) و یا به‌طور قطع قاعده‌ای برای آن بسته پیدا نشود (Miss) این روند ادامه می‌یابد. همانطورکه در تصویر پایین مشخص شده است، یک قاعده‌ی جریان می‌تواند به شکل‌های مختلفی تعریف شود. اگر هیچ قاعده‌ی پیش‌فرضی بر روی سوئیچ نصب نشده باشد آنگاه بسته دور ریخته خواهد شد. هر چند به‌طور متداول، یک قاعده پیش‌فرض بر روی سوئیچ نصب خواهد شد که به سوئیچ دستور می‌دهد تمامی بسته‌های دریافتی را به سمت کنترل‌کننده بفرستد ( و یا به خط لوله معمولی غیر OpenFlow موجود در سوئیچ بفرستد؛ توضیح اینکه در سوئیچ‌های هیبرید با استفاده از خط لوله Normal، این قابلیت وجود دارد که به‌طور پیش‌فرض می‌توان بسته‌ها را بدون استفاده از پروتکل OpenFlow راهنمایی کرد) اولویت‌های این قواعد بر اساس شماره جدول‌ها و ترتیب سطرهای جدول‌های جریان می‌باشد؛ یعنی ابتدا قواعد موجود در جدول ۰ و سپس قواعد موجود در جدول ۱ و الی‌آخر. پس از روی دادن یک انطباق باید اقداماتی برای آن جریان اتفاق بیوفتد.

اقدام‌ها (Actions) مواردیست که در پایین ذکر شده:

• هدایت بسته به سمت پورت(های) خروجی تعیین‌شده
• کپسوله (Encapsulate) و سپس راهنمایی کردن بسته به سمت کنترل‌کننده
• دور ریختن بسته (Drop)
• ارسال آن به سمت خط لوله عادی (Normal pipeline)
• ارسال آن به جدول جریان بعدی و یا به جدول‌های خاص، مانند جداول گروه (Group Tables) و یا جداول اندازه‌گیری (Metering Tables)
• کنترل‌کننده SDN: کنترل‌کننده همانند یک سیستم‌عامل شبکه است که کنترل سخت‌افزار را برعهده‌دارد و هم‌چنین مدیریت خودکار شبکه را تسهیل می‌کند. این سیستم‌عامل، یک واسط قابل برنامه‌ریزی متمرکز و یکپارچه را برای تمام شبکه اماده می‌کند. همان‌طور که سیستم‌عامل موجود بر روی یک رایانه، امکان خواندن و نوشتن را برای برنامه‌های کاربردی به وجود می‌آورد، سیستم‌عامل شبکه نیز قابلیت مشاهده و کنترل شبکه را فراهم می‌سازد؛ پس کنترل‌کننده، به‌تنهایی عمل مدیریت شبکه را انجام نمی‌دهد بلکه صرفاً به‌عنوان یک واسط قابل برنامه‌ریزی هست که امکان مدیریت شبکه را برای نرم‌افزارهای کاربر به وجود می آورد.
• کنترل‌کننده Floodlight

Floodlight یک کنترل‌کننده OpenFlow با ویژگی‌های زیر است:

• Enterprise-class
• Apache-licensed
• Java-based

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

• Device Manager: دستگاه هایی که در شبکه دیده‌شده‌اند را ردیابی می‌کند. این ردیابی شامل مواردی از قبیل اطلاعات آدرس آن‌ها، آخرین تاریخ رؤیت آن‌ها، و آخرین سوئیچ و پورتی که در آن رؤیت شده‌اند می‌باشد؛
• Topology: لینک‌های مابین سوئیچ‌های OpenFlow را کشف می‌کند؛
• Routing: کوتاه‌ترین مسیریابی لایه ۲ را میان دستگاه‌های شبکه فراهم می کند؛
• Web: یک واسط کاربری تحت وب فراهم می کند.

یکی از مزایای Beacon و Floodlight توانایی آغاز و یا خاتمه برنامه‌های کاربردی در حین اجرای فرآیند کنترل‌کننده است؛ یعنی بدون نیاز به غیر فعال‌سازی کنترل‌کننده می‌توان آن‌ها را اضافه و یا حذف کرد. برنامه‌های کاربردی کاملاً چند نخی و دارای الگوریتم‌های (blocking (Shared Queue و (non-blocking (Run-to-completion به‌منظور خواندن پیام‌های OpenFlow هستند. با توجه به مطالعات صورت گرفته، توسط آقای اریکسون ، Beacon در مقایسه با NOX ، Pox و Maestro دارای بهترین کارایی می‌باشد.

از محدودیت‌های دامن‌گیر معماری سنتی می‌توان به موارد زیر اشاره کرد:

1. عدم چابکی و خودکار سازی روال‌های پیاده‌سازی سرویس‌های موردنیاز در کل تجهیزات شبکه: به‌طور مثال پیکربندی ACL و یا QoS باید بر روی تک‌تک تجهیزات شبکه تکرار و انجام شود و این فرآیند زمان‌بر و مستعد اشتباه بوده و رفع مشکلات آن بسیار سخت است. در واقع نمی‌توان پیکربندی موردنیاز را یک‌بار انجام داد و آن را به‌کل تجهیزات شبکه بسط داد.
2. گسترش‌پذیری محدود پردازشی و ناهمگون مبتنی بر نیازهای سرویسی شبکه: performance دستگاه‌های شبکه در صورت اجرای سرویس‌هایی همچون PBR ،QoS ،Calculation Routing ،Traffic Engineering و غیره به‌طور قابل‌توجهی کم می‌شود دلیل این موضوع آن است که برخی از سرویس‌ها بر اساس معماری سنتی سه لایه شبکه تنها در لایه‌ای خاص قابل‌اجرا بوده و درنتیجه بار پردازشی مربوطه در آن لایه از شبکه به‌طور تصاعدی زیاد می شود و به همین دلیل گلوگاه ترافیکی بوجود می آید تلاش برای افزایش توان پردازشی به‌منظور رفع این محدودیت نتیجه‌بخش نبوده است.
3. عدم امکان مدیریت متمرکز تجهیزات درگیر در مسیر جابجا شدن اطلاعات در شبکه، به دلیل نبود دید کامل و دقیق از همبندی منطقی شبکه، امکان ایجاد راه‌کار جامع و یکپارچه برای پیکربندی تجهیزات شبکه درگیر در فرآیند جابجا شدن بسته داده و پایش لحظه‌ای بسته داده در مسیر حرکت خود امکان پذیر نبوده است.
4. عدم امکان ایجاد شبکه‌های هم‌پوشان با امکان جداسازی کامل با گسترش ارائه خدمات میزبانی سرویس‌های فناوری اطلاعات در مراکز داده، نیاز به جداسازی منطقی مشتریان این‌گونه خدمات مورد اهمیت قرار گرفته است. در معماری سنتی این کار با استفاده از شبکه‌های مجازی (Vlan) و اعمال کنترل‌های امنیتی ممکن می شود. به دلیل محدودیت‌های ذاتی در چنین پروتکل‌های، توسعه‌پذیری کمی و کیفی با محدودیت‌های بسیاری روبرو می‌شود. عدم امکان ایجاد شبکه‌های همپوشان و یا Multi-Tenancy با امکان ارائه سرویس از دیگر ضعف‌های معماری سنتی شبکه است.
5. عدم امکان مدیریت و کنترل ترافیک تولیدی از مبدأ تا مقصد در زیرساخت مجازی‌سازی به‌طور کامل به دلیل نبود ارتباط منطقی میان زیرساخت شبکه بستر مجازی با بستر شبکه فیزیکی، امکان اعمال سیاست‌های کنترلی به بسته داده در بستر مجازی ممکن نیست و این امکان تنها محدود به بستر شبکه فیزیکی می‌گردد.

بررسی دیدگاه سیسکو به مقوله ی SDN

با توجه به اینکه اکثر سازمان‌های بخش عمومی در حال آماده‌سازی برای Big Data، موج ترافیک ویدئویی، محیط‌های BYOD و محاسبات Cloud می‌باشند، برنامه‌نویسیِ رفتار شبکه قابلیتی ارزشمند برای آنها محسوب می‌گردد.

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

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

جهت افزایش احتمال برنامه‌نویسی شبکه و رسیدگی به طیف وسیعی از موارد کاربرد آن، نگاه وسیع‌تر به برنامه‌نویسی شبکه، امری ضروری محسوب می گردد. شرکت سیسکو معماری “محیط شبکه‌ی باز یا (Open Network Environment (ONE” خود را به‌عنوان یک رویکرد چندوجهی به برنامه‌نویسی شبکه ارائه نموده که بر سه ستون زیر استوار است:

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

نقاط قوت و نقاط ضعف OpenFlow

شرکت سیسکو به OpenFlow خوشبین است. سیسکو یک کنترلر کامل و آماده‌ی OpenFlow به نام “کنترلر شبکه‌ی بسط‌پذیر سیسکو” یا Cisco Extensible Network Controller ابداع نموده است. برخی از سوئیچ‌های سیسکو دارای Agent‌های OpenFlow می باشند و نقشه‌ی راه مستلزم وجود Agentهای تحت پشتیبانی، روی اکثر محصولات روتینگ و سوئیچینگ سیسکو می باشد.

OpenFlow به‌گونه‌ای طراحی شده است که می تواند از روند مدیریت مبتنی بر Policy، در داخل شبکه پشتیبانی نماید. به ویژه OpenFlow مناسب موارد کاربردی است که به پیش بردن سیاست‌های ازپیش‌تعریف‌شده، برای تفکیک سازی شبکه، اکتفا می‌نمایند. علاوه بر قابلیت‌های ساده‌ی تطبیق گردش و Forwarding، محصولات بعدی با خصوصیات OpenFlow، روش‌های جدیدی برای پیاده‌سازی ساده‌ی کیفیت خدمات (QoS) و اندازه‌گیری گردش معرفی کرده‌اند.

با وجود این قابلیت‌ها، چند حوزه‌ی برنامه‌نویسی شبکه همچنان خارج از مقیاس فعلی OpenFlow می باشند:

تسهیلات برای مدیریت و مانیتورینگ عناصر پایه تجهیزات: مدیریت Image سیستم عامل، مدیریت سخت‌افزار، بکارگیری Zero-Touch، راه‌اندازی رویداد، اطلاعات مکان المان و غیره

قابلیت تاثیر مستقیم بر رفتار Forwarding یک المان شبکه: بهره‌گیری از پایگاه “مسیریابیِ اطلاعات/پایگاه ارسال اطلاعات” یا به اختصار “RIB/FIB”، وضعیت مسیر، اعلان‌های پروتکل مسیریابی، مسیرهای Add/Delete و پشتیبانی از درخت پوشای وسیع

بهره‌گیری از ظرفیت Packet داده: رمزنگاری On-Box و VPN، الگوریتم‌های رمزنگاری سفارشی‌سازی‌شده، بازرسی دقیق Packet، آگاهی برنامه در صورت نیاز به بررسی ظرفیت، قابلیت تزریق Packetها به جریان شبکه

بکارگیری خدمات: OpenFlow توانایی معرفی مستقیم سرویس روی یک المان شبکه را ندارد. نمونه ای از این سرویس ها عبارتند از Firewall، خدمات برنامه‌ای حوزه‌های وسیع (WAAS)، نرم‌افزار سیستم حفاظت در برابر ورود غیرمجاز یا Broadband Network Gate ،IPS یا به اختصار BNG با قابلیت SDN، مانیتورینگ نمودن ویدئو و غیره.

صفحه کنترل توزیعی و APIها: اتکای OpenFlow به یک صفحه کنترل مرکزی، گزینه‌های زمان اجرای برنامه را محدود می‌نماید.

مدل‌های استقرار انعطاف‌پذیر

OpenFlow به کنترلری نیاز دارد که روی یک سرور قرار گرفته باشد. این کنترلر از پروتکل OpenFlow برای ارتباط در شبکه با Agentهای روی سوئیچ‌ها و روترها استفاده می‌نماید. برنامه‌ها با استفاده از APIهای کنترلر OpenFlow به پیاده‌سازی سیاست شبکه می‌پردازند. سیسکو معتقد است این امر علاوه بر مزایایی که دارد در رویکرد Controller/Application یا به عبارتی کنترلر/برنامه‌ OpenFlow، جهت پشتیبانی از چند مدل گسترش برنامه نیز مفید می باشد.

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

قابلیت راه‌اندازی یک سرویس در هر نقطه از شبکه، براساس نیازهای داینامیک، اهمیت فراوانی دارد. مدل‌های انعطاف‌پذیر گسترش برنامه در ارائه‌ی این قابلیت نقش حیاتی دارند. این رویکرد سیسکو از گزینه‌های مختلف از گسترش برنامه پشتیبانی می‌کند:

• برنامه‌هایی که در Container‌های نرم‌افزاری روی روترها و سوئیچ‌ها اجرا می‌شوند.
• برنامه‌هایی که مستقیماً‌ روی سخت‌افزار x86 روی روترها و سوئیچ‌ها اجرا می‌شوند.
• برنامه‌هایی که روی سرورهای مستقل یا مجازی‌سازی‌شده اجرا می‌شوند.

مدل‌های استقرار انعطاف‌پذیر چند مزیت دارند:

می‌توان برنامه‌ها را روی هر یک از Node‌های شبکه، در هر نقطه‌ای که به سرویس نیاز دارد، به‌کار گرفت؛ بدون اینکه نیاز به دسترس‌پذیری بین Node و یک کنترلر مرکزی باشد.

استقرار توزیعی برنامه، مقیاس‌پذیری را تسهیل نموده و رکود صفحه‌کنترل را به حداقل می‌رساند. مقیاس‌پذیری کنترلرهای متمرکز هنوز در محیط‌های مقیاس‌بزرگ امتحان خود را پس نداده‌اند. بدون مقیاس‌پذیری مناسب کنترلر، ممکن است به‌واسطه‌ی بارکاری(Workload) ایجاد شده هنگام پردازش حجم‌های سنگین پیغام‌ها، همزمان با ارسال Policy‌های به‌روزشده‌ به صدها دستگاه، رخدادهایی با مقیاس‌ بزرگ بر کنترلرهای متمرکز چیره شوند. لازم به ذکر است، کنترلرهای کلاسترشده در زمان نگارش این مقاله در حال ورود به بازار می باشند که ممکن است به کاهش این تاثیرات بیانجامد.

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

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

رویایی بزرگتر برای برنامه‌نویسی شبکه

رویای سیسکو برای (Software Defined Networking (SDN ، ایجاد برنامه‌نویسی حقیقی شبکه می باشد؛ تا برای توسعه‌دهندگان، امکان نوشتن برنامه هایی را فراهم سازد که اطلاعات را در لحظه از شبکه استخراج نموده و اطلاعات و تحلیل‌ها را در تعیین سیاست مناسب اعمال نمایند. سپس این سیاست از طریق OpenFlow، onePK یا سایر ابزارها به المان‌های شبکه تحمیل می‌شود.

این مدل Closed-loop منجر به اتصال مستحکم برنامه‌های “شبکه-به-کسب‌وکار” شده و برای برنامه‌ها این امکان را فراهم می سازد تا منابع شبکه را هماهنگ کنند. این امر سناریویی را ممکن می‌سازد که در آن دستگاه‌های شبکه خود به ارائه‌ی تجزیه و تحلیل برای تشخیص تغییرات ترافیک می‌پردازند؛ تغییراتی که نشان‌دهنده‌ی موجی در ترافیک یک برنامه‌ی خاص باشد. برنامه‌ی Orchestration سپس می‌تواند به‌صورت خودکار Policy را اصلاح نماید تا شبکه به گونه ای مجددا پیکربندی شود که به بهینه‌سازی همزمان تجربه‌ی کاربر و عملکرد برنامه بیانجامد.

استفاده از (Software Defined Networking (SDN در بخش عمومی

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

موارد استفاده‌ی تکنولوژی (Software Defined Networking (SDN

بخش عمومی نیز چالش‌های منحصربفردی در کدگذاری داده‌ها و انتقال ایمن شبکه دارد. موارد کاربردی که در زیر اشاره خواهد شد، راهکارهای مناسب Cisco SDN می باشند:

باعث بهبود عملکرد شبکه و بهینه‌سازی ابعاد مناسب Applianceهای خدماتی گرانقیمت با تشخیص پویای جریان‌های قابل اعتماد در لبه‌ی شبکه می شود که این امر جهت هدایت آنها به سمت خدمات Statefulی نظیر Firewall‌ها، سنسورهای IPS و یا تجهیزات NAT می شود. این قابلیت زمانی که چند موسسه‌ی تحقیقاتی داده‌هایشان را به اشتراک می‌گذارند، ارزشمند می‌گردد.

تامین خودکار پهنای باند شبکه‌ جهت آماده‌سازی انتقال‌های برنامه‌ریزی‌شده‌ی داده‌ها. درواقع Cisco SDN برای اتصال برنامه‌های مدیریت داده با شبکه استفاده می‌گردد تا در جهت پشتیبانی از جابجایی دسته‌های بزرگ داده، مسیرهای انتقالی لازم را ایجاد و تخریب نماید. برنامه‌های محاسباتی توزیعی و با توان عملیاتی بالا نظیر HTCondor از روشی برنامه‌مند(Programmatic) در آماده‌سازی مسیرهای شبکه، برای توزیع کار و مدیریت Workload بهره می‌برند. استفاده از مورد فوق بین محققان علمی بسیار رایج می باشد.

ایزوله‌سازیِ بخش‌های شبکه‌ جهت تفکیک آن با اعمال Policy از طریق کنترلر متمرکز جهت محاصره‌ی کامل ترافیک تحقیق.

بسیاری از موسسات بزرگ، سیستم‌های دانشگاهی و دولت‌ها اکنون در حال اتخاذ معماری‌های همگرای دیتاسنتر (Converged Datacenter) جهت بهینه‌سازی دسترس‌پذیری برنامه و در عین حال کاهش هزینه‌ها می باشند, SDN برای سازمان‌ها امکان آسان سازی انتقال از چند دیتاسنتر به یک دیتاسنتر واحد، معماری Multitenant با استفاده از کنترل وابسته به برنامه‌ی توپولوژی‌های مجازی‌سازی‌شده‌ی «لایه‌ی ۲» و همچنین همسازی خدمات (Service Orchestration) را به وجود می آورد.

موارد کاربرد برمبنای OpenFlow با onePK APIهای سیسکو

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

ریسک تهدیدهای جدید سایبری-‌امنیتی حاصل از نیاز به پشتیبانی BYOD را به حداقل برسانید. فرض کنید تبلت یک دانشجو، یک بدافزار شناخته‌شده را وارد شبکه کند. تجهیزات شبکه می‌توانند از یک برنامه‌ی onePK سیسکو با قابلیت‌های بازرسی ظرفیت Packet، جهت تشخیص بدافزار و کاهش تهدیدات به صورت خودکار از طریق قرنطینه‌ی دستگاه مورد نظر و یا به‌روزرسانی محیط‌های رهیابی برای Black Hole کردن ترافیک آزارنده استفاده کنند.

حفاظت گزینشی از اطلاعات حساس با کدگذاری پویای Flow‌ها با استفاده از الگوریتم‌های سفارشی در حال اجرا روی ابزار شبکه. این قابلیت برای بسیاری از سازمان‌های IT ارزش دارد و قابلیتی حیاتی در معماری‌های Multitenant Cloud محسوب می گردد. با متمرکز شدن دیتاسنترهای دولتی، این دیتاسنترها نیاز مشترکی به کدگذاری ترافیک خاص برنامه از Tenantهای خاص دارند. onePK سیسکو توانایی پیاده‌سازی سیاست‌های بسیار Granular را داشته و کدگذاری را تنها به جریان‌هایی که نیازمند آن هستند محدود می‌سازد و در عین حال، به‌شکلی پویا خدمات کدگذاری را روی Nodeهای مربوط به شبکه معرفی می‌نماید.

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

برنامه‌ای که روی یک روتر پیاده سازی‌شده به پایگاه داده‌ی ذخیره‌ی سیستم TelePresence سیسکو متصل می‌شود. این برنامه با دیدن اینکه یک Session مربوط به TelePresence یک سیسکو Multipoint، برای زمانی خاص برنامه‌ریزی شده، به شبکه دستور می‌دهد که پهنای باند لازم برای دوره‌ی زمانی مناسب را رزرو کند. لازم به ذکر است که TelePresence سیسکو پورت واحد‌ی مخصوص برنامه‌ی TelePresence سیسکو ندارد. onePK سیسکو از بازرسی ظرفیت Packet برای شناسایی Flow‌های مربوط بهره می‌گیرد. وقتی Session به پایان می‌رسد، پهنای باند رزرو شده، آزاد می‌گردد. onePK سیسکو در جهت‌دهی ترافیک مورد استفاده قرار میگیرد که در آن مجوز شناسایی Flow براساس تحلیل ظرفیت، گسترش می یابد تا با این کار تطبیق چندتایی (Tuple Matching) را افزایش دهد.

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

مسیر سیسکو: براساس OpenFlow با onePK سیسکو

جهت افزایش احتمال برنامه‌نویسی شبکه، سیسکو معماری Cisco ONE را ابداع نموده است. Cisco ONE براساس OpenFlow بوده و قابلیت‌های جدیدی دارد تا به چالش‌های WANها و دیتاسنترها و همچنین شبکه‌های دانشگاهی بپردازد.

سیسکو اعتقاد دارد که دامین‌های مشکل‌دار WAN، دانشکده و دیتاسنتر به‌اندازه‌ی کافی تفاوت دارند که هیچ فناوری‌ای نمی‌تواند مناسب همه‌ی این قلمروها باشد. به‌علاوه، بخش‌های مختلف مشتریان مشکلات مختلفی نیز دارند.

درواقع Cisco ONE بازنمایی همین عقیده است و رویکردی به برنامه‌نویسی شبکه با استفاده از فناوری‌های متنوع ارائه می‌نماید. سازمان‌های بخش دولتی می‌تواند همه یا بعضی از این اجزاء را مورد استفاده قرار دهند:

واسط کاربری برنامه‌مند قوی onePK سیسکو. APIهای onePK سیسکو، به سیسکو و کنترلرهای شخص ثالث دسترسی برنامه‌نویسی مستقیم به نرم‌افزار Cisco IOS را می‌دهد. آنها از صدها حرکت برنامه‌مند نظیر کشف دستگاه ها، مدیریت آن و کنترل Policyها و Routing پشتیبانی می‌کنند. علاوه بر این، APIهای مسیر داده‌ی onePk سیسکو (Cisco onePK Data Path APIs) اجازه‌ی دسترسی برنامه‌نویسی جهت Extract، Modify و یا ReInsert کردن هریک از Packetها را در یک جریان فعال می‌دهد. نقشه‌ی راه onePk سیسکو شامل پشتیبانی از سیستم عامل‌های IOS، IOS-XE، IOS-XR و NX-OS در تقریباً تمام سوئیچ‌های سری‌های Cisco Catalyst و Cisco Nexus است.

پشتیبانی OpenFlow روی کنترلرهای آماده‌ محصول سیسکو: برخلاف سایر کنترلرهای OpenFlow، کنترلرهای سیسکو کنترل دسترسی نقش‌محور، پشتیبانی از حل مشکل، انتقال مستقل از توپولوژی، قابلیت تزریق ترافیک ترکیبی (inject synthesized traffic) و همچنین Trace Routing را دارد.
این کنترلر از آغاز سال ۲۰۱۲ تست‌های میدانی را پشت سر گذاشته است.

استفاده در زمینه مجازی‌سازی: استفاده از سیسکو در مجازی سازی به ارائه‌ی پشتیبانی Multitenant و Orchestration خدمات با استفاده از VXLAN و قابلیت‌های vPath در سوئیچ‌های سری Cisco Nexus 1000V می‌پردازد. این مورد از مدل‌های آشنای SDN کنترل متمرکز استفاده می‌کنند اما انتقال از طریق کپسوله کردن چارچوب‌ها روی یک توپولوژی ثابتِ «لایه‌ی ۳» رخ می‌دهد.
نتیجه‌گیری

SDN بدعتی الزام‌آور برای بخش عمومی محسوب می گردد که با خودکارسازی و متمرکزسازی، به تسهیل عملیات کارهای مدیریتی شبکه می‌پردازد. با اتصال برنامه‌ها به کنترل شبکه، آنرا در برابر نیازهای موسسه و کسب‌وکار پاسخگو می‌نماید.

SDN به دلیل آنکه تیم های IT می توانند به‌سرعت رفتار شبکه را برای نیازهای نوظهور کسب‌وکار سفارشی‌سازی نماید؛ مهارت بیشتری به آنها ارائه می‌دهد. شتاب فزاینده‌ی توسعه‌ی برنامه، همچنان سازمان‌های IT را برآن خواهد داشت که فناوری‌هایی را به کار گیرند که به آنها اجازه‌ی مقیاس‌بندی و واکنش سریع به نیازهای در حال تغییر را بدهند.

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

از رویکردی مرحله‌به‌مرحله، برای تایید اعتبار ارزش و عقب راندن ریسک، قبل از پیاده سازی‌های با مقیاس بزرگ استفاده کنند. سیسکو در حال حاضر سعی دارد پشتیبانی SDN را در اکثر مجموعه‌های Switching و مسیریابی خود بگنجاند.

این بدان معناست که می‌توان Pilot‌هایی با مقیاس‌کوچک و همچنین proof-of-concept را بدون سرمایه‌گذاری روی سخت‌افزار جدید مدیریت نمود. علاوه بر آن در بسیاری از موارد، می‌توان برنامه‌های تاییدی در عملکرد را روی سخت‌افزارهای موجود و فقط با یک به‌روزرسانی کد به‌کار گرفت.

اگر از OpenFlow استفاده می‌کنید، Cisco ONE Controller را نیز در نظر داشته باشید. این کنترلر قابلیت‌های بی‌نظیری مانند قابلیت‌های رفع مشکل، کنترل دسترسی نقش‌محور و Forwarding مستقل از توپولوژی دارد که در پیاده سازی عملیاتی مورد نیاز می باشد.

مفهوم WILDCARD در شبکه‌های سنتی و SDN چیست؟

برخی از مهندسان کامپیوتر معتقدند که مفهوم wildcard مخالف یا معکوس subnet mask است. متاسفانه این کاملا نادرست است!­­­­­­!! می‌­توان گفت که یک wildcard از لحاظ ظاهری­ همچون subnet mask، از چهار اوکتت بصورت x.x.x.x تشکیل می‌­شود. بیت­‌های هر اوکتت (که شامل 8 بیت است) می­‌توانند مقادیر 0 یا 1 را شامل شوند. در ­واقع از wildcard بعنوان یک قانون مطابقت استفاده می‌شود که دارای قواعد زیر است:

• معادل بیت­‌های پراهمیت (از نظر تعیین ترافیک ورودی از سمت یک میزبان­ تنها، شبکه ­خارجی و…) از آدرس­ IP، در wildcard مقدار “صفر” قرار می­‌دهیم.
• معادل بیت­‌های بی­‌اهمیت از آدرس­ IP، در wildcard مقدار “یک” قرار می­ دهیم.

موارد استفاده از یک wildcard

بیشترین استفاده از wildcard در (ACL (Access List­ها به منظور اجازه­ ورود یا حذف ترافیک به درون شبکه می‌­باشد. این در­حالی است که ترافیک ورودی می­‌تواند از طرف یک میزبان­ تنها، یک شبکه ­خارجی یا یک محدوده­ ای از آدرس IP­ها باشد. در این حالت به منظور مشخص­ کردن هر کدام از حالات مذکور بوسیله wildcard موارد زیر را خواهیم داشت:

یک میزبان ­تنها: اگر­در­نظر ­داشته باشیم ­که ­ دقیقا­ ترافیک از یک آدرس IP مشخص وارد شبکه شود (بعنوان مثال آدرس 192.168.50.50)، در اینصورت نیاز داریم ­­­ wildcard­ ای بنویسیم که دقیقا تمام اوکتت­های ­آدرس­IP را شامل می‌­شود. در اینصورت بعنوان مثال خواهیم داشت:

ip address 192.168.50.50 wildcard:0.0.0.0

مشخص­ کردن یک شبکه: به منظور مشخص کردن یک شبکه، wildcard باید طوری نوشته شود که با بیت­­­­ های Net id تطبیق شود. بعنوان مثال wildcard برای آدرس IP با کلاس­ C برابر است با

ip address 192.168.50.50 wildcard:0.0.0.255

مشخص­ کردن­ محدوده­ ای از آدرس­IP: زمانی­‌که می‌خواهیم­­­­ wildcard ­ای داشته باشیم که یک محدوده­ ای از آدرس IP را در­برگیرد (مثلا 192.168.0.0-192.168.1.255)، بیت‌­های ­مشترک میان دو آدرس را (در این مثال 23) بصورت بیت‌های پر­اهمیت در wildcard درنظر می‌گیریم. بنابراین با احتساب 23 بیت مشترک (جمع 16بیت مربوط به دو اوکتت­ اول و 7 بیت مشترک اوکتت ­سوم) میان دو آدرس­IP، خواهیم داشت:

ip address: (192.168.0.0-192.168.1.255) wildcard: 0.0.1.255

مفهوم wildcard در SDN

مطلبی که این مقاله به آن اشاره کرده‌ایم، مفهوم­ کلیدی جداسازی دو سطح control plane و data plane و برقراری ارتباط دوسطح از طریق پروتکل اپن­ فلو است. این قابلیت امکان تغییر در جداول جریان دستگاه­‌های موجود در سطح data plane را بدون نیاز به اتصال مستقیم به دستگاه ­ها فراهم می‌­کند وکنترلر به عنوان مغز شبکه، جدول­ های لازم (همچون MAC table) برای عملیات فورواردینگ را ایجاد می‌کند. در واقع سوییچ­‌های اپن­ فلو شامل یک یا چند جدول­ جریان به منظور تصمیم­ گیری در مورد عملیات فورواردینگ می‌باشند و کنترلر توسط پروتکل اپن­ فلو می­تواند Flow Entry­هایی را به این جداول اضافه یا حذف یا بروزرسانی کند.

از یک Flow Entry در جدول جریان به منظور تطبیق (match) و پردازش بسته‌های ­ ورودی استفاده می‌­شود. در واقع یک Flow Entry شامل فیلد­هایی همچون Match Field، Instruction، Priority و Counterها می‌باشد و بطور ­خاص هر Flow Entry توسط دو فیلد Match Field و priority از Flow Entry­های دیگردر ­جدول جریان متمایز می ­شود. فیلد Match Field شامل هدر­های بسته، پورت ورودی و مقدار Metadata است. بسته­ های ورودی که با فیلدهایی از Match Field تطبیق می‌­شوند، بر روی آن­ها عمل­ خاصی انجام می‌شود; اما ممکن است که در هیچ کدام از فیلد­های Match Field مقداری مشخص نشود در اینصورت با اصطلاح match any مواجه می­‌شویم و به این حالت ­wildcard می­‌گویند.

به مثال زیر توجه کنید:

همانطور که در شکل مشاهده می­ کنید، در Flow Entry موجود در Flow Table، فیلد­هایی همچون IP Dst و Action مشخص شده ­اند و دیگر فیلد­ها شامل wildcard (*) هستند. اگر فرض کنیم سوئیچ OVS باشد و جدول جریان آن را در این حالت ببینیم بصورت زیر خواهد بود:

cookie=0x0, duration=10.97s, table=0, n_packets=0, n_bytes=0, priority=10, ip_dst=5.6.7.8,action=CONTROLLER:65535

نکته: همانطر که می‌بینید فیلدهای وایلدکارد در جدول سوئیچ (بصورت *) نمایش داده نمی‌شوند.

توجه: یک Flow Entry که همه فیلد­های آن wildcard باشد و اولویت آن برابر با صفر باشد، به اصطلاح Table-miss نامیده می­‌شود. در چنین حالتی بسته به سمت کنترلر ارسال و یا حذف می­‌شود.

مثالی از Table-miss در اوپن فلو:

همانطور که ملاحظه می‌کنید در این مثال هیچ فیلد انطباق یا Match Fieldای قید نشده است و در واقع تمامی فیلدها wildcard هستند.

cookie=0x0, duration=10.97s, table=0, n_packets=0, n_bytes=0, priority=0, action=CONTROLLER:65535