وب سایت آموزشی ، تحقیقاتی

moaveni

به نام خدا

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

اطلاعات بیشتر ......


« مقاله Ethane

ترجمه این مقاله را به صورت فایل پی دی اف از این لینک دریافت کنید و به دیگران نیز توصیه کنید .

اصل مقاله لاتین را از این جا دریافت کنید .

ترجمه و گردآوری : معاونی


Ethane :

مقاله Ethane : در اختیار گرفتن کنترل

Ethane : Taking control of the enterprise

چکیده :

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

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

کلمات کلیدی : شبکه ،  معماری ، امنیت ، مدیریت

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

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

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

یک گزارش توسط گروه Yankee نشان می دهد که ۶۲%  از خرابی شبکه ها در شبکه های چند فروشنده[۱] از خطای انسانی نشات می گیرند و ۸۰% بودجه برای تعمیر و نگهداری و عملیات مربوط به آن صرف می شود .

تلاش های بسیاری برای شبکه های که کنترل پذیرتر و امن تر باشند صورت پذیرفته است (مدیریت آسان تر ) .

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

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

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

با این حال این راه حل ها نهان ،  پیچیدگی مدیریت را کاهش نمی دهند چرا که پروتکل ها به طور مداوم برای پتیبانی از سرعت در حال تغییر هستند و رابط های مدیریت اختصاصی تولید شده توسط عناصر[۲] مدیریت می شوند .

به جای ساخت یک لایه جدید پیچیده در بالای شبکه ، ما باید به این سوال پاسخ دهیم که چگونه ما می توانیم معماری شبکه سازمانی را تغییر دهیم تا مدیریت بیشتری بر روی آن داشته باشیم ؟

پاسخ ما این است که می توانیم معماری به نام Ethane را متصور شویم . Ethane بر اساس سه اصل ساخته شده است که برای مدیریت شبکه ها جز مهم ترین راه حل ها هستند :

  1. شبکه باید با سیاست های اعلام شده سطح بالا اداره شود :

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

  1. سیاست تعیین مسیر جریان بسته ها باید اعمال شود :

دلایل متعددی برای تعیین سیاست مسیرها وجود دارد .

اول این که این سیاست ممکن است بسته ها را به عبور از طریق یک middle box متوسط نیازمند کند . برای مثال یک کاربر مهمان ممکن است به ارتباط با یک پروکسی نیاز داشته باشد یا کاربر از یک سیستم عامل اصلاح نشده برای ارتباط با یک سیستم تشخیص نفوذ[۳] استفاده کند .

دوم این که ترافیک موجود می تواند خدمات مناسب تری را دریافت کند اگرمسیر خود را کنترل کند . مدیریت ارتباطات لحظه ای[۴] در مسیرهای کم ترافیک تر و کاهشمسیرها و ایجاد ارتباطات خصوصی در تمامی مسیرها یک اعتماد مناسب ایجاد کرده و منجر به خدمات بهتر می شود .

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

  1. شبکه باید یک اتصال قوی بین یک بسته و منشا آن تولید کند :

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

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

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

بهترین مدل برای IP این است که هم ساده و هم تغییر ناپذیر باشد و مناسب الگوریتم های توزیع شده باشد . مدیریت شبکه کاملا برعکس است ، مدیریت نیاز به پیچیدگی و سازگاری قوی دارد تا از ان برای محاسبات پیچیده در موضوع توزیع استفاده کند .

اعتراضات بسیاری به روش های استاندارد متمرکز وجود دارد ، مانند انعطاف پذیری و مقیاس پذیری . با این حال در این مقاله ما نشان می دهیم که یک روش استاندارد می تواند انعطاف پذیری بسیار عالی را ارائه دهد و سرعت پردازنده امکان مدیریت تمامی توابع کنترلی روی یک شبکه (در حدود ۲۵۰۰۰هاست) را بوسیله یک کامپیوتر PC فراهم می کند .

Ethane شباهت قابل توجهی به SANE دارد که اخیرا در طرح Clean-Slate به شرکت های امنیتی پیشنهاد شده است . SANE دارای تعدادی Clean Slate بود که استقرار آن ها دشوار بوده و به همین دلیل هرگز آزمایش و تست نشدند . در حالی که SANE شامل تعداد قابل توجهی از ایده های ارزشمند بود . Ethane این کار قبلی را در مسیر اصلی گسترش خواهد داد .

مدیریت امنیت :

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

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

پس با طراحی Ethane ، ما تصمیم گرفتیم که یک رویکرد گسترده برای مدیریت شبکه در نظر بگیریم ، تا امنیت هم در آن به خوبی کار کند .

قابلیت گسترش افزایشی :

SANE به یک بالابر[۵] برای جایگزینی تمام زیرساخت های شبک سازمانی نیاز داشت و باید در تمامی میزبان ها تغییراتی را اعمال می کرد . این کار ممکن است در برخی از موارد مناسب باشد و به وضوح مانعی در مقابل استفاده گسترده آن بوجود نیاید .

Ethane طوری طراحی شده است که بتوان آن را به صورت تدریجی در یک شرکت مستقر کرد وبدون آن که  نیازی به  تغییراتی در میزبان ها وجود داشته باشد . سوئیچ ها Ethane می توانند به صورت تدریجی در کنار سوئیچ های اترنت موجود در شبکه مستقر شوند .

استقرار تجربی قابل توجه :

Ethaneدر هر دوقالب نرم افزاری و سخت افزاری اجرا شده است . (مخصوصا سو ئیچ های اترنت Gigabit) و در بخش علوم کامپیوتری دانشگاه استنفورد در حدود ۴ ماه مدیریت بیش از ۳۰۰ میزبان را بر عهده داشته است .

تجربه فوق به ما امکان تحلیل مسائل عملیاتی از قبیل مواجه با طراحی های خاص و نتایج تغییرات و توسعه ها را در طرح اصلی داده است .

در این مقاله ما به توصیف کار خود در طراحی ، پیاده سازی و استقرار Ethane می پردازیم . ما به یک مرور کلی سطح بالا از آغاز طراحی Ethane پرداخته و در بخش سوم شرح مفصلی از آن را ارائه می کنیم . در بخش چهارم ما به بیان سیاست POL-Eth پرداخته که در آن به توصیف اجرایی مدیریت Ethane می پردازد . در بخش پنجم ما به بیان تجربه اجرا و استقرار Ethane می پردازیم و سپس تجزیه و تحلیل عملکرد را در بخش ششم بررسی کرده و در بخش هفتم به بیان محدودیت های حال حاضر پرداخته و در بخش هشتم به بیان کارهای مرتبط می پردازیم و نهایتا در بخش ۹ نتیجه گیری مقاله قرار دارد .

کنترلر های Ethane اجازه برقراری ارتباط با هر میزبانی را بدون کسب اجازه صریح ندارند . این تحمیل از طریق دو جزء اصلی ایجاد می شود .

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

مولفه دوم مجموعه ای از سوئیچ های Ethane می باشند . در تضاد  با کنترلرهای واقف به همه چیز[۶] ، سوئیچ ها ساده و کند[۷] هستند که از یک جدول جریان ساده تشکیل شده اند و دارای یک کانال امن با کنترلر بوده و سوئیچ های ساده بسته را به سمت کنترلر ارسال می کنند.

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

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

۱-۲ : اسامی ، اتصالات و سیاست های زبانی :

زمانی که یک کنترلر یک بسته را کنترل می کند در واقع سیاست عمومی را کنترل کرده و به ارزیابی بسته با مجموعه ای از قوانین ساده مانند ” مهمان ها برای برقراری ارتباط با HTTP تنها می توانند از یک پراکسی وب استفاده کنند ” و یا ” تلفن های VOIP امکان برقراری ارتباط با لپ تاپ ها را ندارند ” . اگر ما بخواهیم سیاست های عمومی را بر روی قطعات فیزیکی اعمال کنیم ، نیاز داریم تا قابلیت اطمینان و امنیت یک بسته را بوسیله ارتباط با کاربر و گروه و یا ماشینی که بسته را می فرستد تامین کنیم . اگر نگاشتی بین نام ماشین ها و آدرس های IP (DNS) وجود داشته باشد یا بین آدرس IP ها و آدرس های MAC (ARPو DHCP) که در جای دیگر به کار گرفته می شوند و غیر مجاز هستند ، ما نمی توانیم به بسته ها اجازه ارسال بدهیم حتی اگر کاربر معتبری در شبکه باد . این یک ضعف گسترده در شبکه های فعلی می باشد .

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

نخست ، Ethane تمامی آدرس های اتصالات را برعهده می گیرد . وقتی که ماشین ها از DHCP برای در خواست IP استفاده می کنند ، Ethane می داند که پورت سوئیچ به دستگاه متصل است و Ethane صفات یک بسته رسیده از پورت فیزیکی را می تواند بدست آورد .

دوم ، بسته ها باید از یک ماشینی که در یک شبکه ثبت شده است ،  برسند . بنابراین صفات آن مربوط به یک ماشین خاص است . در نهایت ، کاربران می توانند خود را در شبکه احراز هویت کنند به عنوان مثال با تغییر مسیر HTTP به شیوه ای که در Hotspot های تجاری رخ می دهد و کاربران به هاست ها متصل می شوند . بنابراین هنگامی که یک بسته به کنترلر می رسد ، می توان امنیت بسته را با توجه به کاربر خاص و میزبانی که آن را می فرستد کنترل کرد.

چندین نتیجه عالی از کنترل می توان بدست آورد که درباره کاربران و ماشین ها و اتصالات بین آن ها می باشد .

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

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

در اصل Ethane استفاده از یک سیاست خاص زبانی را اجبار نکرده است. ما با این حال ما Pol—Eth را طراحی و استقرار داده ایم که در آن سیاست ها مجموعه ای از قوانینی هستند که شامل اسنادی برای تطبیق جریان های که مجموعه ای از نتایج اقدامات [۸] هستند ، می باشند .

(به عنوان مثال ، اجازه می دهد[۹] ، انکار[۱۰] می کند و یا مسیری با چند ایستگاه[۱۱] را پیشنهاد می دهد ) . همان طور که خواهیم دید Pol – Eth مجموعه کوچکی از قوانینی است که به سادگی می توانند درک شوند و سیاست های انعطاف پذیری و قوی را برای شبکه های بزرگ و پیچیده ایجاد کنند .

۲-۲ : Ethane در استفاده :

ما در حال حاضر ۵ فعالیت اساسی را برای تعریف شبکه Ethane تعریف می کنیم که در شکل ۱ نمایش داده شده است :

شکل ۱ : مثالی از ارتباطات در شبکه Ethane

راه اندازی روتر با نقطه چین و مسیر اولیه بسته هر جریان با خطوط بریده نمایش داده شده است .

ثبت نام [۱۲]. تمام سوئیچ ها ، کاربران و میزبان ها در کنترلر ثبت نام می کنند و اعتبار آن ها باید تایید شود . اعتبار بستگی به نحوه استفاده از مکانیزم های احراز هویت دارد . به عنوان مثال ، میزبان ها ممکن است بوسیله آدرس MAC احراز هویت شوند و کاربران برای تصدیق خود از نام کاربری و رمز عبور استفاده کنند و سوئیچ ها برای این هدف از گواهی امن بهره خواهند برد . تمام سوئیچ ها اعتبار مورد نیاز خود را از طریق کنترلر بدست می آورند  .( به عنوان مثال با استفاده از کلید عمومی کنترلر ).

خود راه اندازی [۱۳]. سوئیچ ها با ایجاد ریشه در یک درخت پوشا در کنترلر راه اندازی می شوند . درخت پوشا ایجاد شده هر سوئیچ را با ایجاد یک کانال امن احراز هویت می کند . (کانال امن بین سوئیچ و کنترلر ) . هنگامی که یک اتصال امن ایجاد شد ، سوئیچ ها به ارسال اطلاعات به کنترلر می پردازند و با این اطلاعات به بازسازی توپولوژی شبکه می پردازند .

راه اندازی جریان[۱۵] .

انتقال[۱۷] .

۱-۳ : یک شبکه Ethane :

شکل ۲ نوعی از شبکه Ethane را نمایش می دهد . میزبان ها در آن اصلاح نشده اند و اتصال با یک سوئیچ Ethane سیمی یا نقاط دسترسی[۱۸] بی سیم Ethane می باشد .( از این پس خطاب ما به هر دو نوع سوئیچ می باشد ) .

شکل۲ : مثالی از شبکه Ethane

هنگامی که ما یک سوئیچ Ethane را به شبکه اضافه می کنیم ،آن سوئیچ کنترلر را پیداکرده و یک کانال آمن به سوی آن باز می کند و به کنترلر کمک می کند تا شکل توپولوژی شبکه را بیابد .

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

از دیدگاه یک سوئیچ ، بسته های یک میزبان جدید تنها قسمت ساده ای از یک جریان جدید می باشد و بنابراین آن بسته ها به صورت اتومات در یک کانال امن به سوی کنترلر به همراه ID و پورت سوئیچی که به آن وارد شده ارسال می شوند .

کنترلر به احراز هویت میزبان ها و اختصاص آدرس IP به آن ها می پردازد . (کنترلر شامل یک سرور DHCP می شود).

۲-۳ : سوئیچ ها :

یک سوئیچ Ethane سیمی مانند یک سوئیچ اترنت ساده است که دارای چندین رابط اترنت می باشد که برای دریافت و ارسال بسته های اترنت استاندارد از آن استفاده می کند .

با این حال این سوئیچ ها بسیار ساده تر از سوئیسچ های معمولی اترنت می باشند که سوئیچ Ethane هیچ گونه نیازی به آن ها دارند چرا که یک سوئیچ Ethane نیازی به یادگیری آدرس ها ، پشتیبانی از VLAN ها و کنترل آدرس مبدا برای جلوگیری از کلاهبرداری را ندارد . (به عنوان مثال زمان شروع و پایان جریان ها ) .

یک سوئیچ Ethane به جایگزینی لایه ۳ سوئیچ یا روتر می پردازد و نیازی به حفظ جداول انتقال و ACL ها یا NAT ها ندارد .

هم چنین سوئیچ های Ethane نیازی به اجرای پروتکل های مسیریابی مانند OSPF ، ISIS ، RIP ندارند و نیازی به جداسازی پشتیبانی برای SPAN ها و پورت های تکراری ندارند . (به طور مستقیم از جداول جریان کنترلر استفاده می شود ).

هم چنین شایان ذکر است که جدول جریان می توانند چندین دستور کوچکتر از جدول انتقال در سوئیچ اترنت را انجام دهد . در یک سوئیچ اترنت ، سایز جدول حداقل ترافیک پخشی [۱۹]می باشد .

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

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

ما انتظار داریم که سوئیچ Ethane به مراتب ساده تر از یک سوئیچ اترنت باشد ، البته بدون آن که قابلیت های خود را از دست بدهند . در حقیقت ما انتظار داریم که یک box بزرگ که از تجهیزات قوی و گران قیمتی ساخته شده توسط چند تراشه که بر روی یک board قرار دارند جایگزین شوند .

جدول جریان ها و جریان های ورودی .

تعیین مسیر داده در سوئیچ ها در واقع مدیریت جدول جریان است . جریان ورودی حاوی یک سرآیند (برای مقایسه بسته ها با یکدیگر) و یک اقدام[۲۰] (به سوئیچ گفته می شود که با بسته چه عملی انجام دهد ) و پیش جریان داده (که آن را در ادامه توضیح خواهیم داد ) می باشد .

دونوع ورودی رایج در جدول جریان وجود دارد :

جریان ورودی و توصیفی از جریان های کاربردی که باید فرستاده شوند وجود دارد و هر میزبان ورودی توصیفی از رفتار میزبان ها با بسته ها را بیان می کند . (این بسته ها بر این اساس می توانند drop شوند ) . برای جریان TCP/UDP فیلدهای سرآیند TCP/UDP و IP را پوشش می می دهد و سرآیندهای اترنت اطلاعات پورت فیزیکی را پوشش می دهند .

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

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

کنترلر ممکن است یک جریان بدرفتار[۲۱] را لغو کند یا ممکن است گروهی از جریان های متعلق به یک هاست بدرفتار را حذف کند ، مثلا هاستی که یک شبکه را ترک کرده و یا هاستی که مرتب در حال ایجاد تغییرات است . جدول جریان با استفاده از دوجدول Exact و Match (دقیق و هماهنگ ) پیاده سازی می شود ؛ که یکی برای ورودی های جریان کاربردی می باشد و دیگری برای میزبان های بدرفتار . هرچند که جریان های ورودی دقیق و هماهنگ هستند و به راحتی می توان از طرح های درهم ساز[۲۲] برای حافظه های معمولی به جای TCAM های گران قیمت استفاده کرد .

اقدامات دیگر هم ممکن است به drop  و Forward اضافه شود . به عنوان مثال ، یک سوئیچ ممکن است صف های چندگانه ای برای کلاس های ترافیک مختلف ایجاد کنند و کنترلر می تواند صف بسته ها را در جریان کاربردی ، در داخل یک صف خاص قرار داده و ID صف را به جدول جریان اضافه کند . این می تواند برای جداسازی end to end ، L2 در کلاس های کاربران و یا هاست های استفاده شود .

یک سوئیچ هم چنین می تواند به ترجمه آدرس ها بوسیله جایگزینی سرآیند بسته ها بپردازد . این می تواند برای استفاده در آدرس های مبهم در شبکه های با آدرس مبادله ای [۲۳] در طول مسیر هر سوئیچی به کار رود و یک استراق کننده نمی تواند با میزبان ارتباط برقرار کند یا به پیاده سازی ترجمه آدرس برای NAT در داخل یک آدرس حفاظت شده بپردازد .

در نهایت یک سوئیچ  می تواند ، نرخ جریان را کنترل کند ، هم چنین سوئیچ می تواند ترافیک ارسالی به سمت کنترلر را تا حدودی کاهش دهد . این مقدار کاهش باید تا حد امکان کوچک باشد تا سادگی سوئیچ حفظ شود اگر چه این موضوع در اختیار طراح است .

از طرفی دیگر  ورودی ها می توانند ترافیک ورودی به کنترلر را کاهش دهند و هم چنین هر ترافیکی که در جدول جریان نتواند قرار گیرد بایدبه کنترلر ارسال شود بنابراین در این جا فقط بحث بهینه سازی[۲۴] مطرح است .

مدیریت سوئیچ های محلی .

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

دو راه برای گفتگو بین سوئیچ و کنترلر وجود دارد :

اول این که فرض کنیم سوئیچ ها قسمتی از شبکه فیزیکی کنترلر هستند . ما انتظار زیادی از این موارد داریم . به عنوان مثال در یک شبکه شرکتی در محیط گسترده .

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

این رویکرد می تواندمورد استفاده برای کنترل سوئیچ ها در محل ای دل خواه قرار گیرد به عنوان مثال در کنار یک روتر معمولی یا در مکان راه دور[۲۵] مورد استفاده قرار گیرد . در اولین کاربرد Ethane ، سوئیچ (به احتمال زیاد Access Point در یک شبکه بی سیم ) در یک تجارت کوچک خانگی قرار داده شده است و از راه دور بوسیله یک کنترلر از طریق یک کانال امن مدیریت می شود .

مدیریت در یک سوئیچ محلی وضعیت لینک را به کنترلر می فرستد تا کنترلر بتواند به بازسازی توپولوژی برای محاسبه مسیر بپردازد . سوئیچ شامل لیستی از سوئیچ ها همسایه هستند که با broad cast یک پیام و دریافت جواب این همسایه ها را شناسایی می کنند . لیست همسایه ها بعد از احراز هویت به کنترلر ارسال می شود و هر تغییر قابل تشخیص در وضعیت لینک ها در یک دوره متناوب[۲۶] ۱۵ ثانیه ای به کنترلر ارسال می شود .

۳-۳ : کنترلر :

کنترلر مغز[۲۷] شبکه است و وظایف متعددی دارد . شکل ۳ یک بلوک دیاگرام را نشان می دهد . این اجزا مجبور نیستند که در همه ماشین ها وجود داشته باشند ۰ در واقع آن ها در پیاده سازی ما نیستند ) به طور خلاصه ، کار قطعات به شرح زیر است :

مولفه احراز هویت [۲۸]. که همه ترافیک تایید شده یا آدرس MAC های غیرمحدود را قبول می کند پس کاربران را احراز هویت کرده و میزبان ها با استفاده گواهی نامه های ذخیره شده در پایگاه داده ثبت نام خود را تصدیق می کنند . زمانی که یک هاست یا یک کاربر احراز هویت می شود کنترلر به خاطر می سپارد که کدام پورت سوئیچ به آن ها (کاربر یا میزبان ) متصل است .

شکل ۳ : اجزا یک کنترلر از دید سطح بالا

کنترلر یک فایل سیاست[۲۹] را نگهداری می کند که از داخل جدول مراجعه گردآوری می شود .[۳۰] (به بخش ۴ مراجعه کنید )

هنگامی که یک جریان جدید شروع می شود ، کنترلر آن را با قوانین چک می کند تا ببیند اگر آن باید پذیرفته ، رد و یا مسیریابی شود از طریق ایستگاه بعدی این کار را انجام دهد  . بعد از ان که محاسبه مسیر با استفاده از توپولوژی شبکه صورت پذیرفت به انتخاب مسیر جریان می پردازد . توپولوژی توسط مدیریت سوئیچ   [۳۱] حفظ می شود و دریافت و بروزرسانی لینک های سوئیچ انجام می شود . در ادامه این بخش ما به توصیفات بیشتر عوامل هر جزء پرداخته و البته از بیان سیاست زبانی برای بخش های بعدی اجتناب می کنیم .

ثبت نام .[۳۲] تمام موجودیت های که توسط شبکه نام گذاری شده اند ۰مانند میزبان ها ، پروتکل ها ، سوئیچ ها ، کاربران و کنترل دترسی ها AP) باید ثبت نام شوند . مجموعه ای از موجودیت ها ثبت نام شده سیاست های فضای نام را می سازند و این اصول ثابت که برای اطمینان بیشتر ایجاد شده اند همواره معتبرند . موجودیت ها می توانند به طور ممستقیم در کنترلر ثبت نام کنند یا حتی در پیاده سازی Ethane امکان ثبت نام عمومی مانند LDAP یا AD وجود دارد تا تردیدی برای کنترلر دیگر بوجود نیاید . با ثبت نام سوئیچ ها ، این امکان برای Ethane وجود دارد تا سرویس های پلاگین را برای پیکربندی سوئیچ های اترنت فراهم آورد . براساس این پیکربندی ، سوئیچ ها کلید توزیع شده را در هنگام راه اندازی سیستم (به جای نیاز به توزیع دستی ) با این فرض که شبکه به خطر نیفتد در اختیار همدیگر قرار می دهند .

احراز هویت [۳۳]. همه سوئیچ ها ، هاست و کاربران مجبور هستند که در شبکه احراز هویت شوند . Ethane یک مکانیسم خاصی برای احراز هویت میزبان ها ندارد و یک شبکه می تواند از چندین روش احراز هویت استفاده کند (مثلا ۸۰۲٫۱ برای ورود کاربر مجاز) و موجودیت های مختلف را با این روش احراز هویت کند . در پیاده سازی به عنوان مثال میزبان ها بوسیله ثبت نام آدر س MAC احراز هویت می شوند و کاربراند از طریق یک وب که به سرور کربروس[۳۴] متصل است تصدیق می شوند . سوئیچ ها از SSL به همراه گواهینامه سرور- مشتری[۳۵] برای احراز هویت خود استفاده می کنند .

ردیابی اتصالات[۳۶] . یکی از ویژگی های قدرتمند Ethane این است که به راحتی می تواند تمامی اتصالات بین نام ها و آدرس و پورت های فیزیکی روی شبکه را پیگیری کند و حتی سوئیچ ها ، میزبان ها و میزبان های متصل و ترک کرده[۳۷] و حرکت در اطراف شبکه را ذخیره نماید .

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

یک اتصال همواره به احراز هویت نیاز دارد بنابراین برای جلوگیری از حمله یک مهاجم باید هویت میزبان یا کاربر دیگر را احراز کند . زمانی که کنترلر تشخیص دهد کاربر یا هاستی شبکه را ترک کند ، تمامی اتصالات مرتبط با آن بی ارزش شده و همه جریان ها در شبکه لغو[۳۸] می شوند . متاسفانه در برخی موارد ما نمی توانیم درباره اتصال و یا ترک کردن رخدادها در شبکه مطمئن باشیم . از این رو کنترلر ممکن است دچار وقفه ای برای تشخیص حرکت فیزیکی نقاط دسترسی قبل از لغو دسترسی آن ها شود .

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

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

ما انتظار داریم که کنترلرهای Ethane یک رابط کاربری فراهمبیاورند تا کاربران از طریق آن به اطلاعات دسترسی داشته باشند . در درون سیستم خودمان ما یک سرور DNS اصلاح شده ایجاده کرده ایم که صف های با برچسب زمانی[۴۰] را می پذیرد و فضای نام کاملی را برای هر کاربر ، میزبان یا آدرس IP را برمی گرداند .(ارجاع به بخش ۵) .

بررسی مجوز و دسترسی به آن[۴۱] . پس از دریافت یک بسته کنترلر به بررسی سیاست ها برای عمل به اقدامات (Actions) می پردازد . نتایج این بررسی ها (اگر جریان مجاز باشد) به مولفه محاسبه مسیر فرستاده می شود تا محدودیت های سیاستی برای تعیین مسیر اعمال شود .

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

محدودیت های اجرای منابع[۴۲] . موارد بسیاری وجود دارد که یک کنترلر می خواهد منابع را برای کاربران ، میزبان ها یا جریان ها محدود کند . برای مثال کنترلر مایل است که نرخ یک جریان را محدود کند ، این محدودیت می تواند در محدود کردن نرخ برای یک جریان جدید و یا محدودیت در تعداد آدرس IP های اختصاص یافته باشد .

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

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

اگر میزبان ها آدرس خود را جعل[۴۳] نمایند کنترلر می تواند پورت سوئیچ آن ها را غیر فعال کند . یک رویکرد مشابه می توان برای جلوگیری از احراز هویت سیل آسا میزبان ها تعریف کرد .

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

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

۴-۳ : مدیریت Broadcast  و Multicast :

شبکه های سازمانی معمولا ترافیک موجود را Broad cast یا Multi cast می کنند . Broad cast ترافیک ارزشمندتر (که باعث کشف پروتکل های از قبیل ARP می شود) از Multi cast ترافیک است (که اغلب در موارد کاربردی مانند ویدئو استفاده می شود ) . در داخل شبکه های بر پایه جریان مانند Ethane ، برای سوئیچ ها مدیریت Multi cast بسیار آسان است . سوئیچ یک نقشه بیتی از هر جریان را برای شناسایی پورت هایی که بسته ها در مسیر آن ها ارسال می شوند در اختیار دارد .

کنترلر می تواند  درخت Broad cast یا Multicast را محاسبه کرده و بیت های مناسب را به طول مسیر راه اندازی شده اختصاص دهد . در اصل پروتکل های اکتشافی Broad cast  به راحتی در کنترلر مدیریت می شوند .

به طور معمول یک هاست تلاش می کند تا یک سرور یا یک آدرس را پیدا کند ، مسلم است که یک کنترلر همه آن ها را می داند و می تواند به همه درخواست ها بدون ایجاد یک جریان جدید و Broad cast ترافیک پاسخ دهد .

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

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

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

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

۵-۳ : بازسازی کنترل ؛ تحمل خطا و مقیاس پذیری :

طراحی معماری یک شبکه در اطراف یک کنترلر مرکزی نگرانی ها را در مورد دسترس پذیری و مقیاس پذیری[۴۴] افزایش می دهد . اندازه گیری های ما در بخش ۶ نشان می دهد که هزاران ماشین می توانند بوسیله یک کامپیوتر معمولی مدیریت شوند و چندین کنترلر به شکل مطلوب خطا را تحمل کرده یا مقیاس پذیری را در شبکه های بزرگ رعایت کنند .

در این بخش سه روش برای بازسازی کنترلر مطرح می شود :

در دو رویکرد ساده تر به تنهایی بر روی بهبود خطا متمرکز است . کنترلر فرعی آماده است تا اگر کنترلر اصلی دچار مشکل شد آن ها وارد عمل شوند .

بدون داشتن اتصالات با شبکه[۴۵] یا داشتن اتصال با شبکه[۴۶] . در این مدل بازسازی ، مقیاس پذیری بهبود یافته و درخواست از سوئیچ ها برای Broadcastکردن فعالانه کنترلر ها صورت می پذیرد .

در روش Cold-Standby یک کنترلر اصلی در ریشه درخت پوشای مینیمال (MST) قرار دارد و همه ثبت نام و احراز هویت می شوند و درخواست جریان ایجاد می شود . در این شیوه کنترلرهای پشتیبان گیری بیکار در انتظار به سر می برند تا اگر به آن ها نیازی بود وارد شوند . همه کنترلر ها در ساخت MST شرکت می کنند و پیام Hello  را به تمام ID سوئیچ ها می فرستند .

در یک درخت پوشای استاندارد اگر ریشه کمترین مقدار را داشته باشد ID آن حذف می شود و شبکه به سمت یک ریشه جدید همگرا می شود (یعنی یک کنترلر جدید ) . اگر ریشه MST جدید شروع به ارسال و دریافت درخواست های جریان کند و اقدامات[۴۷] را انجام دهد به عنوان کنترلر اصلی محسوب خواهد شد .

در این روش ، کنترلرها تا حد زیادی از یکدیگر بی اطلاع هستند و پشتیبان گیر تنها به اطلاعات ثبت نام و سیاست شبکه نیاز دارد . ( تغییرات داده ای به آهستگی صورت می پذیرد و روش های سازگار به آسانی می توانند استفاده شوند .  مزیت اصلی روش های Cold –Standby  سادگی آن ها است . آن چه مهم است این است که میزبان ها ، سوئیچ ها و کاربران نیاز به احراز هویت مجدد و اتصال مجدد برای گریز از شکست دارند . علاوه بر این در شبکه های بزرگ ممکن است MST به راحتی همگرا نشود .

روش Warm – Standby رویکردی پیچیده تری دارد اما بازیابی آن سریع تر است . در این روش یک MST جداگانه برای هر کنترلر ایجاد می شود . کنترلرها بر همدیگر نظارت زنده می کنند و پس از تشخیص یک مشکل اولیه یک کنترلر جایگزین به صورت استاتیک کنترل کار را برعهده می گیرد و مانند قبل به آرامی به تغییرات در ثبت نام و سیاست های شبکه که باعث سازگاری کنترلر ها است می پردازد اما نیاز به جایگزینی اتصالات در سراسر کنترلرها داریم ، زیرا اتصالات به سرعت از کاربران و میزبان ها جدید می آیند .

ما توصیه می کنیم که سازگاری به تنهایی به صورت ضعیف حفظ شود زیرا کنترلرها رخدادهای اتصال را به صورت تنها [۴۸] می سازند و با اولین شکست این اتصالات دیگر کارایی نداشته و نیاز است تا کاربران و میزبان ها برای کنترلر جدید خود را مجدد احراز هویت کنند .

رویکرد باسازی کامل [۴۹] یک گام جلوتر است و دو یا چند کنترلر فعال دارد . در حالی که یک MST دوباره برای هر کنترلر ساخته می شود ، یک سوئیچ نیاز دارد تا خود را برای کنترلر دیگر احراز هویت کند و می تواند درخواست های جریان را گسترش دهد ( با hash کردن و round-robin) . در بازسازی ما نباید کار آن ها را دست کمتر از نگهداری سازگاری اتصال ها بدانیم . ما انتظار داریم که بسیاری از پیاده سازی ها به آسانی شرایط را برای ضعف سازگاری رخدادها فراهم آورند . تکنیک های عملی می توانند جلوی بسیاری از مشکلاتی که به این صورت بوجود می آیند را بگیرند به عنوان مثال می توان به استفاده کنترلرها از آدرس IP های خصوصی در DHCP برای جلوگیری از تخصیص IP های موقت را نام برد .البته شناخت خوبی از جایگزین های قوی تر که سازگاری راضمانت می کند وجود دارد ( به عنوان مثال ماشین های بازسازی) .

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

۶-۳ : شکست لینک :

خرابی لینک و سوئیچ ها نباید شبکه را از کار بیندازد[۵۰] .به یاد دارید که سوئیچ  ها همیشه پیام شناسایی همسایگان را به کنترلر ارسال می کردند تا بتوانند موقعیت لینک ها را پیگیری کنند . هنگامی که یک لینک خراب می شود ، سوئیچ تمام ورودی های جدول جریان را که وابسته به پورت خراب هستند را حذف کرده و اطلاعات جدید موقعیت لینک ها را به کنترلر ارسال می کند . به این ترتیب کنترلر توپولوژی جدید را یاد می گیرد . وقتی بسته ای که مربوط به یک جریان حذف شده از سوئیچ است می رسد ، بسته ها به کنترلر ارسال می شوند ، دقیقا مشابه با یک جریان جدید ، کنترلر به محاسبه و نصب یک مسیر جدید بر اساس توپولوژی جدید می نماید .

۷-۳ : خود راه اندازی[۵۱]  :

هنگامی که شبکه راه اندازی می شود سوئیچ ها مجبور به اتصال و احراز هویت بوسیله کنترلر هستند . راه اندازی Ethane مشابه روش SANE است ، در هنگام راه اندازی شبکه به ایجاد یک درخت پوشا کمینه می پردازد و کنترلر به عنوان ریشه انتخاب می شود .

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

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

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

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

Pol-Eth  یک زبانی است که برای اعلام سیاست های یک شبکه Ethane استفاده می شود .در حالی که Ethane  برای یک زبان خاص اجباری ندارد ما به توصیف Pol-Eth با یک مثال می پردازیم . ما به پیاده سازی Pol-Eth پرداخته و از آن در شبکه نمونه استفاده می کنیم .

۱-۴ : مرور :

در Pol-Eth سیاست شبکه به اعلان مجموعه ای از قوانین است که هرکدام شامل یک سری شرایط و اقدامات[۵۲] مرتبط با آن شرایط می باشند . به عنوان مثال ، قانون خاصی که به کاربر Bob اجازه برقراری ارتباط با یک وب سرور را با استفاده از HTTP می دهد به شکل زیر است :

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

به عنوان مثال گزاره urc=”bob”  شامل همه جریان های می شود که در آن منبع باب است . دامنه های معتبر شامل usrc  ، udst ، hsrc ، hdst ، apsrc ، apdst و protocol می باشند که به ترتیب دلالت بر کاربر ، میزبان و Access Point و پروتکل جریان دارد .

در Pol-Eth ارزش گزاره ها ممکن است تنها شامل نام ها باشد (به عنوان مثال باب) و یا لیستی از نام ها باشد (باب و لیندا) و یا گروهی را شامل شوند (مانندیک ایستگاه کاری) . همه نام ها باید در کنترلر ثبت نام شوند و در فایل سیاست های گروه اعلام شوند .

اقدام [۵۳]. اقدامات شامل اجازه دادن[۵۴] ، انکار[۵۵] ، ایستگاه بین راه[۵۶] ، خارج از مرز[۵۷] (برای امنیت NAT ) می باشند . اعلام ایستگاه بین راه شامل لیستی از موجودیت ها می شود که به مسیریابی جریان از طریق ایستگاه های بین راهی می پردازند (مانند ids و webproxy) .

۲-۴ : قانون و اولویت اقدام :

قوانین Pol-Eth مستقل هستند و حاوی سفارشات نمی باشند بنابراین قوانین چندگانه با اقدامات ناسازگار ممکن است باعث رضایت یک جریان یکسان شود . برای حل این مشکل به اختصاص اولویت[۵۸]  به قوانین و اعلام آن می پردازیم . اگر یک قانون در فایل سیاست موجود باشد که باید همواره به  قوانین دیگر ارجحیت داشته باشد  برای آن اولویت بالاتری را در نظر می گیریم .

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

شکل ۴ : یک مثال از  فایل سیاست با استفاده از Pol-Eth

۳-۴ : نمونه ای از سیاست :

شکل۴ شامل سیاست های حاکم برای اتصال در طرح توسعه ای دانشگاه ما می باشد . فایل سیاست Pol-Eth شامل دو گروه از قوانین جدا از هم می باشد . در این سیاست ، هم جریان های که با قوانین مطابقت نمی کنند مجاز هستند (توسط آخرین قانون) . سرور اجازه برقراری ارتباط با بقیه شبکه را ندارد و باید حفاظت مشابه با DMZ های امروزی را فراهم آورد . تلفن ها و کامپیوترها هرگز نمی توانند ارتباط برقرار کنند . لپ تاپ ها از جریان های داخلی محافظت می شوند (شبیه به حفاظتی که در مورد NAT وجود دارد ) در حالی که ایستگاه های کاری می توانند با یکدیگر ارتباط برقرار کنند .

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

۴-۴ : پیاده سازی :

با توجه به چگونگی ایجاد جریان جدید و چگونگی تصمیمات سریع باید سیاست زبانی ساخته شود و این کار در عمل بدون تفسیر سیاست شبکه امکان پذیر نمی باشد . در عوض ، ما نیاز داریم تا آن را کامپایل کنیم . اما کامپایل Pol-Eth کار بیهوده ای است زیرا که فضای نام به صورت بالقوه در شبکه بزرگ است و ایجاد یک جدول مراجعه[۵۹] برای همه جریان ها در سیاست ها عملا غیر ممکن خواهد بود .

پیاده سازی Pol-Eth ما ترکیبی از گردآوری و هم زمانی در ایجاد توابع جستجو خواهد بود . هر قانون با اصولی که به آن اعمال می شود مرتبط است . این هزینه یکبار در زمان راه اندازی و یا ایجاد تغییرات در سیاست ها انجام می شود . اولین باری که یک فرستنده با یک گیرنده جدید ارتباط برقرار می کند یک تابع بررسی اجازه دسترسی سفارشی را به صورت پویا برای رسیدگی به همه جریان های بعدی بین جفت های منبع و مقصد ایجاد می کند . این تابع مجموعه ای از قوانینی است که برای اتصال به کار می رود . در بدترین حالت ، هزینه تولید تابع با تعدادی از قوانین به صورت خطی[۶۰] می باشد (با فرض هر قانون در مورد هر موجودیت منبع).  اگر همه قوانین شامل شرایطی باشد که در آن بشود استاتیک بودن را در زمان اتصال بررسی کرد (به عنوان مثال ، گزاره های که به تنهایی به تعریف کاربران ، میزبان ها و نقاط دسترسی بپردازند ) ، آن گاه تابع بدست آمده تنها شامل یک Action خواهد بود .در غیر این صورت ، هر درخواست جریان نیاز به اقداماتی برای تجمیع در زمان واقعی دارد .

هم چنین ما به پیاده سازی یک کامپایلر منبع به منبه پرداختیم که کدهای تولیدی C++ را در فایل سیاست Pol-Eth اجرا می کنند . در نتیجه این منبع کامپایل و ارتباط دودویی[۶۱] Ethane را بر عهده دارد . تغییرات سیاست ها در حال حاضر نیاز به ارتباط مجدد با کنترلر دارد . ما در حال ارتقاء سیاست های کامپایلر هستیم به گونه ای که تغییرات سیاست ها بتوانند پویایی بارگذاری را در زمان اجرا بوجود آورد .

ما یک شبکه Ethaneکاربردیرا ساخته و آن را در ۴ ماه گذشته در دانشگاه مستقر کرده ایم . در زمان نوشتن این مقاله Ethane به بیش از ۳۰۰ میزبا ثبت نام شده و چند صد کاربر متصل شده بود .

ما ۱۹ سوئچ را در سه نوع متفاوت مستقر کرده ایم :

نقاط دسترسی (AP) بی سیم Ethane و سوئیچ های اترنت Ethane در دو طعم مختلف ( یک Gigabit  در سخت افزار اختصاصی و یکی دیگر در حالت نرم افزاری ) .

ثبت نام میزبان ها که شامل لپ تاپ ها ، پرینترها و تلفن های VOIP و کامپیوترهای رومیزی ، ایستگاه های کاری و سرورها بودند انجام پذیرفته است . ما هم چنین یک سوئیچ راه دور [۶۲] را در یک مکان خصوصی مستقر کرده ایم . تونل های سوئیچ به کنترل از راه دور متصل اند که به مدیریت همه ارتباطات در شبکه خانگی می پردازند . کل شبکه توسط یک کنترلر که بر پایه PC [63] است مدیریت می شوند . در بخش زیر ، ما به توصیف نمونه Ethane و استقرار آن در بخش علوم کامپیوتری دانشگاه استنفورد خواهیم پرداخت و بدین ترتیب به بیان درس ها و نتایجی بر اساس این تجربه خواهیم پرداخت .

۱-۵ : سوئیچ ها :

ما سه سوئیچ Ethane مختلف ساخته ایم :

یک نقطه دسترسی (AP) بی سیم ۸۰۲٫۱۱g (برپایه یک کنترل دسترسی تجاری) ، یک سوئیچ اترنت ۴ پورتی سیمی Gigabit که بسته را به سرعت خط به جلو می برد ( بر پایه یک پلت فرم سوئیچ قابل برنامه ریزی NetFPGA ) و یک سوئیچ اترنت ۴ پورتی سیمی داخل لینوکس که بر روی یک PC رومیزی اجرا می شود ( در نرم افزار ، هر دو به عنوان یک محیط توسعه هستند و اجازه به کارگیری سریع و تکاملی را می دهند ) .

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

در جدول اصلی برای بسته های که باید به جلو (Forward) فرستاده شوند (در بخش ۲-۳ ببینید ) در حدود ۸۱۹۲ جریان ورودی وجود دارد وبا استفاده از یک جستجو به مطابقت دقیق همه سرآیندها می پردازیم . ما با استفاده از دو تابع درهم ساز[۶۴] (دو CRCs) احتمال برخورد را کاهش می دهیم و تنها یک جریان در هر جدول خواهیم داشت .

هم چنین ما به پیاده سازی یک جدول دوم[۶۵] با ۳۲k ورودی پرداختیم . ما این کار را انجام دادیم چرا که کنترلر ما دارای مکان مشخصی نیست و ما می خواهیم که اقداماتی که در جدول جریان در خارج از ناحیه می باشند را هم پیاده سازی کنیم .

هنگامی که یک جریان خروجی شروع می شود ، ما تمایل داریم که به راه اندازی مسیر بازگشت در همان زمان بپردازیم (زیرا کنترلر مکان ثابتی ندارد و نمی تواند به یاد آورد که جریان خروجی اجازه داشته است یا نه ).  متاسفانه زمانی که از پروکسی ARP استفاده می شود ما نمی توانیم از آدرس های MAC  جریان بسته ها در مسیر معکوس تا زمانی که بسته برسند ،  مطمئن باشیم .

بنابراین ، ما با استفاده از جدول دوم ، به نگهداری جریان ورودی برای مسیرهای برگشت می پردازیم ( با کلمات آدرس MAC ) و هم چنین برای بسته های Drop شده استفاده می شود .

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

نقاط دسترسی (AP) بی سیم Ethane . نقطه دسترسی ما بر روی یک ابزار روتر بی سیم WRTSL54GS اجرا می شود (۲۶۶MHZ MIPS, 32Mb RAM ) که به اجرای OpenWRT می پردازد .

مسیر داده و جدول جریان براساس خطوط ۵k از C++ هستند (۱٫۵k برای جدول جریان است ) . مدیریت سوئیچ محلی در یک نرم افزار نوشته شده است و به کنترلر می گوید که پشته TCP اصلی لینوکس در حال استفاده است . وقتی که هسته در حال اجرا است ، Ethaneاجرای مسیر را با سرعت ۲۳Mb/s انجام می دهد با پل زدن L2 و IP را با همان سرعت به لینوکس می فرستد .

سوئیچ اترنت ۴ پورتی گیگابیت Ethane .

راهحل سخت افزاری . این سوئیچ در NetFPGA نسخه ۲ با ۴ پورت Gigabit اترنت پیاده سازی شد . یک Xilinx Virtex-II FPGA با ۴Mb حافظه SRAM برای بافر بسته ها و جدول جریان وجود دارد . مسیر ارسال سخت افزاری شامل ۷k خط Verilog  می باشد . طول جریان ورودی ۴۰ بایت می باشد . سخت افزار ما می تواند بسته های با حداقل سایز را در یک خط دو طرفه با نرخ ۱Gb/s ارسال کند .

سوئیچ اترنت ۴ پورتی Ethane .

راه حل نرم افزاری . ما هم چنین یک سوئیچ PC رومیزی با قاعده را ساخته ایم (با CPU 1.6GHZ Celeron  و ۵۱۲ Mb DRAM )و یک کارت ۴ پورتی ترنت گیگا بیت بر روی آن قرار دارد .  مسیر ارسال و جدول حریان به صورت بازتابی در سخت افزار ما پیاده سازی می شوند (برای کمک به اشکال زدایی ) .

سوئیچ نرم افزاری ما در داخل هسته می تواند به انتقال بسته های با سایز MTU با ۱Gb/s بپردازد . با این حال ، سایز Drop بسته ها نمی تواند با درهم سازی و وقفه های سرریز در سوئیچ نگهداری شود . در ۱۰۰ بایت ، سوئیچ می تواند تنها به توان عملیاتی ۱۶ Mb/s دست یابد . واضح است در حال حاضر ، سوئیچ نیاز به اجرا در سخت افزار برای دست یابی به عملکرد بالا دارد .

۲-۵ : کنترلر :

ما کنترلر را روی یک PCلینوکس استاندارد اجرا کرده ایم ( CPU با ۱٫۶GHZ از نوع Celeron و DRAM 512 Mb) . کنترلر براساس ۴۵k خط C++ است (با یک ۴k خط اضافه شده برای ایجاد سیاست های کامپایلر ) و ۴٫۵k خط پایتون برای مدیریت رابط ها می باشد .

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

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

در واقع در این جا هر طرح احراز هویتی می تواند مورد استفاده قرار گیرد و هرکسی طرح خود را به اجرا بگذارد .

هم چنین سوئیچ های Ethane نیز به صورت اختیاری میزبان ها را بر اساس آدرس  MAC هایشان که با آن در کنترلر ثبت نام کرده اند احراز هویت می کنند .

وقایع روزانه اتصالات و رابط فضای نام . کنترلر ما به ثبت اتصالات در زمان اضافه یا حذف شدن آن ها می پردازد . حتی زمانی که ما تصمیم به کنترل نقاط اتصال اخیر در هر ورودی با استفاده از برچسب زمانی[۶۶] بگیریم این امکان وجود دارد .

ما از Brekeley DB برای تنظیم برچسب های زمانی در ورود به سیستم[۶۷] استفاده می کنیم . ما سرور DNS هایمان را برای پشتیبانی از پرس جوهای از نوع key.domin.type-time ارتقاء داده ایم که type می تواند میزبان ، کاربر ، MAC یا پورت باشد . پارامترهای اختیاری زمان اجازه می دهد تا تاریخچه پرس و جوهای مختلف در زمان حاضر نمایش داده شوند .

محاسبه مسیر . مسیرها ازقبل با استفاده از یک جفت الگوریتم کوتاه ترین مسیر محاسبه می شوند . توپولوژی در صورت شکست لینک مجددا محاسبه می شود . این محاسبه با بروز رسانی موقعیت لینک ها به صورت پویا انجام می پذیرد . حتی در توپولوژی های بزرگ ، هزینه به روزرسانی مسیرها در صورت شکست حداقل است . به عنوان مثال به طور متوسط ، هزینه بروزرسانی در یک توپولوژی با ۳۰۰۰ گره چیزی در حدود ۱۰ میلی ثانیه است .

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

۳-۵ : استقرار :

نمونه Ethane ما در داخل دپارتمانمان با یک شبکه اترنت ۱۰۰mb/s مستقر شده است . ما یازده سوئیچ سیمی Ethane و هشت سوئیچ بی سیم Ethane را نصب کرده ایم . در حال حاضر حدود ۳۰۰ میزبان در داخل این شبکه Ethane قرار دارد که به طور متوسط ۱۲۰ میزبان فعال در پنجره های ۵ دقیقه ای قرار دارد . ما یک سیاست شبکه ای برای تطبیق نزدیکتر  و در بسیاری از موارد کنترل اتصالات حاضر در محل ایجاد کرده ایم .

ما سیاست های موجود را با توجه به استفاده VLAN ها و پیکربندی فایروال میزبان ها و NAT ها و ACL روترها ایجاد نموده ایم . ما هم چنین متوجه شدیم که اغلب فایل های پیکربندی موجود شامل قوانینی هستند که مربوط به وضعیت فعلی شبکه نمی شوند ، در نتیجه این قوانین شامل سیاست های Ethane  نمی شدند .

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

گره های بی سیم با WPA و یک رمز عبور حفاظت می شوند و به احراز هویت کاربر هم نیازی ندارند . اما اگر آدرس MAC میزبانی ثبت نشده باشد (در شبکه ما بدین معنا است که آن ها مهمان هستند ) آنگاه تنها به تعداد کوچکی از سرویس ها دسترسی خواهد داشت .

(از قبیل :  HTTP , POP , IMAP , SMTP , DNS ,HTTPS,SSH ) .

نقاط دسترسی (AP) بی سیم ما نیاز کاربران را به احراز هویت از طریق سیستم University wide برآورده می کنند . تلفن های VOIP دارای محدودیت های بیشتری  به نسبت دستگاه های غیر از تلفن می باشند و نقاط  دسترسی آن برای جلوگیری از حرکت ثابت می باشند (برای انطباق محل E911 ) . فایل سیاست ما در این زمینه دارای ۱۳۲ خط طولانی است .

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

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

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

چه تعداد کنترلر برای اندازه معین شبکه نیاز است ؟ ما سپس به بررسی رفتار یک شبکه Ethane در کنار کنترلر و شکست لینک ها می پردازیم .

در نهایت برای کمک به تصمیم گیری عملی و هزینه سوئیچ ها برای شبکه های بزرگتر این سوال را در نظر می گیریم که :

به جدول جریان چه اندازه ای در یک سوئیچ نیاز است ؟

۱-۶ : مقیاس پذیری کنترلر :

به یاد دارید که نمونه Ethane ما در حدود ۳۰۰ میزبان با میانگین ۱۲۰ میزبان فعال در پنجره ۵ دقیقه ای را پشتیبانی می کند . از این میزبان ها ، ما ۳۰-۴۰ درخواست جریان جدید را در هر ثانیه می بینیم (شکل ۵) که در اوج خود به ۷۵۰ جریان در هر ثانیه می رسد .

شکل ۵ : فرکانس درخواست راه اندازی جریان در هر ثانیه که برای کنترلر در طی یک دوره ده ساعته (بالا) و مدت ۴ روز (پایین) ارسال می شود .

شکل ۶ نشان می دهد که چگونه کنترلر در زیر بار کار خود را انجام می دهد . تا ۱۱۰۰۰ جریان در هر ثانیه ، بیشتر از اوج بار ، ما مشاهده می کنیم که جریان کمتر از ۱٫۵ میلی ثانیه در بدترین حالت تنظیم شده و CPU یک بار قابل اغماض را نشان می دهد .

شکل ۶ : زمان راه اندازی جریان به عنوان تابعی از بار کنترلر . اندازه بسته ۱۲B, 64B,256B به طور مساوی توزیع شده است .

نتایج ما نشان می دهد که یک کنترلر می تواند به راحتی ۱۰۰۰۰ در خواست جریان جدید را در هر ثانیه رسیدگی کند . ما درخواست افزایش این تعداد را داریم ، و اگر به طراحی بهینه متمرکز شویم می توانیم به آن برسیم .

با استفاده ذهنی از این موضوع ، این سوال ارزش پرسدن دارد که چه تعداد از میزبان های پایانی مربوط به چنین بارگذاری می شوند ؟

ما دومجموعه داده [۶۸] تازه را در نظر گرفته ایم : یکی با شبکه ای که ۸۰۰۰ هاست در LBL دارد و یکی دیگر شبکه ای با ۲۲۰۰۰ هاست در دانشگاه استنفورد می باشد .تعداد حداکثر جریان برجسته در LBL هرگز از ۱۲۰۰ جریان در ثانیه در تمام گره ها بیشتر نمی شود (شکل ۷) .

شکل ۷ : جریان های فعال برای LBL

مجموعه داده استنفورد حداکثر ۹۰۰۰ در خواست جریان جدید در ثانیه را شامل می شود (شکل۸ )

شکل ۸ : نرخ درخواست جریان برای شبکه استنفورد

شاید شگفت آور باشد ولی نتایج ما نشان می دهد که کنترلر تکی می تواند به راحتی یک شبکه با بیش از ۲۰۰۰۰ میزبان را مدیریت کند . در واقع تاخیر راه اندازی جریان برای ادامه بار تا ۶۰۰۰/s  کمتر است . ۶ میلی ثانیه ، معادل متوسط زمان تاخیر برای یک درخواست DNS در داخل شبکه استنفورد است . تاخیر راه اندازی جریان برای بارگذاری درخواست های زیر ۲۰۰۰ تا در یک ثانیه برابر ۴ میلی ثانیه است ، این تقریبا معادل با میانگین RTT بین میزبان ها در زیر شبکه های مختلف در یک شبکه دانشگاهی است .

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

۲-۶ : عملکرد در شکست ها :

از آن جا که کنترلر ما برای بازیابی در شکست ها به صورت cold-standby طراحی شده است (بخش ۵-۳ را ببینید ) ، شکست یک کنترلر منجر به قطع خدمات برای جریان های فعال و تاخیر می شود چرا که جریان باید دوباره ایجاد شده و ارسال شود .

درک این که چه مدت نصب مجدد و راه اندازی یک جریان طول می کشد خیلی مهم است . اتمام ۲۷۵ درخواست HTTP متوالی و بازیابی آن ها در مجموع ۶۳Mb خواهد بود . این در حالی بود که وقتی در خواست ها در حال انجام بود کنترلر ما سقوط [۶۹]کرد و مجبور شدیم آن را برای چندین بار راه اندازی مجدد کنیم .

جدول ۱ نشان می دهد که به وضوح یک جریمه برای هر شکست وجود دارد که چیزی در حدود ۱۰% زمان کلی را افزایش می دهد .

جدول ۱ : زمان اتمام ۲۷۵ فایل HTTP که کنترلر با شکست اولیه مواجه می شود . نتایج میانگین بیش از ۵ بار هستند .

این مشکل را می توان تا حد زیادی از بین برد ، البته در یک شبکه که از warm-standby استفاده کند کنترلر سریعتر می تواند شکستها را پوشش دهد (بخش ۵-۳ را ببینید ) .

در شکست لینک ها در Ethane نیاز است که همه جریان های برجسته دوباره با کنترلر به منظور برقراری مجدد مسیر تماس برقرار کنند . اگر لینک به شدت مورد استفاده قرار گیرد ، کنترلر در خواست Storm را دریافت کرده و متوجه می شود که عملکرد به زودی کاهش خواهد یافت .

ما به ایجاد یک توپولوژی با مسیرهای دارای افزونگی می پردازیم بنابراین شبکه می تواند در مقابل شکست لینک ها مقاومت کرده و زمان تاخیر تجربه شده توسط بسته ها اندازه گیری شود . شکست ها بوسیله یک لینک فیزیکی شبیه سازی شدند . نتایج ما در شکل ۱۰ نشان داده شده است .

شکل ۹ : جریان های فعال از طریق دو سوئیچ مستقر شده

شکل ۱۰ : زمان تاخیر رفت و برگشت توسط بسته از طریق توپولوژی در طول شکست پیوند

در تمام موارد ، مسیرها در کمتر از ۴۰ میلی ثانیه تبدیل می شوند اما یک بسته می تواند تا یک ثانیه تاخیر کند در حالی که کنترلر با سراسیمگی در حال رسیدگی به درخواست ها است . سیاست شبکه ما اجازه می دهد تا چندین مسیر مجزا زمانی که جریان شروع شد توسط کنترلر راه اندازی شوند . به این ترتیب ، همگرایی در طول شکست سریع تر می تواند رخ دهد به خصوص اگر سوئیچ ها شکست را شناسایی کنند می توان به پشتیبان گیری[۷۰] از جریان ورودی بپردازند .

ما این کار را در این نمونه پیاده سازی نمی کنیم اما در حال برنامه ریزی برای انجام این کار در آینده هستیم .

۳-۶ : اندازه گیری  جدول جریان :

در نهایت ما در مورد مقدار بزرگ شدن جدول جریان در سوئیچ ها صحبت می کنیم . در حالت ایده آل ، سوئیچ می تواند تمامی جریان های فعال اخیر را نگهداری کند . شکل ۹ نشان می دهد که چه تعداد جریان فعال در استقرار   Ethane ما دیده می شود . در این شکل هرگز بیش از ۵۰۰ جریان وجود ندارد . با یک جدول ۸۱۹۲ ورودی و دو تابع جدول درهم ساز[۷۱] ما هرکز با برخورد [۷۲]مواجه نمی شویم .

همان طور که قبلا در شکل ۷ توصیف شد ، هرگز شبکه LBL با بیش از ۱۲۰۰ جریان در ۸۰۰۰ میزبان شبکه خود مواجه نشد . در عمل ، تعداد جریان مداوم بستگی به این دارد که سوئیچ در کجای شبکه مستقر است . هرچه سوئیچ ها به لبه ها نزدیکتر باشند تعداد جریان های بیشتری متناسب با تعداد میزبان های متصل را دریافت خواهند کرد .(مثلا گنجایش خروجی خود ) سوئیچ های ما دارای گنجایش خروجی ۴ بوده و بیش از ۵ جریان وجود دارد . ( باید توجه داشت که این یک برآورد بسیار محافظه کارانه با توجه به تعداد کم جریان ها در شبکه LBL می باشد ) .

یک سوئیچ در مرکز یک شبکه به احتمال زیاد جریان های فعال تری را خواهد دید و بنابراین فرض ما این است که همه جریان های فعال را ببیند . هم چنین حافظه مورد نیاز برای یک سوئیچ Ethane در مقایسه با سوئیچ های اترنت امروزی کاملا مناسب است .

برای بررسی بیشتر  مقیاس پذیری کنترلر ، ما عملکرد آن ها را با ورودی شبیه سازی شده در نرم افزار شناسایی سربار آزمایش کردیم . کنترلر با یک فایل سیاست ۵۰  قانونی طراحی شده ااست و ۱۰۰ فرد ثبت نام شده وجود داشتند  و مسیرها مجدد محاسبه و ذخیره شدند . تحت این شرایط این سیستم می تواند ۶۵۰۸۴۵ رخداد اتصال در هر ثانیه ایجاد کرده و اجازه ۱۶۹۷۲۶۰۰ اتصال را در هر ثانیه بدهد .

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

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

Broadcast و کشف سرویس ها . پروتکل های اکتشافی Broadcast ( از قبیل : ARP  ، OSPF ، شناسایی همسایه و .. ) که در شبکه های شرکتی که حجم عظیمی از ترافیک سربار را دارند با مشکل مواجه می شوند . در شبکه  ما ، این ترافیک ها بیش از ۹۰% جریان را تشکیل می دهند . یکی از بزرگترین دلایلی که VLAN ها در شبکه های شرکتی بزرگ حضور دارند کنترل Broadcast ترافیک (از نوع طوفانی یا همان Storm ) می باشد . میزبان اغلب پیام Broadcast  را به شبکه می فرستد و تلاش می کند تا آدرس ها ، همسایه ها یا سرویس ها را بیابند .

Ethane می تواند پروتکل را تفسیر کرده و پاسخ طرف مقابل را بدهد ، Ethane به Broadcast برای پاسخ به همه درخواست ها نیاز دارد ، و خود این موضوع شامل ایجاد تعداد زیادی جریان ورودی می شود که منجر به ترافیک زیادی خواهد شد و اگر یک بدخواه[۷۳] به همه میزبان های پایانی دسترسی داشته باشد شبکه دچار مشکل خواهد شد .

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

مسیریابی لایه کاربرد .  یک محدودیت در Ethane هست که اعتماد به میزبان پایانی باعث تقویت ترافیک و تخلف از سیاست شبکه می شود . اتصالات کنترلی Ethane با استفاده از اترنت و آدرس IP نقاط پایانی می باشد اما سیاست Ethane می تواند با این ارتباطات در یک لایه بالاتر به خطر بیفتد .

به عنوان مثال اگر A مجاز به صحبت با B باشد ولی با C نباشد و اگر B بتواند با C صحبت کند سپس B می تواند به بازپخش پیام A برای C بپردازد . این کار می تواند در لایه ای بالاتر از IP رخ دهد . به عنوان نمونه یک برنامه P2P که باعث ایجاد پوشش در لایه کاربرد می شود و یا مشتریان خانگی که به چندین شبکه متصل می شوند می توانند این نقش را به انجام رسانند . این یک مشکل پیچیده است و به احتمال زیاد نیاز به یک تغییر در سیستم عامل و هر ماشین مجازی در حال اجرا بر روی میزبان دارد .

اطلاع از کار انجام شده برای کاربران . سیاست Ethane فرض می کند که شماره پورت انتقال نشان دهنده کار انجام شده توسط کاربر است . از قبیل پورت ۸۰ HTTP ، پورت ۲۵ SMTP و به همین ترتیب .

یک کاربر مخرب (بدخواه) می تواندتبانی کند و یا برنامه های کاربردی می توانند با فریب Ethane به استفاده از شماره پورت های غیر استاندارد بپردازند و می توانند از برنامه های کاربردی مشترکی که خوب به نظر می رسند و دارای بیش از یک پورت هستند (از قبیل پورت ۸۰) استفاده کرده و به فایروال باز دسترسی یابند .

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

اختلال در آدرس اترنت . سوئیچ های Ethane در اتصالات بین یک کاربر و آدرس اترنت فقط به شناسایی جریان اعتماد می کنند . اگر یک کاربر به جعل [۷۴] یک آدرس MAC اقدام کند ممکن است Ethane فریب خورده و اقدام به انتقال بسته ها به میزبان پایانی نماید . راه حل این مشکل بسیار ساده است ، در یک شبکه Ethane که تنها هر پورت سوئیچ به یک میزبان متصل است و سوئیچ می تواند بسته های را که آدرس MAC آن ها اشتباه است را drop کند .

اگر دو یا چند میزبان پایانی به یک پورت سوئیچ مشابه متصل باشند ممکن است یک نفر خود را به جای دیگری جابزند (Masquerade) . یک راه حل ساده این است که جلوی آن ها را از طریق فیزیکی بگیریم . یک راه حل عملی تر در شبکه های بزرگتر استفاده از ۸۰۲٫۱X در رابطه با مکانیزم های رمزنگاری در سطح لینک از قبیل ۸۰۲٫۱AE می باشد که به تصدیق امن بسته ها و آدرس های می پردازد .

Ethane شامل فلسفه ۴D و ساده سازی Data plane و تمرکز Control plane برای به اجرا درآوردن اهداف شبکه می باشد . Ethane از ۴D منشعب شده (البته با آن متفاوت است) که در پشتیبانی از سیاست مدیریت سیستم به خوبی پشتیبانی می شود .

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

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

در فایروال ها ی توزیع شده ، سیاست مرکزی در یک توپولوژی مستقل برای هر هاست نهایی اجرا می شود . علاوه بر این حسابرسی و مدیریت پشتیبانی متفاوت Ethane به دو روش اصلی انجام می شود :

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

دوم : بسیاری از قدرت Ethane بوسیله تضمین سطح شبکه فراهم می آید مانند سیاست ایستگاه های بین راه . باید توجه داشت که تنها از طریق یک میزبان  پایانی امکان فیلتر وجود ندارد .

سیاست های زبانی Ethane (Pol-Eth) با الهام از گزاره های به مسیریابی می پردازد . این گزاره های عمومی مسیریابی و فیلتر را به صورت یکپارچه اجرا می کنند و مجموعه ای از این گزاره ها اتصالات را توصیف می کنند . با گسترش مدل Pol-Eth می توان برای کاربران به ساخت کلاس ها و اشیاء اقدام کرد و گزاره های سطح بالا از گروه ها پشتیبانی خواهند کرد و محدودیت های در اتصالات را فراهم می آورند .

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

تعدادی هویت مبتنی بر شبکه (IBN)[75] سفارشی در سوئیچ ها وجود دارد مانند سرورهای امن AAA که به سیاست های سطح بالا اجازه تعریف می دهند اما به طور کلی اشاره ای به راه حل ها کنترلی بر روی مسیر داده در شبکه نمی کنند . تعدادی از آن ها به میزبان های پایانی برای اجرای قانون ها تکیه می کنند که باعث ایجاد خطر برای آن ها می شود .

یکی از پیامد های متفاوت این مقاله ساخت اولین نمونه می باشد که باعث می شود درس های متفاوت زیادی را به ما یاد دهد و معمولا به مقدار زیادی نتایج حاصله بیش از انتظار ما بود . Ethane نشان داد که دارای خواص خوب و بد زیادی است .

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

توسط ثبت های روزانه همه ثبت نام ها و اتصالات و مشکلات شبکه قابل شناسایی بودند و این برای مدیران شبکه نشانه خوبی است که می توانند ترافیک شبکه و نظارت شبکه را در کنار هم و به صورت متمرکز به راحتی در اختیار داشته باشند .

ما هم چنین راه هایی را برای اضافه کردن ویژگی های جدید به شبکه پیدا کرده ایم ، از جمله با گسترش سیاست زبانی ، اضافه کردن الگوریتم های مسیریابی جدید (مانند حمایت از مسیرهای زائد یا همان اضافه ) ، معرفی نرم افزارهای پروکسی جدید به ایستگاه ببن راهی .

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

ما مطمئن هستیم که کنترلرها می توانند از مقیاس پذیری در شبکه های بزرگ پشتیبانی کنند . نتایج ما نشان می دهد که یک کنترلر تکی می تواند ۱۰۰۰۰ ماشین را به خوبی مدیریت کند . در عمل ما انتظار داریم که کنترلرها امکان تکرار و کپی موقعیت های مکانی و توپولوژی ها را بر روی شبکه داشته باشند و در عین حال Ethane محدودیتی برای مدیر شبکه ایجاد نمی کند .

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

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

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

ما پیش بینی می کنیم که نو آوری در سوئیچ ها بیش از انتظار خواهد بود . برای مثال ، در حالی که سوئیچ ها یک صف FIFO  را حفظ می کنند می توانند به ایجاد صف های چندگانه[۷۶] بپردازند که کنترلر در آن تصمیم گیرنده و تععین کننده صف فعال جریان ها خواهد بود . این امر منجر به بسیاری از امکانات خواهد شد از جمله : هر کلاس یا جریان در صف ها می تواند اولویت بندی شود و بدین شکل می توان یک ترافیک خاص را منزوی کرد و به کنترل نرخ خط پرداخت .

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

تشکر و قدردانی

منابع و مراجع

مترجم : معاونی

www.moaveni.ir

Email:moaveni1@gmail.com

Tel: 0933 829 38 95

[۱] Multi – Vendor

[۲] Elements

[۳] IDS

[۴] Real time

[۵] Fork Lift

[۶] omniscient

[۷] Simple & Dumb

[۸] Actions

[۹] Allow

[۱۰] Deny

[۱۱] Route via away point

[۱۲] registration

[۱۳] Bootstrapping

[۱۴] Authentication

[۱۵] Flow Setup

[۱۶] Deny

[۱۷] Forwarding

[۱۸] Access Point

[۱۹] Broad Cast

[۲۰] Action

[۲۱] Badly behaved flow

[۲۲] Hash

[۲۳] Swapping

[۲۴] optimization

[۲۵] remote

[۲۶] periodically

[۲۷] Brain

[۲۸] Authentication Component

[۲۹] Policy File

[۳۰] Lookup Table

[۳۱] Switch manager

[۳۲] registration

[۳۳] Authentication

[۳۴] Kerberos

[۳۵] Client – side

[۳۶] Tracking Binding

[۳۷] Join & Leave

[۳۸] Revoke

[۳۹] Name Space Interface

[۴۰] Time Stamp

[۴۱] Permission Check and access granting

[۴۲] Enforcing Resource Limits

[۴۳] Spoof

[۴۴] Available & Scalable

[۴۵] Cold – Standby

[۴۶] Warm – Standby

[۴۷] Actions

[۴۸] Atomic

[۴۹] Fully – replicate

[۵۰] Down

[۵۱] Bootstrap

[۵۲] Actions

[۵۳] Action

[۵۴] allow

[۵۵] deny

[۵۶] waypoint

[۵۷] Out bound only

[۵۸] priority

[۵۹] Lookup Table

[۶۰] Linearly

[۶۱] Binary

[۶۲] Remote Switch

[۶۳] PC -based

[۶۴] Hash

[۶۵] Second table

[۶۶] Time Stamp

[۶۷] Log

[۶۸] dataset

[۶۹] Crash

[۷۰] Back up

[۷۱] Hash – table

[۷۲] collision

[۷۳] Malicious

[۷۴] Spoof

[۷۵] Identity Based Network

[۷۶] Multiple Queues

your ad here

نظری بدهید