Resource Management in Multimedia Networks Using Software-Defined Network Technology
Subject Areas : electrical and computer engineering
1 -
Keywords: SIP overload, mathematical modeling, multimedia network, routing problem, software-defined network technology,
Abstract :
Nowadays, multimedia networks on the Internet have become a low-cost and efficient alternative to PSTN. Multimedia transfer applications on the Internet are becoming more and more popular. This connection consists of two phases: signaling and media. The signaling phase is performed by SIP proxies and the media phase by network switches. One of the most important challenges in multimedia networks is the overload of SIP proxies and network switches in the signaling and media phases. The existence of this challenge causes a wide range of network users to face a sharp decline in the quality of service. In this article, we model the routing problem in multimedia networks to deal with the overload. In this regard, we present a technology-based method of software-based networks and a mathematical programming model in multimedia networks. The proposed method is simulated under various scenarios and topologies. The results investigate that the throughput and resource consumption has improved.
[1] J. Rosenberg, et al., SIP: Session Initiation Protocol, IETF RFC 3261, Jun. 2002.
[2] J. Rosenberg, et al., Requirements for Management of Overload in the Session Initiation Protocol, RFC5390, Dec. 2008.
[3] E. M. Nahum, J. Tracey, and C. P. Wright, "Evaluating SIP server performance," ACM SIGMETRICS Performance Evaluation Review, vol. 35, no. 1, pp. 349-350, Jun. 2007.
[4] M. Ohta, "Performance comparisons of transport protocols for session initiation protocol signaling," in Proc. 4th Int. Telecommunication Networking Workshop on QoS in Multiservice IP Networks, pp. 148-153, Venezia, Italy, 13-15 Feb. 2008.
[5] E. Noel and C. Johnson, "Initial simulation results that analyze SIP based VoIP networks under overload," in Proc. 20th int. Teletraffic Conf. on Managing traffic performance in converged networks, pp. 54-64, Ottawa, Canada, 17-21 Jun. 2007.
[6] M. Ohta, "Simulation study of SIP signaling in an overload condition," in Proc. Communication Internet, and Information Technology, pp. 321-326, Cote d'Azur, France, 26-29 Aug. 2004.
[7] V. K. Gurbani and R. Jain, "Transport protocol considerations for session initiation protocol networks," Bell Labs Technical J., vol. 9, no. 1, pp. 83-97, 2004.
[8] V. Pascual, SIP Server Overload Problem Statement, http://siprouter.org/wiki/_media/tbd/overload_control_problem_statement_vpascualv10.pdf, 2009.
[9] V. Hilt and I. Widjaja, "Controlling overload in networks of SIP servers," in Proc. IEEE Int. Conf. on at the Network Protocols, pp. 83-93, Orlando, FL, USA, 19-22 Oct. 2008.
[10] P. McGregor, R. Kaczmarek, V. Mosley, D. Dease, and P. Adams, "National security/emergency preparedness and the next-generation network," IEEE Communications Magazine, vol. 44, no. 5, pp. 133-143, May 2006.
[11] V. Hilt, Design Considerations for Session Initiation Protocal (SIP) Overload Control, RFC6357, Aug. 2011.
[12] I. Widjaja, V. Hilt, and H. Schulzrinne, Session Initiation Protocol (SIP) Overload Control, IETF, http://tools.ietf.org/html/draft-hilt-sipping-overload-02, 2008
[13] C. Shen and H. Schulzrinne, "On TCP-based SIP server overload control," in Proc. The Principles, Systems and Applications of IP Telecommunications, pp. 71-83, Munich Germany, 2-4 Aug. 2010.
[14] H. Schulzrinne, S. Narayanan, J. Lennox, and M. Doyle, SIP Stone-Benchmarking SIP Server Performance, Columbia University, 2002.
[15] H. Lindholm, T. Vahakangas, and K. Raatikainen, "A control plane benchmark for telecommunications signalling applications," Sort, vol. 20, no. 5, pp. 100-125, May 2007.
[16] M. Cortes, J. R. Ensor, and J. O. Esteban, "On SIP performance," Bell Labs Technical J., vol. 9, no. 3, pp. 155-172, Nov. 2004.
[17] S. Wanke, M. Scharf, S. Kiesel, and S. Wahl, "Measurement of the SIP parsing performance in the SIP express router," in Proc. 13th open European Summer School and IFIP TC6.6 Conf. on Dependable and Adaptable Networks and Services, pp. 103-110, Enschede, The Netherlands, 18-20 Jul. 2007.
[18] S. S. Gokhale and J. Lu, "Signaling performance of SIP based VoIP: a measurement-based approach," in Proc. IEEE Global Telecommunications Conf., pp. 761-765, St. Louis, MO, USA, 28-Nov.-3 Dec. 2005.
[19] C. Chi, D. Wang, R. Hao, and W. Zhou, "Performance evaluation of SIP servers," in Proc. 3rd Int. Conf. on the Communications and Networking in China, pp. 674-679, Hangzhou, China, 25-27 Aug. 2008.
[20] D. Pesch, M. I. Pous, and G. Foster, "Performance evaluation of SIP-based multimedia services in UMTS," Computer Networks, vol. 49, no. 3, pp. 385-403, Oct. 2005.
[21] M. Homayouni, et al., "Configuration of a sip signaling network: an experimental analysis," in Proc. 5th Int. Joint Conf. on INC, IMS and IDC, pp. 76-81, Seoul, South Korea, 25-27 Aug. 2009.
[22] K. K. Ram, I. C. Fedeli, A. L. Cox, and S. Rixner, "Explaining the impact of network transport protocols on SIP proxy performance," in Proc. IEEE Int. Symp. on the Performance Analysis of Systems and Software, pp. 75-84, Austin, TX, USA, 20-22 Apr. 2008.
[23] X. Wenfeng, et al., "A survey on software-defined networking," IEEE Communications Surveys & Tutorials, vol. 17, no. 1, pp. 27-51, Firstquarter 2015.
[24] A. R. Montazerolghaem, S. K. Shekofteh, M. H. Yaghmaee, and M. Naghibzadeh, "A load scheduler for SIP proxy servers: design, implementation and evaluation of a history weighted window approach," International J. of Communication Systems, vol. 30, no. 3, Article ID: e2980, May 2015.
[25] J. Hongbo, et al., "Design, implementation, and performance of a load balancer for SIP server clusters," IEEE/ACM Trans. on Networking, vol. 20, no. 4, pp. 1190-1202, Aug. 2012.
[26] K. Singh and H. Schulzrinne, "Failover, load sharing and server architecture in SIP telephony," Computer Communications, vol. 30, no. 5, pp. 927-942, Mar. 2007.
[27] W. M. Wu, K. Wang, R. H. Jan, and C. Y. Huang, "A fast failure detection and failover scheme for SIP high availability networks," in Proc. 13th Pacific Rim Int. Symp. on the Dependable Computing, pp. 187-190, Melbourne, Australia, 17-19 Dec. 2007.
[28] Y. J. Cheng, K. Wang, R. H. Jan, C. Chen, and C. Y. Huang, "Efficient failover and load balancing for dependable SIP proxy servers," in Proc. IEEE Symp. on the Computers and Communications, pp. 1530-1346, Marrakech, 6-9 Jul. 2008.
[29] G. Kambourakis, D. Geneiatakis, T. Dagiuklas, C. Lambrinoudakis, and S. Gritzalis, "Towards effective SIP load balancing," in Proc. 3rd VoIP Security Workshop, 6 pp., Berlin, Germany, 15-17 Jun. 2006.
[30] S. Montagna and M. Pignolo, "Performance evaluation of load control techniques in sip signaling servers," in Proc. 3rd Int. Conf. on the Systems, pp. 51-56, Cancun, Mexico, 13-18 Apr. 2008.
نشریه مهندسی برق و مهندسی كامپیوتر ایران، ب- مهندسی کامپیوتر، سال 20، شماره 1، بهار 1401 1
مقاله پژوهشی
مدیریت منابع در شبکههای چندرسانهای
با استفاده از شبکههای نرمافزارمحور
احمدرضا منتظرالقائم
چكیده: امروزه شبکههای چندرسانهای بر روی اینترنت به یک جایگزین کمهزینه و کارامد برای PSTN تبدیل شده است. برنامههای کاربردی جهت انتقال مالتیمدیا بر روی بستر اینترنت روزبهروز فراگیرتر شده و به محبوبیت بسیار چشمگیری دست پیدا کردهاند. این ارتباط از دو فاز تشکیل شده است: فاز سیگنالینگ و فاز تبادل مدیا. فاز سیگنالینگ توسط پروکسیهای SIP و فاز تبادل مدیا توسط سوئیچهای شبکه انجام میشود. از مهمترین چالشها در شبکههای چندرسانهای، اضافهبار شدن پروکسیهای SIP و سوئیچهای شبکه به ترتیب در فازهای سیگنالینگ و مدیا است. وجود این چالش سبب میشود که طیف وسیع کاربران شبکه با افت شدید کیفیت سرویس مواجه شوند. ما در این مقاله به مدلسازی مسئله مسیریابی در شبکههای چندرسانهای جهت مقابله با اضافهبار میپردازیم. در این راستا یک روش مبتنی بر فناوری شبکههای نرمافزارمحور و بر پایه یک مدل برنامهریزی ریاضی محدب در شبکههای چندرسانهای ارائه میکنیم. روش پیشنهادی تحت سناریوها و توپولوژیهای متنوع شبیهسازی میگردد و نتایج نشان میدهند که گذردهی و مصرف منابع، بهبود یافته است.
کلیدواژه: شبکههای نرمافزارمحور، کنترل اضافهبار، مدلسازی ریاضی، شبکه SIP، مدیریت منابع شبکه.
1- مقدمه
امروزه علاقهمندی به شبکههای چندرسانهای بر روی اینترنت، رو به افزایش است [1]. گستردگي و تنوع سرويسهاي فراهمشده توسط شبکههاي IP سبب رويآوردن فناوریهای مختلف به يکپارچه و مجتمع سازي انواع شبکهها و گرويدن به شبکههای چندرسانهای بر روی اینترنت شده است. ارتباطات در این شبکه دو فاز اصلی دارد: فازهای سیگنالینگ
و مدیا. پروتکل SIP [2] برای سيگنالينگ مکالمات صوتی و تصویری
از رشد روزافزونی برخوردار گردیده و به عنوان پروتکل سيگنالينگ پيشنهادي براي شبکههاي نسل آينده در نظر گرفته شده است [3]. همچنین روزبهروز فناورهای بیسیم نسل چهارم و پنجم از سوی شرکتهای مخابراتی بیشتری مورد استفاده قرار میگیرد و در نتیجه در آیندهای نهچندان دور تقریباً تمامی تلفنها و دستگاههای موبایل مجبور خواهند بود که برای جلسات چندرسانهای خود، از پروتکل SIP به عنوان پروتکل سیگنالینگ پشتیبانی نمایند [4]. پس از فاز سیگنالینگ، فاز
مدیا برای تبادل مالتیمدیا است. شکل 1 یک پیکربندی معمول SIP را نشان میدهد. پیش از ایجاد یک جلسه بین تماسگیرنده (یا UAC) و تماسپذیرنده (یا UAS)، اطلاعات مورد نیاز برای ایجاد یک جلسه از طریق سیگنالینگ SIP مبادله میشود [5]. سیگنالینگ SIP از طریق ارسال پیامهای درخواست و پاسخ به وسیله پروکسی سرورهای SIP انجام میشود. مسیر پیامهای درخواست و پاسخ از مسیر عبور مدیا مستقل است [6]. سیگنالینگ SIP را به وسیله (1) تا (7) در این شکل نشان دادهایم. ارتباط (8) نیز نشاندهنده عبور مدیا از سوئیچهای شبکه از طریق پروتکل RTP است [7]. پس پیامهای سیگنالینگ هم از سوئیچهای شبکه عبور میکنند و هم از پروکسیهای SIP. اما پیامهای مدیا فقط از سوئیچهای شبکه عبور میکنند. پیامها برای رسیدن به مقصد (تماسپذیرنده) نیاز به مسیریابی دارند [8].
پروکسیهای SIP وظیفه مسیریابی لایه هفت پیامها و سوئیچهای شبکه وظیفه مسیریابی لایه سه پیامها را بر عهده دارند [9]. عدم مسیریابی مناسب پیامها سبب عدم استفاده درست از منابع پروکسیهای SIP و همچنین سوئیچهای شبکه میشود [5]. از آنجا که دو فاز مطرحشده مستقل از هم عمل میکنند، مسیریابی و مدیریت منابع نیز به صورت مستقل در دو سطح پروکسیهای SIP و سوئیچهای شبکه انجام میگیرد [10]. علاوه بر این که این نوع مسیریابی بین تمام سوئیچها و پروکسیها توزیع شده است. این باعث عدم یک دید کلی از کل شبکه
به عنوان یک شبکه واحد میشود که سبب پدیده اضافهبار میگردد و مستقیماً بر گذردهی شبکه تأثیرگذار است [11].
2- مفاهیم
در شکل 2 مشاهده میشود که پدیده اضافهبار در شبکههای چندرسانهای سبب شده که گذردهی شبکه به صفر نزول کند [4]. پسنیاز به یک مدیریت منابع درست و متمرکز بسیار احساس میشود. به عبارت دیگر منابع در شبکههای چندرسانهای به دو دسته منابع محاسباتی (پروکسی سرورهای SIP) و منابع شبکهای (سوئیچهای شبکه) تقسیم میشوند که بایستی به صورت مرکزی مدیریت شوند تا مسیریابی مبتنی بر منابع به درستی انجام گردد.
همان طور که در شکل 3 مشاهده میشود، شبکههای چندرسانهای تشکیلشده از مجموعهای از پروکسیهای SIP هستند که پیامهای سیگنالینگ را با استفاده از سرآیند لایه 7، پرش به پرش تا مقصد مسیریابی میکنند [12]. این شبکه، خود بر روی شبکهای از سوئیچهای سنتی قرار دارد که وظیفه مسیریابی پیامها توسط سرآیند لایه 3 را دارند. متأسفانه در این ساختار سنتی، مسیریابی توزیعشده و بدون در نظر گرفتن یکپارچه منابع محاسباتی و شبکهای انجام میشود [13]، علاوه بر این که پیچیدگی زیادی دارد. همان طور که قبلاً ذکر شد، مسیریابی نامناسب باعث پدیده اضافهبار میشود که عواقب وخیمی برای شبکه دارد [14].
[1] این مقاله در تاریخ 21 خرداد ماه 1399 دریافت و در تاریخ 20 مهر ماه 1400 بازنگری شد.
احمدرضا منتظرالقائم، دانشكده مهندسي كامپيوتر، دانشگاه اصفهان، اصفهان، ایران، (email: a.montazerolghaem@comp.ui.ac.ir).
شکل 1: سیگنالینگ و مدیا جهت برقراری مالتیمدیا.
شکل 2: افت گذردهی پروکسی SIP در مواجهه با اضافهبار [4].
در این ساختار هر پروکسی SIP مستقلاً یک واحد کنترل اضافهبار شامل تابع کنترل بار، ناظر و بکارانداز دارد [15]. پردازنده SIP هم وظیفه بررسی پیامهای SIP و مسیریابی آنها را بر عهده دارد. در این ساختار، شناسایی و مقابله با اضافهبار با همکاری همه پروکسیها اتفاق میافتد و آمار بار ترافیکی به صورت محلی بین پروکسیها دستبهدست میشود [16]. عدم وجود یک کنترلکننده مرکزی در این ساختار باعث عدم آگاهی از توپولوژی و منابع کل شبکه میگردد [17].
ما در این مقاله یک روش متمرکز کنترل اضافهبار را برای شبکه SIP توسط مفهوم شبکههای نرمافزارمحور پیشنهاد میدهیم. این روش به مدیریت کلیه منابع محاسباتی و شبکهای به صورت یکپارچه میپردازد. شبکههای نرمافزارمحور یک معماری جدید در شبکه هستند و با استفاده از معماری کل شبکه و اجزای آن به صورت یک شبکه مجازی واحد دیده میشوند که با استفاده از نرمافزارها و APIهای طراحیشده قابل کنترل میگردند.
پسنیاز به یک پروتکل ارتباطی بین نرمافزارها و سختافزارها مشهود است که پروتکل OpenFlow مطرح گردید. هر جزیی از شبکه که
این پروتکل را پشتیبانی کند میتواند در شبکه نرمافزارمحور قرار گیرد. معماری شبکههای نرمافزارمحور دارای ویژگیهای ارتقای پیکربندی، بهبود كارايي، پويايي، مديريت یکپارچه منابع و توان، مدیریت ترافیک، قابلیت برنامهریزی، کاهش هزینهها و دسترسپذیری بالا است.
شكل 4 نمايي از معماري شبکههای نرمافزارمحور را نمايش ميدهد که از سه قسمت اصلی صفحه کنترل، صفحه داده و صفحه برنامههای کاربردی تشکیل شده است. صفحه داده شامل دستگاههای شبکه از جمله دستگاههای مسیریابی، سوئیچ و ... است به طوری که فاقد بخش کنترلی و یا نرمافزاری جهت تصمیمگیریهای خودکار میباشند. بخش هوشمند شبکه در کنترلکنندههای نرمافزاری شبکههای نرمافزارمحور قرار دارد که ساختار کلی شبکه را نگهداری میکند (صفحه کنترل). صفحه برنامههای کاربردی نیز شامل مجموعهای از برنامههای کاربردی مانند مسیریابی، فایروال، تعادل بار، نظارت و غیره است. پروتکل ارتباطی بین صفحات، یک سری Open APIs استاندارد از جمله پروتکل OpenFlow است. در صورت وجود چنین رابطهایی، کنترلکننده قادر به برنامهریزی دستگاههای ناهمگون شبکه به صورت پویا میباشد.
مشارکتهای اصلی این مقاله در ادامه آمده است:
- پیشگیری از وقوع اضافهبار و توزیع بار در شبکه SIP از طریق مدیریت یکپارچه منابع
- طراحی یک روش متمرکز مبتنی بر شبکههای نرمافزارمحور جهت مسیریابی در دو سطح سوئیچها و پروکسیها
- مدلسازی ریاضی مسئله مسیریابی در شبکههای SIP در دو فاز سیگنالینگ و مدیا
- شبیهسازی روش پیشنهادی در یک بستر آزمون واقعی و ارزیابی عملکرد تحت سناریوهای متنوع
پس در این راستا اهداف ذیل کسب میشوند:
1) افزایش گذردهی کل شبکه SIP
2) کاهش تأخیر برقراری تماس
3) مسیریابی در مسیرهای پروکسیها و سوئیچها جهت توزیع بار
3- کارهای پیشین
عمده مقالات در این حوزه در تلاش برای حل مشکل اضافهبار از طریق بازطراحی سیستم کنترلی اضافهبار سنتی هستند. طراحی مناسب شبکه و توزیع مناسب بار بین پروکسیهای SIP یکی از عوامل جلوگیری از کارافتادن سرویس در شبکههای چندرسانهای است [18] تا [23]. یک رویکرد برای مقابله با اضافهبار، توزیع ترافیک ورودی جدید بین سرورهای SIP بر اساس ظرفیت در دسترس آنها با استفاده از یک متعادلساز بار است [24] تا [26]. بنابراین احتمال این که اضافهبار در سرور مشخصی اتفاق بیفتد، کاهش مییابد. اما عملکرد این روشها وابسته به کارایی متعادلساز بار است، چرا که تمام ترافیک سیگنالینگ شبکه SIP از آن عبور میکند. در نتیجه در اضافهبار شدید امکان وقوع اضافهبار در خود متعادلساز بار نیز وجود دارد و باید با روشهایی ظرفیت آن را نیز بالا برد.
[1] . Call-Join-Shortest-Queue
[2] . Transaction-Join-Shortest-Queue
شکل 3: سیگنالینگ SIP در شبکهای از پروکسیها و سوئیچها.
شکل 4: معماری لایهای در شبکههای نرمافزارمحور.
1TLWL معرفی شده است. CJSQ بر مبنای تعداد جلسات تخصیصیافته به یک سرور، میزان کاری را که بر عهده آن سرور میباشد برآورد میکند. مطابق شکل 5، متعادلساز بار برای هر سرور یک شمارشگر جهت شمارش تعداد تماسهای تخصیصیافته دارد. زمانی که یک درخواست INVITE جدید (که متناظر با یک تماس جدید است) دریافت میشود، این تقاضا به سروری که کمترین شمارشگر را دارد اختصاص و شمارشگر آن سرور یک عدد افزایش مییابد. زمانی که متعادلساز بار برای یک درخواست BYE مربوط به این تماس، یک پاسخ OK 200 دریافت کند، متوجه میشود که پردازش آن تماس توسط این سرور به اتمام رسیده و در نتیجه شمارشگر این سرور را یک عدد کاهش میدهد.
یکی از محدودیتهای این روش این است که تعداد تماسهای اختصاصیافته به یک سرور همواره سنجه دقیقی از بار آن سرور نیست. ممکن است بین تراکنشهای یک تماس، زمانهای توقف (بیباری) طولانیای وجود داشته باشد. علاوه بر این، تماسهای مختلف، ممکن است از تعداد متفاوتی تراکنش تشکیل شده باشند.
در TJSQ، متعادلساز بار تماس جديد را به جای سرور با كمترين تماسهای فعال، به سروري كه كمترين تعداد تراكنشهاي فعال را دارد، مسیردهی ميكند. در واقع شمارشگرها، تعداد تراکنشهای تخصیصیافته به هر سرور را مشخص میکنند و تماسهای جدید به سرورهایی که پایینترین شمارشگر را دارند اختصاص مییابند. یکی از محدودیتهای این روش این است که در آن تمامی تراکنشها به طور برابر وزندهی میشوند. در پروتکل SIP، تراکنشهای INVITE از تراکنشهای BYE پرهزینهتر هستند، زیرا ماشین حالت تراکنش INVITE نسبت به ماشین حالت تراکنشهای BYE پیچیدهتر است. در [25] با یک سری آزمایش نشان داده شده که تراکنشهای INVITE در حدود 75% بيشتر از تراکنشهای BYE هزينه دارند.
در TLWL يك تماس جديد به سروري كه كمترين كار را دارد، مسیردهی ميشود. در اینجا كار (يا به عبارت دیگر بار) بر مبناي تخمینهای نسبي از هزینههای تراكنش میباشد. به عبارت دیگر در این روش، شمارشگرها مجموع وزندار تراکنشهای تخصیصیافته به هر سرور را مشخص میکنند و تماسهای جدید به سرورهایی که پایینترین شمارشگر را دارند اختصاص مییابند. به عنوان مثال اگر یک سرور در حال پردازش یک تراکنش INVITE (با هزینه نسبی 75/1) و BYE (با هزینه نسبی 0/1) باشد، آن گاه بار آن سرور برابر 75/2 است.
در [26] نیز یک متعادلساز بار برای SIP با استفاده از تابع آمیزش2 ارائه شده که بر مبنای دریافتکننده تماس، درخواستها به سرورها مسیردهی میشوند. در [27] یک مدل افزونگی برای توزیعکنندههای بار در شبکه SIP پیشنهاد شده و با استفاده از OpenAIS [28] سلامت پروکسیهای پاییندست، نظارت و خرابی یک پروکسی به سرعت کشف و پروکسی دیگری جایگزین آن میشود.
در [29] ساختاری تحت عنوان Snocer برای توزیع بار در شبکههای SIP معرفی شده که در آن کاربر در صورت دسترسی به توزیعکننده بار به آن وصل میشود و در غیر این صورت از طریق DNS و یا به طور مستقیم به یکی از پروکسیهای موجود در شبکه وصل میگردد.
در [28] و [29] از سرورهای پشتیبان به عنوان افزونگی استفاده شده است. در [30] انواع افزونگی به چهار دسته مبتنی بر مشتری، مبتنی بر DNS، مبتنی بر IP و مبتنی بر تکرار پایگاه داده، طبقهبندی گردیده و مورد مطالعه قرار گرفته است. همچنین انواع روشهای تقسیم و توزیع بار با استفاده از DNS، شناسه SIP، پروکسیهای با آدرس یکسان و مترجم آدرس شبکه، معرفی و کارایی آنها روی یک معماری دوسطحی متشکل از پروکسیهای SIP ارزیابی شده است.
به عنوان نتیجهگیری این بخش میتوان به این نکته اشاره کرد که تقریباً تمامی رویکردهای پیشین این حوزه توزیعشده هستند و همین توزیعشدگی باعث پیچیدگی، کاهش کارایی و همچنین عدم مدیریت یکپارچه و متمرکز منابع میشود. البته ذکر این نکته ضروری است که تحقیقات پژوهشی در این زمینه هنوز به شدت ادامه دارد.
4- رویکرد پیشنهادی
4-1 مدل سیستم
در حالت کلی، شبکه SIP یک مجموعه 
تایی از پروکسیهای SIP به همراه یک مجموعه 
تایی از سوئیچها با منابع پردازشی و حافظهای محدود میباشد. هر پروکسی یا سوئیچ منابع خود را جهت برقراری جلسه بین کاربران محلی خود و یا کاربران دامنههای مختلف مصرف میکند. در
[1] . Transaction-Least-Work-Left
[2] . Hash Function
شکل 5: توزیع بار بین سرورهای SIP توسط متعادلساز بار [25].
این مدل سیستم، فرض شده که ماتریس باینری و متقارن 
توپولوژی شبکه SIP را در بر دارد. در این ماتریس اگر برابر یک باشد به معنی وجود لینک فیزیکی بین نود 
و 
است و در غیر این صورت، عدم وجود لینک فیزیکی بین دو نود را نشان میدهد. قطر اصلی این ماتریس صفر میباشد.
همچنین ماتریس مربعی 
نشاندهنده تعداد درخواست تماس از کاربران پروکسی 
به کاربران پروکسی 
میباشد. در این صورت 
تعداد درخواستهای محلی پروکسی و تعداد درخواستهای خارج دامنهای پروکسی میباشد. فرض میکنیم مقدار بهینه تعداد تماسهای پذیرفتهشده از پروکسی به پروکسی ، 
باشد به طوری که 
است.
همچنین 
نشاندهنده تعداد درخواستهای سیگنالینگ از سوئیچ به سوئیچ میباشد و بهینه آن 
است. تعداد درخواستهای مدیا بین دو سوئیچ و نیز 
و بهینه آن 
میباشد. همچنین 
نیز نشاندهنده تعداد درخواستهای پذیرفتهشده از مبدأ به مقصد است که از دو پروکسی مجاور و 
میگذرد 
. بنابراین تعداد کل درخواستهای پذیرفتهشده از به با مشخص میگردد به طوری که نحوه توزیع آن بین مسیرهای موجود بین و را نشان میدهد. ما در این مقاله را جریان مبدأ به مقصد که از مسیر و میگذرد، تعریف میکنیم.
هر پروکسی یا سوئیچ برای انجام عملیات خود متکی به میزان باقیمانده منابع خود یعنی پردازنده و حافظه میباشد. مقدار باقیمانده پردازنده و حافظه پروکسی یا سوئیچ را به ترتیب با 
، 
، 
و 
نشان میدهیم.
کنترلکننده وظیفه مدیریت این منابع را بر عهده دارد. در ابتدای هر بازه زمانی 
، هر پروکسی و سوئیچ تعداد درخواستهای جدید خود را به همراه مقادیر 
، 
از طریق پروتکل OpenFlow به کنترلکننده ارسال میکنند (جمعآوری اطلاعات در ابتدای زمان ). کنترلکننده با توجه به ماتریس و اطلاعات دریافتی و با استفاده از مدل برنامهریزی خطی معرفیشده در زیر، مقادیر بهینه پارامترهای ، ، 
، 
، 
، 
و 
را محاسبه (محاسبات) میکند و سپس به پروکسیها جهت اعمال، اطلاع میدهد (اطلاعرسانی).
4-2 فاز سیگنالینگ
در ادامه یک مدل خطی چندهدفه برای مسئله مسیریابی پیامهای سیگنالینگ با توجه به محدودیتهای مطرحشده ارائه میدهیم
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)
(19)
(20)
(21)
در مدل فوق، هدف، ماکسیممکردن گذردهی پروکسیها و سوئیچها و همچنین کاهش مصرف منابع آنهاست. 
تعداد درخواستهای پذیرفته به کل درخواستهای پروکسی و 
تعداد درخواستهای پذیرفته به کل درخواستهای سوئیچ را نشان میدهد. ترمهای سوم و چهارم در تابع هدف به ترتیب نشاندهنده منابع مصرفی (پردازنده و حافظه) پروکسیها و سوئیچها هستند که به دنبال کاهش آنها هستیم. ضرایب 
، 
، 
و 
درجه تأثیر گذردهی یا منابع در تابع هدف را نشان میدهد. با این ضرایب میتوان یک موازنه بین گذردهی و منابع ایجاد کرد، به این معنی که اگر ضرایب مربوط به گذردهی بیشتر باشد 
و 
، آن گاه تابع هدف با صرف منابع بیشتر، به دنبال ماکسیممکردن گذردهی است. برعکس اگر ضرایب مربوط به منابع بیشتر باشد 
و 
، آن گاه تابع هدف به دنبال کاهش مصرف منابع است.
محدودیتها به 2 دسته کلی محدودیتهای پروکسیها و سوئیچها تقسیم شده است. قید (2) نشان میدهد که حداکثر میتوان به تعداد درخواستها، پذیرش داشت 
. قید (3) در هر پروکسی بین جریانهای ورودی و خروجی توازن برقرار میکند، یعنی مجموع جریانهای ورودی و خروجی به پروکسی که از مبدأ به مقصد میباشند، باید برابر باشند. قید (4) مجموع جریانهای ورودی به پروکسی از مبدأ که از پروکسیهای بین مسیر میگذرد را ملزم میکند که برابر با 
باشد. قید بعدی نیز مجموع جریانهای خروجی از سرور به مقصد را بین سرورهای همجوار سرور توزیع میکند. قید (6) امکان ایجاد جریانی با مبدأ و مقصد یکسان را نخواهد داد. قید (7) نیز از ایجاد دورها در مسیر جلوگیری مینماید. قیود (8) تا (11) قیود تخصیص منابع پروکسیها هستند. قید (8) نشان میدهد که پردازنده پروکسیها
با ضرایب 
و 
صرف رسیدگیکردن تماسهای محلی و خارج دامنهای میشود. قید (9) نیز نشان میدهد که حافظه پروکسیها با ضرایب 
و 
صرف رسیدگیکردن تماسهای محلی و خارج دامنهای میشود.
حدود بالای منابع پردازشی و حافظهای مصرفی بهینه در مدل بالا 
و 
هستند که بنا بر قیود (10) و (11) حداکثر میتوانند 
و 
باشند. قید (12) پذیرش درخواستها توسط سوئیچها را محدود به ظرفیت آنها میکند. قیود (13) تا (17) جهت مسیریابی ترافیک سیگنالینگ در سوئیچها میباشد. قیود (18) تا (21) نیز جهت مدیریت منابع سوئیچها هستند. از آنجا که طرفین (18) و (19) همجنس نیستند، از ضرایب 
و 
برای نرمالایزکردن این معادلات استفاده شده است.
نهایتاً مدل فوق بدون وقوع اضافهبار به دنبال افزایش مجموع گذردهی شبکه از طریق تخصیص بهینه منابع میباشد. مجموع گذردهی را میتوان به صورت مجموع جریانهایی که از شبکه عبور میکنند، در نظر گرفت. پس با توجه به منابع، کنترلکننده سعی در حداکثرنمودن پذیرش تماسها دارد به نحوی که بتواند آنها را بین پروکسیها و سوئیچهای شبکه توزیع کند.
4-3 فاز مدیا
فاز بعدی کنترلکننده، مسیریابی مدیا در بین سوئیچهای شبکه میباشد و بدین جهت مدل خطی زیر پیشنهاد شده است. هدف، افزایش گذردهی مدیا در شبکه سوئیچها با حداقل مصرف منابع میباشد
(22)
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)
(31)
(32)
در (22) ضرایب 
و 
موازنه بین گذردهی مدیا و منابع ایجاد میکنند. اگر از بیشتر باشد آن گاه وزن بیشتر با افزایش گذردهی است اما اگر از بیشتر باشد آن گاه کاهش مصرف منابع، وزن بیشتری دارد. قید (23) حداکثر ظرفیت سوئیچها برای تبادل مدیا را مشخص میکند. قیود (24) تا (28) برای مسیریابی مدیا با توجه به ترافیک مدیا 
است. قیود (29) تا (32) نیز منابع را به مسیریابی مدیا تخصیص میدهند. ضرایب 
و 
جهت نرمالایزکردن (29) و (30) استفاده میشوند.
5- ارزیابی کارایی
به منظور ارزیابی متد پیشنهادی، 3 سناریوی کمبار، بار متوسط و پربار
(الف)
(ب)
(ج)
شکل 6: پردازنده و حافظه مصرفی به همراه نرخ پذیرش مربوط به فاز سیگنالینگ در پروکسیها، (الف) میزان مصرف پردازنده پروکسیها 
، (ب) میزان مصرف حافظه پروکسیها 
و (ج) نرخ پذیرش تماسها توسط پروکسیها 
.
در نرمافزار Matlab استفاده شده است. سناریوها 
تصادفی با توزیع نرمال هستند. همچنین هر سناریو با حالتهای متفاوت و در فاز سیگنالینگ (که با 
تا 
نمایش میدهیم) و حالات متفاوت و در فاز مدیا (که با 
تا 
نمایش میدهیم) مورد بررسی قرار گرفته است. مقادیر ، و 
را برای تمامی پروکسیها و سوئیچها در ابتدا به ترتیب 100، 512 و 350 در نظر گرفتیم. همچنین توپولوژیهای 
، 
و 
نشاندهنده تعداد نودهای شبکه میباشند (به ترتیب 10، 18 و 23). در ادامه نتایج ارائه میگردد.
5-1 آزمایش اول: فاز سیگنالینگ
در این آزمایش به بررسی عملکرد پروکسیها و سوئیچها در فاز سیگنالینگ میپردازیم. در آزمونهای این بخش، فرض گردیده است
که 
، 
و 
و همچنین 
، 
و 
است.
پروکسی: در شکلهای 6 مقادیر بهینه ، و برای حالات مختلف 
در سه سناریو و سه توپولوژی نشان داده شده است. در هر سه سناریو و در هر سه توپولوژی با تغییر حالت از تا ، منابع مصرفی
(الف)
(ب)
(ج)
شکل 7: پردازنده مصرفی پروکسیها در سه توپولوژی در فاز سیگنالینگ، (الف) مصرف پردازنده پروکسیها در توپولوژی 
، (ب) مصرف پردازنده پروکسیها در توپولوژی 
و (ج) مصرف پردازنده پروکسیها در توپولوژی 
.
رشد و درصد پذیرش تماسها نیز افزایش مییابد، چرا که نسبت ضرایب و به یکدیگر نشاندهنده اهمیت پذیرش تماسها یا حفظ منابع میباشد. در حفظ منابع نسبت به بسیار پراهمیتتر بوده و حتی باعث میگردد درصدی از تماسها بلاک شوند. برعکس در حالت پذیرش هرچه بیشتر تماسها مهم است، حتی اگر به قیمت صرف منابع بیشتر باشد. میتوان با ایجاد یک توازن بین این ضرایب هم درصد پذیرش تماس بالایی داشت و هم از منابع به صورت مناسبی استفاده کرد. با حرکت از سناریوی 1 (کمبار) به سناریوی 3 (پربار)، منابع مصرفی رشد مییابند اما ممکن است بار ورودی به شبکه آن قدر زیاد شود که حتی با صرف تمام منابع شبکه نیز نتوان به تمام تماسهای ورودی پاسخگو بود (سناریوی 3 حالت 
و ).
شکل 7 مصرف پردازنده پروکسیها در سه توپولوژی را نشان میدهد. در این شکلها ترکیبهای مختلفی از حالت و سناریو در نظر گرفته شده است (مثلاً 
یا 
). همان طور که مشاهده میشود، مستقل از توپولوژی و سناریو، بار بین پروکسیها، بالانس توزیعشده است.
(الف)
(ب)
(ج)
(د)
(ﻫ)
(و)
شکل 8: تأثیر 
و 
بر 
، 
، 
و 
پروکسیها، (الف) تأثیر 
بر پردازنده، (ب) تأثیر بر تماسهای محلی، (ج) تأثیر بر تماسهای خارج دامنهای، (د) تأثیر 
بر حافظه، (ﻫ) تأثیر بر تماسهای محلی و (و) تأثیر بر تماسهای خارج دامنهای.
زیرا کنترلر از منابع باقیمانده پروکسیها آگاه بوده و با توجه به آن در مورد توزیع بار و مسیر ترافیک تصمیمگیری میکند. همین روند برای حافظه نیز صادق است و از ارائه نتایج آن صرف نظر میکنیم.
شکلهای 8 به بررسی اثر پارامترهای 
و 
بر منابع پردازشی، حافظهای، تماسهای محلی و تماسهای خارج دامنهای میپردازد. همان طور که در شکلهای 8- الف تا 8- ج مشخص است، با افزایش نسبت به ، تماسهای محلی پذیرفتهشده افزایش و تماسهای خارج دامنهای کاهش مییابد. همچنین پردازنده مصرفی نیز کاهش مییابد. دلیل آن این است که در (8)، ضریب 
است و همچنین رسیدگیکردن به تماسهای محلی منابع کمتری را نیاز دارد. از آنجا که در معادله تخصیص حافظه (9)، ضریب است پس افزایش باعث افزایش تماسهای محلی پذیرفتهشده میشود (شکل 8- ﻫ). افزایش تماسهای محلی نسبت به تماسهای خارج دامنهای به حافظه کمتری نیاز دارد (شکل 8- د).
سوئیچ: در شکلهای 9 مقادیر بهینه ، و برای حالات مختلف تابع 
و همچنین سه سناریو و سه توپولوژی نشان داده شده است. یک تابع از ضرایب و است که وزن "پذیرش جریانها" و "منابع سوئیچها" در تابع هدف (1) هستند. همان طور که در این شکلها مشاهده میشود، در هر سه سناریو با حرکت از تا منابع مصرفی رشد و درصد پذیرش تماسها نیز افزایش مییابد، چون ضریب در بیشتر میشود. همچنین با حرکت از سناریوی 1 (کمبار)
به سناریوی 3 (پربار)، منابع مصرفی رشد مییابند. اما نتایج مستقل از توپولوژی است و با پیچیدهشدن توپولوژی عملکرد کنترلر تحت تأثیر قرار نمیگیرد. این گویای این است که شبکه نرمافزارمحور میتواند شبکه گستردهای از سوئیچهای OpenFlow را به دلیل داشتن دید کلی مدیریت کند.
پردازنده و حافظه مصرفی سوئیچها در فاز سیگنالینگ برای توپولوژیهای و به ترتیب در جداول 1 و 2 آورده شده است. همان طور که در این جدولها مشاهده میشود، منابع مصرفی سوئیچها بسیار نزدیک به هم هستند. به عنوان مثال در سناریوی 1 و در حالت ، پردازنده مصرفی هر هفت سوئیچ حدوداً 22% است که این روند برای حافظه مصرفی هم صادق میباشد. این نشان میدهد که بار به صورت عادلانه و یکنواخت بین سوئیچها توزیع شده است. نتایج برای توپولوژی نیز از همین الگو پیروی میکند و از آوردن مجدد آن صرف نظر کردیم. فاز بعدی، فاز مدیا است.
5-2 آزمایش دوم: فاز مدیا
در این فاز سوئیچها درگیر هستند و پروکسیها نقشی ندارند. نتایج این فاز برای سه سناریوی کمبار، بار متوسط و پربار در شکل 10 آورده شده است. 
تابعی از و است. در 
مقدار (حفظ منابع) و در 
مقدار (نرخ پذیرش) بیشتر است. مقادیر بهینه 
، 
و در این شکل برای مدت 600 ثانیه آورده شده است. در 200 ثانیه اول، سناریوی کمبار اجرا شده و سپس در 200 ثانیه دوم و سوم به ترتیب سناریوهای بار متوسط و پربار اجرا گشته است. همان طور که مشاهده میشود با افزایش بار در گذر زمان، منابع مصرفی 
و 
نیز به جهت ثابت نگه داشتن نرخ پذیرش جریان، افزایش مییابند. این افزایش با بیشتر است به طوری که در سناریوی سوم با مصرف کل منابع (شکل 10- الف و 10- ب)، نرخ پذیرشی بهتر از 78% به دست نمیآید.
(الف)
(ب)
(ج)
شکل 9: پردازنده و حافظه مصرفی و نرخ پذیرش در فاز سیگنالینگ سوئیچها، (الف) میزان مصرف پردازنده سوئیچها 
، (ب) میزان مصرف حافظه سوئیچها 
و (ج) نرخ پذیرش جریان سیگنالینگ توسط سوئیچها 
.
5-3 آزمایش سوم: تأثیر زمان اجرا
در این بخش به تأثیر بر کارایی روش پیشنهادی میپردازیم. بدین منظور ما نرخ پذیرش تماس و منابع مصرفی را با مقادیر مختلف (2، 4، 6 و 8 ثانیه) به دست میآوریم. همان گونه که در شکل 11- الف مشاهده میشود، زمانی که کم است (2 ثانیه)، زمان انتظار برای تماسهای جدید کم میباشد و فاصله زمانی تصمیمگیری کنترلر نیز کوتاه است. در نتیجه ، و دقیقتر هستند که این باعث افزایش نرخ پذیرش تماس میشود. با این حال همان گونه که در شکل 11- ب و 11- ج نشان داده شده است، میانگین پردازنده و حافظه مصرفی در حالت برابر 2 ثانیه، بیشتر از سایر موارد است.
در شکلهای 12 نیز به تأثیر بر کارایی سوئیچها در روش پیشنهادی میپردازیم. بدین منظور ما نرخ پذیرش تماس و منابع مصرفی سوئیچها را با مقادیر مختلف (2، 4، 6 و 8 ثانیه) به دست میآوریم. همان گونه که در شکل 12- الف مشاهده میشود، زمانی که کم است (2 ثانیه)، زمان انتظار در سوئیچها برای تماسهای جدید کم میباشد که
(الف)
(ب)
(ج)
شکل 10: پردازنده و حافظه مصرفی سوئیچها و نرخ پذیرش در فاز مدیا، (الف) میزان مصرف پردازنده سوئیچها 
، (ب) میزان مصرف حافظه سوئیچها 
و (ج) نرخ پذیرش جریان مدیا توسط سوئیچها 
.
در نتیجه نرخ پذیرش تماس توسط سوئیچها بالاست. با این حال همان گونه که در شکل 12- ب و 12- ج مشخص است، میانگین پردازنده و حافظه مصرفی در حالت برابر 8 ثانیه، کمتر از سایر موارد است. دلیل این امر این است که هرچه کمتر باشد، سربار کنترلر نیز بیشتر است، چرا که تصمیمات و حل مدل ریاضی در بازههای زمانی کمتری انجام میشود، پس مصرف منابع در این حالت بیشتر میباشد. تصمیمگیری در مورد و بازههای زمانی حل مدل توسط کنترلر از این جهت حایز اهمیت است که مستقیماً روی مصرف منابع و افزایش یا کاهش پیچیدگی روش پیشنهادی تأثیرگذار است. پس باید با توجه به منابع و نرخ پذیرش تماسهای مد نظر، یک مناسب را در نظر گرفت.
5-4 آزمایش چهارم: تأثیر خرابی نودها
علاوه بر ازدحام آنی، یکی دیگر از دلایلی که ممکن است سرورهای SIP را با اضافهبار روبهرو کند، خرابشدن ناگهانی اجزای شبکه و کاهش
جدول 1: منابع مصرفی سوئیچها در توپولوژی (%).
| سناریوی 1 | سناریوی 2 | سناریوی 3 | ||||||||||
|
|
|
|
|
|
|
|
|
|
|
| ||
سوئیچ 1 | پردازنده | 2 | 12 | 22 | 22 | 5 | 42 | 60 | 70 | 8 | 47 | 70 | 78 |
سوئیچ 2 | پردازنده | 3 | 11 | 23 | 23 | 5 | 41 | 62 | 69 | 7 | 46 | 71 | 79 |
سوئیچ 3 | پردازنده | 2 | 11 | 22 | 22 | 6 | 40 | 62 | 69 | 8 | 46 | 70 | 77 |
سوئیچ 4 | پردازنده | 3 | 13 | 21 | 22 | 4 | 43 | 63 | 68 | 7 | 45 | 72 | 76 |
سوئیچ 5 | پردازنده | 2 | 11 | 22 | 22 | 5 | 44 | 60 | 70 | 7 | 48 | 70 | 75 |
سوئیچ 6 | پردازنده | 3 | 10 | 21 | 23 | 6 | 42 | 61 | 69 | 6 | 46 | 71 | 77 |
سوئیچ 7 | پردازنده | 2 | 12 | 20 | 22 | 4 | 41 | 62 | 70 | 8 | 45 | 73 | 74 |
سوئیچ 1 | حافظه | 6 | 64 | 128 | 28 | 15 | 196 | 344 | 418 | 48 | 298 | 412 | 472 |
سوئیچ 2 | حافظه | 7 | 64 | 128 | 126 | 14 | 199 | 343 | 417 | 47 | 298 | 410 | 471 |
سوئیچ 3 | حافظه | 5 | 63 | 127 | 126 | 16 | 198 | 342 | 416 | 46 | 297 | 411 | 470 |
سوئیچ 4 | حافظه | 6 | 62 | 125 | 128 | 14 | 200 | 344 | 418 | 48 | 296 | 413 | 472 |
سوئیچ 5 | حافظه | 7 | 66 | 128 | 125 | 15 | 197 | 342 | 417 | 47 | 295 | 411 | 473 |
سوئیچ 6 | حافظه | 7 | 61 | 125 | 128 | 16 | 196 | 344 | 420 | 46 | 298 | 410 | 472 |
سوئیچ 7 | حافظه | 5 | 62 | 126 | 124 | 15 | 196 | 343 | 418 | 48 | 297 | 411 | 470 |
جدول 2: منابع مصرفی سوئیچها در توپولوژی (%).
| سناریوی 1 | سناریوی 2 | سناریوی 3 | ||||||||||
|
|
|
|
|
|
|
|
|
|
|
| ||
سوئیچ 1 | پردازنده | 2 | 14 | 24 | 25 | 8 | 46 | 61 | 72 | 11 | 51 | 69 | 79 |
سوئیچ 2 | پردازنده | 2 | 13 | 23 | 25 | 7 | 45 | 60 | 72 | 10 | 50 | 69 | 78 |
سوئیچ 3 | پردازنده | 3 | 12 | 24 | 24 | 8 | 45 | 62 | 71 | 12 | 52 | 68 | 77 |
سوئیچ 4 | پردازنده | 4 | 14 | 22 | 26 | 6 | 47 | 61 | 70 | 11 | 51 | 67 | 79 |
سوئیچ 5 | پردازنده | 3 | 13 | 23 | 27 | 7 | 44 | 62 | 70 | 10 | 51 | 69 | 77 |
سوئیچ 6 | پردازنده | 2 | 14 | 24 | 25 | 8 | 46 | 60 | 71 | 12 | 52 | 69 | 78 |
سوئیچ 7 | پردازنده | 3 | 12 | 22 | 24 | 8 | 46 | 60 | 72 | 11 | 53 | 67 | 77 |
سوئیچ 8 | پردازنده | 4 | 13 | 24 | 24 | 7 | 47 | 62 | 72 | 12 | 52 | 66 | 78 |
سوئیچ 9 | پردازنده | 3 | 14 | 23 | 25 | 8 | 47 | 61 | 72 | 13 | 51 | 68 | 79 |
سوئیچ 10 | پردازنده | 2 | 14 | 22 | 25 | 7 | 46 | 62 | 72 | 12 | 53 | 67 | 79 |
سوئیچ 1 | حافظه | 16 | 85 | 150 | 160 | 25 | 226 | 354 | 422 | 59 | 308 | 412 | 472 |
سوئیچ 2 | حافظه | 15 | 83 | 149 | 161 | 24 | 224 | 353 | 421 | 58 | 308 | 412 | 470 |
سوئیچ 3 | حافظه | 14 | 84 | 152 | 160 | 23 | 225 | 354 | 420 | 57 | 607 | 411 | 471 |
سوئیچ 4 | حافظه | 16 | 85 | 151 | 162 | 25 | 226 | 355 | 418 | 59 | 306 | 410 | 470 |
سوئیچ 5 | حافظه | 15 | 86 | 152 | 163 | 24 | 227 | 354 | 419 | 58 | 308 | 412 | 469 |
سوئیچ 6 | حافظه | 14 | 85 | 153 | 160 | 23 | 224 | 355 | 423 | 57 | 308 | 411 | 473 |
سوئیچ 7 | حافظه | 16 | 84 | 152 | 161 | 25 | 224 | 356 | 422 | 59 | 307 | 412 | 472 |
سوئیچ 8 | حافظه | 14 | 85 | 151 | 162 | 24 | 226 | 354 | 422 | 58 | 306 | 410 | 471 |
سوئیچ 9 | حافظه | 15 | 86 | 150 | 163 | 23 | 225 | 355 | 421 | 57 | 306 | 410 | 470 |
سوئیچ 10 | حافظه | 16 | 84 | 149 | 160 | 24 | 224 | 354 | 420 | 58 | 307 | 411 | 469 |
ناگهانی ظرفیت میباشد. این خرابی ممکن است تحمیل بار سرور خرابشده روی سایرین در یک مجموعه سرور باشد. برای آزمایش چنین وضعیتی، 1000 تماس (بار ارائهشده1) در یک بازه زمانی 600 ثانیهای به توپولوژی تزریق شد. در ثانیه 200، نودی از شبکه دچار خرابی شده و در ثانیه 400 مجدداً به کار میافتد. همان گونه که در شکل 13- الف مشاهده میشود، با کنترلر تا قبل از ثانیه 200 به طور میانگین 955 درخواست سرویس داده میشوند. میانگین مصرف پردازنده و حافظه برای پروکسیها در این 200 ثانیه تقریباً 61% و 59% میباشد (شکل 13- ب و 13- ج). با خرابشدن یک سرور در ثانیه 200 مسیری از مسیرهای شبکه حذف میگردد که تنها کنترلر از آن آگاه است. در این حالت، کنترلر
به دلیل حالت قصد دارد بدون دچارشدن به عواقب اضافهبار از
بیشتر ظرفیت سرورهای موجود در مسیرهای جایگزین برای مقابله با افت شدید نرخ سرویس استفاده کند. به همین خاطر میانگین مصرف پردازنده و حافظه افزایش مییابد (شکل 13- ب و 13- ج منحنی با برچسب "With controller" از ثانیه 200 تا 400). در صورت عدم وجود کنترلر، تعداد درخواستهای سرویس داده شده در 200 ثانیه دوم تقریباً به 636
(الف)
(ب)
(ج)
شکل 11: نرخ پذیرش، پردازنده و حافظه مصرفی پروکسیها با تغییر 
، (الف) نرخ پذیرش تماس توسط پروکسیها ، (ب) میزان مصرف پردازنده پروکسیها و (ج) میزان مصرف حافظه پروکسیها .
افت مییابد و میانگین نرخ پذیرش تماس برابر 5/63% میشود (شکل 13- الف منحنی با برچسب "Without controller" از ثانیه 200 تا 400).
(الف)
(ب)
(ج)
شکل 12: نرخ پذیرش، پردازنده و حافظه مصرفی سوئیچها با تغییر ، (الف) نرخ پذیرش تماس توسط سوئیچها ، (ب) میزان مصرف پردازنده سوئیچها و (ج) میزان مصرف حافظه سوئیچها .
با بازگشت مجدد پروکسی سرور خرابشده به مسیر در ثانیه 400 و عبور از وضعیت اضافهبار، نرخ پذیرش تماس در هر دو حالت برابر میشود اما به دلیل مدیریت هوشمندانه منابع توسط کنترلر، میانگین مصرف
(الف)
(ب)
(ج)
شکل 13: کارایی در طول زمان و در صورت خرابی یک نود در ثانیه 200، (الف) نرخ پذیرش تماس، (ب) میزان مصرف پردازنده و (ج) میانگین حافظه مصرفی.
پردازنده و حافظه کمتر است. یعنی کنترلر به نرخ پذیرش مناسب با مصرف منابع کمتر دست مییابد و این به دلیل آگاهی جامع از کل شبکه توسط کنترلر است. از ثانیه 400 به بعد مجدداً تمام پروکسی سرورها میتوانند به نرخ سرویس قبل از اضافهبار بازگردند.
6- جمعبندی و کارهای آتی
اضافهبار پروکسیهای SIP از مشکلات مهم شبکههای چندرسانهای مبتنی بر اینترنت است که به دلیل مسیریابی نامناسب درخواستهای تماس در لایه کاربرد، باعث اشباع منابع و در نتیجه افت شدید کارایی میشود. علاوه بر این، در فاز مدیا نیز عدم مسیریابی متمرکز باعث افت "کارایی سوئیچها" و "گذردهی شبکه" میشود. در این مقاله، یک روش مبتنی بر فناوری شبکههای نرمافزارمحور برای ارتقای شبکههای SIP ارائه شد تا بتوان بر این مشکلات فایق آمد. در این راستا، در لایه کنترل یک کنترلر OpenFlow بر پایه مدلهای برنامهریزی خطی طراحی شد و قیود این مدلها، مصرف منابع و مسیریابی هستند. برای ارزیابی کارایی روش پیشنهادی به شبیهسازی آن پرداخته شد و آزمایشهای متنوع در قالب چند سناریو و در سه توپولوژی انجام گردید. نتایج نشاندهنده بهبود گذردهی و مصرف منابع، در هر دو فاز سیگنالینگ و مدیا بود. برای کارهای آتی به تعمیم و توسعه مدلهای ریاضی برای تخصیص بهینه منابع برای همه تجهیزات شبکه به صورت عمومی خواهیم پرداخت. همچنین چارچوب پیشنهادی را مجهز به فناوری مجازیسازی توابع شبکه خواهیم کرد. در این صورت منابع به صورت مجازی و در صورت تقاضا در دسترس خواهند بود. همچنین در نظر داریم متد پیشنهادی
را در زیرسیستم چندرسانهای 2(IMS) با استفاده از Open IMS پیادهسازی کنیم.
مراجع
[1] J. Rosenberg, et al., SIP: Session Initiation Protocol, IETF RFC 3261, Jun. 2002.
[2] J. Rosenberg, et al., Requirements for Management of Overload in the Session Initiation Protocol, RFC5390, Dec. 2008.
[3] E. M. Nahum, J. Tracey, and C. P. Wright, "Evaluating SIP server performance," ACM SIGMETRICS Performance Evaluation Review, vol. 35, no. 1, pp. 349-350, Jun. 2007.
[4] M. Ohta, "Performance comparisons of transport protocols for session initiation protocol signaling," in Proc. 4th Int. Telecommunication Networking Workshop on QoS in Multiservice IP Networks, pp. 148-153, Venezia, Italy, 13-15 Feb. 2008.
[5] E. Noel and C. Johnson, "Initial simulation results that analyze
SIP based VoIP networks under overload," in Proc. 20th int. Teletraffic Conf. on Managing traffic performance in converged networks, pp. 54-64, Ottawa, Canada, 17-21 Jun. 2007.
[6] M. Ohta, "Simulation study of SIP signaling in an overload condition," in Proc. Communication Internet, and Information Technology, pp. 321-326, Cote d'Azur, France, 26-29 Aug. 2004.
[7] V. K. Gurbani and R. Jain, "Transport protocol considerations for session initiation protocol networks," Bell Labs Technical J., vol. 9, no. 1, pp. 83-97, 2004.
[8] V. Pascual, SIP Server Overload Problem Statement, http://siprouter.org/wiki/_media/tbd/overload_control_problem_statement_vpascualv10.pdf, 2009.
[9] V. Hilt and I. Widjaja, "Controlling overload in networks of SIP servers," in Proc. IEEE Int. Conf. on at the Network Protocols, pp. 83-93, Orlando, FL, USA, 19-22 Oct. 2008.
[10] P. McGregor, R. Kaczmarek, V. Mosley, D. Dease, and P. Adams, "National security/emergency preparedness and the next-generation network," IEEE Communications Magazine, vol. 44, no. 5, pp. 133-143, May 2006.
[11] V. Hilt, Design Considerations for Session Initiation Protocal (SIP) Overload Control, RFC6357, Aug. 2011.
[12] I. Widjaja, V. Hilt, and H. Schulzrinne, Session Initiation Protocol (SIP) Overload Control, IETF, http://tools.ietf.org/html/draft-hilt-sipping-overload-02, 2008.
[13] C. Shen and H. Schulzrinne, "On TCP-based SIP server overload control," in Proc. The Principles, Systems and Applications of IP Telecommunications, pp. 71-83, Munich Germany, 2-4 Aug. 2010.
[14] H. Schulzrinne, S. Narayanan, J. Lennox, and M. Doyle, SIP Stone-Benchmarking SIP Server Performance, Columbia University, 2002.
[15] H. Lindholm, T. Vahakangas, and K. Raatikainen, "A control plane benchmark for telecommunications signalling applications," Sort, vol. 20, no. 5, pp. 100-125, May 2007.
[16] M. Cortes, J. R. Ensor, and J. O. Esteban, "On SIP performance," Bell Labs Technical J., vol. 9, no. 3, pp. 155-172, Nov. 2004.
[17] S. Wanke, M. Scharf, S. Kiesel, and S. Wahl, "Measurement of the SIP parsing performance in the SIP express router," in Proc. 13th open European Summer School and IFIP TC6.6 Conf. on Dependable and Adaptable Networks and Services, pp. 103-110, Enschede, The Netherlands, 18-20 Jul. 2007.
[18] S. S. Gokhale and J. Lu, "Signaling performance of SIP based VoIP: a measurement-based approach," in Proc. IEEE Global Telecommunications Conf., pp. 761-765, St. Louis, MO, USA, 28-Nov.-3 Dec. 2005.
[19] C. Chi, D. Wang, R. Hao, and W. Zhou, "Performance evaluation of SIP servers," in Proc. 3rd Int. Conf. on the Communications and Networking in China, pp. 674-679, Hangzhou, China, 25-27 Aug. 2008.
[20] D. Pesch, M. I. Pous, and G. Foster, "Performance evaluation of SIP-based multimedia services in UMTS," Computer Networks, vol. 49, no. 3, pp. 385-403, Oct. 2005.
[21] M. Homayouni, et al., "Configuration of a sip signaling network: an experimental analysis," in Proc. 5th Int. Joint Conf. on INC, IMS and IDC, pp. 76-81, Seoul, South Korea, 25-27 Aug. 2009.
[22] K. K. Ram, I. C. Fedeli, A. L. Cox, and S. Rixner, "Explaining the impact of network transport protocols on SIP proxy performance," in Proc. IEEE Int. Symp. on the Performance Analysis of Systems and Software, pp. 75-84, Austin, TX, USA, 20-22 Apr. 2008.
[23] X. Wenfeng, et al., "A survey on software-defined networking," IEEE Communications Surveys & Tutorials, vol. 17, no. 1, pp. 27-51, Firstquarter 2015.
[24] A. R. Montazerolghaem, S. K. Shekofteh, M. H. Yaghmaee, and
M. Naghibzadeh, "A load scheduler for SIP proxy servers: design, implementation and evaluation of a history weighted window approach," International J. of Communication Systems, vol. 30, no. 3, Article ID: e2980, May 2015.
[25] J. Hongbo, et al., "Design, implementation, and performance of a load balancer for SIP server clusters," IEEE/ACM Trans. on Networking, vol. 20, no. 4, pp. 1190-1202, Aug. 2012.
[26] K. Singh and H. Schulzrinne, "Failover, load sharing and server architecture in SIP telephony," Computer Communications, vol. 30, no. 5, pp. 927-942, Mar. 2007.
[27] W. M. Wu, K. Wang, R. H. Jan, and C. Y. Huang, "A fast failure detection and failover scheme for SIP high availability networks," in Proc. 13th Pacific Rim Int. Symp. on the Dependable Computing, pp. 187-190, Melbourne, Australia, 17-19 Dec. 2007.
[28] Y. J. Cheng, K. Wang, R. H. Jan, C. Chen, and C. Y. Huang, "Efficient failover and load balancing for dependable SIP proxy servers," in Proc. IEEE Symp. on the Computers and Communications, pp. 1530-1346, Marrakech, 6-9 Jul. 2008.
[29] G. Kambourakis, D. Geneiatakis, T. Dagiuklas, C. Lambrinoudakis, and S. Gritzalis, "Towards effective SIP load balancing," in Proc. 3rd VoIP Security Workshop, 6 pp., Berlin, Germany, 15-17 Jun. 2006.
[30] S. Montagna and M. Pignolo, "Performance evaluation of load control techniques in sip signaling servers," in Proc. 3rd Int. Conf. on the Systems, pp. 51-56, Cancun, Mexico, 13-18 Apr. 2008.
احمدرضا منتظرالقائم تحصيلات خود را در مقاطع كارشناسيِ مهندسی فناوری اطلاعات و كارشناسيارشد مهندسی کامپیوتر بهترتيب در سالهاي 1389 و 1392 به پايان رسانده است. او همچنین دکتری سیستمهای نرم افزاری خود را در سال 1396 با درجه عالی از دانشگاه فردوسی مشهد اخذ نموده است و هم اكنون استادیار دانشكده مهندسي كامپيوتر دانشگاه اصفهان ميباشد. ایشان در سال 1393 موفق به دریافت جایزه تحصیلی بنیاد ملی نخبگان شده و پژوهشگر برتر سال 1395 دانشکده مهندسی دانشگاه فردوسی مشهد بوده است. نامبرده قبل از پيوستن به دانشگاه اصفهان، در سالهاي 1389 الي 1397 مدیر کیفی آزمایشگاه تایید نمونه تجهیزات شبکه ویپ دانشگاه فردوسی مشهد بوده است. از دیگر سوابق وی میتوان به شرکت در پروژه توسعه زیرساختِ ابر مجازی و هوشمندِ SAVI دانشگاه تورنتو کانادا و تحقیق به عنوان پژوهشگر پسادکتری بر روی مدیریت انرژی شبکههای ارتباطی نرمافزار محور در دانشگاه فردوسی مشهد اشاره کرد. همچنین ایشان در طرحهای پژوهشی و پروژههای متعددی از جمله پیاده سازی ویپ شرکت ایران خودرو خراسان، طراحی و پیاده سازیِ معماری دیتاسنتر شرکت توزیع برق مشهد و همچنین بررسی، مطالعه، راه اندازی و استقرار سیستم ویپ استانداری خراسان رضوی مشارکت داشتهاند. زمينههاي تحقيقاتي مورد علاقه ايشان عبارتند از: شبکههای کامپیوتری، شبکههای نرمافزار محور، مجازیسازی توابع شبکه، شبکههای چندرسانهای، شبکههای سلولی و اینترنت اشیا.
[1] . Offered Load
[2] . IP Multimedia Subsystem