Sctp протокол что это

SCTP: надстройка протокола TCP для улучшения эффективности его работы

ОЛЕГ РУДЗЕЙТ, студент группы информатики и вычислительной техники, кафедра информационных систем управления, ДВФУ, Владивосток, rudzeyt18@mail.ru АННА СМЫШЛЯЕВА, студентка группы информатики и вычислительной техникиа, кафедра информационных систем управления, ДВФУ, Владивосток, AnyaC957@mail.ru

SCTP: надстройка протокола TCP
для улучшения эффективности его работы

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

Описание протокола TCP/IP

В 70-х годах ХХ века потребовалось создать протокол, который смог бы безопасно передавать данные. Поэтому при создании TCP все усилия были направлены на создание механизма надежной, а не скоростной передачи. В те годы не было мобильных и спутниковых сетей, а единственный трансатлантический канал из США в Европу имел скорость 64 Кбит/с. TCP был разработан так, чтобы скорость передачи данных была обратно пропорциональна расстоянию между двумя конечными точками. В случае потери пакетов TCP считает, что канал перегружен, и самостоятельно уменьшает скорость передачи. Производительность TCP снижается с ростом расстояния между конечными точками и из-за низкого качества сети [1]. Чем больше расстояние, тем больше задержка и ниже скорость передачи. Маршрутизатору требуется время на обработку пакета, а если роутер настроен неправильно или перегружен, передаваемые пакеты могут быть утеряны. Чем больше пакетов утрачено, тем более затратной по времени становится передача. На рис. 1 показано, что TCP имеет хорошую производительность в локальных сетях относительно доступной пропускной способности сети, ночем больше время задержки и потеря пакетов, тем ниже будет производительность передачи данных. Также производительность протокола не растет с увеличением канала. Рисунок 1. Производительность TCP/IP Количество пакетов, которые может отправить TCP в момент времени, определяется механизмом под названием «окно TCP» (TCP Sliding Window). Окно TCP регулируется алгоритмом предотвращения перегрузки AIMD (Adaptive Increase Multiplicative Decrease) и контролем передачи (Flow Control), регулируя скорость отправки пакетов. Благодаря этому TCP может быть «уверен» в том, что пакеты отправляются не быстрее, чем их может принять получатель. В случае обнаружения потери пакета/подтверждения отправитель, используя AIMD-алгоритм, уменьшает размер окна TCP либо вдвое, либо до нуля. Если представить скорость передачи протокола TCP в виде графика (см. рис. 2), получится «пилообразная» функция. Рисунок 2. Размер окна передачи данных

Протокол SCTP

SCTP создает двустороннюю ассоциацию между двумя конечными точками и дает возможность работы с несколькими потоками каждой паре конечных точек, а также обеспечивает поддержку концепции многоинтерфейсного узла натранспортном уровне [2] (см. рис. 3). Рисунок 3. Концепция многоинтерфейсного узла Сервисы, предоставляемые SCTP, имеют много общего с сервисами TCP и UDP. Протокол SCTP описывается в RFC 4960 [3]. Несмотря на принципиальную разницу между SCTP и TCP, для приложения интерфейс «точка – точка» почти ничем не отличается от интерфейса TCP. Подобно TCP, протокол SCTP обеспечивает приложениям, взаимодействующим по IP-сети, транспортную службу с гарантией доставки и сохранением порядка следования пакетов. Протокол унаследовал многие функции, разработанные для TCP, а именно возможность контроля перегрузки и восстановления утерянных пакетов. В действительности любое приложение, работающее по протоколу TCP, можно перевести на SCTP без потери функциональности. Соединение по протоколу SCTP между клиентом и сервером называется ассоциацией, так как это многопотоковый протокол, позволяющий задать несколько IP-адресов и один порт для каждой стороны соединения (см. рис. 4). Рисунок 4. Ассоциация протокола SCTP Наличие у конечной точки нескольких IP-адресов позволяет обеспечить дополнительную устойчивость в случае отказа сети и уменьшить задержки. Для сокращения задержек, вызванных переключением с первичного направления наальтернативные, используется механизм контроля работоспособности. Пока идет передача данных по первичному направлению, протокол SCTP посылает пакеты контроля работоспособности на адреса, находящиеся в режиме ожидания. В отличие от TCP протокол SCTP ориентирован не на поток байтов, а на сообщения. Он обеспечивает упорядоченную доставку данных и сохраняет границы сообщений в пакетах приложения, размещая сообщения в одной или нескольких структурах данных SCTP, называемых фрагментами. Несколько сообщений могут объединяться в один фрагмент, а длинное сообщение может быть сегментировано. Благодаря этому свойству устраняется возможная блокировка линии типа head-of-line, присущая протоколу TCP, так как утрата сообщения в одном из потоков не блокирует доставку сообщений по другим. С помощью SCTP приложения могут использовать различные модели доставки, в том числе строгий порядок передачи (как TCP), частичное упорядочивание (по потокам) и неупорядоченную доставку (как UDP). Для восстановления утраченных пакетов используется схема выборочного подтверждения, унаследованная из TCP. Поддерживая обратную связь с отправителем, приемник SCTP сообщает, какие пакеты необходимо отсылать повторно, если они были утеряны. Для контроля перегрузки используются стандартные методики: медленный старт, предотвращение перегрузки и быстрая повторная передача. SCTP лишен двух особенностей TCP. Одна из них – состояние неполного закрытия соединения на своей стороне, которое возникает, когда приложение закрывает свой конец соединения, но разрешает встречной стороне отправлять данные ипринимает их. Также не поддерживается обработка внеочередных данных. Для доставки срочных данных в SCTP можно использовать отдельный поток, хотя это и не позволяет в точности воспроизвести поведение TCP в данной ситуации.

Заключение

1. Кручинин С.В. Стеки сетевых технологий TCP/IP и OSI/ISO//Вопросы науки. – 2015. – Т. 3. – С. 145-147.
2. [Электронный ресурс]. Режим доступа: https://www.ibm.com/developerworks/ru/library/l-sctp/index.html#artrelatedtopics (дата обращения: 03.01.2019).
3. [Электронный ресурс]. Режим доступа: https://tools.ietf.org/html/rfc4960 (дата обращения: 05.01.2019).
4. Кручинин С.В. Реализация модели OSI/ISO телекоммуникационным модулем сопряжения для MESH-сетей //Научно-исследовательские публикации, 2016, № 5. – С. 27-32.
5. Кручинин С.В. Семиуровневая сетевая модель OSI/ISO и стек протоколов TCP/IP: исследование взаимоотношения и интерпретации//Научно-исследовательские публикации, 2015, № 5. – С. 115-120.

Ключевые слова: интернет, протокол, соединение.

SCTP: новый транспортный протокол для TCP/IP

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

В течение последних 20 лет приложения и конечные пользователи, имевшие дело с семейством TCP/IP, работали с одним из двух протоколов: TCP или UDP. Однако уже сегодня некоторые приложения требуют функциональности, выходящей за рамки той, которую в состоянии предоставить TCP или UDP, а в будущем эти требования возрастут еще больше. Для того чтобы увеличить функциональность транспортного уровня, в Internet Engineering Task Force в октябре 2000 года одобрили в качестве предварительного стандарта протокол контроля потоковой передачей SCTP (stream control transmission protocol) [2].

SCTP был создан в рамках проекта, начатого рабочей группой IETF Signaling Transport и посвященного разработке специализированного транспортного протокола для решений, связанных с передачей голоса по IP-сетям (VoIP) [3]. Осознав, что и другие приложения могут использовать некоторые возможности нового протокола, в IETF теперь рассматривают SCTP в качестве протокола транспортного уровня общего назначения, объединяющего функции TCP и UDP над уровнем IP.

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

Проблемы TCP

TCP, поддерживающий самые популярные на сегодняшний день приложения Internet, в последние годы был значительно усовершенствован с тем, чтобы обеспечить надежность и производительность в сетях различной емкости и качества. Тем не менее, в своей основе, его поведение остается таким же, как в 1981 году его описал один из пионеров Internet Джон Постел [4]. В том числе, в нем сохранились свойства, в силу которых он плохо подходит в качестве транспортного протокола для таких задач, как передача сигналов в VoIP-сетях или асинхронная обработка на базе транзакций. TCP требует наличия службы доставки со строго упорядоченной передачей для всех данных, пересылаемых между двумя хостами. Это слишком серьезное ограничение для приложений, которые допускают как последовательную (частичное упорядочивание), так и непоследовательную доставку потоков. TCP трактует каждую передачу данных как неструктурированную последовательность байт. В силу этого, приложения, которые обрабатывают отдельные сообщения, должны добавлять в поток байт границы сообщений и отслеживать их.

Основанный на механизме TCP-сокетов API-интерфейс не поддерживает множественную адресацию. С конкретным TCP-соединением с другим хостом приложение может связать только один IP-адрес. Если интерфейс, назначенный этому IP-адресу, отключается, TCP-соединение прерывается и его необходимо устанавливать заново.

Наконец, TCP-хосты восприимчивы к атакам типа «отказ в обслуживании» (DoS — denial of service). Для таких атак характерны своего рода «штормы», огромное количество пакетов TCP SYN, сигнализирующих ничего не подозревающему хосту о том, что отправитель хочет установить с ним TCP-соединение. Хост-получатель резервирует память и отвечает на запрос сообщениями SYN ACK. Когда атакующая система не возвращает сообщения ACK, необходимые для завершения трехэтапной процедуры установки TCP-соединения, ресурсы хоста, подвергнувшегося атаке, остаются неосвобожденными. Поэтому он оказывается не готов к обслуживанию легитимных запросов на установку TCP-соединения [5].

Свойства SCTP

Рис. 1. Архитектура SCTP. Новый протокол предлагает расширенную функциональность транспортного уровня. Два SCTP-хоста образуют ассоциацию, использующую несколько интерфейсов при доступе к IP-сети

На рис. 1 показано место SCTP в архитектуре TCP/IP вместе с разбиением его на базовые функциональные подуровни. Чтобы подчеркнуть отличие от традиционного понятия «соединение» (connection), под которым неявно подразумевается связь между одним адресом отправителя и одним адресом получателя, в SCTP используют термин «ассоциация» (association) для определения состояния протокола, установленного между двумя равноправными SCTP-хостами, обменивающимися сообщениями. Ассоциация SCTP может использовать несколько адресов на каждом из хостов.

SCTP поддерживает ряд функций, унаследованных от TCP и других протоколов, которые предлагают дополнительную функциональность.

• Сохранение границ сообщений. SCTP сохраняет границы сообщений в пакетах приложения, размещая сообщения в одной или нескольких структурах данных SCTP, называемых фрагментами (chunk). Несколько сообщений могут объединяться в один фрагмент, а длинное сообщение может быть распределено по нескольким фрагментам.
• Отсутствие блокировок типа head-of-line. SCTP устраняет задержку, вызываемую блокировкой обслуживания, которая может возникнуть тогда, когда приемник TCP оказывается вынужден восстанавливать корректную последовательность пакетов, поступающих в нарушенном порядке из-за переупорядочивания в сети или утраченных.
• Несколько режимов доставки. SCTP поддерживает несколько моделей доставки, в том числе строгий порядок передачи (как TCP), частичное упорядочивание (по потокам) и неупорядоченную доставку (как UDP).
• Поддержка «многодомности». SCTP посылает пакеты по одному IP-адресу получателя, но может перевести сообщения на альтернативный адрес, если данный IP-адрес недоступен.
• Контроль перегрузки. SCTP использует стандартные методики, впервые применявшиеся для контроля перегрузки в TCP [1, 6], в том числе «медленный старт», предотвращение перегрузки и быстрая повторная передача. Приложения SCTP могут, таким образом, получать свою долю сетевых ресурсов, сосуществуя с приложениями TCP.
• Выборочные подтверждения. SCTP использует схему выборочного подтверждения, унаследованную из TCP, для восстановления утраченных пакетов [7]. Приемник SCTP поддерживает обратную связь с отправителем, сообщая, какие пакеты необходимо отсылать повторно когда они теряются.
• Фрагментация пользовательских данных. SCTP разбивает сообщения на фрагменты, так чтобы максимальный размер передаваемого элемента (MTU — maximum transfer unit) соответствовал ограничениям конкретного маршрута пересылки между взаимодействующими хостами. Эта функция описана в RFC 1191 и опционально используется протоколом TCP/IP, чтобы избежать снижения производительности, когда IP-маршрутизаторы вынуждены выполнять фрагментацию [8].
• Механизм контроля работоспособности (hearbeat, дословно «сердцебиение» — Прим. перев.). SCTP посылает пакеты контроля работоспособности на адреса, находящегося в режиме ожидания хоста, которые входят в ассоциацию. Протокол декларирует, что IP-адрес будет отключен, как только он достигнет порогового значения невозвращенных подтверждений о работоспособности.
• Защита от DoS-атак. Чтобы смягчить воздействие атак, передающих массу пакетов TCP SYN на хост-адресат, SCTP использует механизм cookie при инициализации ассоциации.

Многодомность

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

Современные IP-сети, как правило, устойчивы к ошибкам, однако зачастую критическим оказывается отрезок времени восстановления (reconvergenve), в течение которого сеть маршрутизации «излечивает» себя. В течение этого периода трафик может «отсылаться в никуда», либо передача может оказаться прерванной. Множественная адресация в конечной точке может уменьшить влияние отрезка восстановления связи, поскольку потерянные пакеты повторно передаются на альтернативный адрес. Ассоциация SCTP должна благодаря этому восстанавливаться быстрее и обеспечивать более высокую пропускную способность.

Снижение нагрузки

Стремясь обеспечить избыточность, предприятия часто подключаются ко второму Internet-провайдеру. Чтобы гарантировать возможность доставки пакетов по второму каналу, пользователь должен сообщить набор адресов (обычно полученный от первого провайдера), который выходит за рамки адресного диапазона, поддерживаемого вторым провайдером. Второй Internet-провайдер должен затем сообщить свое собственное объединенное адресное пространство и конкретные адреса, выделенные данному клиенту, что приводит к значительному росту числа записей в таблице маршрутизации.

Такое решение становится необязательным при работе с SCTP, поскольку ассоциация будет охватывать IP-адреса, содержащиеся в объединенных адресных диапазонах, поддерживаемых обоими провайдерами. Многодомность SCTP может, таким образом, использоваться для снижения нагрузки в системе маршрутизации Internet.

Топологическое разнообразие

Преимущества многодомности реализуются, если пути маршрутизации IP-адресов в ассоциации в достаточной мере различаются. Разнообразие путей маршрутизации диктует уровень отказоустойчивости для ассоциации SCTP. Это «топологическое разнообразие» можно физически организовать в небольших сетях, но гигантской сети Internet добиться этого гораздо сложнее. Некоторые предприятия заключают договоры с разными Internet-провайдерами уровня I и уровня II, чтобы увеличить свои шансы на сохранение соединения с помощью раздельных и разнообразных топологий маршрутизации.

Другие методики также могут обеспечить отказоустойчивость интерфейса хоста, однако они не в состоянии гарантировать приемлемое (с точки зрения конкретных приложений) время восстановления соединения [9].

Варианты доставки

Еще один связанный с SCTP аспект, который может вызвать путаницу, — это различие между надежной и упорядоченной доставкой. При работе с TCP эти два аспекта неразрывно связаны, поскольку все данные надежно доставляются (к примеру, утерянные пакеты передаются повторно) хосту-получателю и предоставляются приложению в той последовательности, в какой они передавались. Для этого TCP использует номер последовательности в заголовке каждого пакета.

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

Инициация

Оба протокола и SCTP, и TCP, ориентированы на установление соединения, и они требуют определения состояния соединения на каждом хосте. Соединение TCP определяется двумя IP-адресами и двумя номерами портов. Пусть имеется два хоста A и Z, тогда соединение TCP определяется как [IP-A]+[Port-A]+[IP-Z]+[Port-Z], где IP-A и Port-A — это один конец соединения, а IP-Z и Port-Z — другой.

Ассоциация SCTP определяется как [набор IP-адресов на хосте A]+[Port-A]+[набор IP-адресов на хосте Z]+[Port-Z]. Любые из IP-адресов на любом хосте могут указываться в качестве отправителя или получателя в IP-пакете и это корректно идентифицирует ассоциацию.

Рис. 2. Четырехэтапная процедура установки соединения SCTP. Ее результатом является создание ассоциации SCTP между двумя хостами

Прежде, чем начнется обмен данными, два SCTP-хоста должны передать друг другу информацию о состоянии соединений (в том числе задействованные IP-адреса) с помощью четырехэтапной процедуры установки соединения, показанной на рис. 2. В трехэтапной процедуре установки соединения в TCP, процедура, предусмотренная протоколом SCTP, позволяет защититься от DoS-атак. Получателю сообщения о намерении установить контакт INIT в четырехэтапной процедуре установки соединения не требуется сохранять никакую информацию о состоянии или резервировать какие-либо ресурсы. Вместо этого он посылает в ответ сообщение INIT-ACK, которое включает в себя специальную запись (cookie) состояния, содержащую всю информацию необходимую отправителю INIT-ACK для того, чтобы сформировать свое состояние. Спецзапись состояния подписывается цифровой подписью (см., например, [10]). Оба сообщения, INIT и INIT-ACK, содержат несколько параметров, необходимых для установки начального состояния:

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

После обмена этими сообщениями, отправитель INIT возвращает назад спецзапись состояния в виде сообщения COOKIE-ECHO, которое также может содержать связанные с ним пользовательские сообщения DATA (при наличии связанных путем ограничений на максимальный размер передаваемого элемента). При получении COOKIE-ECHO получатель полностью меняет свое состояние и отправляет обратное сообщение COOKIE-ACK, подтверждающее, что настройка завершена. Этот COOKIE-ACK также может сопровождаться пользовательскими сообщениями DATA.

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

Рис. 3. Формат пакета SCTP. За общим заголовком (с адресами портов отправителя и получателя, контрольной суммой и тегом проверки) следует один или несколько фрагментов данных переменной длины

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

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

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

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

Рис. 4. Обмен сообщениями SCTP. Данные SCTP и фрагменты SACK пересылаются между взаимодействующими хостами

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

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

Отключение

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

Рис. 5. Отключение SCTP. Ассоциация SCTP закрывается путем обмена последовательностью управляющих фрагментов SHUTDOWN

На рис. 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 при установке голосовых соединений [11].

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.

Литература

1. P. Amer, S. Iren, and P. Conrad, «The Transport Layer: Tutorial and Survey», ACM Computing Surveys, vol. 31, no. 4, Dec. 1999
2. J. Postel, «Transmission Control Protocol», IETF RFC 793, Sept. 1981
3. IETF Signaling Transport working group charter, ietf.org/html.charters/sigtran-charter.html
4. R. Stewart et al., «Stream Control Transmission Protocol», IETF RFC 2960, Oct. 2000
5. «Defining Strategies to Protect against TCP SYN Denial of Service Attacks», Cisco Systems, tech. memo, Aug. 2001; www.cisco.com/warp/public/707/4.html
6. M. Allman, V. Paxson, W. Stevens, «TCP Congestion Control», IETF RFC 2581, Apr. 1999
7. M. Mathis et al., «TCP Selective Acknowledgment Options», IETF RFC 2018, Oct. 1996
8. J. Mogul, S. Deering, «Path MTU Discovery», IETF RFC 1191, Nov. 1999
9. J. Touch, «Dynamic Internet Overlay Deployment and Management Using the X-Bone», Computer Networks, July 2001
10. [10] H. Krawczyk, M. Bellare, R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», IETF RFC 2104, Feb. 1997
11. [11] A. Jungmaier et al., «SCTP: A Multi-link End-to-End Protocol for IP-based Networks», Int’l J. Electronics and Comm., vol. 55, no. 1, Jan. 2001

Рэнделл Стюарт (rrs@cisco.com) — ведущий научный сотрудник компании Cisco Systems, где он фокусируется, в частности, на вопросах беспроводных Internet-технологий. Основной разработчик документа RFC 2960, в котором описан SCTP. Стюарт — соавтор книги Stream Control Transmission Protocol (SCTP): A Reference Guide (Addison Wesley Longman, 2001).

Крис Метц (chmetz@cisco.com) — технический руководитель группы Cisco Service Provider Engineering. Соавтор книги ATM and Multiprotocol Networking (McGraw-Hill, 1997) и автор книги IP Switching: Protocols and Architectures (McGraw-Hill, 1999).

Randall Stewart, Chris Metz, SCTP: New Transport Protocol for TCP/IP. IEEE Internet Computing, November — December 2001. Copyright IEEE Computer Society, 2001. All rights reserved. Reprinted with permission

Ресурсы SCTP

Дополнительную информацию о протоколе контроля потоковой передачей можно найти в Web.

• Лаборатория исследования протоколов Университета Делавера o www.cis.udel.edu/~iyengar/research/SCTP/
• Международный инженерный консорциум o www.iec.org/online/tutorials/sctp/
• Сетевая лаборатория Университета Темпла o netlab.cis.temple.edu/SCTP/
• Домашняя страница SCTP o sctp.chicago.il.us/sctpoverview.html
• SCTP для начинающих o tdrwww.exp-math.uni-essen.de/pages/forschung/sctp_fb/
• Журнал Telecommunications Magazine, o www.telecoms-mag.com/telecom/default.asp?journalid=3&func=articles&page=0105t5&year =2001&month=5
• R. Stewart, Q. Xie, Stream Control Transmission Protocol (SCTP): A Reference Guide, Addison Wesley Longman, Boston, Mass., 2001.

Протоколы транспортного уровня (TCP, UDP, SCTP)

SCTP (Stream Control Transmission Protocol — протокол передачи с управлением потока) — протокол транспортного уровня. Выполняет те же функции, что и протоколы TCP и UDP. Но объединяет при этом их преимущества, лишает недостатков и добавляет новые возможности.

Отличия от протоколов TCP и UDP:

Основные преимущества (пояснения к таблице):

• Сохранение границ — в протоколе TCP данные передаются непрерывным потоком байт, читаются так же, поэтому программист должен сам следить за тем, как расставлять границы в этом потоке и разделать куски данных. SCTP позволяет ставить границы и обрабатывать данные пакетами, как в UDP. Но при этом гарантирует порядок доставки пакетов, обеспечивает надёжность и ориентирован на соединения. Упорядоченность пакетов, кстати, можно отключить для повышения скорости.
• Multihoming (многолинейность, множественная адресация, см. иллюстрацию ниже) — SCTP позволяет устанавливать соединение к одному серверу по разным линиям связи (например, по Wi-Fi и по Ethernet). Таким образом, если одна линия связи отвалится (скорей всего Wi-Fi), то соединение не разорвётся. Это так же позволяет передавать данные сразу по нескольким линиям, что увеличивает скорость передачи. Если в TCP одна линия связи оборвётся, то соединение будет потеряно, придётся устанавливать новое.

• Multithreading (многопоточность) — позволяет передавать несколько потоков в рамках одной ассоциации (ассоциацией в SCTP называется соединение между двумя хостами). Например в TCP данные и служебная информация передаются по одному соединению. Поэтому задержка в получении служебнной информации может быть вызвана текущей передачей данных (например, ACK может не прийти вовремя, поэтому мы пошлём дупликат). Такая проблема называется head-of-line blocking, HOL. Многопоточность позволяет передавать эти данные независимо, что приведёт к лучшему использованию доступных ресурсов.
• 4-way handshake — протокол TCP подвержен SYN-flood атакам. Злоумышленник шлёт много пакетов в короткое время для запроса TCP соединения (запрос на соединение помечен битом SYN в заголовке, поэтому и SYN-flood). Но при этом не подтверждает установление соединения. Таким образом на сервере образуются полуоткрытые соединения. Они закрываются сами по истечению таймаута. Но цель злоумышленника состоит в том, чтобы создать как можно больше таких соединений, не давая тем самым создавать новые валидные соединения из-за ограничения в их количестве на стороне сервера (сервер не может иметь бесконечное число соединений, а если сделать таймаут на обрыв слишком маленьким, то валидные соединения могут отваливаться раньше времени, что тоже нехорошо, и это всё делает syn-атаки возможными). В SCTP используется не тройное рукопожатие, а четверное (из разряда: «я хочу установить соединение — ты точно хочешь установить соединение? — да, я точно хочу установить соединение — ну тогда ладно»). Таким образом за короткий промежуток времени нельзя создать много новых соединений.

• В SCTP не бывает полузакрытых соединений, как в TCP. Если мы закрываем соединение, то сразу в обе стороны.

К сожалению, несмотря на все преимущеста, протокол SCTP не получил пока широкого распространения. Это связано с инертностью (TCP работает, зачем менять?) и сложностью поддержки на аппаратном уровне (например, вся обёртка сетевых протоколов, те же фаерволы, имеют правила в духе «пропускать только UDP, TCP» пакеты; для примера можно вспомнить, как это используется в NAT).

Источники информации

• Лекция А. Масальских — Транспортный уровень. Введение. TCP. UDP. SCTP
• SCTP в Java (примеры кода)
• RFC 4960 — SCTP

SCTP

SCTP (англ. Stream Control Transmission Protocol — «протокол передачи с управлением потоком»), протокол транспортного уровня в компьютерных сетях, появившийся в 2000 году в IETF. RFC 4960 описывает этот протокол, а RFC 3286 содержит техническое вступление к нему.

Как и любой другой протокол передачи данных транспортного уровня, SCTP работает аналогично TCP или UDP [1] . Будучи более новым протоколом, SCTP имеет несколько нововведений, таких как многопоточность, защита от SYN-flood атак, синхронное соединение между двумя хостами по двум и более независимым физическим каналам (multi-homing).

Безопасное установление соединения

Создание нового подключения в протоколах TCP и SCTP происходит при помощи механизма подтверждения (квитирования) пакетов. В протоколе TCP данная процедура получила название трехэтапное квитирование (three-way handshake). Клиент посылает пакет SYN (сокр. Synchronize). Сервер отвечает пакетом SYN-ACK (Synchronize-Acknowledge). Клиент подтверждает прием пакета SYN-ACK пакетом ACK. На этом процедура установления соединения завершается.

Протокол TCP имеет потенциальную уязвимость, обусловленную тем, что нарушитель, установив фальшивый IP-адрес отправителя, может послать серверу множество пакетов SYN. При получении пакета SYN сервер выделяет часть своих ресурсов для установления нового соединения. Обработка множества пакетов SYN рано или поздно, затребует все ресурсы сервера и сделает невозможным обработку новых запросов. Такой вид атак называется «отказ в обслуживании» (Denial of Service (DoS)).

Протокол SCTP защищен от подобных атак с помощью механизма четырехэтапного квитирования (four-way handshake) и вводом маркера (cookie). По протоколу SCTP клиент начинает процедуру установления соединения посылкой пакета INIT. В ответ сервер посылает пакет INIT-ACK, который содержит маркер (уникальный ключ, идентифицирующий новое соединение). Затем клиент отвечает посылкой пакета COOKIE-ECHO, в котором содержится маркер, посланный сервером. Только после этого сервер выделяет свои ресурсы новому подключению и подтверждает это отправлением клиенту пакета COOKIE-ACK.

Для решения проблемы задержки пересылки данных при выполнении процедуры четырехэтапного квитирования в протоколе SCTP допускается включение данных в пакеты COOKIE-ECHO и COOKIE-ACK.

Поэтапное завершение передачи данных

Рассмотрим отличия между процедурой закрытия сокетов протокола SCTP и процедурой частичного закрытия (half-close) протокола TCP.

В протоколе TCP возможна ситуация частичного закрытия соединения, когда один узел закончил передачу данных (выполнив посылку пакета FIN), но продолжает принимать данные по этому соединению. Другой узел может продолжать передавать данные до тех пор, пока сам не проведёт закрытие соединения на своей стороне. Состояние частичного закрытия используется приложениями крайне редко, поэтому разработчики протокола SCTP посчитали нужным заменить его последовательностью сообщений для разрыва существующей ассоциации. Когда узел закрывает свой сокет (посылает сообщение SHUTDOWN), оба корреспондента должны прекратить передачу данных, при этом разрешается лишь обмен пакетами, подтверждающими прием ранее отправленных данных.

Многопоточность

TCP управляет последовательностью байт: данные, посланные приложением-отправителем, должны поступать приложению-получателю строго в том же порядке (в то время как протокол IP способен поменять последовательность пакетов; кроме того, пропавшие пакеты посылаются повторно и обычно прибывают к получателю с нарушением последовательности; для борьбы с этими явлениями данные накапливаются в буфере). SCTP может транспортировать данные между двумя точками одновременно по нескольким потокам сообщений. В противоположность к TCP, SCTP обрабатывает целые сообщения, а не обычные байты информации. Это означает, что если отправитель отсылает серверу сообщение, состоящее из 100 байт за первый шаг, а за ним ещё 50 байт, то получатель за первый шаг получит именно первые 100 байт в первом сообщении, а только затем и только 50 байт на второй операции чтения из сокета.

Термин «многопоточность» (англ. multi-streaming) обозначает способность SCTP параллельно передавать по нескольким независимым потокам сообщений. Например, мы передаем несколько фотографий через HTTP-приложение (например, браузер). Можно использовать для этого связку из нескольких TCP-соединений, однако также допустимо SCTP-ассоциация (англ. SCTP-association), управляющее несколькими потоками сообщений для этой цели.

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

Достоинства

Достоинства использования SCTP включают в себя:

• Использование множественных интерфейсов (англ Multihoming)
  Допустим, у нас есть два хоста. И хотя бы один из них имеет несколько сетевых интерфейсов, и соответственно несколько IP-адресов. В TCP, понятие «соединение» означает обмен данными между двумя точками, в то время, как в SCTP имеет место концепция «ассоциации» (англ. association), обозначащая всё происходящее между двумя хостами

• Многопоточность
  Данные приходят в точку по независимым потокам. Это позволяет устранить феномен en:Head-of-line blocking, которым так страдает TCP
• Поиск пути с мониторингом
  Протоколом выбирается первичный маршрут передачи данных, а также производится проверка и мониторинг связности пути.
• Механизмы валидации и проверки подлинности
  Защита адресата от flood-атак (технология 4-way handshake), и уведомление о потерянных пакетах и нарушенных цепочках.
• Улучшенная система контроля ошибок, подходящая для jumbo-пакетов в Ethernet.

Часть достоинств вытекает из того факта, что изначально разработчики SCTP проектировали протокол под нужды передачи телефонии (SS7) по протоколу IP.

Причины появления

Протокол TCP предоставляет основные средства для передачи данных по сети Internet по надежному пути. Однако TCP накладывает некоторые ограничения на транспорт данных:

• TCP предоставляет надежную передачу данных в строгой последовательности. Тем не менее одни приложения требуют передачу без управления и контроля последовательности, а другие будут вполне удовлетворены частичной упорядоченностью данных. Оба этих случая страдают из-за ненужных задержек, связанных с восстановлением и упорядочиванием нарушенных последовательностей TCP.
• Природа TCP ориентирована на поток байт, что вызывает неудобства. Приложения вынуждены самостоятельно добавлять собственные маркеры в пакеты, чтобы распараллелить передачу собственных сообщений, а также использовать дополнительные ухищрения, чтобы убедиться в том, что целое сообщение было доставлено за определенное время.
• Ограниченные рамки возможностей TCP-сокетов ещё более усложняют задачу предоставления возможности параллельной передачи информации к хостам по нескольким каналам связи (см. multi-homing выше).
• TCP относительно уязвим к атакам класса «Отказ в обслуживании» (DoS), таким как SYN-flood.

Все эти ограничения наносят ущерб производительности работы телефонных сетей через IP.

Безопасность

SCTP был разработан с некоторыми функциями позволяющими повысить безопасность, такими как «4-х кратное рукопожатие» (по сравнению с «трёхкратным рукопожатием» в TCP), чтобы предотвратить SYN-flood атаки, и больших Cookie для проверки подлинности ассоциации.

Надежность была одним из ключевых аспектов разработки безопасности протокола SCTP. Multi-homing позволяет ассоциации оставаться открытой, даже если некоторые используемые маршруты и интерфейсы стали недоступны. Это имеет особое значение для SIGTRAN, который используя SCTP, передаёт сообщения и сервисы протоколов ОКС-7 поверх IP сети, что требует сильной устойчивости во время отключений линков для поддержания телекоммуникационных услуг, даже при серьёзных аномалиях в сети.

Шифрование не является частью оригинального дизайна SCTP.

В некоторых случаях SCTP является хорошим кандидатом для проверки на прочность стэка TCP/IP (англ.). Причиной для этого является тот факт, что некоторые операционные системы распространяются с поддержкой протокола SCTP, но ввиду его слабой известности (по сравнению с TCP или UDP), администраторы иногда забывают настроить в брандмауэре обнаружения вторжений, что даёт возможности для сканирования трафика.

Сравнение возможностей протоколов транспортного уровня

Параметр	UDP	TCP	SCTP
Установка соединения	Нет	Да	Да
Надежная передача	Нет	Да	Да
Сохранение границ сообщения	Да	Нет	Да
Упорядоченная доставка	Нет	Да	Да
Неупорядоченная доставка	Да	Нет	Да
Контрольные суммы данных	Да	Да	Да
Размер контрольной суммы (бит)	16	16	32
Путь MTU	Нет	Да	Да
Управление накоплением	Нет	Да	Да
Многопоточность	Нет	Нет	Да
Поддержка множественных интерфейсов	Нет	Нет	Да
Связка потоков	Нет	Да	Да

Формирование кадров сообщения

При формировании кадров сообщения обеспечивается сохранение границ сообщения в том виде, в котором оно передается сокету; это означает, что если клиент посылает серверу 100 байт, за которыми следуют 50 байт, то сервер воспринимает 100 байт и 50 байт за две операции чтения. Точно так же функционирует протокол UDP, это является особенностью протоколов, ориентированных на работу с сообщениями.

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

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

Структура пакета

Биты	Биты 0-7								8-15								16-23								24-31
+0	Порт источника																Порт назначения
32	Тег проверки
64	Контрольная сумма
96	Тип 1 блока								Флаги 1 блока								Длина 1 блока
128	Данные 1 блока
…	…
…	Тип N блока								Флаги N блока								Длина N блока
…	Данные N блока

SCTP пакеты имеют более простую структуру, чем пакеты TCP. Каждый пакет состоит из двух основных разделов:

1. Общий заголовок, который занимает первые 12 байт (выделены синим цветом)
2. Блоки данных, которые занимают оставшуюся часть пакета.

Первый блок отмечен зелёным цветом, и последний из блоков N (N блок) выделен красным.

Каждый блок имеет идентификатор типа, занимающий один байт. Таким образом, возможно определение не более 255 различных типов блоков. RFC 4960 определяет список типов блоков, всего на данный момент определено 15 типов. Остальная часть блока состоит из поля длины размером в 2 байта (максимальная длина, которя может содержаться в данном поле, равна 65535 байтам) и, собственно, данных. Если размер блока не кратен 4-м байтам, то он заполняется нулями до размера, кратного 4-м байтам.

Обработка ошибок

Повтор передачи

Повторная передача блоков DATA может быть обусловлена (a) тайм-аутом, определяемым таймером повтора (retransmission timer) или (b) получением SACK, показывающих что блок DATA не был получен адресатом. Для снижения вероятности насыщения повтор передачи блоков DATA ограничивается. Значение тайм-аута для повтора (RTO) устанавливается на основе оценки времени кругового обхода и уменьшается экспоненциально с ростом частоты потери сообщений. Для активных ассоциаций с почти постоянным уровнем трафика DATA причиной повтора скорей всего будут сообщения SACK, а не тайм-аут. Для снижения вероятности ненужных повторов используется правило 4 SACK, в соответствии с которым повтор передачи происходит только по четвертому SACK, указывающему на пропуск блока данных. Это позволяет предотвратить повторы передачи, вызванные нарушением порядка доставки.

Сбой в пути

Поддерживается счетчик для числа повторов передачи по конкретному адресу получателя без подтверждения успешной доставки. Когда значение этого счетчика достигает заданного порога (конфигурационный параметр), адрес объявляется неактивным и протокол SCTP начинает использовать другой адрес для передачи блоков DATA. Кроме того, по всем неиспользуемым (дополнительным) адресам периодически передаются специальные блоки Heartbeat и поддерживается счетчик числа блоков Heartbeat, переданных без возврата соответствующего Heartbeat Ack. Когда значение счетчика достигает заданного порога (параметр конфигурации), соответствующий адрес объявляется неактивным. Блоки Heartbeat передаются по неактивным адресам до тех пор, пока не будет получено сообщение Ack, говорящее о восстановлении активности адреса. Частота передачи блоков Heartbeat определяется значение RTO и дополнительной задержкой, которая позволяет передавать блоки Heartbeat без помех для пользовательского трафика.

Отказ в конечной точке

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

Реализации

Протокол SCTP реализован в следующих операционных системах:

• Linux 2.4 и выше
• Sun Solaris 10
• Cisco IOS 12+
• DragonFly BSD начиная с версии 1.4
• QNX Neutrino,
• BSD UNIX (с внешним дополнением от проекта KAME)
• FreeBSD начиная с версии 7
• HP-UX
• AIX 5

Примечания

1. ↑ TCP и UDP работают столь различно, что проводить аналогию к ним обоим некорректно. Вся аналогия — в том, что SCTP​​, TCP и UDP относятся к одному и тому же уровню стека TCP/IP.

Ссылки

• RFC 3286
• http://rfc2.ru/3286.rfc — перевод RFC 3286 на русский язык
• http://www.sigtran.org
• http://www.sctp.org
• http://www.openss7.org
• http://www.sctp.de
• http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro.html
• SeveNTest онлайн декодер сообщений TCP/IP
• RFC 2960 — Stream Control Transmission Protocol,
• RFC 3257 — Stream Control Transmission Protocol Applicability Statement,
• RFC 3286 — An Introduction to the Stream Control Transmission Protocol (SCTP),
• RFC 3309 — Stream Control Transmission Protocol (SCTP) Checksum Change,
• RFC 3436 — Transport Layer Security over Stream Control Transmission Protocol,
• RFC 3554 — On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,
• RFC 3758 — Stream Control Transmission Protocol (SCTP) Partial Reliability Extension,
• RFC 3873 — Stream Control Transmission Protocol (SCTP) Management Information Base (MIB),
• RFC 4460 — Stream Control Transmission Protocol (SCTP) Specification Errata and Issues,
• RFC 4820 — Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP),
• RFC 4895 — Authenticated Chunks for the Stream Control Transmission Protocol (SCTP),
• RFC 4960 — Stream Control Transmission Protocol,
• RFC 5061 — Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,
• RFC 5062 — Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures.