Многие докладчики говорили о необходимости создания для IP-телефонии новых протоколов, которые позволят упростить аппаратно-програмную реализацию и обеспечить лучшую совместимость оборудования различных производителей.

Стандарты для VoIP

Сейчас среди стандартов в области передачи речи поверх сетей IP доминирует всем хорошо известный Н.323. Его первая редакция была принята в 1996 г., вторая — летом 1998 г. Но стоит напомнить, что Н.323 является целым семейством рекомендаций ITU-T, разработанных для организации видеоконференц-связи в пакетных сетях с негарантированным качеством обслуживания. Эти взаимодополняющие протоколы создавались на основе семейства Н.320, которое описывает видеоконференц-связь по сетям ISDN.

Когда стали появляться решения, предназначенные для передачи только голоса поверх IP, то, естественно, их разработчики первым делом обратили внимание на Н.323. Однако этот стандарт (в первую очередь, та его часть, которая определяет процессы сигнализации и управления) вызвал множество нареканий.

Указанное семейство рекомендаций уже неоднократно описывалось на страницах нашего журнала, а о том, как осуществляются сигнализация и управление, заинтересованный читатель может узнать из статьи А. Осадчука и С. Матвеева «Стандарт мультимедийной конференц-связи Н.323» («Сети», 1999, № 8-9, с. 16).

Несмотря на постоянное обновление Н.323 (сейчас идет работа над третьей редакцией) данный протокол перестал удовлетворять нуждам рынка IP-телефонии. Во-первых, он очень избыточен и при его реализации требуются значительные ресурсы, что приводит к росту стоимости оборудования. Во-вторых, оставляет желать лучшего совместимость решений на базе Н.323, созданных различными производителями. Дело в том, что каждый из них пытается «облегчить» этот протокол по своему усмотрению, а в результате возникает множество «фирменных» реализаций, имеющих мало общего с исходным Н.323.

Данная ситуация привела к появлению новых протоколов, предназначенных для передачи сигнальной информации по сетям пакетной телефонии. Некоторые из них (SIP, Megaco, MGCP) уже существуют, другие еще разрабатываются. Об одном из таких протоколов — SCTP (Stream Control Transmission Protocol) — мы и расскажем.

Хорошие новости

SCTP разрабатывается в рамках IETF (RFC 2026) как протокол для передачи сигнальной информации между телефонными станциями, включая ОКС №7 (SS7), поверх сетей IP. В начале июня нынешнего года в лаборатории компании Siemens проводились испытания на совместимость реализаций SCTP, созданных различными производителями. В тестировании приняли участие фирмы 3Com, Alcatel, Ericsson, Motorolla, Telcordia and Trillium, Nokia, Sun, Nortel Networks, Performance Technologies (точнее — недавно приобретенная последней компания MicroLegend), Siemens и корейская S-Link.

На базе испытываемого оборудование создали сеть. Каждый производитель организовал две IP-подсети, которые были подключены к эмулятору глобальной сети. Это устройство генерировало «условия», характерные для Internet, — имитировались задержки, искажения и потери IP-пакетов.

Тестирование предусматривало четыре сценария. В первом (нереальном) случае отсутствовали задержки и не было потерь информации. В другом варианте имитировались различные задержки, как постоянные, так и меняющиеся в ходе сеанса передачи информации (они имеют наиболее «разрушительный» характер). Затем проверялась устойчивость к потерям пакетов, но без задержек. И наконец, оборудование заставили работать в самых жестких условиях: одновременно вводились всевозможные задержки и организовывалась потеря части передаваемой информации.

В ходе испытаний проверялись базовые функции протокола SCTP:

  • установка и сброс соединений SCTP;
  • перенаправление трафика по альтернативному пути при отказе основного маршрута;
  • передача данных в правильной последовательности;
  • разрешение коллизий, возникающих при установке соединений.

Как сообщили участники тестирования, результаты превзошли любые ожидания: оборудование всех компаний показало отличную совместимость между собой. Эти исследования дали массу материала рабочей группе Sigtran (Signaling Transport) IETF, которая создает SCTP. По словам ее председателя доктора Линдона Онга из фирмы Nortel Networks, группа пришла к выводу, что протокол способен поддерживать не только передачу сигнализации, но и выполнение других приложений.

Архитектура SCTP

SCTP пока еще имеет статус draft-стандарта. Хотя в Sigtran поступило для рассмотрения несколько вариантов его реализации, уже сейчас понятно, что будет собой представлять этот протокол и как он будет функционировать.

Изначально SCTP разрабатывался для передачи сигнальной информации традиционных телефонных станций через сеть IP. Он обеспечивает следующий сервис:

  • безошибочную передачу с подтверждением приема;
  • фрагментацию данных с учетом максимальной длины передаваемого блока в IP-пакете (параметр MTU);
  • соблюдение верной последовательности сообщений для каждого приложения внутри потока, объединяющего информацию от многих источников;
  • оптимальную упаковку информации для нескольких приложений в одном IP-пакете;
  • устойчивость передаваемых данных к сетевым ошибкам.

Кроме того, протокол имеет механизмы защиты от перегрузок, которые могут возникать в ходе хакерских атак или некорректной работы сети.

SCTP допускается рассматривать как функциональный уровень между приложениями, пользующимися его услугами, и пакетной сетью типа IP, которая не обеспечивает поддержку соединений. На рис. 1 показана организация связи между двумя приложениями с использованием этого протокола. Легко заметить, что он не задействует сервис, предлагаемый TCP или UDP. Разработчики настроены весьма оптимистично: они заявляют, что SCTP можно рассматривать как вариант замены широко применяемых протоколов транспортного уровня.

Как известно, UDP позволяет осуществлять быструю передачу информации без установления соединений. Данный протокол поддерживает так называемую передачу, ориентированную на сообщения, и очень хорошо подходит для транспортировки данных, критичных к задержкам и устойчивых к потере и дублированию пакетов.

В свою очередь, TCP ориентирован на соединения или потоки. Он обеспечивает хорошую защиту от искажения информации, но мало подходит для передачи данных, критичных к задержкам. При транспортировке сигнализации телефонных станций характерная для TCP поддержка строгой последовательности принимаемых данных может сослужить плохую службу. Допустим, что с помощью сегментов TCP передается информация о нескольких телефонных вызовах, и один из пакетов IP пришел искаженным. Пока осуществляется его повторная передача, остальные данные блокируются, хотя они приняты верно и уже могут быть задействованы для проключения разговорных каналов связи. Таким образом, увеличивается время установления телефонного соединения.

Разработчики SCTP постарались использовать лучшие черты UDP и TCP при создании протокола, предназначенного для передачи столь специфической информации, как телефонная сигнализация. Протокол позволяет разбивать передаваемое сообщение для размещения в нескольких IP-пакетах или мультиплексировать несколько сообщений в одном IP-пакете. Дополнительно обеспечивается устойчивость к ошибкам за счет поддержки нескольких IP-адресов на одном узле SCTP.

Для описания основного информационного блока разработчики использовали термин «пакет», хотя, согласно семиуровневой модели OSI, PDU (Protocol Data Unit) транспортного уровня следует называть сегментом (кстати, именно «сегмент» фигурирует в описании TCP). Но для исключения возможной путаницы не будем отходить от терминологии, предложенной Sigtran.

Пакет SCTP состоит из заголовка и нескольких субпакетов (chunk), которые представляют собой информационные блоки с собственными заголовками. Каждый субпакет служит для передачи автономной информации. Например, в отдельных субпакетах могут размещаться данные, предназначенные для установления речевых соединений в разных направлениях. На рис. 2 показаны форматы пакета SCTP, его заголовка и субпакета. В каждом пакете допускается размещать несколько субпакетов, что обеспечивает мультиплексирование различных потоков информации. Число субпакетов зависит от длины каждого из них и параметра MTU (Maximum Transfer Unit), определяемого протоколом IP.

Форматы SCTP

Заголовок пакета включает в себя четыре поля, назначение которых типично для телекоммуникационных протоколов. Имеется два 16-разрядных поля (номера портов отправителя и получателя), которые фактически являются аналогами «портов», используемых в TCP/UDP. Поле Verification Tag (проверочная метка) имеет длину 32 бита и предназначено для проверки отправителя пакета. Его значение определяется на этапе установления соединения. Благодаря этому механизму улучшается защищенность информации от возможного искажения. Назначение поля контрольной суммы пакета SCTP, думаю, не требует отдельного пояснения.

Более подробно опишем формат субпакета.

В нем также можно выделить поля, выполняющие функции заголовка. Одно из них, восьмиразрядное поле типа субпакета, способно принимать до 255 значений (в настоящее время определены 15, а остальные зарезервированы). Если данное поле имеет нулевое значение, то это говорит о передаче полезной информации (payload data); в других случаях субпакет «несет» служебные сведения. Второе поле, тоже состоящее из восьми бит, содержит флаги; его использование определяется типом субпакета. Третье, поле длины c разрядностью 16 бит, заполняется суммарным значением длины субпакета с учетом полей заголовка.

Информационная часть предназначена для передачи собственно данных, которые определяются типом субпакета. Согласно протоколу SCTP, размерность субпакета должна быть кратна четырем. В противном случае информационная часть дополняется нулевыми значениями, но в поле длины указывается истинная величина. Это позволяет на приемном конце соединения исключить добавленные нули из передаваемых данных.

Функционирование SCTP

Как и любой другой протокол транспортного уровня, SCTP может быть представлен в виде набора некоторого числа процедур (иерархическая модель их взаимодействия приводится на рис. 3). Кратко рассмотрим их назначение.

Иерархия процедур SCTP

Установление и завершение сеанса связи (Association startup and takedown). В соответствии с запросом от приложения, использующего протокол SCTP для передачи информации, устанавливается сеанс связи. Для повышения защищенности данных, передаваемых по сети IP, на этом этапе применяются служебные индексные файлы, более известные как cookies. Они хранятся на каждой стороне соединения и позволяют не передавать по каналу связи часть информации, необходимой для его установления. В протоколе предусматриваются два варианта завершения сеанса связи — нормальное и аварийное. В первом случае инициатива исходит только от приложения, а инициатором второго могут выступать и процедуры самого протокола SCTP (например, при обнаружении некоторых ошибок). В отличие от TCP, данный протокол поддерживает прекращение отсылки данных в сеть обеими сторонами.

Проверка пакета (Packet Validation). Обязательное поле Verification Tag и поле контрольной суммы заголовка пакета SCTP позволяют проверять подлинность принимаемых данных. Как указывалось выше, значение поля Verification Tag для каждой стороны определяется на этапе установления соединений. Пакеты с неверным значением игнорируются. Выбраковываются и пакеты с неверной контрольной суммой.

В паре с проверкой пакетов используется процедура управления маршрутом (Path Management). В процессе последней определяется IP-адрес назначения в соответствии с правилами, которые задают приложения, и текущим состоянием возможных путей передачи.

Упаковка субпакетов (Chunk Bundling). Основным назначением этой процедуры является заполнение данными отдельных субпакетов и формирование из них пакета SCTP. Разумеется, выполняется и обратное действие.

Подтверждение приема и устранение перегрузок (Acknowledgement and Congestion Avoidance). Данная процедура состоит в назначении уникального номера TSN (Transmission Sequence Number) каждому сообщению. Этот номер никак не привязан к идентификаторам потоков, присваиваемым на уровне приложения. Приемная сторона посылает подтверждения на все принятые TSN, даже если в принимаемой последовательности имеются пропуски, т.е. обеспечение гарантированности доставки функционально отделено от организации самой доставки. Условия, в которых требуется повторная передача пакета, аналогичны с определяемыми протоколом TCP.

Фрагментация данных (User Data Fragmentation). Эта процедура позволяет согласовать размеры сообщений, передаваемых от приложения, с установленными значениями MTU. На приемной стороне фрагменты вновь «склеиваются».

Обеспечение последовательности внутри потоков (Sequenced delivery within streams). В SCTP под потоком подразумевается набор сообщений, следующих от приложения, который должен быть доставлен в заданной последовательности вне зависимости от других сообщений этого же приложения. Число потоков определяется на этапе установления соединения. Протокол SCTP присваивает номер потока каждому сообщению, поступающему от приложения. На приемной стороне происходит проверка корректности доставки различных потоков. Если теряется часть информации какого-либо из них, это никак не сказывается на доставке данных из других потоков. Такое свойство очень выгодно отличает SCTP от TCP.

* * *

Хотя новый протокол еще не прошел процедуры официального утверждения в IETF, уже сейчас можно предсказать, что он займет достойное место в телекоммуникационных сетях.