CC BY
43
21 декабря 2011 r. 16:36
"Инфокоммуникачионно-управленческие сети. Расчет и оптимизация систем связи"
Влияние процедуры регистрации пользовательского SIP-оборудования на функционирование телефонной сети общего пользования
Развитие сетей телефонной связи общего пользования на базе технологии SIP приводит к возникновению рисков, связанных с нарушением нормального режима функционирования ТфОП. Одной из причин возникновения таких рисков является наличие в протоколе SIP процедуры регистрации пользовательского SIP-оборудования (SIP-телефонов), предназначенной для обеспечения переносимости номера. Данная процедура формирует дополнительную нагрузку на сеть, причем в ряде случаев - лавинообразную. В частности, при отключении электропитания коммутационного оборудования, различных сетевых атак и пр. Б статье рассматриваются особенности функционирования процедуры регистрации протокола SIP, влияние процедуры на функционирование ТфОП, а также работы организаций стандартизации, посвященных анализируемому вопросу.
Журавлев С В.
21 января 2010 г. многие американские пользователи приложения Skype не смогли осуществить привычные голосовые вызовы своим родственникам и друзьям. Их приложения выдавали отказ в авторизации приложения Skype на управляющих серверах Skype [1]. Позднее проблема распространилась на часть территории Европы, после чего была локализована и исправлена.
Общее время массовой аварии составило около 4-х часов. Компания Skype признала факт аварии. Однако причины и подробности аварии не сообщались. В то же время многие отраслевые специалисты обратили внимание на схожесть этой аварии с аналогичной массовой аварией в августе 2007 г. [2].
С 15 по 17 августа 2007 г. наблюдались многочисленные отказы в обслуживании десятков миллионов пользователей Skype из-за невозможности осуществить авторизацию или зарегистрировать новую учетную запись.
Масштаб аварии не разглашался, но сообщения об отказах поступали из многих стран. Сообщения об эффектах проявления аварии поступали разные. Некоторые коммуникаторы проходили процедуру авторизации, но были принудительно отключены минуту спустя. Другие получали огромное число «мгновенных сообщений» IM, в том числе и адресованных другим абонентам.
Компания Skype назвала причиной аварии программные «обновления» операционной системы Windows, регулярно выпускаемые компанией Microsoft [3].
Подавляющее число приложений Skype работает на персональных компьютерах, функционирующих под управлением операционной системы Windows. При выпуске очередных исправлений и дополненений к этой операционной системе, они становятся доступны всем пользователям Windows. В большинстве случаев установка исправлений проводится автоматически и завершается перезагрузкой компьютеров. Фактически, наступает одномоментная перезагрузка миллионов компьютеров для вступления изменений в силу.
Именно это и стало причиной отказа системы Skype. После одномоментной загрузки большого числа компьютеров на управляющие серверы Skype начали поступать попытки авторизации (регистрации) со стороны клиентских приложений. При этом, в отличие от нормальной ситуации регистрации при включении ПО пользователем (что представляет собой распределенный и относительно равномерный по времени процесс), в условиях аварии попытки регистрации поступили практически одномоментно с сотен миллионов компьютеров, что привело к перегрузке управляющих серверов Skype. При этом поток повторных попыток регистрации не позволил равномерно распределить нагрузку, и устранение последствий аварии растянулось на несколько дней.
Таким образом, причиной массового отказа компьютерной телефонной службы Skype стали особенности функционирования процедуры регистрации пользовательского программного обеспечения (оборудования) в условиях аварии сети и перегрузки уравляющего оборудования.
Процедура регистрации пользовательского оборудования, помимо компьютерных служб, специфицирована для протокола SIP, являющегося основной построения сетей связи на базе технологии коммутации пакетов (NGN/IMS). Поэтому аварии, схожие с рассмотренными выше, могут наблюдаться и в современных телефонных сетях связи [6].
Необходимо отметить, что нормы проектирования сетей телефонной связи, существующие в отрасли, не учитывают наличие процедуры регистрации пользовательского оборудования. Следовательно, на этапе проектирования не закладываются технические решения по предостращению перегрузок такого рода.
На практике с такими перегрузками пытаются бороться административными методами - распараллеливанием нагрузки, контролем нагрузки в процессе эксплуатации и пр. Сегодня такие методы позволяют справляться с критическими ситуациями, поскольку число пользовательского SIP-оборудования (например, SIP-телефонов) невелико, однако по мере роста мас-
76
штаба сетей, их может оказаться недостаточно. Поэтому сегодня операторы связи, активно развивающие сети NGN (например, Verizon, British Telecom, NTT) исследуют вопросы перегрузок со стороны пользовательского SIP-оборудования, подготавливаясь к будущим кризисным ситуациям [4, 5, 6].
На практике могут встречаться ситуации, развивающиеся стремительно, и не позволяющие оперативно предотвратить их административными методами. К таким ситуациям относятся:
- отключение электроэнергии в городском районе и обесточивание большого количества SIP-телефонов с последующим одновременным их включением;
- авария коммутационного оборудования, приводящая к необходимости одновременной перерегистрации SIP-телефонов на резервном коммутационном оборудовании;
- преднамеренные атаки, имитирующие одновременную регистрацию большого числа SIP-телефонов вида и вызывающие ситуацию «отказ в обслуживании» со стороны коммутационного оборудования вследствие его перегрузки;
- программные ошибки со стороны производителей оборудования и прошивок пользовательского оборудования, когда в результате загрузки такого ПО SIP-телефоны перезагружаются и перерегистрируются одномоментно.
Распределение вероятностей наступления различных ситуаций, может быть проиллюстрировано табл.1, составленной по результатам анализа отказов узлов маршрутизации Интернет [8]. Поскольку архитектурно и технологически коммутационное оборудование NGN/IMS тождественно маршрутизирующему оборудованию, можно прогнозировать аналогичное распределение причин аварий для телефонной сети на базе технологии коммутации пакетов.
Таблица 1
Распределение причин аварий маршрутизирую-
комендует не осуществлять немедленного повтора попытки регистрации, и не устанавливает мимнимальное время между попытками регистрации.
На практике, производители пользовательского SIP-оборудования не всегда придерживаются этой рекомендации. Это связано с тем, что перечисленные выше ситуации относятся к чрезвычайным, стимулирующим абонентов звонить в экстренные службы. Поэтому, в целях выполнения требований по доступу к экстренным службам, многие SIP-телефоны осуществляют немедленную повторную передачу сообщений регистрации. Некоторые модели SIP-телефонов даже увеличивают интенсивность попыток регистрации, передавая несколько сообщений одновременно. Это сделано для того, чтобы повысить вероятность положительного ответа хотя бы на одно переданное сообщение в условиях передачи попыток регистрации в пакетах UDP, не гарантирующих доставку.
Следует заметить, что в силу специфики работы процедуры регистрации [например, 9, п. 2.1], по сети связи всегда передается избыточное число попыток регистрации, которое тем больше, чем меньше установлен интервал времени между повторными попытками регистрации. В частности, имитационная модель контроллера MGC, разработанная автором статьи, позволяет построить зависимость между объемом полезной (accept) и избыточной (reject) нагрузки в сети связи, рис.1.
Экспериментальные данные подтверждают значительный рост числа отказов в обработке сообщений сигнализации SIP в зависимости от нагрузки оборудованием PartySIP [10], рис.2.
С учетом этих данных, можно составить теоретический график процесса аварии, рис.З.
В нормальном состоянии в сети существует полезная и избыточная нагрузка от попыток регистрации.
Она носит стационарный характер, не зависящий от времени суток (ЧНН), поскольку генерируется автоматически через заданные интервалы времени.
Причина Доля отказов по этой причине
Сбои программного обеспечения 16,2%
Аварии электропитания 16,0%
Обрыв линий связи 15,3%
Неисправность оборудования 9,0%
Ошибки маршрутизации 6,1%
Перегрузка 4,6%
РОоБ атаки 1,5%
Программные ошибки 1,3%
Таким образом, вероятность массовой аварии, связанной с полной недоступностью коммутационного оборудования, достаточно велика и может составлять более 0,3 от всех случаев аварий.
После исправления аварии на управляющие контроллеры поступает нагрузка, значительно превышающая доступный ресурс производительности, контроллеры не справляются и входят в режим аварии. На пользовательском SIP-оборудовании при этом возникает ошибка таймаута. Спецификация протокола SIP [7, п. 10.2.7] не описывает подробно действия пользовательского SIP-оборудования в состоянии таймаута. Спецификация ре-
•eerwwcw дчч» ««(пии a»v«<* eeneww*
\
^ \
1 \
1 \
1 \
Г'“ \
D
Рис. 1. Соотношение количества успешных и неуспешных попыток регистраций при разных значениях интервала времени между попытками регистрации
После восстановления коммутационного оборудования после аварии на него одномоментно поступает резко возросший поток заявок. При этом избыточная (reject) нагрузка начинает доминировать.
Если производительности коммутационного оборудования достаточно для обработки входящей нагрузки,
77
Первый метод [7] предусматривает, что коммутационное оборудование при успешной регистрации пользовательского SIP-оборудования передает в ответном сообщении поле "Retry-After: X", где X - время в секундах, в течение которого SIP-телефон не должен передавать сообщения регистрации.
SlP/2.0 200 ОК Vn SIP/20/UDP
»1 adorta e*omplecom5060.brancb-z9hG4bK2d4790 I , received* 19202 111 Via: SIP/2 .O/UDP
cbor* aHaria oxarnplc com 5060 brancb=z9bG4b< 74Ы9, roc ef*od=192 0.2 101 Record-Route <*ip:s»2bloxjexomplecom;lr>( <up u 1 aHooia exomple.com lr>
From: Akce <srpake?c<kjr#a example com> tog -9txced76il To Bob <*ip bob?Ыохг example com>;»ag*314159
CoB-ID 38482762982201885) l«b<crto^crrykcom
СопдеЯюо Server » proxy 1 .nyc example com. NefcworV, level * 4. texJ“*80V I Ibmhald*
Retry-after: 30
CSeq 2 REGISTER
Context <4pbi^'~ client Ыош example com lrt:r%fx»rt^UDI
Второй метод [11] предусматривает, что коммута-цонное оборудование передает на пользовательское оборудование свой текущий уровень загрузки, а пользовательское SIP-оборудование рассчитывает значение интервала времени между попытками регистрации. Значения указываются в поле комментария, где параметр «ос» означает загрузку сервера в процентах, а «ос____validity» - задержку передачи и обработки инфор-
мации в миллисекундах.
SIP/2 0 200 0K Via: SIP/2 O/UDP
ul аёаПа •«ample com5060.broncb=z9hG4bK2d4790.1. received* 192.0.2 111
Vo SIP/2 O/UDP _________
«2 adarta enarrple com5060.branchaz9hG4bK2d4790.1 received“ 192.02.1 ;oc*2Qoc
_vdd#r500
Via SIP/2 O/UDP
»3 aiorta example com5060 bror>cb-z9hG4bK2d47901,received* 192.0.2.11 Vo: 9P/2.0/UDPcS-
ert adanlo example com5060,braocb-z9KG4bK74b<9: received-192.0.2.101 Record-Route <лр м2 Ыоя example com; lr> <*ip:u 1 aHoria e*omple.com.lr>
From: AJke <srp oke ' cibrto example com* tog^9fxced76d To Bob <ыр ЬоЬ вЫох! example com>;tog*314159 CaH-ID 3848276298220188511 oafor*> «яогфЬ com CSeq: 2 REGISTER
I'' : t ' О I • I ■ !>■•' •! I * i *1 ■ :ti| !• ir » :i f • .ft __________
Третий метод [6] предусматривает передачу на пользовательское оборудование команды "Register-Restart". Этот метод аналогичен первому из описанных выше и отличается от него наличием методики расчета значения паузы, не зависящей от текущей загрузки коммутационного оборудования. Расчет величины интервала осуществляется по формуле (R/C) * (1+к), где R - число SIP-телефонов, обслуживаемых контроллером, С - производительность в «регистрациях в секунду», и к - коэффициент допустимой перегрузки оборудования, выражающий избыточную производительность для обработки критических нагрузок (рекомендовано - 0,1).
diertafata.exomple com:5060;branch2z9bG4bK74bf9. rece*«d= 192.0.2-101 Record-Route <ыр:м2 bloxiexamplecom lr>. <«ip:u I oiaria exomplecom;lr>
From: Aice <ap akce<> aionta example com> tog =9fxced76d To Bob <vpbob's*b4o«examp4ecom> tagt:314159 Cail-ID. 3848276298220188511 codoNa.exirrple.com Regiiter-Reitart 300 CSeq 2 REGISTER
Contact: <Mpbob<1clicrtbloxi exomplecomttoniport°UDP>
Несмотря на наличие решений по управлению интенсивностью сигнального потока от пользовательского SIP-оборудования, при планировании сети необходимо учитывать, что существующий парк SIP-телефонов не поддерживает их. А учитывая, что жизненный цикл фиксированного телефона составляет 10-15 лет, можно говорить о том, что актуальность проблемы перегрузки коммутационного оборудования попытками регистрации сохраняется.
Таким образом, проблема перегрузки коммутационного оборудования попытками регистрации пользовательского SIP-оборудования является актуальной и новой для фиксированных сетей телефонной связи, построенных на базе технологий NGN/IMS, и требует разработки проектно-технических решений для ее предотвращения.
Литература
1. International Business Time. "Skype outage leaves site down in US and Europe." 21 Jan. 2010. http://www.ibtimes.com/ articles/20100121/ skype-outageskype-down-skype-slatus-skype-outage-skype-offline.htm (23 Feb. 2010).
2. Недоступность услуг Skype в августе 2007 г. // Информационный обзор ЦНИИС - 2007. - h? 11. - С. 12-13.
3. Peter Sayer. IDG News Service. "Skype Offers More Details of Outage." 21 Aug. 2007. http://www.pcwoHd.com/ article/136209/ skype_offers_more_details_of_outage.html (14 Mar. 2008).
4. Session Initiation Protocol Overlood Protection // Steavan H. Helden, Brian Somes, Timothy W. Bischoff, Arthur Doskow, Kevin V. Bohn, Gary L. Lockhart, Verizon Business Services, 2009.
5. NGN Control Plane Overload and its Management // tan Jenkins, British Telecom. MSF Technical Report MSF-TR-ARCH-007-FINAL. February 2006.
6. C. Shen, H. Schulzrinne, A. Koike. "A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control." // IETF SIPPING Working Group. 23 May 2010.
7. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston. RFC 3261 "SIP: Session Initiation Protocol". IETF. Jun. 2002.
8. Sean Donelan. Internet outage trends. Atlanta, Georgia, 2001. NANOG 21.
9. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. RFC 3665 "Session Initiation Protocol (SIP) Basic Call Flow Examples". IETF. Dec. 2003.
10. M. Zubair Rafique, M. Ali Akbar, Muddassar Farooq "Evaluating DoS Attacks Against SIP-Based VoIP Systems*. FAST Notional University of Computer & Emerging Sciences (NUCES) Islamabad, Pakistan. 2009.
11. V. Hilt, I. Widjaja, H. Schulzrinne. "Session Initiation Protocol (SIP) Overload Control". // IETF, draft-hilt-sipping-ovedoad-06. 7 Mar. 2009.
| Ум SlP/2 O/UDP
79
