Передача данных

рис. 3

Структурой сообщений SCTP предусматривается контроль формирования пакетов и сообщения данных в одном формате. На рис. 3показан формат пакета SCTP. Вслед за общим заголовком размещается один или несколько фрагментов переменной длины, которые используют формат «тип-длина-значение» (TLV — type-length-value). Различные типы фрагментов применяются для контроля переноса или информации о данных в пакете SCTP.

Любой пакет SCTP в ассоциации, не содержащий данный тег, при получении будет удален. Тег проверки защищает от старых, неактуальных пакетов, «отставших» от предыдущей ассоциации, а также от различных вторжений, позволяет избежать характерного для TCP состояния ожидания, при котором расходуются ресурсы и ограничивается общее число соединений, которые может поддерживать хост.

Каждый из типов фрагмента включает в себя информацию заголовка TLV, который содержит тип фрагмента, флаги обработки доставки и длину поля. Кроме того, перед фрагментом DATA будет размещаться пользовательская информация о полезной нагрузке, состоящей из номера транспортной последовательности (TSN — transport sequence number), идентификатора потока, номера последовательности потока (SSN — stream sequence number).

рис. 4

TSN и SSN — два разных номера последовательности для каждого фрагмента DATA. TSN используется для обеспечения надежности каждой ассоциации, а SSN для упорядочивания по потокам. Идентификатор потока отмечает отдельные сообщения в каждом потоке.

На рис. 4показан пример нормального обмена данными между двумя хостами SCTP. Хост SCTP посылает избранные подтверждения (фрагменты SACK) в ответ на каждый пакет SCTP, сопровождающий фрагменты DATA. Сообщение SACK полностью описывает состояние получателя так, что отправитель может принимать решение о повторной передаче в зависимости от того, что ему уже удалось получить. SCTP поддерживает алгоритмы быстрой повторной передачи и повторной передачи с тайм-аутом, аналогичные тем, которые применяются в TCP.

За небольшим исключением большинство типов фрагментов можно объединить вместе в один пакет SCTP.

Отключение

Транспортному протоколу, ориентированному на соединение, необходим метод постепенного отключения ассоциации. SCTP использует трехэтапную процедуру установки соединения, которая имеет важное отличие от процедуры, применяемой в TCP: конечная точка TCP может инициировать процедуру отключения, сохраняя открытым соединение и получая новые данные от другого хоста. SCTP не поддерживает такого «наполовину закрытого» состояния, т. е. обе стороны не могут передавать новые данные на свой более высокий уровень, если инициирована последовательность постепенного отключения.

рис. 5

На рис. 5показана типичная последовательность постепенного отключения в SCTP. В этом примере приложение на хосте A хочет отключить и закрыть ассоциацию с хостом Z. SCTP вводит состояние SHUTDOWN_PENDING, в котором он не будет принимать данные от приложения, но по-прежнему будет посылать новые данные, которые помещаются в очередь на передачу на хост Z. После подтверждения всех размещенных в очереди данных, хост A посылает фрагмент SHUTDOWN и вводит состояние SHUTDOWN_SENT.

До получения фрагмента SHUTDOWN хост Z уведомляет свой более высокий уровень, что прекращает принимать от него новые данные и вводит состояние SHUTDOWN_RECEIVED. Z передает оставшиеся данные на A, за которыми следуют фрагменты SHUTDOWN, информирующие Z о появлении данных и подтверждающие, что ассоциация отключена. Как только подтверждены все данные, помещенные в очередь на хосте Z, хост A посылает соответствующий фрагмент SHUTDOWN-ACK, за которым следует фрагмент SHUTDOWN-COMPLETE, завершающий отключение ассоциации. Развертывание протокола SCTP

19 компаний, в том числе Ericsson, Motorola, IBM, Cisco и Nokia, приняли участие в «конкурсе» SCTP, состоявшемся в апреле 2001 года. Здесь были продемонстрированы решения, в рамках которых реализована поддержка SCTP, такими операционными системами, как Linux, IBM AIX, Sun Solaris, Windows и FreeBSD. Успех тестов на интероперабельность между различными решениями позволяет предположить, что SCTP в скором времени будет поддерживаться в коммерческих продуктах.

Код SCTP уже можно получить в нескольких организациях. Компания Intellinet (www.intellinet-tech.com), поставщик решений конвергенции SS7/IP, предлагает стек протоколов SCTP. Компания Data Connection (www.dataconnection.com/sctp), производитель программного обеспечения сетевых протоколов разработала мобильную реализацию SCTP. Исходные тексты ядра Linux для поддержки SCTP предоставляет OpenSS7 (www.openss7.org). Несколько университетов работают над стеками протоколов SCTP, в том числе университеты Темпла и Делавера, а Рэнделл Стюарт разработал эталонную реализацию протокола для FreeBSD (www.sctp.org).

В дополнение к усилиям рабочих групп Sigtrans и Transport Area, к примеру, IETF активно изучает вопрос применения SCTP для поддержки транспортного уровня в HTTP и Diameter для обработки больших объемов сообщений. Несомненно SCTP окажет значительное влияние на технологии VoIP.

По мере того, как IP-сети начинают обрабатывать все больший объем голосового трафика, им потребуется взаимодействие с телефонными сетями, использующими сигнальный протокол на базе надежной передачи сообщений Signaling System 7 для установки голосовых соединений. Усилия рабочей группы Sigtrans направлены на адаптацию и инкапсуляцию сообщений протокола SS7 в IP-пакеты. Шлюзы, которые являются интерфейсами между SS7 и IP-сетями, являются основными кандидатами на создание ассоциаций SCTP с другими шлюзами SS7/IP или узлами VoIP при установке голосовых соединений. SCTP также предлагает механизм для разгрузки сети SS7; существующие сети SS7 используют относительно низкоскоростные каналы (56 Кбит/с) для транспортировки сообщений управления вызовами. По мере распространения мобильного Internet, эта дополнительная емкость, скорее всего, будет необходима для обработки растущих объемов сигнальных сообщений, представленных повсеместно распространенными приложениями, такими как служба коротких сообщений.

Вопросы будущегоСейчас IETF работает над следующей версией протокола SCTP, в которую будут внесены некоторые усовершенствования. Так, Джонатан Стоун продемонстрировал, что испорченные пакеты могут выходить из SCTP с корректной контрольной суммой Adler-32 (изначально использовавшейся в SCTP) и порождать проблемы на уровне приложений. В силу этого, рабочая группа Transport Area намерена заменить контрольную сумму на CRC-32, которая превосходно подходит для обработки пакетов небольшого размера.

Чтобы добиться паритета с традиционными приемами работы с существующими сетями SS7, рабочая группа изучает вопрос о том, как динамически добавлять и удалять IP-адреса в ранее созданные ассоциации. Это усовершенствование позволит администраторам динамически добавлять сетевую плату (и, таким образом, новый IP-адрес) в устройство (скажем шлюз SS7/IP), не создавая заново ассоциацию SCTP.

Учитывая, что в скором времени начнется распространение IPv6, протокол SCTP также должен «уметь» работать с адресами IPv6.

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