دانلود رایگان ترجمه مقاله مطالعه گذشته و آینده شبکه های قابل برنامه ریزی (آی تریپل ای 2014)

مبتدی (مناسب برای درک مفهوم کلی مطلب) 

B) شبکه‌های فعال: در اواسط 1990، شبکه‌های فعال [8]، [9] ابتکار عمل این ایده از زیرساخت‌های شبکه را پیشنهاد دادند که می‌توانست برای خدمات سفارشی برنامه‌ریزی شود. دو روش اصلی در این زمینه وجود دارد، عبارتند از: (1) سوئیچ قابل برنامه‌ریزی، با انتقال داده‌ها و خارج از باند کانال‌های مدیریت؛ (2) کپسول‌ها، که هر قطعه از برنامه هستند که می‌توانند در پیام‌های کاربر جای گیرند. هر قطعه از برنامه توسط روتر اجرا می‌شود. با وجود انگیزه‌ی فعالیت قابل توجهی، شبکه‌های فعال هرگز به جمع‌آوری و استفاده گسترده و توسعه صنعت، به دلایل امنیتی و نگرانی عملکرد روی نیاوردند [10].

C) DCAN: ابتکار عمل دیگری که در اواسط 1990 روی داد کنترل شبکه‌های ATM بود (DCAN) ]11[. هدف این پروژه طراحی و توسعه زیرساخت‌های لازم برای کنترل مقیاس‌پذیر و مدیریت شبکه ATM بود. در این پروژه فرض بر این بود که، کنترل و مدیریت توابع در بسیاری از دستگاه‌ها (سوئیچ‌های ATM در مورد DCAN) باید جدای از خود دستگاه‌ها باشد و به موجودیت‌های خارجی اختصاص داده شده برای این منظور که اساسا با مفهوم DCAN همراه هستند واگذار شود. DCAN فرض می‌کند که یک پروتکل بین مدیر و شبکه وجود دارد، همان خطوطی که امروزه در طرح‌هایی مانند OpenFlow اتفاق می‌افتد. موارد بیشتر را می‌توان در پروژه‌ی DCAN در [12] یافت.
هنوز در خطوط SDNs و جدایی پیشنهادی کنترل و نقشه‌ی داده بر روی شبکه‌های ATM، در میان دیگران، در کار ارائه شده در [13] معماری کنترل چندگانه ناهمگن، مجاز به اجرای همزمان شبکه‌های ATM فیزیکی با پارتیشن‌بندی منابعی که بین آن کنترل‌ها جابه‌جا می‌شوند، است.

D) پروژه‌ی 4بعدی: با شروع در سال 2004، پروژه‌ی 4بعدی ]14[، [15]، [16] از یک طراحی حمایت کرد که بر جدایی بین مسیریابی تصمیم‌گیری منطقی و پروتکل حاکم بر تعامل بین عناصر شبکه تاکید داشت. که “تصمیم‌گیری” در مورد یک دیدگاه جهانی از شبکه، سرویس‌های “انتشار” و “کشف” نقشه‌ها، برای کنترل «داده» جهت حمل ترافیک را پیشنهاد داد. این ایده‌ها یک القای مستقیم برای کاهای بعدی مانند NOX ارائه کردند [17]، که “سیستم عامل برای شبکه‌ها” یک پیشنهاد در چارچوب شبکه OpenFlow بود.

E) NETCONF: در سال 2006، گروه پیکربندی شبکه IETF، NETCONF را به‌عنوان یک پروتکل مدیریت برای تغییر تنظیمات دستگاه‌های شبکه پیشنهاد داد. پروتکل به دستگاه‎‌های شبکه امکان افشای API از طریق توسعه پیکربندی داده‌ها را برای ارسال و بازیابی می‌داد.
پروتکل مدیریت دیگری، که به‌طور گسترده از گذشته تا به امروز استفاده می‌شد، SNMP نام داشت ]19]. SNMP در اواخر دهه 80 مطرح شد و به‌عنوان یک شبکه‌ی مدیریت پروتکل بسیار محبوب مطرح شد، که از مدیریت ساختار رابط (SMI) برای واکشی داده‌های موجود در مدیریت پایگاه اطلاعات (MIB) استفاده می‌کرد. این مسئله می‌تواند برای تغییر متغیرها در MIB به‌منظور تغییر تنظیمات پیکربندی استفاده شود. بعد از آن علی‌رغم آنچه که بود، SNMP برای پیکربندی تجهیزات شبکه استفاده نمی‌شد، بلکه به عنوان یک عملکرد و ابزاری برای نظارت بر خطا به‌کار می‌رفت. علاوه بر این، کاستی‌های متعددی در مفهوم SNMP شناسایی شد، قابل توجه‌ترین آن‌ها عدم امنیت قوی بود. این در نسخه‌های بعدی پروتکل نشان داده شده است.
NETCONF، در آن زمان توسط IETF پیشنهاد شده بود و توسط بسیاری به‌عنوان یک رویکرد جدید برای مدیریت شبکه دیده که کاستی مذکور را در SNMP حل می‌کرد به‌کار می‌رفت. اگر چه پروتکل NETCONF هدف ساده‌ی دستگاه، پیکربندی و عمل به‌عنوان یک بلوک ساختمان برای مدیریت را انجام می‌داد، هیچ جدایی بین داده‌ها و نقشه‌های کنترل وجود نداشت. همان را می‌توان در مورد SNMP نیز اعلام کرد. یک شبکه با NETCONF باید به‌طورکامل به‌عنوان قابلیت‌های جدید در هر دو دستگاه شبکه و مدیریت قابل برنامه‌ریزی در نظر گرفته شود، به‌طوری‌که هر قابلیت جدیدی را بتواند ارائه دهد. علاوه بر این، باید طوری طراحی شود که در درجه اول به پیکربندی خودکار نه برای کنترل غیرمستقیم سرویس کمک کند. با این وجود، هر دو NETCONF و SNMP ابزارهای مدیریتی مفیدی هستند که ممکن است به‌صورت موازی در سوئیچ ترکیبی از دیگر راه‌حل‌های شبکه که قادر به برنامه‌ریزی هستند حمایت کند.
گروه NETCONF درحال‌حاضر فعال است و استاندارد پیشنهادی اخیر در ژوئن 2011 منتشر شد.

F) Ethane: کار قبل از OpenFlow بود پروژه SANE/Ethan بود [20]، که در سال 2006، یک معماری جدید برای شبکه‌های سازمانی تعریف کرد. تمرکز Ethan بر استفاده از کنترل متمرکز برای مدیریت سیاست و امنیت در شبکه می باشد. یک مثال قابل توجه ارائه‌ی کنترل دسترسی مبتنی بر تشخیص است. مشابه SDN، Ethan دو قطعه را به‌کار برد: یک کنترل‌کننده برای تصمیم‌گیری اگر یک بسته باید فرستاده شود، و یک کلید Ethan متشکل از یک جدول جریان و یک کانال امن برای کنترل.
Ethan پایه و اساس تبدیل شدن به شبکه با تعریف نرم‌افزار است. برای قرار دادن Ethan در پارادایم SDN امروز، کنترل دسترسی مبتنی بر هویت Ethan به احتمال زیاد به عنوان یک برنامه در بالای کنترل SDN مانند ] NOX 17]، Maestro [21]، Beacon ]22]،] SNAC 23]، Helios [24]، و غیره اجرا خواهد شد.

3. معماری شبکه‌های با تعریف نرم‌افزار
شبکه‌های ارتباطی داده‌ها معمولا شامل کاربر نهایی دستگاه، یا میزبان متصل شده توسط زیرساخت‌های شبکه است. این زیرساخت‌ها توسط میزبان و به‌کارگیری عناصر سوئیچینگ مانند روتر و سوئیچ و همچنین لینک‌های ارتباطی برای حمل داده‌ها بین میزبان به اشتراک گذاشته می‌شود. روترها و سوئیچ‌ها معمولا سیستم‌های “بسته” اغلب با رابط محدود کنترل فروشنده هستند. بنابراین، یک بار مستقر می‌شوند و در تولید زیرساخت های شبکه متداول کاملا دشوار هستند؛ به‌عبارت‌دیگر، استقرار نسخه‌های جدید پروتکل‌های موجود (به‌عنوان مثال، IPv6)، به‌طورکامل به استقرار پروتکل‌ها و خدمات جدید نیست و تقریبا مانع غیر قابل عبور در شبکه‌های فعلی است. اینترنت، به‌عنوان شبکه‌ای از شبکه‌ها، از این قاعده مستثنی است.
همانطور که قبلا ذکر شد، به اصطلاح اینترنت “استخوان”[2] است و تا حد زیادی به اتصال میان نسبت داده اطلاعاتی و کنترل نقشه بستگی دارد به این معنی که تصمیم‌گیری در مورد اطلاعات جریان از طریق شبکه در هیئت مدیره هر عنصر شبکه ساخته شده است. در این نوع محیط، استقرار برنامه‌های کاربردی شبکه جدید با اهمیت است، همان‌طور که آن‌ها نیاز به اجرای مستقیم زیرساخت‌ها دارند. حتی کارهای ساده مانند پیکربندی و یا اجرای سیاست ممکن است نیاز به مقداری تلاش به‌دلیل عدم وجود یک رابط کنترل مشترک به دستگاه‌های شبکه‌های مختلف داشته باشند. روش دیگر، استفاده از “”middleboxe ( به‌عنوان مثال، فایروال، تشخیص نفوذ سیستم‌ها، مبدل آدرس شبکه و غیره) بالای زیرساخت‌های شبکه‌های زیربنایی ارائه شده است و به‌عنوان راهی برای دور زدن استخوان‌سازی اثر شبکه است. شبکه‌های تحویل محتوا (CDN ها) [25] مثال خوبی هستند.
شبکه با تعریف نرم‌افزار برای تسهیل نوآوری و فعال کردن کنترل ساده و برنامه‌ریزی شده از مسیر داده‌های شبکه، توسعه داده شده است. همانطور که در شکل 1 می‌بینید، جدایی سخت‌افزار حمل‌ونقل از منطق کنترل اجازه می‌دهد تا استقرار پروتکل‌های جدید و برنامه‌های کاربردی، تجسم شبکه و مدیریت، و تحکیم middleboxesهای مختلف برای کنترل نرم‌افزار راحت‌تر شود. به‌جای اجرای سیاست‌ها و پروتکل‌های در حال اجرا در دستگاه‌های پراکنده، شبکه به حمل”ساده” سخت‌افزار و کنترل شبکه تصمیم‌گیری (بازدیدکنندگان) کاهش می‌یابد.

A) معماری کنونی SDN
در این بخش، ما به بررسی دو معماری شناخته شده SDN، یعنی ForCES [1] و OpenFlow ]2] خواهیم پرداخت. هر دوی OpenFlow و ForCES به‌دنبال اصل اساسی SDN از جدایی بین کنترل و داده‌ها هستند؛ و هر دو تبادل اطلاعات بین نقشه‌ها را استاندارد می‌کنند. بااین‌حال، آنها از لحاظ فنی در طراحی، معماری، مدل و رابط پروتکل حمل بسیار متفاوت هستند.