دانلود رایگان مقاله تعادل بار و مدیریت مهلت صف در یک سوئیچ OpenFlow SDN

چکیده

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

1. مقدمه

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

          معماری SDN هر دو از دستگاه های فعال SDN (سوئیچ ها / روتر ها) 1 و از یک کنترلر مرکزی (کنترل کننده SDN) تشکیل شده است. یک دستگاه SDN پردازش و ارائه بسته ها را با توجه به قوانین ذخیره شده در جدول جریان خود (حالت روبه جلو)، در حالی که کنترل کننده SDN وضعیت رو به جلو هر دستگاه SDN با استفاده از یک پروتکل استاندارد به نام OpenFlow (OF) [2] را تنظیم می کند. کنترل کننده SDN همچنین مسئول ساخت توپولوژی مجازی نشان دهنده توپولوژی فیزیکی است. توپولوژی مجازی توسط ماژول های نرم افزاری که در سطح بالای کنترل کننده SDN اجرا می شود برای اجرای منطق های مختلف کنترل و توابع شبکه (مانند مسیریابی، ترافیک، اقدامات فایروال) استفاده می شود.

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

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

         یک راه حل ممکن برای کاهش تضعیف عملکرد، شامل مسیریابی مجدد جریانهایی است که نقض محدودیتهای زمانی (مثلا جریانهایی که به طور کامل از محدودیت زمان ثابت دریافت شده است) [4] در مسیرهای کمتر یا صفهای کمتری دریافت میکنند. ایده اصلی این است که، چون ما نمی توانیم نرخ سرویس صف ها را تغییر دهیم، ما بر ترافیک ورودی عمل می کنیم، در صورت نیاز به یک زیر مجموعه از جریان ها در مسیرهای مختلف یا صف ها حرکت می کنیم. به منظور سازگاری 100٪ با سخت افزار فعلی OF، ما هیچ تغییری در مشخصات و دستورالعمل های OF اعمال نمی کنیم. در عوض ما پیشنهاد می کنیم یک کنترل کننده محبوب SDN را تغییر دهیم: Beacon [5]. راه حل پیشنهادی، BeaQoS، به یک سوئیچ تک SDN اعمال شده است، گسترش کار قبلی ما است که در [6] ارائه شده است. کنترلر جدید به روز شده ما آمار مربوط به صف ها، جریان ها و پورت های سوئیچ های OF را دریافت می کند و تخمین سرعت جریان و از دست دادن بسته صف ها را محاسبه می کند. بر اساس سیاست های قابل تنظیم، BeaQoS قادر خواهد بود زیر مجموعه ای از جریان هایی را که از صف مشکل دار عبور می کنند را انتخاب کند و آنها را دوباره به صف دیگر و با پیچیدگی کمتر هدایت کند، بنابراین عملکرد سوئیچ هابهبود می یابد. عمل جابجایی مسیر جریان ممکن است نه تنها برای مدیریت زمان پایان، بلکه همچنین برای بارگیری یکنواخت کارآمد صف، مورد بهره برداری قرار گیرد. از سوی دیگر، تعادل بار، اغلب به عنوان یک اقدام برای جلوگیری از پیچیدگی و به تبع آن، محدود کردن و به تأخیر افتادن عملکرد به حساب می آید.

         باقی مانده از این مقاله به شرح زیر است. ما بخش های مربوط به این زمینه را در بخش 2 شرح دهیم. با توجه به سهم اصلی این مقاله:

– ما انگیزه هایی را بیان می کنیم که منجر به بررسی رابط های چند صف با نرخ سرویس متغیر برای پشتیبانی مدیریت زمان پایان در بخش 3 می شود.

– ما ایده اولیه ای را درباره مکانیزم های مسیریابی مجدد معرفی شده در این مقاله در بخش 4.1 توضیح می دهیم، جایی که ما همچنین نشان می دهیم چگونه می توان آن را در مورد معماری های چند هسته ای و مسائل متعادل کننده بار در میان صف ها مورد استفاده قرار داد؛

– ما تغییرات کنترل کننده Beacon مورد نیاز برای پیاده سازی دوباره مسیر در بخش 4.2 را شرح می دهیم.

- ما پنج راهکار مسیریابی مجدد در BeaQoS پیشنهاد می دهیم: دو مورد از آنها برای بهبود مدیریت زمان پایان پیشنهاد شده است و سه مورد از آنها با هدف تعادل بار در میان صف در یک سوئیچ SDN در بخش 5 انجام شده است.

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

Abstract

           Current OpenFlow specification is unable to set the service rate of the queues inside OpenFlow devices. This lack does not allow to apply most algorithms for the satisfaction of Quality of Service requirements to new and established flows. In this paper we propose an alternative solution implemented through some modifications of Beacon, one popular SDN controller. It acts as follows: using ‘almost’-real-time statistics from OpenFlow devices, Beacon will re-route flows on different queues to guarantee the observance of deadline requirements (e.g. the flow is still useful if, and only if, is completely received by a given time) and/or an efficient queue balancing in an OpenFlow SDN switch. Differently from the literature, we do not propose any new primitive or modification of the OpenFlow standard: our mechanism, implemented in the controller, works with regular OpenFlow devices. Our changes in the SDN controller will be the base for the design of a class of new re-routing algorithms able to guarantee deadline constraints and queue balancing without any modification of the OpenFlow specification, as well as, of OpenFlow devices.

1. Introduction

           Software Defined Networking (SDN) is revolutionizing the networking industry by enabling programmability, easier management and faster innovation [1,2]. These benefits are made possible by its centralized control plane architecture which allows the network to be programmed and controlled by one central entity.

           The SDN architecture is composed both of SDN enabled devices (switches/routers)1 and of a central controller (SDN controller). An SDN device processes and delivers packets according to the rules stored in its flow table (forwarding state), whereas the SDN controller configures the forwarding state of each SDN device by using a standard protocol called OpenFlow (OF) [2]. The SDN controller is responsible also to build the virtual topology representing the physical topology. The virtual topology is used by the application modules that run on top of the SDN controller to implement different control logics and network functions (e.g. routing, traffic engineering, firewall actions).

          Currently the Quality of Service (QoS) management in OF is quite limited: in each OF switch one or more queues can be configured for each outgoing interface and used to map flow entries on them. Flow entries mapped to a specific queue will be treated according to the queue’s configuration in terms of service rate, but the queue’s configuration takes place outside the OF protocol. For example, the queue’s service rate cannot be modified by OF.

          Supposing that a flow is traversing a chain of queues from the source to the destination node, and that the flow data rate increases, a possible consequence is that queues increase their occupancy, and a bottleneck may be generated with consequent network congestion. The impossibility to change the bottleneck queue’s service rate through real-time OF directives can lead to a severe performance degradation for the flows traversing that queue because, without a proper rate assignment, it is very difficult to guarantee Quality of Service requirements to the flows [3].

          A possible solution to mitigate the performance degradation involves the re-routing of the flows experiencing a violation of deadline constraints (e.g. the flows that are totally received beyond the fixed time constraint) [4] on less congested paths or queues. The underlying idea is that, since we cannot change the service rate of the queues, we act on the ingress traffic, moving a subset of flows on different paths or queues in case of need. In order to be 100% compatible with current OF hardware, we impose no changes to OF specifications and directives. Instead we propose to modify one popular SDN controller: Beacon [5]. The proposed solution, BeaQoS, applied to a single SDN switch, is an extension of our previous work presented in [6]. Our new updated controller will receive statistics about queues, flows and ports from OF switches and will compute an estimation of the flow rates and of the packet loss of the queues. Based on customizable policies, BeaQoS will be able to select a subset of flows experiencing congestion over the bottleneck queue and to re-route them on another and less congested queue, so improving the switch performances. The action of flow re-routing may be exploited not only for deadline management but also for efficient queue load balancing. On the other hand load balancing is often seen as an action to prevent congestion and, consequentially, to limit and delay performance detriment.

         The remainder of this paper is structured as follows. We describe related works on this field in Section 2. Concerning the main contributions of the paper:

– We explain the motivations that lead to consider multi-queue interfaces with variable service rate to support deadline management in Section 3;

– We describe the basic idea concerning the re-routing mechanisms introduced in this paper in Section 4.1, where we also show how it can be usefully applied in case of multi-core architectures and load balancing issues among queues;

– We describe the modifications of the Beacon controller required to implement re-routing in Section 4.2;

– We propose five effective re-routing strategies in BeaQoS: two of them aimed at improving deadline management and three of them aimed at balancing the load among queues in a SDN switch in Section 5.

         We show the performance analysis of our proposed algorithms in Section 5. We report a discussion about the obtained results together with the conclusions in Section 7.

چکیده

1. مقدمه

2. کارهای مربوطه

3. انگیزه

4. راه حل های ممکن و اصلاح Beacon مورد نیاز

4.1. ایده کلی

4.2. پیاده‌سازی BeaQos

5. تحلیل راهبردهای مسیریابی

5.1. سناریوی مدیریت مأموریت

5.2. سناروی متعادل سازی صف

6. ملاحظات

6.1. افزایش کارایی

6.2. هماهنگی سوئیچ

6.3. عملکرد زمان بندی و سربار در سناریوی متعادل کردن صف

7. نتیجه گیری

منابع

ABSTRACT

1. Introduction

2. Related works

3. Motivations

4. Possible solutions and required Beacon modification

4.1. General idea

4.2. Implementation: BeaQoS

5. Re-routing strategies analysis

5.1. Deadline management scenario

5.2. Queue balancing scenario

6. Considerations

6.1. Scaling performances

6.2. Switch coordination

6.3. Timing performances and overheads in queue balancing scenario

7. Conclusions

References