CC BY
86
7 декабря 2011 r. 18:49
ТЕХНОЛОГИИ ИНФОРМАЦИОННОГО ОБЩЕСТВА
О проблеме перегрузок в мультимедийных IP-ориентированных сетях
Будущее сетей операторов связи невозможно представить без подсистемы /MS (IP Multimedia Subsystem). Активный переход к полностью IP-ориентированным сетям для предоставления мультимедийных услуг, включая голосовые услуги, ставит новые вопросы о возможных перегрузках в сетях связи и необходимости анализа возникновения перегрузок и способов их предупреждения Сигнальный трафик в IP-ориентированных сетях порождаемый протоколом SIP (Session 1пНюИоп Protocol) при установлении, модификации и разьединении сеансов связи, существенно отличается от сигнального трофика ОКС 7 в традиционных сетях связи. В докладе показана необходимость исследования перегрузок в сетях, построенных на базе подсистемы IMS.
Реймер ДА,
Директор Департамента интегрированных бизнес решений,
ЛАНИТ,
reimer@lanitjv
Введение
Бурный рост интереса к IP-ориентированным сетям и активный переход операторов связи к предоставлению мультимедийных услуг на базе подсистемы IMS (IP Multimedia Subsystem) открывает перед операторами широкие возможности по конвергенции технологий и способов предоставления услуг. Использование пакетной коммутации и протокола IP для передачи и данных и голоса позволяет существенно расширить спектр услуг с одной стороны, но в то же время ставит новью задачи по обеспечению требуемого качества предоставляемых услуг. Предоставление услуг с требуемым уровнем качества в мультимедийных IP-ориентированных возможно при отсутствии блокировок в сети или выполнении автоматических процедур с использованием механизмов управления перегрузками.
Мультимедийные 1Р-ориентирошаныне сети
Идея построения мобильной сети на базе IP технологий прорабатывалась консорциумом 3GPP (3rd Generation Partnership Project) [1 ] для сетей мобильной связи. Первая спецификация 3GPP появилась в 1999 году и носила название 3GPP Release 99 [2]. В ней впервые были введены классы качества обслуживания QoS (Quality of Service) и намечен революционный переход от стандартизации услуг к стандартизации возможностей предоставления услуг (Services Capabilities). После этого в 3GPP начали разрабатывать концепцию мобильной сети, полностью базирующейся на протоколе IR но в силу трудоемкости задачи, ее решение было разбито на Release 4(2] и Release 5[2]. Архитектура IMS, полностью базирующаяся на IP впервые была представлена в Release 5. Предполагалось, что она должна стать независимой от технологии доступа и полностью базирующейся на IP сетевой архитектурой. В Release 6[2] в архитектуру IMS были введены изменения, а также появилась поддержка Wireless IAN сетей. Благодаря работе группы TISPAN, Release 7[2] 3GPP добавил поддержку фиксированных сетей и IMS стала основой и для сетей фиксированной связи следующего поколения (NGN, Next Generation Networks).
Основными функциональными элементами IMS являются модуль, реализующий функцию управления сеансами связи CSCF (CaD Session Control Function) и сервер домашних абонентов HSS (Home Subscriber Server), факту^ески являющийся базой пользовательских данных.
В состав модуля CSCF включены три функции — функция обслу-
живания (S-CSCF, Serving CSCF), функция запроса (Interrogating CSCF, I-CSCF) и функция прокси-сервера (P-CSCF, Proxy CSCF). Функция S-CSCF предназначена для регистрации абонентов в базе данных HSS, а также осуществляет контроль и управление сеансами связи. Функция I-CSCF реализует доступ в домашнюю сеть и, в случае необходимости, может выполнять функции сетевого экрана, скрывая внутреннюю топологию сети. Функция Р-CSCF обеспечивает первую точку контакта для терминала IMS, а также может выполнять шифрование и сжатие сообщений. Важно, что в общем случае при управлении сеансами связи функциональные узлы IMS (далее, для краткости — узлы IMS) обмениваются сигнальными сообщениями и создают сигнальный трафик, который должен обслуживаться с заданными параметрами качества, которые могут определяться требованиями стандартов, а также соглашениями об уровне обслуживания (SIA Service level Agreement). Узлы CSCF обмениваются между собой сообщениями протокола SIP, а для обращения к серверу HSS используется протокол Diameter. Терминалы абонентов (UE, User Equipment) соединяются посредством узлов Р-CSCF тех сетей, в которых они на данный момент находятся и через эти функции взаимодействуют с другими узлами IMS, находящимися в их домашних сетях. При регистрации абонента в некоторой сети, функция P-CSCF этой сети определяет домашнюю сеть абонента и соответствующую функцию S-CSCF, в которой он обслуживается.
Особенности механизма управления
перегрузками сигнального трафика
Важным звеном в подсистеме IMS является протокол SIP (Session Initiation Protocol) [31 выполняющий роль основного протокола сигнализации, который используется для установления, мод ификации и разьединения сеансов связи, аналогично ОКС 7 для сети GSM и для интеллектуальной сети связи.
Протокол SIP позволяет устанавливать сессии, передавая согласованные между инициаторами соединения параметры и совместимые типы медиаданных. SIP использует так называемые прокси-серверы для более эффективной маршрутизации запросов текущего местонахождения пользователя, его аутентификации и авториза^ и других различных услуг, а также осуществляет функции маршрутизации, регистрации пользователей и др. Существует множество приложений, требующих установления и управления соединениями, где сессия представляет собой обмен данными между некоторым количеством участников. Внедрение подобных приложений осложняется поведением пользователей, которые могут перемещаться между оконечными устройствами, иметь несколько адресных имен, одновременно использовать различные мультимедиа сервисы. Некоторые протоколы могут осуществлять передачу разных типов данных в режиме реального времени, таких, как голос, видео, текстовые сообщения. SIP работает в соответствии с концепцией таких протоко-
148
T-Comm, #7-2010
ТЕХНОЛОГИИ ИНФОРМАЦИОННОГО ОБЩЕСТВА
лов, устанавливая оконечные точки (называемые пользовательскими агентами UA) для установления местонахождения друг друга, а также для согласования параметров соединения. Для локализации возможных участников соединения, SIP поддерживает создание инфраструктуры сетевых хостов (прокси-серверов), на которые пользовательские агенты UA отправляют сообщения о регистрации, запросы на установление сессий. Таким образом, SIP является гибким многофункциональным инструментом создания, управления и завершения сессий, работающим независимо от транспортных протоколов более низких уровней, а также независимо от типа устанавливаемого соединения.
Несмотря на популярность и увеличение количества внедрений в промышленной эксплуатации механизм управления перегрузками в протоколе SIP малоизучен. Хотя протокол SIP и обладает базовым механизмом управления перегрузками, но на практике этот алгоритм оказался малоэффективным и часто не способным предотвратить перегрузку SIP серверов. Проблема становится еще более актуальной в настоящее время, т.к внедрения становятся более масштабными и охватывают все большее число пользователей.
Перегрузка на SIP серверах возникает, если интенсивность поступления сообщений превышает возможности по обработке сообщений. При повышении нагрузки производительность сервера существенно подает. Кроме этого SIP сервер генерирует внутренние сообщения, например, для повторной передачи сообщения, если не был получен ответ на предыдущее сообщение в требуемое время. Это приводит к тому, что перегрузка сервера может возникнуть и в случае, когда интенсивность поступления сообщений меньше, чем скорость обработки сообщений. Таким образом, перегрузка на одном сервере может повлечь за собой перегрузки на соседних серверах и привести к перегрузке всей сети.
Рассмотрим механизм возникновения блокировок более подробно. Для обеспечения надежных соединений SIP-сообщения д олжны передаваться поверх протокола ТС В однако, иногда используется ненадежное UDP-соединение в зависимости от технических характеристик оконечного оборудования. В этом случае для того, чтобы компенсировать ненадежность передачи SIP-сообщений, SIP-запросы передаются вновь, если не был получен адекватный ответ в течение заданного промежутка времени. Хотя пересылки повышают надежность, они вызывают перегрузки сигнальной сети SIP
На Рис 1 представлена типичная сетевая структура протокола SIP Перед установлением сессхи между вызьвающим (пальзоватегь-А (user А) на Рис-1) и вызываемым (пользователь-В (user В) на Рис1) их пользовательские агенты (UA) обмениваются информацией, необходимой для установления сессии посредством SIP-сигнализации, которая осуществляется посред ством отправки запросов и ответов через прокси-серверы SIR причем пути доставки таких запросов независимы от пути установления сессии. На Рис. 1 обмен сигнальными SIP-co-общениями происходи между соседними компонентами сети 1, 2, 3. Присваивая адрес SIP URI, каждый прокси-сервер SIP выполняет маршрутизацию запросов и ответов протокола SIP
На рис2 представлена типичная временная диаграмма установления SIP-сессии. Пользователь-A запрашивает пользователя-В, используя его уникальный идентификатор SIP URI, посылая ему первоначально сообщения типа INVITE. Узел, получивший такое сообщение, возвращает предварительный ответ 100 Trying, подтверждающий получение IMVTTE и содержащий параметры для продолжения установления сессии, и в случае успеха пользователь-В возвращает 180 Ringing. Когда пользователь-В отвечает, отправляя сообщение типа 200 ОК, и пользователь-А получает его, он немедленно отправляет обратно подтверждение установления сессии АСК. Как только это произошло, оба пользователя обмениваются различными мультимедиа пакетами, и по окончании вызова сторона-инициатор отправляет сообщение типа BYE для завершения сессии.
Базовый механизм управления перегрузками в SIP протоколе использует код ошибки 503 (Service Unavailable). В сл/чое если SIP сервер не может обработать запрос из-за временной перегрузки, то он отклоняет запрос с кодом ошибки 503. Перегруженный сервер может добавить Retry-After заголовок в SIP сообщение об ошибке, указав время в секундах, в течение которого сервер не хочет получать каких-либо сообщений от отправителя. Отправитель, прекращает отправку сообщений на этот период времени и возобновляет после его окончания.
Кроме этого, протокол SIP предусматривает два типа процедур повторной отправки сообщений [4]: сообщения INVITE и остальные (200 OK, BYE, АСК), причем время отправки Т1 определено в документе RFC 3261 [3]. Пересылка сообщений INVITE со стороны клиента происходит с первоначальнькм интервалом вТ1 секунд (значениеТ1 по умолчанию равно 500ms), который затем удваивается после каж-
Домен А
Агент пользователя (UA) Пользователь А
Агент пользователя (UA) Пользователь В
FW.1. Сетевая структура протокола SIP
T-Comm, #7-2010
149
ТЕХНОЛОГИИ ИНФОРМАЦИОННОГО ОБЩЕСТВА
Источник SIP UA
(Пользователь А)
Ф
A INVITE
SIP Proxy-а
Получатель SIP UA SIP Proxy-b (Пользователь В)
100 Trying
180 Ringing
200 OK
_ACK_
A BYE
!®
I 200 OK
INVITE
180 Ringing
200 OK
ACK
INVITE
100 Trying
180 Ringing
200 OK
2
ACK
Сессия установлена
BYE
200 OK
BYE
200 OK
IViC 2. Временная диаграмм обмена SlP-сообщвниями
дой передачи пакетов, и прекращается в случае, когда получен требуемый ответ или когда с момента первой отправки прошло более 64?Т1, то есть 32 секунды Повторная пересьика сообщений, отличных от INVITE (200 OK и BYE), происходил иначе. В RFC 3261 задан интервал Т2: запросы вновь отправляются через время Т1, которое удваивается для каждого следующего пересылоемого пакета, пока не достигает значения Т2 (по умолчанию равно 4 секундам). В соответствии со стандартом RFC 3261, сообщения типа INVITE пересылаются 7 раз, а 200 ОК и BYE — 11 раз в общем итоге, что может негативно влиять на производительность сигнальной сети в целом
Примеры простейших моделей управления
перегрузками
Рассмотрим структуру сигнальной SIP-сети на рис 3. Источниками являются пользовательские SIP-агенты (UA), показанные квадратиками в левой части рис. 3, соединенными с роутерами, обозначенными кружками. Прокси-серверы SIR обозначенные квадратиками серого цвета, также соединены с роутерами. Области, окруженные пунктирными линиями, составляют домен, причем каждый О- п-1 домен содержит т пользовательских агентов UA и один прокси-сервер SIR Домен п включает в себя пхт получателей-пользо-вательских агентов SIP (обозначенных в правой части рис 3 небольшими квадратами) и один прокси-сервер SIP Роутеры 0 - л-1 соединены с роутером п, а пути маршрутизации сессий (обозначены на рис 3 пунктирными стрелками) независимы от путей рассылки SIP-сообщений. Все пхт пар источников и приемников UA могут устанавливать сессии, и если каждый приемник находится в домене п, то все SIP-сообщения направляются на прокси-сервер SIR что в таком случае может привести к образованию пробки на сервере.
Управление перегрузками может быть как локальным, применяемым на конкретном SIP-сервере, так и распределенным, включающих несколько SI Р-серверов.
Первый алгоритм локального управления — эго простой алгоритм bang-bang control (ВВС)[4]. В рамках аппарата теории массового обслуживания система поступления SIP-сообщений на сервер — этоси-
стема с очередью заданной емкости В, с дисциплиной обслуживания FIFO, причем время обслуживания таких сообщений на сервере зависит от их типа. Обьнно сообщения Tvna INVITE требуют больше времени, чем остальные, поскольку они предполагают также предварительный запрос SIP URI в базе данных [3,4]. Введем д ва пороговых значения наполнения очереди Ь и I с целью обнаружения перегрузок; если в очереди находится более Ь заявок, то прокси-сервер SIP переходит в состояние перегрузки, впоследствии, если число заявок в буфере становится меньше I, сервер считает перегрузку ликвидированной. Таким образом, сервер может находиться в двух состояниях; рабочем "полпаГ и состояhvh перегрузки "congesfon", и переходы из одного в другого можно описать следующей неравенствами. Если х — колкме-ство заявок в очереди, то в стационарном режиме данной СМО сервер переход ит в состояние "congestion" при х > h и возвращается об-
Источник SIP UA .
Получатель
/ SIP_QXy.?r . . Сессия в. /..........0 \
і 0.--------------[..Сессия 1/........Л7|
\ QJ j
PI SIPProjy о
Домен О
/ SIP UA / П SIP Proxy/M
! □ домам и
Рис 3. Модель сигнальной сети на базе протокола SIP
Домен п
□
Сессия (т я п- 1)
□
150
T-Comm, #7-2010
ТЕХНОЛОГИИ ИНФОРМАЦИОННОГО ОБЩЕСТВА
ротно при х<1. Когда сервер находится в состоянии перегрузки, сигнальная сеть SIP регулирует поступление новых вызовов, и если в обычном случае прокси-сервер SIP отправляет "1 ОСУ' в ответ на запрос "INVrTP*, то в данном — возврачрет "503”, что означает, что сервис недоступен- Согласно RFC 3261, когда источит SIP UA (клиент) получает ответ с кодом "300-699“, он должен в течение времени D (равного 32 секундам по умолчанию) оставаться в состоянии, когд а он не может посылать сообщения "INVITE". Регулируя поступление новых вызовов изменением значения D, можно уменьшить или временно ликвидировать нагрузку на сеть.
Второй алгоритм локального управления называется occupancy (ОСС)[51 в котором входящие INVITE запросы принимаются с вероятность f (или отклоняются с вероятностью 1 -/). Алгоритм ООС базируется на том, что нагрузка (занятость) на сервер равна р. Целью алгоритма является динамическое регулирование значения f для поддержания коэффициента нагрузки на уровне или ниже полученного целевого значения pta(g. Нагрузка р периодически обновляется каждые Т секунд.
Каждые Nh моменты времени коэффициент нагрузки р, обновляется и сравнивается с р^. Основная идея алгоритма состоит в увеличении значения f, если р < ptoig, и уменьшении в противном случае.
Разумное управление ретрансляциями ответов может позволить предотвратить отправку лишних копий потерянных сообщений и таким образом увеличить поступающую нагрузку.
Вместо просмотра сообщений, локальное управление перегрузками позволяет сдерживать ретрансляции при отказе в обслуживании. Кроме того, когда сервер может отклонить индивидуально каждый запрос, он может легко выбрать и группу запросов для отклонения, тем самым "сглаживать" контроль обслуживания поступающих запросов При этом локальное управление перегрузками не требует объединения серверов.
В свою очередь распределенные механизмы управления перегрузками позволяют загруженному серверу избавиться от необходимости ретрансляции запросов на другие сервера по маршруту.
При распределенном управлении перегрузками SIP-сервера задействованы в обеспечении обратной связи (для контроля перегрузок) с серверами, которые располагаются дальше в сети в направлении пересылки сообщений. Обратная связь для контроля перегрузки может осуществляться, например, за счет передачи информации в заголовках SIP-отеетов [6]. Цикл обратной связи для контроля перегрузки может быть применен как между парами соседних SIP серверов на всем маршруте (Нор-Ьу-Ьор), так и централизованно, обеспечивая сквозное управление на всем маршруте (End-to-end).
Неэффективность работы механизма управления перегрузками в SIP протоколе исследована в работе [7], в которой было проведено имитационное моделирование на нескольких топологиях сети с использованием представленных алгоритмов ВВС (Bang-Bang Control) и ОСС (Occupancy Algorithm) в различных моделях контроля перегрузками, в результате которого показано, что использова-
(а) Пошаговое
V —ll
^ X Jl
' ' \ J
(Ь) Сквозное
Рис 4. Модели распределенного управления перегрузками
ние механизма ретрансляции различными SIP-таймерами приводит как к перегрузкам серверов, так и может вызвать лавинную перегрузку во всей сети.
Необходимо дальнейшее более детальное изучение моделей сигнального SIP-трафика в масштабе всей сети. Распределенные алгоритмы управления являются более эффективными для предотвращения перегрузки всей сети, но и существенно более сложными и трудоемкими по сравнению с алгоритмами локального управления.
Заключение
Увеличение масштабов внедрения мультимедийных IP-ориентированных сетей и бурный рост числа пользователей ставит новые вопросы в исследовании механизмов сигнализации на базе протокола SIP Существующие механизмы управления перегрузками в протоколе SIP являются неэффективными и требуют дополнительной проработки и, возможно, развития и доработок в протоколе. Исследование моделей поведения пользователей и серверов в сети IMS и более глубокий анализ работы механизмов сигнализации в крупных IMS сетях позволит повысить стабильность работы сети и обеспечить требуемый уровень качества услуг для пользователей.
Литература
1. 3rd Generation Partnership Project, http://www.3gpp.org.
2.3GPP Release 99,4-7, http://www.3gpp.org/reieases
3. J. Rosenberg. SIP: Session Initiation Protocor, RFC 3261, hllp://www.ietf.org/rfc/rfc3261M, 269 pp.
4 Masalaka Ota. "Overbad Control in a SIP Signaling Network", PWASET VOLUME 12 march 2006 ISSN 1307-6884, 205-210 pp.
5 B. L Cyr, 1 S. Kaufman and P. T. Lee. "Load balancing and overload control in a distributed processing telecommunication systems," Unied States Patent No. 4,974,256, 1990.
6 V. Hit I- Widjaja and H. Schubrinne. Session Inifiaion Protocol (SIP) Overbad Control," IETF, Intemet-Drafi, drali-hilt-sipping-overtoad, 2008, 21 pp.
7 V. Hi and Indra Wc^aja "Controling Overload in Netwoiks of SIP Servers",IEEE, 2008, 83-93 pp.
T-Comm, #7-2010
151
