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

فناوری 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 ارتقاء پیدا کرده اند و این روند همچنان ادامه دارد.

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

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

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

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

این مدل سطح بالا از 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. عدم امکان مدیریت و کنترل ترافیک تولیدی از مبدأ تا مقصد در زیرساخت مجازی‌سازی به‌طور کامل به دلیل نبود ارتباط منطقی میان زیرساخت شبکه بستر مجازی با بستر شبکه فیزیکی، امکان اعمال سیاست‌های کنترلی به بسته داده در بستر مجازی ممکن نیست و این امکان تنها محدود به بستر شبکه فیزیکی می‌گردد.