
- •Глава 7 Группа Sigtran
- •7.1. Система общеканальной сигнализации №7 в ip-сети
- •Архитектура Sigtran
- •Транспортный протокол с управлением потоками
- •Основные функциональные возможности sctp
- •Множественная адресация
- •С множественной адресацией
- •Соединения для нескольких потоков
- •Фрагменты
- •7.3.5. Фрагмент полезной нагрузки data
- •Б.С.Гольдштейн
- •Установление соединения
- •Протокол m3ua
- •Функции m3ua
- •Терминология
- •Код пункта сигнализации
- •Примитивы
- •7.4.5. Сообщения m3ua
- •Протокол m2ua
- •Протокол м2ра
- •Протокол sua
- •Протокол iua
- •Протокол v5ua
Глава 7 Группа Sigtran
Не меняются только самые мудрые и самые глупые
Конфуций
7.1. Система общеканальной сигнализации №7 в ip-сети
Речь в главе идет, разумеется, о первой из двух групп, указанных в приведенном в качестве эпиграфа изречении. Действительно, последняя и лучшая из двух региональных (R1 и R2) и семи международных систем сигнализации, стандартизованных МККТТ, - система общеканальной сигнализации №7 (ОКС7) - оказалась чрезвычайно удачной. Только мудростью разработчиков ОКС7 и созданной ими архитектурой стека протоколов ISUP, MAP, INAP, ТСАР, SCCP, МТР 1, 2, 3 и др. можно объяснить долгую жизнь и сохраняющуюся перспективность этой системы сигнализации. И в сегодняшнем инфокоммуникационном мире, революционно изменяющемся в процессе конвергенции, роль ОКС7 практически не меняется.
Именно поэтому в рамках IETF и была создана рабочая группа Sigtran (IETFSigTran Working Group), предназначенная для исследования транспортировки сигнальной информации ОКС7 в сетях IP и взаимодействия с другими сетями, в частности, ТфОП. С момента первого своего заседания в Орландо в 1998 этой рабочей группе удалось создать достаточно полную архитектуру ОКС7 (и не только ОКС7) поверх IP. Прежде чем приступить к ее обсуждению в этой книге, читателю, не знакомому со стеком протоколов ОКС7, было бы очень полезно пролистать параграф 8.4 учебника [6], или главу 10 книги [4], или более подробные источники [12].
Чтобы прояснить взаимодействие ОКС7 с протоколами сигнализации, описанными в предыдущих главах, рассмотрим в качестве примера сценарий на рис. 7.1, являющийся расширением сценария, изображенного на рис. 6.6 предыдущей главы. В этом
сценарии уже два Softswitch связываются друг с другом по протоколу SIP (глава 4) и управляют соответствующими транспортными шлюзами MG по протоколу Megaco (глава 6). Шлюзы сигнализации соединяют Softswitch непосредственно с пунктами сигнализации SP или транзитными пунктами сигнализации STP сети ОКС7. Поскольку Softswitch управляют обслуживанием вызовов в своих сетях, преобразованные в SG сигнальные сообщения ISUP направляются в Softswitch.
Пересылка сигнальной информации ISUP от SP/STP к SG и от SG к SP/STP помечается на рис. 7.1 как ISUP (в трактовке ®ITU_т), а пересылка той же сигнальной информации от SG к Softswitch или от Softswitch к SG помечается как принадлежащая IP, т.е. ®Sigtran. Содержание сообщений при этом не изменяется, а единственное отличие состоит в том, что сообщения ISUP передаются к Softswitch и от него поверх IP, а не поверх стандартного протокола МТР(Message Transfer Part) стека ОКС7. Таким образом, все, что делает SG, - это получает сообщение ISUP из сети ОКС7 и доставляет его к соответствующему объекту в сети IP.
Рис.
7.1.
Сценарий
установления соединения SIP/Megaco
/ISUP
В некоторых реализациях сообщения ISUP просто помещаются в пакеты UDP или TCP и передаются из SG в Softswitch, т.е. вместо ®sigtran■ используются ®UDP или ®тср. Однако оба этих подхода ущербны с точки зрения характерных для ОКС7 строгих требований к парамет-
рам потерь сообщений и к соблюдению очередности следования сообщений. Эти требования не позволяют всерьез использовать UDP, поскольку он ненадежен в своей основе. Гораздо больше надежд возлагалось на протокол TCP, но и он не подходит по своим временным характеристикам: хотя TCP может гарантировать строгую очередность доставки сообщений, доставка происходит недостаточно быстро. Это связано с тем, что блокировка несвоевременно пришедших данных, предлагаемая протоколом TCP, вносит ненужную задержку. Поясним подробнее и другие проблемы, связанные с использованием TCP.
Протокол TCP отслеживает переданные байты и подтверждает принятые байты. Этот характер протокола TCP, ориентированный на передачу байтов, часто причиняет неудобства, когда приложение желает отслеживать переданные сообщения в целом. Чтобы гарантировать, что все сообщение передано в приемлемое время, приложение должно добавлять собственную маркировку для очерчивания границ своих сообщений и использовать в явном виде средство форсированной отправки push протокола TCP
Ограниченная область действия TCP-портов усложняет задачу переноса данных с множественной адресацией - весьма важное обстоятельство, обсуждающееся ниже в этой главе. Менее важный аспект, связанный с протоколом TCP, - его уязвимость к атакам злоумышленников, приводящим к отказу в обслуживании, например, к SYN-атакам, которые могут засорить сеть и сделать законный доступ практически невозможным (атака TCP-SYN - это когда злонамеренный объект постоянно пытается открыть TCP-соединения с атакуемым объектом с целью истощить его ресурсы). Несмотря на то, что такие атаки трудно полностью исключить, могут быть введены методы, позволяющие ограничить их последствия.
Разработкой средств доставки сообщений ISUP поверх IP, свободных от недостатков UDP и TCP, и занимается рабочая группа Sigtran. Предложенные ею общий подход и методология для транспортировки сигналов ОКС7 по сетям IP изложены в документе RFC 2719 «Framework Architecture for Signaling Transport». Но - обо всем по порядку.