اترنت (Ethernet)
در 22 می1973 باب متکالف[۱] در مرکز تحقیقاتی شرکت زیراکس در کالیفرنیا یادداشتی در مورد شبکه‌ای که برای اتصال ایستگاه های کاری به یکدیگر طراحی کرده بود نوشت. اولین رایانه با واسط گرافیکی و ماوس و همچنین اولین چاپگر لیزری توسط زیراکس ارائه شده بود که شبکه متکالف آن‌ها را به‌هم متصل می‌کرد. در ابتدای امر اترنت به عنوان یک شبکه انعطاف‌پذیر، غیر‌متمرکز و ارزان با ظرفیت 3Mbps و برای پشتیبانی از حداکثر256 میزبان طراحی شد. بعدها استاندارد اترنت 10Mbps توسط کنسرسیوم شرکت‌های DEC، Intel و Xerox تدوین و در 1980 منتشر شد که بر اساس حرف اول نام هرکدام از این شرکت‌ها DIX نام گرفت. استانداردسازی از آن پس توسط موسسه مهندسان‌برق‌و‌الکترونیک (IEEE) تا به امروز که تکامل و پیشرفت های زیادی در اترنت صورت پذیرفته، ادامه یافته است. امروزه اترنت تنها نجات‌یافته‌ی نزاع بین فناوری‌های شبکه‌ی محلی و مبتنی بر فریم[۲] است. زیربنای اینترنتیست که همگان از آن استفاده می‌کنند. در ادارات، خانه ها و مراکز محاسباتی یافت می‌شود و در حامل‌ها، خودروها، هواپیماها و صنایع مورد استفاده قرار می‌گیرد. کیفیت اولیه‌ی لحاظ شده در طرح اصلی، متضمن این امر است که اترنت (در اشکال مختلف) تقریباً تنها فناوریست که امروزه در شبکه‌های محلی مورد استفاده قرار می‌گیرد.
شبکه نرم افزار محور (Software defined network)
زیرساخت های مدرن اینترنت از مجموعه ای از دستگاه‌های شبکه با معماری ASIC[۳] و تراشه های مخصوص برای رسیدن به توان عملیاتی بالا، تشکیل شده است. لذا شبکه‌های سخت‌افزار‌محور یا سخت‌افزارمتمرکز را شاهدیم. این شبکه‌های سخت‌افزارمتمرکز از کاستی‌هایی نظیر قابلیت مدیریت، انعطاف‌پذیری و توسعه‌پذیری رنج می‌برند. تجهیزات شبکه معمولاً از یک سری دستورات و پیکره‌بندی، بسته به میان‌افزار[۴] یا سیستم‌عامل توکار[۵]شان، پشتیبانی می‌کنند. بنابراین مدیران شبکه محدود به مجموعه‌ای از دستورات از پیش تعیین شده هستند. در صورتی که اگر امکان برنامه‌پذیری در بخش کنترلی شبکه وجود داشته باشد، پشتیبانی از پروتکل‌ها و برنامه‌های بیشتر، سهل‌تر و کاراتر خواهد بود. و به این طریق در واقع انعطاف‌پذیری و واکنش‌پذیری بیشتری را از شبکه شاهد خواهیم بود. بعلاوه این که محققین و پژوهشگران عموماً به جای پیاده کردن سناریوهای دنیای واقعی، به‌دنبال ساخت بسترهای آزمایشی و شبیه‌سازی به جهت تحقق ایده‌های خود هستند. به عبارت دیگر پژوهش و نوآوری در شرایط فعلی شبکه‌های سخت‌افزارمتمرکز، هزینه بر است. برای غلبه بر چنین محدودیت‌هایی مفهوم شبکه‌های نرمافزارمحور (SDN) پیشنهاد شد. SDN را می توان معماری شبکه‌ی نوظهوری دانست که در آن بخش کنترل شبکه از مکانیزم forwarding جدا و تفکیک شده و مستقیماً برنامه‌پذیر است. در SDN (حداقل) یک کنترل کننده متمرکز منطقی وجود دارد که توپولوژی و نمای کلی شبکه را در اختیار دارد و ادوات مختلف که کار forward بسته‌ها را انجام می‌دهند (مثل سوئیچ) را کنترل و آن‌ها را از طریق واسطی (نظیرForCES و OpenFlow) پیکره‌بندی می‌کند. مثلاً سوئیچ OpenFlow یک یا چند جدول Forwarding دارد که توسط کنترل کننده مرکزی، کنترل می‌شوند. لذا قابلیت برنامه‌پذیری در لایه و سطح کنترل محقق می‌شود. جداول forwarding برای نظارت بر بسته‌ها مورد استفاده قرار می‌گیرند. (مثل forward کردن یا لغو(drop) کردن). بنابراین با توجه به خط‌مشی و سیاست کنترل‌کننده‌ای که این جداول را مدیریت می‌کند، یک سوئیچ OpenFlow قادر است به عنوان مسیریاب، سوئیچ، مترجم‌نشانی‌شبکه[۶]، دیواره‌آتش یا توابع ترکیبی از آن‌ها (بر اساس قواعد مدیریت بسته)، ارائه کند. SDN با توجه به ذات و ماهیت تفکیک شده‌اش، به عنوان یک فناوری نوین شبکه شناخته می‌شود که عملیات و مدیریت شبکه‌های امروزی را ساده‌سازی و بستری برای نوآوری و درانداختن طرح‌های نو در شبکه مهیا کرده است. لذا در اینترنت فعلی و معماری‌های آینده اینترنت نظیر شبکه‌اطلاعات‌محور، از سوی جامعه آکادمیک مورد توجه شایسته‌ای قرار گرفته است. علاوه بر آن امروزه مراکز داده عظیم، با شبکه های گذشته در چند مورد کلیدی متفاوتند: پایداری توپولوژی، الگوهای ترافیکی و مقیاس. سرویس‌های این مراکز، نیازمند تغییرات مستمر در پیکره‌بندی بوده و سطحی از چابکی را می‌طلبند که در گذشته مطرح نبوده است. راهکارهای شبکه سنتی به اندازه کافی برای سطوح مورد نیاز در این مقیاس کافی نیستند. SDN صراحتاً برای این نسل جدید شبکه‌ها طرح ریزی شده و نمایانگر تغییرات اساسی و بنیادین در سوئیچینگ سنتی اینترنت است.
معماری سوئیچینگ سنتی ، سطوح داده، کنترل و مدیریت
اکثریت قریب به اتفاق بسته‌هایی که سوئیچ با آن‌ها مواجه است صرفاً در سطح یا لایه‌ی داده مورد دستیابی قرار می‌گیرند. لایه داده شامل درگاه‌های مختلف برای دریافت و ارسال بسته‌ها، جدول forwarding و منطق مرتبط با آن است. این لایه مسئولیت بافر کردن بسته‌ها، زمانبندی آن‌ها، تغییرات سرآیند و forward آن‌ها را برعهده دارد. اگر اطلاعات سرآیند بسته‌ی داده‌ی رسیده، در جدول forwarding موجود باشد متصور است که با برخی تغییرات احتمالی در سرآیند، بدون دخالت هیچ کدام از دو لایه دیگر، forward شود. البته همه بسته‌ها به این شیوه مدیریت نمی شوند مثل مواقعی که اطلاعات لازم در جدول موجود نیست یا بسته‌ها متعلق به پروتکل کنترلی خاصی باشند که در لایه کنترل باید پردازش شود.
همان گونه که در شکل ۳ مشاهده می شود، در لایه کنترل فعالیت‌های زیادی انجام می‌شود. نقش اصلی این لایه بروزنگهداشت اطلاعات جدول forwarding است. با این تفسیر لایه داده به طور مستقل می تواند بالاترین درصد ترافیک ممکن را مدیریت کند. لایه کنترل مسئول پردازش تعدادی پروتکل‌های کنترلیست که بسته به نوع و پیکره بندی سوئیچ ممکن است در جدول forwarding تاثیرگذار باشند. این پروتکل‌های کنترلی مشترکاً مدیریت توپولوژی فعال شبکه را عهده دارند و به‌دلیل پیچیدگی نیازمند بهره‌گیری از پردازنده‌های عمومی و نرم‌افزار مختص خود در لایه کنترل می باشند. امروزه لایه داده را می‌توان بالکل به صورت سخت‌افزاری و سیلیکونی متصور شد. لایه سوم نشان داده شده در شکل ۳، لایه مدیریت است. مدیران شبکه از طریق این لایه سوئیچ‌ها را مدیریت و پایش می نمایند که به نوبه خود و به طور مقتضی اطلاعات را از لایه‌های کنترل و داده استخراج و یا تغییراتی را اعمال می کنند. مدیران شبکه از انواع مختلف سیستم‌های مدیریت شبکه برای ارتباط با لایه مدیریت سوئیچ استفاده می‌نمایند.
فهرستی بلندبالا از پروتکل‌هایی که در یک سوئیچ لایه ۲ یا مسیریاب لایه ۳ مدرن امروزی باید پیاده شوند را می توان تهیه نمود که توضیح و شرح در خصوص این پروتکل‌ها از حوصله این نوشتار خارج است. این پروتکل‌ها برای کارکرد صحیح و دقیق سوئیچ‌ها و مسیریاب‌ها لازمند. در شکل ۴ مشاهده می‌شود که لایه کنترل سوئیچ چطور توسط ترافیک مختص برخی از این پروتکل‌ها بمباران شده است. بررسی‌ها نشان داده است که در شبکه‌های مراکزداده‌ی عظیم، ۳۰ درصد حجم و ظرفیت لایه کنترل مسیریاب یا سوئیچ صرف ردیابی تغییرات توپولوژی می‌شود. و زمانی که در مرکز داده، بخشی ناگزیر تغییر نماید، مثلاً با افزودن یک سرویس‌دهنده یا خارج کردن لینکی از سرویس، زمان زیادی توسط سوئیچ‌ها و مسیریاب‌ها صرف بازسازی توپولوژی شده و عملاً ویرانی موقتی پیش می‌آید.
منفک کردن لایه کنترل از سوئیچ
یک راهکار برای حل معزلات اشاره شده که در مفهوم SDN گنجانده شده و در شکل مشاهده می‌شود، حذف لایه کنترل از سوئیچ و انتقال آن به یک لایه کنترلی و متمرکز است که کل شبکه را پوشش دهد. این لایه کنترل مرکزی جداول forwarding تمامی سوئیچ ها را برنامه ریزی می‌کند. سادگی مفهوم این راهکار از موارد ملموس زیر سرچشمه می‌گیرد:
- توپولوژی داخل مرکز داده به اندازه کافی پایدار است و تحت محدودیت‌های کنترل مدیریتی محلی واقع است.
- اطلاعات مختص توپولوژی متمرکز بوده و توسط مدیران یکسانی کنترل می‌گردد.
- زمانی که خرابی گره یا لینک اتفاق می افتد این اطلاعات کلی از توپولوژی، توسط کنترل مرکزی، برای ایجاد مجدد مجموعه‌ای صحیح و نامتناقض از جداول forwardingمورد استفاده قرار می‌گیرد.
دلایل مهم و کلیدی مهاجرت به SDN
با صحبت های انجام شده می توان موراد زیر را اهم دلایل کلیدی مهاجرت به SDN دانست:
مفهوم واسط مرز شمالی و واسط مرزجنوبی در SDN
واسط مرز شمالی (Northbound) واسطیست که به مولفه‌ای خاص در شبکه اجازه ارتباط و تعامل با مولفه(ها)ی سطح بالاتر را می‌دهد. و برعکس واسط مرز جنوبی (Southbound Interface) واسطی را گویند که برای یک مولفه از شبکه امکان ارتباط با مولفه(ها)ی سطح پایین تر را فراهم می‌کند. در دید مفهومی جریان (flow) مرزشمالی را می‌توان حرکت به سمت بالا و flow ی مرز جنوبی را حرکت به سمت پایین درنظر گرفت. در نمودارهای مربوط به معماری‌ها، واسط‌های Northbound در بالای مولفه و واسط‌های Southbound در پایین مولفه ترسیم می‌شوند. مفاهیم Northbound و Southbound را تقریباً می‌توان در هر نوع شبکه‌ی کامپیوتری بکار برد اما در سال‌های اخیر و در مواجهه با API[۷] ها به طور فزاینده ای در SDN مورد استفاده قرار گرفته است.
در SDN و در Southbound پروتکل هایی با کارکرد اصلی برقراری ارتباط بین کنترل‌کننده و گره‌های موجود در شبکه (سوئیچ‌ها و مسیریاب‌های فیزیکی و مجازی) مورد استفاده قرار می‌گیرد که از بین آن‌ها پروتکل OpenFlow بیشتر مورد استقبال جامعه آکادمیک قرار گرفته است. به واسطه‌ی این پروتکل(ها) سوئیچ‌ها و مسیریاب‌ها قادرند توپولوژی را شناسایی، جریان(flow)ها را تعریف و درخواست‌های ارسال شده را از طریق API های مختص Northbound انجام دهند. واسط Northbound، محدوده‌ی ارتباطی قابل پشتیبانی توسط پروتکل را بین کنترل‌کننده و برنامه‌های کاربردی تعریف می‌نماید.
در یک مرکزداده سازمانی، توابع و کارکرد API های Northbound، شامل راهکارهای مدیریت برای اتوماسیون و ارکستراسیون (برقراری هماهنگی و هارمونی) و اشتراک‌گذاری داده‌های قابل اجرا، بین سیستم‌هاست. توابع و کارکرد API های مربوط به Southbound، شامل برقراری ارتباط با فابریک سوئیچ، پروتکل های مجازی سازی شبکه و یا یکپارچه‌سازی یک شبکه محاسباتی توزیع شده است.
پروتکل OpenFlow
این پروتکل نمونه ای از معماری SDN و مجموعه ای از ویژگی هاییست که توسط انجمن شبکه‌ی آزاد (ONF[۸]) حمایت می‌شود. در هسته و محور این ویژگی ها تعریفی از یک ماشین انتزاعی پردازش بسته وجود دارد که به نام سوئیچ شناخته می‌شود. این سوئیچ بسته‌ها را با استفاده از ترکیبی از محتویات بسته و پیکره‌بندی خودش پردازش می‌نماید. پروتکلی برای تغییر دادن و دستکاری در وضعیت پیکره‌بندی سوئیچ و در عین حال دریافت رویدادهای خاص آن تعریف شده است. درنهایت، کنترل‌کننده مولفه‌ای است که از پروتکل، برای مدیریت پیکره‌بندی وضعیت سوئیچ‌ها و پاسخ به رویدادها استفاده می‌کند.
OpenFlow رایج ترین پروتکل ارتباطی در مرز جنوبیست. هرکنترل‌کننده در شبکه با استفاده از این پروتک قادر است به سوئیچ متصل شده و اطلاعات forwarding و مسیریابی را در جدول forwarding و مسیریابی سوئیچ (جداول flow) اضافه یا حذف کند یا آن‌ها را تغییر دهد. هر ردیف از جدول دارای دو قسمت اصلی می‌باشد، قسمت شرط و قسمت دستورالعمل. سوئیچ بسته‌های ورودی را با شروط هر ردیف جدول مقایسه می‌کند و در صورت تطابق، دستورالعمل تعریف شده در قسمت دوم آن ردیف از جدول را اجرا می‌کند. دستورالعمل ممکن است شامل انتقال به یک پورت خروجی، حذف بسته، فرستادن بسته به کنترل کننده و غیره باشد. عمل تطابق بسته با شرط یا شروط تعریف شده در هر ردیف از جدول، از جدول اول آغاز می‌شود و ممکن است در جدول‌های اضافی دیگر هم انجام گردد.
ظهور OpenFlow را می‌توان نقطه و سرآغاز تولد SDN دانست. در حقیقت مفهوم SDN تا یک سال پس از زمان ارائه‌ی Openflow (سال 2008 میلادی)، نامعلوم بود. اما زمانی که OpenFlow پای به عرصه‌ی وجود نهاد و توسط جوامع تحقیقاتی و همچنین ارائه دهندگان تجهیزات شبکه مورد پذیرش قرار گرفت، تغییری عظیم در شبکه های کامپیوتری بوجود آمد که همچنان نیز مشاهده می‌شود. البته با این که مفهوم SDN در جوامع تحقیقاتی از اوایل سال 2009 در حال استفاده بود، اما تا سال 2011 عملاً تاثیر چندانی در صنایع عریض و طویل شبکه نداشت. ویژگی های این پروتکل، سازندگان تجهیزات شبکه را ترغیب به پیاده سازی آن در محصولات سوئیچینگ خود و راه‌اندازی در شبکه‌های کالج-دانشگاهی[۹] نمود. امروزه بسیاری از ارائه دهندگان تجهیزات شبکه، OpenFlow را در محصولات خود گنجانده اند.
ادامه دارد...
استفاده از مطالب با ذکر منبع بلامانع است.
منابع و ماخذ
1. Spurgeon, C. and J. Zimmerman, Ethernet : the definitive guide. Second edition. ed. 2014: O’Reilly Media, Inc. xxi.
2. Metcalfe, R.M. and D.R. Boggs, Ethernet: distributed packet switching for local computer networks, in Communications of the ACM. July 1976. vol 19: p. 395-404.
3. Sommer, J., S. Gunreben, and F. Feller, Ethernet – A Survey on its Fields of Application. 2010. 12(2): p. 236-284.
4. IEEE, Standard for Ethernet 802.3. 2012.
5. Farhady, H., H. Lee, and A. Nakao, Software-Defined Networking: A survey. ELSEVIER, 2015.
7. Goransson, P., C. Black, and T. Culver, Software Defined Networks : A Comprehensive Approach, Second Edition. 2017.
8. Rouse, M. Northbound interface / Southbound interface. Available from: http://whatis.techtarget.com/definition/northbound-interface-southbound-interface.
9. OpenFlow overview.; Available from: http://flowgrammable.org/sdn/openflow
[1] Bob Metcalfe
[2] Frame
[3] Application Specific Integrated Circuit
[4] Middleware
[5] Embedded Operating System
[6] Network Address Translation (NAT).
[7] Application Programming Interface
[8] Open Networking Forum
[9] Campus Area Network
