Please enter banners and links.
Network Working Group R. Stewart, Ed.
Request for Comments: 4960 September 2007
Obsoletes: 2960, 3309
Category: Standards Track
Протокол SCTP
Stream Control Transmission Protocol
Статус документа
Этот документ является спецификацией стандарта Internet, предназначенного для сообщества Internet, и служит приглашением к дискуссии в целях развития протокола. Сведения о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.
Тезисы
Этот документ отменяет RFC 2960 и RFC 3309. Документ описывает протокол управления потоковой передачей SCTP1. Протокол SCTP предназначен для передачи сигнальных сообщений PSTN2 через сети IP, но может использоваться и для других приложений.
SCTP представляет собой протокол транспортного уровня с гарантированной доставкой, работающий в пакетных сетях без явной организации соединений таких, как IP. Протокол обеспечивает пользователям следующие типы сервиса:
- передача пользовательских данных с корректировкой ошибок, подтверждением доставки и отсутствием дубликатов;
- фрагментирование данных в соответствии с определенным для пути значением MTU3;
- упорядоченная доставка пользовательских сообщений внутри множества потоков с возможностью управления порядком доставки отдельных пользовательских сообщений;
- возможность группировки пользовательских сообщений в один пакет SCTP;
- устойчивость к отказам на сетевом уровне за счет поддержки многодомных хостов на обеих сторонах соединения.
Протокол SCTP включает механизмы предотвращения насыщения и устойчивости к атакам с использованием лавины пакетов (flooding) или маскированием адресов (masquerade).
Оглавление
Исключено в версии HTML
1. Введение
В этом разделе рассматриваются причины, побудившие к разработке протокола SCTP, обеспечиваемые протоколом типы сервиса, а также базовые концепции, требуемые для детального описания протокола.
Этот документ заменяет собой [RFC2960] и [RFC3309].
1.1. Мотивация
Протокол TCP [RFC793] обеспечивает, прежде всего, гарантированную доставку данных в сетях IP. Однако многие современные приложения сталкиваются с ограниченными возможностями TCP и вынуждены реализовать свои средства обеспечения гарантированной доставки на основе транспорта UDP [RFC768]. Ниже перечислены основные ограничения TCP, которые пользователи стремятся обойти.
- Протокол TCP обеспечивает гарантию доставки данных с сохранением их порядка. Некоторым приложениям требуется лишь гарантированная доставка, независимо от порядка, а другим приложениям может быть достаточно частичного сохранения порядка доставки. Оба типа приложений не устраивают дополнительные задержки TCP, возникающие при нарушении порядка доставки пакетов в сети.
- Потоковая природа протокола TCP зачастую не подходит для приложений, которым приходится вводить свои средства маркировки записей для делинеаризации передаваемых сообщений. Кроме того, приложениям приходиться явно использовать средства «выталкивания» данных (push) для того, чтобы сообщение было передано полностью за разумное время.
- Ограниченные возможности сокетов TCP усложняют для приложений задачу обеспечения высокого уровня доступности при обмене данными за счет использования многодомных4 хостов.
- Протокол TCP достаточно слабо защищен от атак на службы5, в частности, от SYN-атак.
Передача сигнальных сообщений PSTN через сети IP является примером приложения, которое сталкивается со всеми ограничениями протокола TCP. Это послужило основным мотивом разработки протокола SCTP, но можно найти и другие приложения, для которых транспорт SCTP будет предпочтительным.
1.2. Архитектура SCTP
Протокол SCTP размещается в многоуровневой модели между уровнем пользовательских приложений SCTP и сетевым сервисом без организации явных соединений (например, IP). В остальной части этого документа предполагается, что SCTP работает «поверх» протокола IP. Основным типом сервиса, обеспечиваемого протоколом SCTP, является гарантированная передача сообщений между пользователями SCTP. Этот сервис обеспечивается в контексте ассоциаций между парами конечных точек SCTP. В параграфе 10 данного документа приводится схематическое рассмотрение интерфейса API, который должен существовать на границе между протоколом SCTP и пользовательскими приложениями SCTP.
_____________ _____________ | Приложения | | Приложения | | SCTP | | SCTP | |-------------| |-------------| |Транспортный | |Транспортный | | сервис SCTP | | сервис SCTP | |-------------| |-------------| | Сетевой |Один или ---- Один или | Сетевой | | сервис IP |несколько \/ несколько | сервис IP | | |адресов IP /\ адресов IP | | |_____________| ---- |_____________| SCTP-узел A |<-------- Сетевой транспорт ------->| SCTP-узел B
Рисунок 1. SCTP-ассоциация
Протокол SCTP работает на основе явных соединений6, но ассоциация SCTP представляет собой более широкое понятие, нежели соединение TCP. Протокол SCTP обеспечивает для каждой конечной точки SCTP (см. параграф 1.4) способ обеспечения другой конечной точки (в процессе создания ассоциации) списком транспортных адресов (т. е., множеством адресов IP в комбинации с номером порта SCTP), которые эта конечная точка может использовать для связи и откуда она будет получать пакеты SCTP. Ассоциация может передавать данные с использованием всех возможных пар адресов отправителя и получателя, которые могут быть созданы на основе списков адресов конечных точек.
1.3. Основные термины
Некоторые термины, используемые в контексте SCTP, уже были упомянуты в предыдущих параграфах. Здесь даются определения основных терминов, связанных с протоколом.
Active destination transport address — активный транспортный адрес получателя
Адрес транспортного уровня конечной точки-партнера, который отправитель рассматривает как доступный для приема пользовательских сообщений.
Bundling – группировка
Дополнительная операция мультиплексирования, позволяющая передать в одном пакете несколько сообщений SCTP. Каждое пользовательское сообщение помещается в отдельный блок DATA.
Chunk – блок
Единица информации в пакете SCTP, содержащая заголовок блока (chunk header) и данные.
Congestion window (cwnd) — окно насыщения
Переменная SCTP, ограничивающая объем данных (число байтов), которые отправитель может передать в один активный адрес получателя до получения от последнего подтверждения.
Cumulative TSN Ack Point – указатель на кумулятивный номер Ack
Значение TSN для последнего блока DATA, подтвержденного с использованием поля Cumulative TSN Ack в SACK.
Idle destination address – неиспользуемый адрес получателя
Адрес, который не используется для передачи пользовательских сообщений в течение некоторого периода (обычно ≥ HEARTBEAT).
Inactive destination transport address – неактивный транспортный адрес получателя
Адрес, который считается неактивным в результате обнаружения ошибки, и не доступен для доставки пользовательских сообщений.
Message = user message – пользовательское сообщение
Данные, полученные протоколом SCTP от протокола вышележащего уровня (Upper Layer Protocol или ULP).
Message Authentication Code (MAC) – код аутентификации сообщения
Механизм проверки целостности, основанный на криптографической хэш-функции с секретным ключом. Обычно коды аутентификации сообщений используются между партнерами, использующими общий секретный ключ для проверки целостности информации, передаваемой между системами. В SCTP этот код применяется конечными точками для проверки информации State Cookie, полученной от удаленной стороны в блоке COOKIE ECHO. Термин MAC может иметь различные трактовки в разном контексте. В SCTP этот термин используется в том же значении, которое принято в [RFC2104].
Network Byte Order – сетевой порядок байтов
Порядок передачи байтов, при котором старший байт следует первым. Синоним Big Endian.
Ordered Message – упорядоченные сообщения
Пользовательские сообщения, доставленные в том же порядке, в котором они были помещены в поток.
Outstanding TSN (at an SCTP endpoint)
Номер TSN (и связанный с ним блок DATA), который был передан конечной точкой, но его получение еще не подтверждено.
Path – путь
Маршрут, используемый пакетами SCTP, переданными одной конечной точкой SCTP по определенному транспортному адресу другой конечной точки SCTP. Передача пакетов по различным транспортным адресам удаленной точки не обязательно ведет к изменению пути.
Primary Path – основной путь
Комбинация адресов отправителя и получателя которая будет помещаться в исходящие пакеты SCTP по умолчанию. Адрес отправителя включен в определение потому, что реализации протокола могут указывать оба адреса (получателя и отправителя) для обеспечения контроля пути возврата блоков с откликами и выбора интерфейса для передачи пакетов многодомными хостами.
Receiver Window (rwnd) – приемное окно
Переменная SCTP, которую отправитель использует для хранения последнего рассчитанного значения размера окна приема своего партнера по ассоциации. Размер окна приема задается количеством байтов. Значение размера позволяет отправителю определить величину свободного пространства в приемном буфере получателя.
SCTP association – ассоциация SCTP
Протокольные отношения между конечными точками SCTP, включающие пару узлов SCTP и информацию о состоянии протокола (теги Verification, активные значения TSN и т. п.). Для уникальной идентификации ассоциаций SCTP могут использоваться пары транспортных адресов конечных точек ассоциации. Между любой парой конечных точек SCTP недопустимо одновременное существование нескольких ассоциаций.
SCTP endpoint – конечная точка SCTP
Логический приемник/передатчик пакетов SCTP. Для многодомных хостов конечная точка SCTP представляется своему партнеру как комбинация набора допустимых транспортных адресов, по которым можно передавать пакеты SCTP и набора допустимых адресов транспортного уровня, с которых могут приниматься пакеты SCTP. Все транспортные адреса, используемые конечной точкой SCTP, должны быть связаны с одним номером порта, но могут иметь различные адреса IP. Транспортные адреса, используемые конечной точкой SCTP, недопустимо устанавливать для другой конечной точки SCTP (транспортный адрес каждой конечной точки SCTP должен быть уникальным).
SCTP packet (packet) – пакет SCTP
Элемент данных, передаваемый через интерфейс между SCTP и пакетной сетью без организации соединений (например, IP). Пакет SCTP включает общий заголовок SCTP, а также блок пользовательских данных (DATA chunk) и может включать блок управления SCTP.
SCTP user application (SCTP user) – пользовательское приложение SCTP (пользователь SCTP)
Логический объект вышележащего уровня, который использует сервис SCTP. Используется также термин Upper-layer Protocol (ULP) — протокол вышележащего уровня.
Slow-Start Threshold (ssthresh) – порог замедленного старта
Переменная SCTP, определяющая пороговое значение, по которому конечная точка будет определять необходимость использования для конкретного транспортного адреса процедуры slow start или congestion avoidance. Значение ssthresh указывается в байтах.
Stream – поток
Однонаправленный логический канал между двумя участниками ассоциации SCTP, через который передаются все пользовательские сообщения. При доставке сообщений их порядок сохраняется, если не была задана неупорядоченная доставка.
Примечание. Соотношения между номерами потоков в противоположных направлениях сильно зависят от того, как приложения используют эти потоки. Ответственность за поддержку корреляции между порядковыми номерами (если она нужна) ложится на пользовательское приложение SCTP.
Stream Sequence Number – порядковый номер в потоке
16-битовый порядковый номер, используемый SCTP для обеспечения упорядоченной доставки пользовательских сообщений в данном потоке. Каждому пользовательскому сообщению в потоке присваивается один порядковый номер.
Tie-Tags
Два 32-битовых случайных значений, которые вместе образуют 64-битовое одноразовое значение nonce. Эти теги используются в State Cookie и TCB для связывания недавно перезапущенной ассоциации с ее предшественником на конечной станции, которая не была перезагружена, но, тем не менее, не может найти тегов Verification существующей ассоциации.
Transmission Control Block (TCB) – блок управления передачей
Внутренняя структура данных, создаваемая конечной точкой SCTP для каждой из существующих ассоциаций SCTP с другими конечными точками SCTP. TCB содержит всю информацию о состоянии и режиме работы для конечной точки, чтобы поддерживать соответствующую ассоциацию и управлять ею.
Transmission Sequence Number (TSN)– порядковый номер при передаче
32-битовый порядковый номер, используемый протоколом SCTP для нумерации передаваемых блоков. Значение TSN связывается с каждым блоком, который содержит пользовательские данные, чтобы дать возможность конечной точке SCTP на приемной стороне подтвердить прием блока и обнаружить дубликаты.
Transport address – транспортный адрес
Адрес транспортного уровня обычно определяется комбинацией адреса сетевого уровня, транспортным протоколом и номером порта на транспортном уровне. При использовании SCTP в сетях IP транспортный адрес представляет собой комбинацию адреса IP и номера порта SCTP (транспортным протоколом является SCTP).
Unacknowledged TSN (at an SCTP endpoint) – неподтвержденный TSN (в конечной точке SCTP)
Номер TSN (и связанный с ним блок DATA), который был получен конечной точкой, но прием этого блока еще не был подтвержден удаленной стороне. С точки зрения передающей стороны это случай, когда пакет был передан, но подтверждение еще не получено.
Unordered Message – неупорядоченные сообщения
Неупорядоченные сообщения могут передаваться с изменением их местоположения в потоке относительно других сообщений. Неупорядоченные сообщения могут размещаться в потоке перед упорядоченными или после них.
User message – пользовательское сообщение
Элемент данных, передаваемый через интерфейс между пользовательским приложением и уровнем SCTP.
Verification Tag — тег верификации
32-битовое беззнаковое целое значение, которое обычно выбирается с использованием генератора случайных чисел. Verification Tag позволяет получателю проверить принадлежность полученного пакета SCTP к ассоциации и избавиться от старых пакетов из прежних ассоциаций.
1.4. Сокращения
MAC – Message Authentication Code [RFC2104] (код аутентификации сообщения).
RTO – Retransmission Timeout (тайм-аут повтора передачи).
RTT – Round-Trip Time (время кругового обхода).
RTTVAR – Round-Trip Time Variation (вариации времени кругового обхода).
SCTP – Stream Control Transmission Protocol (протокол управления потоковой передачей).
SRTT – Smoothed RTT (сглаженное значение RTT).
TCB – Transmission Control Block (блок управления передачей).
TLV – Type-Length-Value coding format (формат представления тип-размер-значение).
TSN – Transmission Sequence Number (порядковый номер при передаче).
Пользовательские приложения SCTP ----------------------------------------------------- _____________ ____________________ | | | Упорядоченная | | Создание | | доставка в потоке | | | |____________________| | и | | | ____________________________ | разрыв | | Фрагментация польз. данных | | | |____________________________| | ассоциаций | | | ____________________________ | | | Подтверждения | | | | и предотвращения | | | | насыщения | | | |____________________________| | | | | ____________________________ | | | Связывание блоков | | | |____________________________| | | | | ________________________________ | | | Проверка пакетов | | | |________________________________| | | | | ________________________________ | | | Управление путями | |_____________| |________________________________|
Рисунок 2 Функциональное представление сервиса SCTP
ULP – Upper-Layer Protocol (протокол вышележащего уровня).
1.5. Функциональность SCTP
Транспортный сервис SCTP можно разделить на несколько функциональных групп, показанных на рисунке 2.
1.5.1. Создание и разрыв ассоциаций
Ассоциации создаются по запросам пользователей SCTP (см. описание примитива ASSOCIATE на стр. 47 или SEND на стр. 48).
В процессе создания ассоциаций используется механизм cookie, подобный предложенному Кэрном (Karn) и Симпсоном (Simpson) в [RFC2522], для обеспечения защиты от атак на синхронизацию. Этот механизм использует четырехэтапное согласование (four-way handshake), в котором два последних этапа могут использоваться для передачи пользовательских данных в целях ускорения процедуры соединения. Стартовые последовательности описаны в главе 5 данного документа.
Протокол SCTP обеспечивает аккуратное завершение работы активных ассоциаций (shutdown) по запросу пользователя SCTP (см. описание примитива SHUTDOWN на стр. 48). Протокол SCTP позволяет также разрывать ассоциации (abort) по запросу пользователя (примитив ABORT) или в результате обнаружения ошибок на уровне SCTP. В главе 9 описаны оба варианта завершения работы ассоциаций.
Протокол SCTP не поддерживает полуоткрытых состояний (как в TCP), когда одна сторона может передавать данные после того, как другая сторона уже закрыла соединение. Когда любая из конечных точек выполняет процедуру завершения shutdown, на обеих сторонах ассоциации прекращается прием новых данных и доставляются лишь данные из очереди (см. главу 9).
1.5.2. Упорядоченная доставка в потоках
Термин «поток» (stream) используется в протоколе SCTP для обозначения последовательности пользовательских сообщений, которые доставляются протоколам вышележащих уровней в том же порядке, который сообщения имели в самом потоке. Это отличается от значения термина поток в контексте TCP, где потоком называют последовательности байтов (в этом документе предполагается, что размер байта составляет 8 битов).
Пользователь SCTP может во время создания ассоциации задать число потоков, поддерживаемых этой ассоциацией. Это значение согласуется с удаленной стороной (см. параграф 5.1.1). Пользовательские сообщения связываются с номерами потоков (см. примитивы SEND на стр. 48 и RECEIVE на стр. 49). Протокол SCTP присваивает порядковые номера в потоке каждому сообщению, полученному протоколом от пользователя SCTP. На приемной стороне SCTP обеспечивает доставку сообщений пользователю с сохранением их последовательности в данном потоке. В силу того, что один поток может быть заблокирован ожиданием следующего по порядку пользовательского сообщения, в это время возможна доставка сообщений из других потоков.
Протокол SCTP обеспечивает механизм обхода упорядоченной доставки. Пользовательские сообщения, переданные с использованием такого механизма, доставляются пользователю по мере их приема.
1.5.3. Фрагментация пользовательских данных
При необходимости протокол SCTP фрагментирует пользовательские сообщения, чтобы пакеты SCTP, передаваемые нижележащему уровню, соответствовали значению MTU для пути. При получении фрагменты собираются протоколом SCTP до их доставки пользователю.
1.5.4. Подтверждения и предотвращение насыщения
Протокол SCTP присваивает номер TSN каждому фрагменту и нефрагментированному пользовательскому сообщению. Нумерация TSN не зависит от порядковых номеров в потоках, присваиваемых на уровне потока. Принимающая сторона подтверждает все полученные TSN даже при обнаружении пропуска в номерах. Такой подход обеспечивает независимую функциональность для гарантии доставки и сохранения порядка сообщений.
Функция подтверждения и предотвращения насыщения отвечает за повторную передачу пакетов, когда подтверждение о доставке не приходит от получателя вовремя. Повтор передачи связан с предотвращением насыщения подобно тому, как это сделано для протокола TCP. В главах 6 и 7 приводится подробное описание протокольных процедур, связанных с выполнением этой функции.
1.5.5. Группировка блоков
Как описано в главе 3, пакет SCTP, передаваемый на нижележащий уровень, содержит общий заголовок, за которым следует один или несколько информационных блоков (chunk). Каждый блок может содержать пользовательские данные или управляющую информацию SCTP. Пользователь SCTP может запросить группировку нескольких сообщений в один пакет SCTP. Функция группировки блоков (chunk bundling) протокола SCTP отвечает за сборку таких пакетов и их последующую разборку на приемной стороне.
В периоды насыщения реализация SCTP может продолжать группировку сообщений даже в тех случаях, когда пользователь просил SCTP не группировать сообщения. Пользовательский запрет группировки влияет лишь на реализации SCTP, которые могут вносить незначительную задержку перед отправкой пакета в сеть. Когда пользовательский уровень запрещает группировку, этой незначительной задержки не возникает, но группировка по-прежнему будет использоваться при насыщении и повторных передачах.
1.5.6. Проверка пакетов
Обязательное поле Verification Tag и 32-битовая контрольная сумма (см. Приложение B, в котором приведено описание контрольных сумм CRC32c), передаются в общем заголовке SCTP. Значение Verification Tag выбирается каждой стороной в процессе создания ассоциации. Пакеты, полученные без ожидаемого значения Verification Tag, отбрасываются в целях защиты от атак вслепую с маскированием адресов и избавления от старых пакетов SCTP, оставшихся от предыдущей ассоциации. Контрольная сумма CRC32c помещается отправителем в каждый пакет SCTP для обеспечения дополнительной защиты от повреждения данных в сети. Получатель пакета SCTP с некорректной контрольной суммой CRC32c отбрасывает такие пакеты без уведомления.
1.5.7. Управление путями
Передающий пакеты SCTP пользователь может манипулировать набором транспортных адресов, используемых для указания получателя пакетов SCTP с помощью примитивов, описанных в главе 10. Функция управления путями SCTP выбирает транспортный адрес получателя для каждого исходящего пакета SCTP на основе пользовательских инструкций и доступной информации о достижимости желанного для пользователя адреса. Функция управления путями ведет мониторинг доступности с помощью блоков heartbeat, когда другой трафик не позволяет получить достоверных данных о доступности адресов, и сообщает пользователю об изменениях состояния доступности любых адресов транспортного уровня на удаленной стороне. Функция управления путями отвечает также за передачу информации о доступных локальных адресах транспортного уровня на удаленную сторону в процессе создания ассоциации и за передачу пользователю таких сведений, полученных от удаленной стороны.
При создании ассоциации определяется основной путь (primary path) для каждой конечной точки SCTP. Этот путь в дальнейшем используется при нормальных условиях работы.
На приемной стороне функция управления путями отвечает за проверку существования корректной ассоциации SCTP, к которой относятся входящие пакеты SCTP, до передачи таких пакетов на дальнейшую обработку.
Примечание. Функции Path Management и Packet Validation выполняются одновременно, хотя и описаны по отдельности (в реальности эти функции не могут выполняться независимо одна от другой).
1.6. Порядковые номера
Важно помнить, что пространство пространство порядковых номеров TSN ограничено, хотя и достаточно велико. Значения порядковых номеров могут находиться в диапазоне от 0 до 232 – 1. Ввиду конечных размеров пространства номеров TSN все арифметические операции с такими номерами должны осуществляться по модулю 232 – это обеспечит возможность после достижения максимального значения TSN снова перейти к номеру 0. При сравнении значений порядковых номеров следует принимать во внимание цикличность их изменения. Символ =< применительно к TSN означает «меньше или равно» (модуль 232).
При арифметических операциях и сравнении номеров TSN для протокола SCTP следует пользоваться арифметикой порядковых номеров, определенной в [RFC1982] для случая SERIAL_BITS = 32.
Конечным точкам не следует передавать блоки DATA со значением TSN, которое более чем на 231 – 1 превышает начальное значение TSN для текущего окна передачи. Использование таких значений может привести к возникновению проблем при сравнении TSN.
Порядковые номера TSN сбрасываются в 0 при достижении границы 232 – 1. Т. е., следующий блок DATA после блока с TSN = 232 – 1 должен иметь TSN = 0.
Во всех арифметических операциях с порядковыми номерами в потоках (Stream Sequence Number) следует использовать арифметику порядковых номеров, определенную в [RFC1982] для случая SERIAL_BITS = 16. Все прочие операции с порядковыми номерами в данном документе используют обычную арифметику.
1.7. Отличия от RFC 2960
Протокол SCTP был изначально определен в [RFC2960], который данный документ отменяет. Читателям, интересующимся подробностями отличий, рекомендуется прочесть [RFC4460].
2. Соглашения о терминах
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии сRFC 2119].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3. Формат пакетов SCTP
Пакет SCTP состоит из общего заголовка и блоков (chunk), содержащих пользовательские сообщения или управляющую информацию.
Формат пакетов SCTP показан на рисунке.
В одном пакете SCTP может содержаться множество блоков, пока размер пакета не превышает значение MTU. Исключение составляют блоки INIT, INIT ACK, и SHUTDOWN COMPLETE, которые недопустимо группировать с другими блоками в один пакет. Более подробное описание группировки блоков приводится в параграфе 6.10.
Если пользовательское сообщение не помещается в пакет SCTP, оно может быть разделено на фрагменты с использованием процедуры, описанной в параграфе 6.9.
Все целочисленные поля пакетов SCTP должны передаваться с использованием сетевого порядка байтов, если явно не указан другой порядок.
3.1. Описание полей общего заголовка SCTP
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Формат SCTP Common Header показан на рисунке.
Source Port Number – 16 битов (целое число без знака)
Номер порта SCTP, используемого отправителем. Это значение, вместе с IP-адресом отправителя, номером порта получателя и (возможно) IP-адресом получателя, может использоваться на приемной стороне для идентификации ассоциации, к которой относится пакет. Значение 0 для номера порт недопустимо.
Destination Port Number – 16 битов (целое число без знака)
Номер порта SCTP, в который данный пакет адресован. На приемной стороне это значение будет использоваться для демультиплексирования пакета SCTP соответствующей конечной точке или приложению. Значение 0 для номера порт недопустимо.
Verification Tag – 32 бита (целое число без знака)
Принимающая сторона использует тег Verification для проверки отправителя пакета SCTP. На передающей стороне значение поля Verification Tag должно устанавливаться в соответствии со значением Initiate Tag, полученным от партнера при создании ассоциации, за исключением перечисленных ниже случаев.
- В пакетах, содержащих блок INIT, тег Verification должен быть установлен в 0.
- В пакетах, содержащих блок SHUTDOWN-COMPLETE с установленным флагом T, значение тега Verification должно копироваться из пакета с блоком SHUTDOWN-ACK.
- В пакетах, содержащих блок ABORT, тег верификации может быть копией значения тега из пакета, вызвавшего передачу блока ABORT. Более подробное описание приведено в параграфах 8.4 и 8.5.
Блок INIT должен быть единственным блоком в пакете SCTP.
Checksum – 32 бита (целое число без знака)
Это поле содержит контрольную сумму для данного пакета SCTP. Расчет контрольных сумм описан в параграфе 6.8. Протокол SCTP использует алгоритм CRC32c, описанный в Приложении B.
3.2. Описание поля Chunk
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
На рисунке показан формат блоков (chunk), передаваемых в пакетах SCTP. Каждый блок содержит поле Chunk Type, зависящие от типа флаги (Flags), поле размера Chunk Length и поле данных Value.
Chunk Type – 8 битов (целое число без знака)
Это поле указывает тип блока, содержащегося в поле Chunk Value. Поле типа может содержать значения от 0 до 254. Значение 255 зарезервировано для будущего использования в качестве расширения.
Значения идентификаторов типа приведены в таблице.
| ID | Тип блока | ID | Тип блока |
|---|---|---|---|
| 0 | Пользовательские данные (DATA) | 12 | Зарезервировано для Explicit Congestion Notification Echo (ECNE) |
| 1 | Инициализация (INIT) | 13 | Зарезервировано для Congestion Window Reduced (CWR) |
| 2 | Подтверждение инициирования (INIT ACK) | 14 | Процедура окончания работы завершена (SHUTDOWN COMPLETE) |
| 3 | Выборочное подтверждение (SACK) | 15 – 62 | Доступны |
| 4 | Запрос Heartbeat (HEARTBEAT) | 63 | Резерв для определенных IETF расширений |
| 5 | Подтверждение Heartbeat (HEARTBEAT ACK) | 64 – 126 | Доступны |
| 6 | Прерывание (ABORT) | 127 | Резерв для определенных IETF расширений |
| 7 | Завершение работы (SHUTDOWN) | 128 – 190 | Доступны |
| 8 | Подтверждение завершения (SHUTDOWN ACK) | 191 | Резерв для определенных IETF расширений |
| 9 | Ошибка при операции (ERROR) | 192 – 254 | Доступны |
| 10 | State Cookie (COOKIE ECHO) | 255 | Резерв для определенных IETF расширений |
| 11 | Подтверждение Cookie (COOKIE ACK) |
Коды Chunk Type выбраны таким образом, чтобы два старших бита определяли действие, которое следует предпринять конечной точке на приемной стороне, если Chunk Type не удается распознать.
00 – прекратить обработку данного пакета SCTP и отбросить его, не выполняя никаких действий по отношению к содержащейся в нем информации
01 – прекратить обработку пакета SCTP и отбросить его без выполнения каких либо действий с содержащимися в пакете данными, указать неопознанный параметр в поле Unrecognized Parameter Type.
10 – пропустить данный блок и продолжить обработку пакета.
11 – пропустить данный блок и продолжить обработку пакета с генерацией блока ERROR, содержащего в поле Unrecognized Chunk Type сведения о причине ошибки.
Примечание. Типы типы ECNE и CWR зарезервированы для использования в будущем явных уведомлений о насыщении (ECN7), описанных в Приложении A.
Chunk Flags – 8 битов
Использование этих битов определяется типом блока, указанным в поле Chunk Type. Если в документе явно не указано иное, на передающей стороне все биты следует устанавливать в 0, а на приемной – игнорировать.
Chunk Length – 16 битов (целое число без знака)
Это поле указывает размер блока в байтах с учетом полей Chunk Type, Chunk Flags, Chunk Length и Chunk Value. Следовательно, для блоков с пустым Chunk Value поле Length имеет значение 4. Байты заполнения в поле Chunk Length не учитываются.
Блоки (включая поля Type, Length и Value) дополняются отправителем нулями для выравнивания по 4-байтовой границе. Использовать заполнение размером более 3 байтов недопустимо. Значение поля Chunk Length не учитывает заполнение в конце блока. Однако в размере учитывается заполнение в любых параметрах переменного размера, за исключением последнего параметра в блоке. Получатель должен игнорировать заполнение.
Примечание. Отказоустойчивым реализациям следует воспринимать блоки даже в тех случаях, когда поле Chunk Length учитывает заполнение.
Chunk Value – переменный размер
Поле Chunk Value содержит передаваемую в этом блоке информацию. Формат этого поля и способы его использования зависят от значения Chunk Type.
Общий размер блока (включая поля Type, Length и Value) должен быть кратным 4. Если размер блока не кратен 4, отправитель должен дополнить блок байтами со значением 0, не учитывая эти байты в поле Chunk Length. Заполнение размером долее 3 байтов недопустимо. Получатель должен игнорировать байты заполнения.
Подробное описание используемых в SCTP блоков приводится в параграфе 3.3. Руководства для создания расширений, определяемых IETF, приведены в параграфе 14.1.
3.2.1. Необязательные параметры и поля переменного размера
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Parameter Type | Chunk Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Блоки управления SCTP включают зависящий от типа блока заголовок с набором полей, за которым может следовать то или иное количество параметров. Необязательные параметры и поля переменной длины указываются в формате TLV8 как описано ниже.
Chunk Parameter Type – 16 битов (целое число без знака)
Поле Type содержит 16-битовый идентификатор типа параметра и может принимать значения от 0 до 65534.
Значение 65535 зарезервировано для определяемых IETF расширений. Все значения, кроме перечисленных в данном документе при описании конкретных блоков SCTP, зарезервированы для использования IETF.
Chunk Parameter Length – 16 битов (целое число без знака)
Поле Parameter Length указывает размер параметра в байтах с учетом полей Parameter Type, Parameter Length и Parameter Value. Следовательно, для параметров с полем Parameter Value данное поле имеет значение 4. Поле размера не учитывает байты заполнения.
Chunk Parameter Value – переменный размер
Поле Parameter Value содержит информацию, передаваемую с помощью данного параметра.
Общий размер параметра (включая поля Type, Length и Value) должен быть кратным 4. Если размер параметра не кратен 4, отправитель добавляет в конце (т. е., полсе Parameter Value) байты с нулевым значением. Байты заполнения не учитываются в поле размера. Для отправителя недопустимо использование более 3 байтов заполнения. Получатель должен игнорировать байты заполнения.
Поле Parameter Type кодируется так, чтобы два старших бита определяли действия, предпринимаемые при обнаружении неизвестного параметра.
00 – прекращение обработки данного параметра и отказ от обработки других параметров данного блока.
01 – прекращение обработки данного параметра и отказ от обработки других параметров данного блока с генерацией сообщения об ошибке, указывающего нераспознанный параметр в поле Unrecognized Parameter, как описано в параграфе 3.2.2.
10 – пропуск параметра и продолжение обработки.
11 – пропуск параметра и продолжение обработки с генерацией сообщения об ошибке, указывающего нераспознанный параметр в поле Unrecognized Parameter, как описано в параграфе 3.2.2.
Следует отметить, что во всех 4 случаях передается блок INIT ACK или COOKIE ECHO. Для случаев 00 и 01 обработка параметров после неизвестного параметра не производится, но уже обработанные параметры не отбрасываются.
Реальные параметры SCTP определяются в параграфах, посвященных конкретным блокам SCTP. Правила для определенных IETF расширений параметров определены в параграфе 14.2. Отметим, что тип параметра должен быть уникальным для всех блоков. Например, тип параметра 5 используется для представления адресов IPv4 (см. параграф 3.3.2.1). Значение 5 в этом случае резервируется во всех блоках для представления адресов IPv4 и недопустимо его использование в ином смысле в любом другом блоке.
3.2.2. Уведомления о неизвестных параметрах
Если получатель блока INIT обнаруживает неизвестные параметры и сообщает о них в соответствии с параграфом 3.2.1, он должен указать эти параметры в поле Unrecognized Parameter блока INIT ACK, передаваемого в ответ на INIT. Отметим, что если получатель блока INIT не организует ассоциацию (например, по причине нехватки ресурсов), поле Unrecognized Parameter не включается в блок ABORT, передаваемый в ответ на INIT.
Если получатель блока INIT ACK обнаруживает неизвестные параметры и сообщает о них в соответствии с параграфом 3.2.1, ему следует сгруппировать блок ERROR, содержащий поле Unrecognized Parameters с указанием причины ошибки, с блоком COOKIE ECHO, передаваемым в ответ на INIT ACK. Если получатель INIT ACK не группирует блок COOKIE ECHO с блоком ERROR, последний можно передать отдельно, но не раньше получения COOKIE ACK.
Примечание. В любом случае передачи в пакете блока COOKIE ECHO этот блок должен быть первым блоком.
3.3. Определения блоков SCTP
В этом разделе описываются форматы блоков SCTP различных типов.
3.3.1. Пользовательские данные (DATA) (0)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (последовательность n потока S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Для блоков DATA должен использоваться показанный на рисунке формат.
Reserved – 5 битов
Отправителю следует заполнить это поле нулями, а получатель – игнорировать его.
U – 1 бит
Флаг разупорядочивания, устанавливаемый для блоков DATA, которые могут передаваться без сохранения порядка. Для таких блоков значение поля Stream Sequence Number не устанавливается, следовательно, получатель должен его игнорировать.
После сборки (если она требуется) неупорядоченные блоки DATA должны диспетчеризоваться получателем на вышележащий уровень без попыток восстановления порядка, если флаг U имеет значение 1.
Если неупорядоченное пользвательское сообщение фрагментируется, для каждого фрагмента должен устанавливаться флаг U = 1.
Таблица 1: Состояния флагов B и E
| B | E | Описание |
|---|---|---|
| 1 | 0 | Первый фрагмент |
| 0 | 0 | Один из средних фрагментов |
| 0 | 1 | Последний фрагмент |
| 1 | 1 | Нефрагментированное сообщение |
B – 1 бит
Флаг первого фрагмента пользовательского сообщения.
E – 1 бит
Флаг последнего фрагмента пользовательского сообщения.
В нефрагментированных пользовательских сообщениях нужно устанавливать (1) оба флага B и E. Нулевые значения обоих флагов устанавливаются в средних (не первом и не последнем) фрагментах пакета.
При фрагментировании пользовательского сообщения на множество блоков получатель использует для сборки номера TSN. Это означает, что фрагменты должны передаваться в строгой последовательности.
Length – 16 битов (целое число без знака)
Это поле показывает размер блока DATA от начала поля типа и до конца пользовательских данных (без учета байтов заполнения). Для блока DATA с одним байтом пользовательских данных Length = 17 (17 байтов).
Блок DATA с полем User Data размера L будет иметь поле Length со значением (16 + L) и L должно быть больше 0.
TSN – 32 бита (целое число без знака)
Это поле содержит порядковый номер TSN для блока DATA. Значения номеров TSN могут находиться в диапазоне от 0 до 4294967295 (232 – 1). После достижения TSN максимального значения 4294967295 нумерация продолжается с 0.
Stream Identifier S – 16 битов (целое число без знака)
Идентификатор потока, к которому относится блок данных.
Stream Sequence Number n – 16 битов (целое число без знака)
Это значение представляет порядковый номер пользовательских данных в потоке S. Допустимые значения лежат в диапазоне от 0 до 65535.
При фрагментировании пользовательского сообщения протоколом SCTP в каждом фрагмент должен указываться одинаковый порядковый номер в потоке.
Payload Protocol Identifier – 32 бита (целое число без знака)
Это поле содержит заданный приложением (или вышележащим протоколом) идентификатор протокола. SCTP получает идентификатор от вышележащего уровня и передает его удаленному партнеру. Значение идентификатора не используется протоколом SCTP, но может быть использовано некоторыми сетевыми объектами и приложениями на удаленной стороне для идентификации типа информации, передаваемой в блоке DATA. Это поле должно передаваться даже для фрагментированных блоков DATA (чтобы обеспечить доступность информации для агентов в сети). Отметим, что реализации SCTP не работают с этим полем, поэтому в нем не требуется использовать порядок байтов big endian. За преобразования порядка байтов в этом поле отвечает вышележащий уровень.
Нулевое значение показывает что протокол вышележащего уровня не указал идентификатор протокола для этого блока.
User Data – переменный размер
Это поле переменной длины содержит пользовательскую информацию. Реализация протокола должна обеспечивать выравнивание размеров поля по 4-байтовой границе путем добавления от 1 до 3 байтов с нулевым значением. Недопустимо учитывать байты заполнения в поле размера блока. Для отправителя недопустимо использование более 3 байтов заполнения.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Необязательные параметры и параметры переменной длины / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.2. Инициализация (INIT) (1)
Этот блок используется для создания ассоциации SCTP между парой конечных точек. Формат блока INIT показан на рисунке.
Блок INIT содержит перечисленные ниже параметры. Если явно не сказано иное, каждый параметр должен включаться в блок INIT в одном экземпляре.
| Фиксированные параметры | Статус |
|---|---|
| Initiate Tag | Обязательный |
| Advertised Receiver Window Credit | Обязательный |
| Number of Outbound Streams | Обязательный |
| Number of Inbound Streams | Обязательный |
| Initial TSN | Обязательный |
| Переменные параметры | Статус | Тип |
|---|---|---|
| IPv4 Address9 | Необязательный | 5 |
| IPv6 Address1 | Необязательный | 6 |
| Cookie Preservative | Необязательный | 9 |
| Reserved for ECN Capable10 | Необязательный | 32768 (0x8000) |
| Host Name Address11 | Необязательный | 11 |
| Supported Address Types12 | Необязательный | 12 |
Примечание для разработчкиов. Если принят блок INIT с известными параметрами, которые не являются опциональными для блока INIT, получателю следует обработать блок INIT и возвратить его отправителю INIT ACK. Получатель блока INIT может позднее сгруппировать блок ERROR с блоком COOKIE ACK. Однако реализация может возвратить блок ABORT в ответ на блок INIT.
Поле Chunk Flags в INIT является резервным и отправителю следует устанавливать все его биты в 0, а получателю — игнорировать их. Параметры блока INIT можно обрабатывать в любом порядке.
Initiate Tag – 32 бита (целое число без знака)
Получатель INIT (отвечающая сторона) записывает значение параметра Initiate Tag. Это значение должно включаться в поле Verification Tag каждого пакета SCTP, который получатель данного блока INIT будет передавать через эту ассоциацию.
Поле Initiate Tag может содержать любые значения кроме 0. Рекомендации по выбору значений этого тега приводятся в параграфе 5.3.1.
Если в принятом блоке INIT значение Initiate Tag = 0, получатель должен трактовать это как ошибку и закрывать ассоциацию, передавая ABORT.
Advertised Receiver Window Credit (a_rwnd) – 32 бита (целое число без знака)
Это значение представляет размер (в байтах) выделенного буферного пространства, которое отправитель INIT зарезервировал для данной ассоциации. В течение срока существования ассоциации не следует снижать размер этого буфера (т. е., буфер может быть удален только вместе с ассоциацией), однако конечная точка может изменить значение с помощью параметра a_rwnd, переданного в SACK.
Number of Outbound Streams (OS) – 16 битов (целое число без знака)
Указывает число исходящих потоков, которые отправитель блока INIT желает открыть для данной ассоциации. Для этого параметра недопустимо использование значения 0.
Примечание. Получателю блока INIT с OS = 0 следует прервать ассоциацию.
Number of Inbound Streams (MIS) – 16 битов (целое число без знака)
Указывает максимальное число потоков, которые отправитель данного блока INIT готов принять от удаленного партнера для этой ассоциации. Использование значений 0 в данном поле недопустимо.
Примечание. Здесь не используется согласование числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.
Примечание. Получателю блока INIT с MIS = 0 следует прервать ассоциацию.
Initial TSN (I-TSN) – 32 бита (целое число без знака)
Определяет начальное значение TSN, которое будет использовать отправитель (диапазон допустимых значений – от 0 до 42949672950). В это поле можно помещать значение поля Initiate Tag.
3.3.2.1. Необязательные параметры и параметры переменного размера в блоке INIT
Перечисленные ниже параметры используют формат TLV, как описано в параграфе 3.2.1. Любые комбинации параметров TLV должны размещаться в блоке после параметров фиксированного размера, описанных в предыдущем параграфе.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Параметр IPv4 Address (5)
IPv4 Address – 32 бита (целое число без знака)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Содержит адрес IPv4 передающей стороны в двоичном формате.
Параметр IPv6 Address (6)
IPv6 Address – 128 битов (целое число без знака)
Содержит адрес IPv6 [RFC2460] передающей стороны в двоичном формате.
Примечание. Отправителю недопустимо использовать адреса отображенные на IPv4 адреса IPv6 [RFC4291], вместо этого следует применять параметр IPv4 Address для адреса IPv4.
Вместе с параметром Source Port Number в общем заголовке SCTP адреса IPv4 и IPv6 определяют адрес транспортного уровня, который отправитель блока INIT будет поддерживать для создаваемой ассоциации. Т. е., этот IP-адрес в течении срока существования данной ассоциации может появляться в поле отправителя дейтаграмм IP, передаваемых отправителем данного блока INIT, и может использоваться в качестве IP-адреса получателя в дейтаграммах, передаваемых получателем данного блока INIT.
В блоке INIT можно указывать более одного адреса IP, если отправитель INIT является многодомным хостом. Более того, многодомные хосты могут быть подключены к разнотипным сетям и в блоках INIT могут указываться одновременно адреса IPv4 и IPv6.
Если INIT содержит хотя бы один параметр IP Address, адрес отправителя в дейтаграмме, содержащей блок INIT, и любые адреса, указанные в INIT, могут использоваться другой стороной при ответе в качестве адреса получателя. Если INIT не содержит ни одного параметра IP Address, получившая блок INIT конечная точка должна использовать адрес отправителя в заголовке дейтаграммы IP, содержащей блок INIT, как единственный адрес партнера в данной ассоциации.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested Cookie Life-span Increment (мсек.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Отметим, что отсутствие параметров IP address в блоках INIT и INIT ACK упрощает организацию ассоциаций при работе через устройства NAT.
Параметр Cookie Preservative (9)
Отправителю блока INIT следует использовать этот параметр для того, чтобы предложить получателю INIT увеличение срока жизни State Cookie.
Suggested Cookie Life-Span Increment – 32 бита (целое число без знака)
Этот параметр показывает получателю размер увеличения срока жизни cookie в миллисекундах.
Этот необязательный параметр отправителю следует добавлять в блок INIT при попытке создания ассоциации после того, как предыдущая попытка сорвалась по причине ошибки в работе stale cookie. Получатель может проигнорировать предложенное увеличение срока жизни cookie в соответствии со своей политикой безопасности.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Параметр Host Name Address (11)
Отправитель блока INIT использует этот параметр для передачи партнеру своего имени (Host Name) взамен адреса IP. Преобразование имени осуществляется на приемной стороне. Использование этого параметра может упростить создание ассоциаций через NAT.
Host Name – переменный размер
Это поле содержит имя хоста с использованием синтаксиса, определенного в параграфе 2.1 RFC1123 [RFC1123]. Метод преобразования имени в адрес выходит за пределы спецификации протокола SCTP.
Примечание. Имя хоста должно содержать по крайней мере один завершающий нуль-символ, который учитывается в поле размера.
Параметр Supported Address Types (12)
Отправитель блока INIT использует этот параметр для перечисления всех типов поддерживаемых им адресов.
Address Type – 16 битов (целое число без знака)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type #1 | Address Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В этом поле указывается значение типа адреса из соответствующего TLV (например, IPv4 = 5, IPv6 = 6, Hostname = 11).
3.3.3. Подтверждение инициализации (INIT ACK) (2)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Необязательные параметры и параметры переменной длины / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Блок INIT ACK используется для подтверждения инициирования ассоциации SCTP.
Параметры INIT ACK форматируются подобно параметрам блока INIT. Кроме того, блоки данного типа содержат два дополнительных параметра – State Cookie и Unrecognized Parameter.
Формат блока INIT ACK показан на рисунке.
Initiate Tag – 32 бита (целое число без знака)
Получатель блока INIT ACK записывает значение параметра Initiate Tag. Это значение должно помещаться в поле Verification Tag каждого пакета SCTP, который получатель INIT ACK будет передавать в данной ассоциации.
Для поля Initiate Tag недопустимо использование значения 0. Выбор значений параметра Initiate Tag рассматривается в параграфе 5.3.1.
Если в полученном блоке INIT ACK параметр Initiate Tag = 0, приемная сторона должна трактовать это как ошибку и прерывать ассоциацию, отбрасывая TCB. Получатель может передать блок ABORT для отладки.
Advertised Receiver Window Credit (a_rwnd) – 32 бита (целое число без знака)
Это значение указывает размер буфера (в байтах), выделенного отправителем INIT ACK для данной ассоциации. Во время существования ассоциации не следует уменьшать размер буфера (т. е., выделенный буфер должен умереть вместе с ассоциацией).
Number of Outbound Streams (OS) – 16 битов (целое число без знака)
Определяет число исходящих потоков, которые отправитель INIT ACK желает создать для данной ассоциации. Недопустимо устанавливать для этого параметра значение 0, недопустимо также устанавливать для параметра значение, превышающее значение MIS, переданное в блоке INIT.
Примечание. Получателю блока INIT ACK с параметром OS = 0 следует закрыть ассоциацию, отбросив TCB.
Number of Inbound Streams (MIS) – 16 битов (целое число без знака)
Указывает максимальное число потоков, которые отправитель INIT ACK позволяет создать удаленному партнеру в данной ассоциации. Недопустимо использование нулевого значения для этого параметра.
Примечание. Здесь нет согласования числа потоков – каждая сторона просто выбирает меньшее из двух значений – предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.
Примечание. Получателю блока INIT ACK с параметром MIS = 0 следует разорвать ассоциацию, отбрасывая TCB.
Initial TSN (I-TSN) – 32 бита (целое число без знака)
Определяет начальный номер TSN, который отправитель INIT ACK будет использовать. Корректные значения лежат в диапазоне от 0 до 4294967295. Это поле может содержать значение параметра Initiate Tag.
| Фиксированные параметры | Статус |
|---|---|
| Initiate Tag | Обязательный |
| Advertised Receiver Window Credit | Обязательный |
| Number of Outbound Streams | Обязательный |
| Number of Inbound Streams | Обязательный |
| Initial TSN | Обязательный |
| Переменные параметры | Статус | Тип |
|---|---|---|
| State Cookie | Обязательный | 7 |
| IPv4 Address13 | Необязательный | 5 |
| IPv6 Address1 | Необязательный | 6 |
| Unrecognized Parameter | Необязательный | 8 |
| Reserved for ECN Capable14 | Необязательный | 32768 (0x8000) |
| Host Name Address15 | Необязательный | 11 |
Примечание для разработчиков. Реализации должны быть готовы к получению INIT ACK достаточно большого (более 1500 байтов) размера по причине переменного размера State Cookie и списка адресов. Например, если отвечающая на INIT сторона имеет 1000 адресов IPv4, по которым она желает принимать данные, для них потребуется не менее 8000 байтов в блоке INIT ACK.
Примечание для разработчиков. Если принят блок INIT ACK с известными параметрами, которые не являются опциональными для INIT ACK, получателю следует обработать блок INIT ACK и передать в ответ COOKIE ECHO. Получатель INIT ACK может группировать блок ERROR с блоком COOKIE ECHO. Однако ограниченные реализации могут передавать блок ABORT в ответ на INIT ACK.
Вместе с параметром Source Port Number в общем заголовке SCTP параметр IP Address в INIT ACK указывает получателю INIT ACK адрес транспортного уровня, который отправитель блока INIT ACK будет поддерживать в течение срока жизни создаваемой ассоциации.
Если INIT ACK содержит хотя бы один параметр IP Address, указанные в нем адреса вместе с адресом отправителя в заголовке дейтаграммы IP, содержащей INIT ACK, могут использоваться получателем INIT ACK блока в качестве адресов получателя для этой ассоциации. Если в INIT ACK нет параметра IP Address, получатель блока INIT ACK должен использовать адрес отправителя содержащей этот блок дейтаграммы IP в качестве единственного адреса получателя для этой ассоциации.
Параметры State Cookie и Unrecognized Parameters используют формат TLV в соответствии с определением параграфа 3.2.1 и описаны ниже.
Остальные поля соответствуют одноименным полям блока INIT.
3.3.3.1. Необязательные параметры и параметры переменной длины
Параметр State Cookie (7)
Тип
7
Размер
Переменный, зависит от размера Cookie.
Значение
Значение этого параметра должно включать всю необходимую информацию о состоянии и параметрах, требуемую отправителю данного блока INIT ACK для создания ассоциации, а также код аутентификации сообщения (MAC16). See Section 5.1.3 for details on State Cookie definition.
Параметр Unrecognized Parameter
Тип
8
Размер
Переменный.
Значение
Этот параметр возвращается отправителю блока INIT, если этот блок включает нераспознанный параметр, значение которого показывает, что следует уведомить отправителя. Значение этого поля включает нераспознанные параметры, копируемые из блока INIT (все 3 поля Type, Length и Value).
3.3.4. Селективное подтверждение (SACK) (3)
Этот блок передается партнеру для подтверждения приема блоков DATA и информирования партнера о пропусках в порядковых номерах блоков DATA, представленных в TSN.
Блок SACK должен включать поля Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks и Number of Duplicate TSNs.
По определению поле Cumulative TSN Ack содержит значение последнего номера TSN, полученного до того, как была нарушена последовательность принятых TSN, следующее за этим значение TSN (на 1 большее) еще не получено стороной, передающей SACK. Этот параметр, следовательно, подтверждает доставку всех TSN, номера которых не превышают значение поля.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ ... \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Обработка a_rwnd получателем SACK рассмотрена в параграфе 6.2.1
SACK может также содержать параметры Gap Ack Block, каждый из которых подтверждает последовательность TSN, полученных после прерывания основной последовательности номеров TSN. По определению все TSN, подтвержденные с помощью Gap Ack Block, имеют значения, превышающие Cumulative TSN Ack.
Chunk Flags – 8 битов
Заполняется нулями на передающей стороне и игнорируется на приемной.
Cumulative TSN Ack – 32 бита (целое число без знака)
Этот параметр содержит значение TSN последнего блока DATA, который был принят до прерывания последовательности номеров. Если блоков DATA еще не получено, это поле содержит партнерское значение Initial TSN – 1.
Advertised Receiver Window Credit (a_rwnd) – 32 бита (целое число без знака)
Это поле показывает обновленное значение размера (в байтах) приемного буфера на стороне отправителя данного блока SACK (см. параграф 6.2.1).
Number of Gap Ack Blocks – 16 битов (целое число без знака)
Показывает число параметров Gap Ack Block, включенных в SACK.
Number of Duplicate TSNs – 16 битов
Это поле показывает число дубликатов TSN, полученных конечной точкой. Каждый дубликат TSN указывается в последующем списке Gap Ack Block.
Блоки Gap Ack
Эти поля содержат параметры Gap Ack Block, число которых задано значением поля Number of Gap Ack Blocks. Все блоки DATA с номерами TSN, большими или равными Cumulative TSN Ack + Gap Ack Block Start и меньшими или равными Cumulative TSN Ack + Gap Ack Block End из каждого предполагаются принятыми без ошибок.
Gap Ack Block Start – 16 битов (целое число без знака)
Показывает стартовое смещение TSN для данного Gap Ack Block. Для расчета реального номера TSN это смещение добавляется к значению параметра Cumulative TSN Ack. Рассчитанное таким способом значение TSN указывает первый номер TSN в данном Gap Ack Block, который был принят.
Gap Ack Block End – 16 битов (целое число без знака)
Показывает финишное смещение TSN для данного Gap Ack Block. Для расчета реального номера TSN это смещение добавляется к значению параметра Cumulative TSN Ack. Рассчитанное таким способом значение TSN указывает последний номер TSN в данном Gap Ack Block для принятого блока DATA.
Предположим для примера, что недавно принятые блоки DATA в момент принятия решения о передаче SACK образуют последовательность, показанную на рисунке.
----------
| TSN=17 |
----------
| | <- не получен
----------
| TSN=15 |
----------
| TSN=14 |
----------
| | <- не получен
----------
| TSN=12 |
----------
| TSN=11 |
----------
| TSN=10 |
----------
Тогда часть блока SACK должна включать поля, показанные на следующем рисунке (предполагается, что новое значение a_rwnd = 4660).
+--------------------------------+
| Cumulative TSN Ack = 12 |
+--------------------------------+
| a_rwnd = 4660 |
+----------------+---------------+
| num of block=2 | num of dup=0 |
+----------------+---------------+
|block #1 strt=2 |block #1 end=3 |
+----------------+---------------+
|block #2 strt=5 |block #2 end=5 |
+----------------+---------------+
Duplicate TSN – 32 бита (целое число без знака)
Показывает количество случаев, когда номер TSN был принят как дубликат, с момента передачи последнего блока SACK. При получении каждого дубликата TSN (до момента передачи SACK) этот дубликат добавляется в список. Счетчик дубликатов сбрасывается в 0 после отправки каждого блока SACK.
Например, если получатель принял TSN 19 трижды, номер 19 будет указан два раза в блоке SACK. После отправки SACK, если TSN 19 будет принят снова, он будет указан в списке нового блока SACK.
3.3.5. Запрос Heartbeat (HEARTBEAT) (4)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Chunk Flags | Heartbeat Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (переменный размер) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Конечной точке следует передавать такой запрос своему партнеру для проверки его доступности через тот или иной транспортный адрес, указанный для данной ассоциации.
Поле Heartbeat Information имеет переменный размер и содержит структуру данных, понятную только отправителю.
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
Heartbeat Length – 16 битов (целое число без знака)
Задает размер блока в байтах с учетом заголовка и поля Heartbeat Information.
Heartbeat Information – переменный размер
Параметр переменного размера, который использует формат, описанный в параграфе 3.2.1.
| Параметр | Статус | Тип |
|---|---|---|
| Heartbeat Info | Обязательный | 1 |
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Info Type=1 | HB Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Sender-Specific Heartbeat Info / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В поле Sender-Specific Heartbeat Info обычно следует включать информацию о текущем времени отправителя на момент передачи данного блока HEARTBEAT и транспортный адрес получателя этого блока (см. параграф 8.3). Эта информация просто «отражается» получателем в его блоке HEARTBEAT ACK (см. параграф 3.3.6). Отметим также, что сообщения HEARTBEAT служат для проверки доступности и корректности пути (см. параграф 5.4). При использовании блока HEARTBEAT для проверки пути он должен включать 64-битовое случайное значение nonce.
3.3.6. Подтверждение Heartbeat (HEARTBEAT ACK) (5)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Chunk Flags | Heartbeat Ack Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (переменный размер) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Конечной точке следует передавать такой блок в ответ на запрос HEARTBEAT (см. параграф 8.3). Блок HEARTBEAT ACK всегда передается по тому адресу IP, который был указан в заголовке дейтаграммы, содержавшей HEARTBEAT.
Поле параметра содержит «непрозрачную» структуру данных с переменным размером.
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
Heartbeat Length – 16 битов (целое число без знака)
Задает размер блока в байтах с учетом заголовка и поля Heartbeat Information.
Heartbeat Information – переменный размер
Это поле должно содержать параметр Heartbeat Information из запроса Heartbeat, на который отвечает данный блок Heartbeat Acknowledgement.
| Параметр | Статус | Тип |
|---|---|---|
| Heartbeat Info | Обязательный | 1 |
3.3.7. Разрыв ассоциации (ABORT) (6)
Блок ABORT передается партнеру для разрыва ассоциации. Блок ABORT может содержать параметры Error Cause, информирующие партнера о причинах разрыва ассоциации. Недопустимо группировать блоки DATA с блоком ABORT. Блоки управления (кроме INIT, INIT ACK и SHUTDOWN COMPLETE) могут группироваться с ABORT, но эти блоки должны размещаться перед блоком ABORT в пакете SCTP, поскольку в противном случае получатель проигнорирует их.
Если конечная точка получает блок ABORT с некорректным форматом или TCB не найдено, такой блок должен быть отброшен без уведомления. Более того, в некоторых случаях для получившей такой блок ABORT конечной точки недопустимо передавать в ответ свой блок ABORT.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 |Reserved |T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Причины ошибок (Error Cause) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов
Reserved – 7 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
T – 1 бит
Бит T сбрасывается в 0, если отправитель заполнил поле Verification Tag, ожидаемое партнером. Если в Verification Tag используется «отраженное» значение, должно устанавливаться T = 1. Отражение означает, что переданное значение Verification Tag совпадает с принятым.
Примечание. Для проверки этого типа блоков применяются специальные правила, описанные в параграфе 8.5.1.
Length – 16 битов (целое число без знака)
Указывает размер блока в байтах с учетом заголовка и всех полей Error Cause.
Определения причин ошибки (Error Cause) приведены в параграфе 3.3.10.
3.3.8. Завершение ассоциации (SHUTDOWN) (7)
Конечная точка ассоциации должна использовать этот блок для аккуратного завершения работы ассоциации. Формат блока описан ниже.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Chunk Flags | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
Length – 16 битов (целое число без знака)
Показывает размер параметра и имеет значение 8.
Cumulative TSN Ack – 32 бита (целое число без знака)
Этот параметр содержит номер последнего TSN, принятого без пропусков в нумерации.
Примечание. Поскольку блок SHUTDOWN не содержит параметров Gap Ack Block, он не может служить подтверждением TSN, принятых с нарушением порядка. В блоках SACK отсутствие Gap Ack Block, которые были указаны в предыдущих сообщениях, показывает, что получатель данных отказался от соответствующих блоков DATA. Поскольку SHUTDOWN не содержит Gap Ack Block, получателю блока SHUTDOWN не следует интерпретировать отсутствие Gap Ack Block как отказ (см. параграф 6.2).
3.3.9. Подтверждение закрытия ассоциации (SHUTDOWN ACK) (8)
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Этот блок должен использоваться для подтверждения приема блока SHUTDOWN при завершении процесса закрытия, описанного в параграфе 9.2.
Блок SHUTDOWN ACK не содержит параметров.
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
3.3.10. Ошибка при работе (ERROR) (9)
Конечные точки передают блоки этого типа для уведомления партнера о некоторых типах ошибок. Блок содержит один или несколько кодов ошибок. Прием сообщения об ошибке не обязывает партнера разрывать ассоциацию, однако такие блоки могут передаваться вместе с блоком ABORT в качестве отчета о причине разрыва. Параметры блока описаны ниже.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Одно или несколько полей Error Cause / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
Length – 16 битов (целое число без знака)
Указывает размер блока в байтах с учетом заголовка и всех полей Error Cause.
Причины ошибок указываются как параметры переменного размера в соответствии с определением параграфа 3.2.1.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-Specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code – 16 битов (целое число без знака)
Указывает код причины, которая вызвала передачу сообщения.
| Код | Описание | Код | Описание |
|---|---|---|---|
| 1 | Некорректный идентификатор потока | 8 | Нераспознанные параметры |
| 2 | Отсутствие обязательного параметра | 9 | Отсутствие пользовательских данных |
| 3 | Ошибка Stale Cookie | 10 | Получение Cookie в процессе закрытия |
| 4 | Нехватка ресурсов | 11 | Перезапуск ассоциации с новыми адресами |
| 5 | Не удалось преобразовать адрес | 12 | Инициированный пользователем разрыв |
| 6 | Нераспознанный тип блока | 13 | Протокольное нарушение |
| 7 | Некорректный обязательный параметр |
Cause Length – 16 битов (целое число без знака)
Указывает размер параметра в байтах с учетом полей Cause Code, Cause Length и Cause-Specific Information
Cause-Specific Information – переменный размер
В этом поле указываются сведения об ошибке.
Причины ошибок SCTP рассматриваются в параграфах 3.3.10.1 – 3.3.10.10. Рекомендации по определению новых типов ошибок для IETF даны в параграфе 14.3.
3.3.10.1. Неприемлемый идентификатор потока (1)
Причина ошибки
Invalid Stream Identifier
Показывает, что конечная точка получила блок DATA, переданный в несуществующий поток.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=1 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream Identifier – 16 битов (целое число без знака)
Это поле содержит значение Stream Identifier из блока DATA, вызвавшего ошибку.
Reserved – 16 битов
Зарезервированное поле. Устанавливается в 0 на передающей стороне и игнорируется на приемной.
3.3.10.2. Отсутствует обязательный параметр (2)
Причина ошибки
Missing Mandatory Parameter
Говорит об отсутствии одного или нескольких обязательных параметров TLV в принятом блоке INIT или INIT ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=2 | Cause Length=8+N*2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of missing params=N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #1 | Missing Param Type #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Missing Param Type #N-1 | Missing Param Type #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of Missing params – 32 бита (целое число без знака)
Это значение указывает число отсутствующих параметров, перечисленных в поле Cause-specific Information.
Missing Param Type – 16 битов (целое число без знака)
Каждое поле содержит пропущенный обязательный параметр.
3.3.10.3. Ошибка Stale Cookie (3)
Причина ошибки
Stale Cookie Error
Говорит о получении корректного значения State Cookie с истекшим сроком.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=3 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Measure of Staleness (мксек.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Measure of Staleness – 32 бита (целое число без знака)
В этом поле указывается разница между текущим временем и временем окончания срока действия State Cookie (в микросекундах).
Отправитель этого сообщения может указать время, прошедшее после завершения срока действия State Cookie, отличным от нуля значением поля Measure of Staleness. Если отправитель не хочет передавать эти сведения, ему следует установить нулевое значение в поле Measure of Staleness.
3.3.10.4. Нехватка ресурсов (4)
Причина ошибки
Out of Resource
Указывает нехватку ресурсов у отправителя и передается обычно в комбинации с блоком ABORT или просто в нем.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=4 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.5. Не удалось преобразовать адрес (5)
Причина ошибки
Unresolvable Address
Говорит о том, что отправителю не удалось преобразовать указанный адресный параметр (например, отправитель не поддерживает этот тип адресов) и передается обычно в комбинации с блоком ABORT или просто в нем.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=5 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unresolvable Address /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unresolvable Address – переменный размер
Поле Unresolvable Address содержит полное значение параметра TLV, задающего адрес (или параметра Host Name) или имя хоста, которые не удалось преобразовать.
3.3.10.6. Не распознан тип блока (6)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Причина ошибки
Unrecognized Chunk Type
Эта информация передается отправителю блока, если получатель не смог определить тип блока и два старших бита поля Chunk Type имеют значение 01 или 11.
Unrecognized Chunk – переменный размер
Поле Unrecognized Chunk содержит нераспознанный блок из пакета SCTP, включая поля Chunk Type, Chunk Flags и Chunk Length.
3.3.10.7. Неприемлемый обязательный параметр (7)
Причина ошибки
Invalid Mandatory Parameter
Это сообщение передается отправителю блока INIT или INIT ACK, когда один или несколько обязательных параметров имеют некорректные значения.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=7 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.8. Нераспознанные параметры (8)
Причина ошибки
Unrecognized Parameters
Это сообщение возвращается отправителю блока INIT ACK, если получателю не удается распознать один или несколько необязательных параметров TLV в блоке INIT ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=8 | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Unrecognized Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Parameters – переменный размер
Поле Unrecognized Parameters содержит нераспознанные параметры, скопированные из блока INIT ACK полностью в форме TLV. Это сообщение обычно передается в блоках ERROR, объединенных с блоком COOKIE ECHO при отклике на INIT ACK, когда отправитель блока COOKIE ECHO желает сообщить о нераспознанных параметрах.
3.3.10.9. Нет пользовательских данных (9)
Причина ошибки
No User Data
Это сообщение передается отправителю блока DATA, если принятый блок не содержит пользовательских данных.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=9 | Cause Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ TSN value /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TSN value – 32 бита (целое число без знака)
Значение поля TSN из блока DATA, принятого без пользовательских данных.
Это сообщение обычно передается в блоке ABORT (см. параграф 6.2).
3.3.10.10. Получение Cookie во время процедуры закрытия (10)
Причина ошибки
Cookie Received While Shutting Down
Это сообщение говорит о приеме COOKIE ECHO в то время, когда конечная точка находилась в состоянии SHUTDOWN-ACK-SENT. Обычно этот код возвращается в блоке ERROR, сгруппированном с повторным блоком SHUTDOWN ACK.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=10 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.11. Перезапуск ассоциации с новыми адресами (11)
Причина ошибки
Restart of an association with new addresses
Был получен блок INIT в существующей ассоциации и этот блок добавляет адреса, которые раньше не были частью данной ассоциации. Новые адреса указываются в коде ошибки. Этот сообщение обычно передается как часть блока ABORT, отвергающего INIT (см. параграф 5.2).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Примечание. Каждый элемент New Address TLV является точной копией связанного с новым адресом TLV из блока INIT, включая Parameter Type и Parameter Length.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.12. Разрыв по инициативе пользователя (12)
Причина ошибки
Эта причина ошибки может включаться в блоки ABORT, передаваемые по запросам вышележащего уровня. Этот уровень может указать значение Upper Layer Abort Reason, которое прозрачно передается протоколом SCTP и может быть доставлено протоколу прикладного уровня у партнера.
3.3.10.13. Протокольное нарушение (13)
Причина ошибки
Эта причина ошибки может включаться в блоки ABORT передаваемые в результате обнаружения конечной точкой SCTP нарушение протокола партнером, которое не может быть описано причинами, указанными в параграфах 3.3.10.1 – 3.3.10.12. Реализация может предоставить дополнительную информацию о нарушении протокола.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.11. Cookie Echo (COOKIE ECHO) (10)
Этот блок используется только в процессе создания ассоциации. Он передается инициатором ассоциации удаленному партнеру для завершения процесса инициирования ассоциации. Такой блок должен предшествовать любому блоку DATA, передаваемому через ассоциацию, но может быть сгруппирован с одним или несколькими блоками DATA в один пакет.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 |Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
Length – 16 битов (целое число без знака)
Указывает размер блока в байтах, включая 4 байта заголовка блока и размер Cookie.
Cookie – переменный размер
Это поле должно содержать точную копию параметра State Cookie, полученного в предыдущем блоке INIT ACK.
Реализациям протокола следует стремиться к уменьшению размера cookie в целях обеспечения интероперабельности.
Примечание. Блок Cookie Echo не включает параметр State Cookie и данные из поля Parameter Value в State Cookie становятся Chunk Value в Cookie Echo. Это позволяет реализациям поменять лишь два первых байта параметра State Cookie, чтобы сделать из него блок COOKIE ECHO.
3.3.12. Подтверждение Cookie (COOKIE ACK) (11)
Этот тип блоков используется только при создании ассоциации и служит подтверждением приема блока COOKIE ECHO. Данный блок должен предшествовать любому блоку DATA или SACK в данной ассоциации, но может группироваться с одним или несколькими блоками DATA или блоком SACK в одном пакете SCTP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 |Chunk Flags | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
3.3.13. Закрытие ассоциации завершено (SHUTDOWN COMPLETE) (14)
Этот тип блоков должен использоваться для подтверждения приема блока SHUTDOWN ACK при завершении ассоциации (см. параграф 9.2).
Блок SHUTDOWN COMPLETE не содержит параметров.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 14 |Reserved |T| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags – 8 битов
Reserved – 7 битов
Устанавливается в 0 на передающей стороне и игнорируется на приемной.
T – 1 бит
Бит T сбрасывается в 0, если отправитель заполнил поле Verification Tag, ожидаемое партнером. Если в Verification Tag используется «отраженное» значение, должно устанавливаться T = 1. Отражение означает, что переданное значение Verification Tag совпадает с принятым.
Примечание. Для проверки этого типа блоков применяются специальные правила, описанные в параграфе 8.5.1.
4. Диаграмма состояний ассоциации SCTP
В течение срока существования ассоциации SCTP участвующие в ней конечные точки могут переходить из одного состояния в другое в результате тех или иных событий. События, способные изменить состояние ассоциации, включают:
- вызовы пользовательских примитивов SCTP (например, [ASSOCIATE], [SHUTDOWN], [ABORT]);
- прием управляющих блоков INIT, COOKIE ECHO, ABORT, SHUTDOWN и т. п.;
- тайм-ауты.
----- -------- (из любого состояния)
/ \ / rcv ABORT [ABORT]
rcv INIT | | | ---------- или ----------
--------------- | v v удалить TCB snd ABORT
генерация Cookie \ +---------+ удалить TCB
и INIT ACK ---| CLOSED |
+---------+
/ \ [ASSOCIATE]
/ \ ---------------
| | создать TCB
| | snd INIT
| | запустить таймер init
rcv корректн. | |
COOKIE ECHO | v
(1) ---------------- | +------------+
создать TCB | | COOKIE-WAIT| (2)
snd COOKIE ACK | +------------+
| |
| | rcv INIT ACK
| | -----------------
| | snd COOKIE ECHO
| | остановить таймер init
| | запустить таймер cookie
| v
| +--------------+
| | COOKIE-ECHOED| (3)
| +--------------+
| |
| | rcv COOKIE ACK
| | -----------------
| | остановить таймер cookie
v v
+---------------+
| ESTABLISHED |
+---------------+
(продолжение рисунка на следующей странице)
Приведенные рисунки показывают возможные состояния ассоциации и переходы между ними вместе с вызывающими эти переходы событиями и выполняемыми при смене состояния действиями. Некоторые ошибки не показаны на схеме состояний. Полное описание всех состояний и переходов приводится в тексте документа.
Примечание. Имена блоков указаны заглавными буквами, а в именах параметров только первая буква является заглавной (например, блок COOKIE ECHO и параметр State Cookie). Если смену состояния могут вызвать несколько событий или сообщений, они помечаются (A), (B) и т. д.
Примечания.
- Если параметр State Cookie в принятом блоке COOKIE ECHO не приемлем (например, не прошла проверка целостности), получатель должен отбросить пакет без уведомления. Если получен State Cookie с истекшим сроком (см. параграф 5.1.5), получатель должен оправить в ответ блок ERROR. В обоих случаях получатель остается в состоянии CLOSED.
- Если истекло время по таймеру T1-init, конечная точка должна повторить передачу INIT и заново запустить таймер T1-init без смены своего состояния. Эти действия должны повторяться до Max.Init.Retransmits раз, после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.
- Если истекло время по таймеру T1-cookie, конечная точка должна повторить передачу COOKIE ECHO и заново запустить таймер T1-cookie без смены состояния. Эта процедура должна повторяться до Max.Init.Retransmits раз, после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.
- В состоянии SHUTDOWN-SENT конечная точка должна подтверждать все принятые блоки DATA без задержек.
- В состоянии SHUTDOWN-RECEIVED для конечной точки недопустимо принимать любые новые запросы на передачу от пользователя SCTP.
- В состоянии SHUTDOWN-RECEIVED конечная точка должна передать (возможно повторно) данные и выйти из этого состояния после того, как будут переданы все данные из очереди.
- В состоянии SHUTDOWN-ACK-SENT для конечной точки недопустимо принимать от пользователя SCTP любые новые запросы на передачу.
Состояние CLOSED на схеме используется для того, чтобы показать, что ассоциация еще не создана (т .е., не существует).
5. Создание ассоциации
До того, как сможет произойти передача первых данных от одной конечной точки SCTP (“A”) к другой (“Z”), эти две точки должны выполнить полностью процесс создания ассоциации.
Пользователю SCTP в конечной точке следует применять примитив ASSOCIATE для создания ассоциации с другой конечной точкой SCTP.
Примечание для разработчиков. С точки зрения пользователя SCTP ассоциация может быть создана неявно без обращения к примитиву ASSOCIATE (см. параграф 10.1 B) просто путем передачи первых пользовательских данных удаленному адресату. Инициирующий ассоциацию узел SCTP будет задавать принятые по умолчанию значения для всех обязательных и дополнительных параметров INIT/INIT ACK.
После создания ассоциации организуются двухсторонние потоки данных для передачи информации в обоих направлениях (см. параграф 5.1.1).
5.1. Нормальное создание ассоциации
(только из состояния ESTABLISHED)
|
|
/--------+--------\
[SHUTDOWN] / \
-------------------| |
проверить оставшиеся | |
блоки DATA | |
v |
+---------+ |
|SHUTDOWN-| | rcv SHUTDOWN/проверить
|PENDING | | оставшиеся блоки DATA
+---------+ | ----------------------
| |
нет оставшихся блоков| |
---------------------| |
snd SHUTDOWN | |
запустить таймер | |
shutdown v v
+---------+ +-----------+
(4) |SHUTDOWN-| | SHUTDOWN- | (5,6)
|SENT | | RECEIVED |
+---------+ +-----------+
| \ |
(A) rcv SHUTDOWN ACK | \ |
----------------------| \ |
ост. таймер shutdown | \rcv:SHUTDOWN |
send SHUTDOWN COMPLETE| \ (B) |
удалить TCB | \ |
| \ | нет оставшихся блоков
| \ | -----------------
| \ | send SHUTDOWN ACK
(B)rcv SHUTDOWN | \ | запустить таймер
----------------------| \ | shutdown
send SHUTDOWN ACK | \ |
зап. таймер shutdown | \ |
перейти в SHUTDOWN- | \ |
ACK-SENT | | |
| v |
| +-----------+
| | SHUTDOWN- | (7)
| | ACK-SENT |
| +----------+-
| | (C)rcv SHUTDOWN COMPLETE
| |-----------------
| | запустить таймер shutdown
| | удалить TCB
| |
| | (D)rcv SHUTDOWN ACK
| |--------------
| | останов. таймер shutdown
| | send SHUTDOWN COMPLETE
| | удалить TCB
| |
\ +---------+ /
\-->| CLOSED |<--/
+---------+
Рисунок 3 Диаграмма состояний протокола SCTP (продолжение)
Процесс инициализации описан ниже в предположении, что конечная точка A пытается создать ассоциацию, а точка Z принимает вызов.
- A сначала передает блок INIT точке Z. В блока INIT точка A должна указать свой Verification Tag (Tag_A) в поле Initiate Tag. Для Tag_A следует использовать случайное число из диапазона от 1 до 4294967295 (см. рекомендации по выбору значения тега в параграфе 5.3.1). После передачи блока INIT A запускает таймер T1-init и переходит в состояние COOKIE-WAIT.
- Z следует сразу же ответить на запрос блоком INIT ACK. IP-адрес получателя в блоке INIT ACK должен совпадать с адресом отправителя блока INIT, для которого передается INIT ACK. Кроме заполнения других полей отклика точка Z должна скопировать в поле Verification Tag значение Tag_A, а также указать свое значение Verification Tag (Tag_Z) в поле Initiate Tag.
Кроме того, точка “Z” должна сгенерировать и передать с INIT ACK значение State Cookie (см. параграф 5.1.3). - При получении блока INIT ACK от Z точке A следует остановить таймер T1-init и выйти из состояния COOKIE-WAIT. Далее A следует передать значение State Cookie из принятого блока INIT ACK в ответном блоке COOKIE ECHO, запустить таймер T1-cookie и перейти в состояние COOKIE-ECHOED.
- При получении блока COOKIE ECHO точка Z будет передавать блок COOKIE ACK после создания TCB и перехода в состояние ESTABLISHED. Блок COOKIE ACK может объединяться с любыми ожидающими передачи блоками DATA и/или SACK, но блок COOKIE ACK должен быть первым в пакете.
Примечание для разработчиков. Реализация протокола может передавать уведомление Communication Up пользователю SCTP при получении корректного блока COOKIE ECHO. - Приняв блок COOKIE ACK, точка A будет переходить из состояния COOKIE-ECHOED в состояние ESTABLISHED, останавливая таймер T1-cookie. Она может также уведомить ULP об успешном создании ассоциации с помощью Communication Up (см. раздел 10).
- Примечание. Блок COOKIE ECHO может группироваться с любыми ожидающими передачи блоками DATA, но эти блоки должны размещаться в пакете после COOKIE ECHO. До получения ответного блока COOKIE ACK недопустима передача каких-бы то ни было пакетов удаленному партнеру.
- Примечание. Сразу после передачи INIT ACK с параметром State Cookie для Z недопустимо выделять какие-либо ресурсы или сохранять какие-либо состояния для новой ассоциации, поскольку это сделает точку Z уязвимой для атак на ресурсы системы.
Блоки INIT и INIT ACK недопустимо группировать с другими блоками. Такой блок должен быть единственным в содержащем его пакете SCTP.
Конечная точка должна передавать блок INIT ACK по адресу IP, с которого был передан блок INIT.
Примечание. Для таймеров T1-init и T1-cookie должны выполняться правила, описанные в параграфе 6.3.
Если конечная точка, получившая блок INIT, INIT ACK или COOKIE ECHO, решает не создавать новую ассоциацию по причине отсутствия обязательных параметров в блоке INIT или INIT ACK, неприемлемых значений параметров или нехватки локальных ресурсов, ей следует передать в ответ блок ABORT. Этой точке также следует указать причину отказа (тип отсутствующих обязательных параметров и т. п.), включив соответствующий параметр в блок ABORT. Поле Verification Tag в общем заголовке исходящего пакета SCTP, содержащего блок ABORT, должно содержать значение Initiate Tag, полученное от партнера.
Отметим, что блок COOKIE ECHO без проверки целостности не рассматривается, как неприемлемый, и требует специальной обработки, описанной в параграфе 5.1.5.
После получения первого блока DATA в ассоциации конечная точка должна без промедления передать блок SACK для подтверждения приема блока DATA. Последующие подтверждения передаются в соответствии с рекомендациями параграфа 6.2.
При создании TCB каждая точка должна установить для внутреннего параметра Cumulative TSN Ack Point значение переданного Initial TSN – 1.
Примечание для разработчиков. В качестве ключей поиска TCB для данного экземпляра SCTP обычно используются IP-адреса и номер порта SCTP.
5.1.1. Обработка параметров потока
В блоках INIT и INIT ACK отправитель должен указывать число исходящих потоков (OS), которые он желает поддерживать для данной ассоциации, а также максимальное число входящих потоков (MIS), которые он будет принимать от удаленного партнера.
После получения сведений о конфигурации потоков от другой стороны каждая конечная точка должна выполнить ряд проверок. Если значение полученное от партнера значение MIS меньше локального OS, это означает, что удаленный партнер не сможет поддерживать все исходящие потоки и данная точка должна установить для числа исходящих потоков значение MIS или может сообщить вышележащему уровню о нехватке ресурсов на удаленной стороне. На основании этого вышележащий уровень может принять решение о разрыве ассоциации, если работа при нехватке ресурсов не приемлема для него.
После того, как ассоциация инициализирована, приемлемые значения идентификаторов исходящих потоков для нее могут находиться в диапазоне [0 – min(local OS, remote MIS)-1].
5.1.2. Обработка адресов
В процессе создания ассоциации конечным точкам следует использовать перечисленные ниже правила для определения и сохранения транспортных адресов своего партнера.
- Если в принятом блоке INIT или INIT ACK нет адресных параметров, следует взять адрес отправителя из заголовка пакета IP, в котором был доставлен блок, и сохранить этот адрес вместе с номером порта SCTP, использованным отправителем пакета, как единственный транспортный адрес партнера.
- Если в полученном блоке INIT или INIT ACK присутствует параметр Host Name, имя следует преобразовать в адрес (список адресов) IP и сохранить транспортные адреса партнера, как комбинации полученных при преобразовании адресов IP и номера порта отправителя SCTP.Пока получатель блока INIT выполняет преобразование имени хоста в адрес, он подвержен потенциальному риску атак на SCTP. Если получатель INIT преобразует имя хоста в адрес при получении блока и используемый механизм преобразования может вносить достаточно большую задержку (например, запросы DNS), получатель может быть открыт для атаки на ресурсы в течение периода ожидания результатов преобразования имени до создания State Cookie и освобождения локальных ресурсов.Получателю INIT ACK всегда следует незамедлительно предпринять попытку преобразования имени после получения блока.Если не удается преобразовать имя, конечная точка должна незамедлительно передать своему партнеру блок ABORT с причиной ошибки Unresolvable Address. Блок ABORT следует отправлять по адресу IP из заголовка пакета, в котором был получен последний пакет от партнера.
- Если в принятом блоке INIT или INIT ACK присутствуют только адреса IPv4/IPv6, получателю следует выделить и записать все транспортные адреса из полученного блока и адреса отправителя в заголовке пакета IP, содержащего блок INIT или INIT ACK. Транспортные адреса представляют собой комбинацию номера порта SCTP (из общего заголовка) и адресов IP, переданных в блоке INIT или INIT ACK и заголовке пакета IP, доставившего блок. Получателю следует использовать только эти транспортные адреса для передачи последующих пакетов удаленному партнеру.
- Блок INIT или INIT ACK должен трактоваться, как относящийся к организованной ранее (или организуемой сейчас) ассоциации, если использование любого из содержащихся в нем корректных адресных параметров уже зафиксировано в существующих TCB.
- Для получателя INIT или INIT ACK недопустима передача пользовательских данных до преобразования имени хоста в адрес.
- Следовательно, в тех случаях, когда преобразование имен может происходить достаточно долго, получатель INIT должен отложить процедуру преобразования до того, как будет получен блок COOKIE ECHO от партнера. В таких случаях получателю INIT следует создать State Cookie с использованием полученного значения Host Name (вместо транспортного адреса получателя) и передать блок INIT ACK по адресу отправителя из заголовка IP в пакете, содержащем принятый блок INIT.
- Конечная точка должна игнорировать все дополнительные параметры с IP-адресами, если они присутствуют в блоке INIT или INIT ACK.
Примечание для разработчиков. В некоторых случаях (например, когда реализация не контролирует IP-адреса отправителя, используемые при передаче) конечной точке может потребоваться включение в блок INIT или INIT ACK всех адресов IP, которые могут использоваться для передачи.
После выделения транспортного адреса из блока INIT или INIT ACK с использованием описанных выше правил конечной точке следует выбрать один из таких адресов для организации первичного пути.
Примечание. Блок INIT ACK должен передаваться по адресу отправителя блока INIT.
Отправитель блока INIT может включить в этот блок параметр Supported Address Types, показывающий поддерживаемые типы адресов. При наличии такого параметра получатель блока INIT должен использовать один из указанных этим параметром типов адресов при передаче отклика на INIT или разорвать ассоциацию с помощью блока ABORT с причиной ошибки Unresolvable Address, если конечная точка не желает или не может использовать ни один из типов адресов, указанных партнером.
Примечание для разработчиков. В тех случаях, когда получателю блока INIT ACK не удается выполнить преобразование адреса вследствие отсутствия поддержки указанного типа, попытка создания ассоциации может быть прервана, после чего предпринимается попытка повторной организации с использованием параметра Supported Address Types в новом блоке INIT для индикации предпочтительных типов адресов.
Примечание для разработчиков. Если конечная точка SCTP, поддерживающая только один из типов адресов (IPv4 или IPv6), получает адреса IPv4 и IPv6 в блоке INIT или INIT ACK от своего партнера, она должна использовать все указанные партнером адреса, которые относятся к поддерживаемому типу. Не следует в таких случаях передавать какие-либо сообщения об ошибке.
Примечание для разработчиков. Если конечная точка SCTP указывает в параметре Supported Address Types только один из типов IPv4 и IPv6, но использует для передачи пакета с блоком INIT другой тип или перечисляет адрес другого типа в блоке INIT, адреса не указанного в параметре Supported Address Types типа получателю блока INIT также следует считать поддерживаемыми. Не следует в таких случаях передавать какие-либо сообщения об ошибке.
5.1.3. Генерация State Cookie
При передаче блока INIT ACK в ответ на INIT отправитель INIT ACK создает значение State Cookie и передает его в одноименном параметре блока INIT ACK. В параметр State Cookie отправителю следует включить MAC (см., например, [RFC2104]), временную метку генерации State Cookie и время жизни параметра State Cookie, а также другую информацию, требуемую для создания ассоциации.
При генерации State Cookie следует выполнить перечисленные ниже операции.
- Создать для ассоциации TCB с использованием информации из полученного блока INIT и передаваемого блока INIT ACK.
- В TCB установить время создания по текущему времени суток, а для срока жизни использовать протокольный параметр Valid.Cookie.Life (см. раздел 15).
- Из TCB выделить и сохранить минимальный набор информации, требуемой для повторного создания TCB, и создать MAC с использованием этого набора и секретного ключа (см. пример генерации MAC в [RFC2104]).
- Создать State Cookie, объединив минимальный набор информации и полученное значение MAC.
После передачи блока INIT ACK с параметром State Cookie отправителю следует удалить TCB и все прочие локальные ресурсы, связанные с новой ассоциацией в целях предотвращения атак на ресурсы.
Метод хеширования, используемый для генерации MAC является приватным для получателя блока INIT. Использование MAC является обязательным с целью предотвращения атак на службы. В качестве секретного ключа следует использовать случайное значение (см. рекомендации [RFC4086]), которое следует менять достаточно часто. Для идентификации ключа, который будет использоваться для проверки MAC, может служить временная метка момента создания State Cookie.
Для обеспечения интероперабельности реализациям протокола следует минимизировать размер cookie.
5.1.4. Обработка State Cookie
Когда конечная точка (в состоянии COOKIE WAIT) получает блок INIT ACK с параметром State Cookie, она должна незамедлительно передать своему партнеру блок COOKIE ECHO с полученным значением State Cookie. Отправитель может также добавить в пакет ожидающие обработки блоки DATA после блока COOKIE ECHO.
Конечной точке следует также запустить таймер T1-cookie после передачи блока COOKIE ECHO. По истечении заданного для таймера периода конечной точке следует повторить передачу блока COOKIE ECHO и заново включить таймер T1-cookie. Эту процедуру следует повторять до получения блока COOKIE ACK или исчерпания числа попыток Max.Init.Retransmits (см. раздел 15). Если заданное число попыток не привело к успеху, партнер помечается как недоступный (и ассоциация переводится в положение CLOSED).
5.1.5. Аутентификация State Cookie
Когда конечная точка получает блок COOKIE ECHO от другой конечной точки, с которой нет действующей ассоциации, ей следует выполнить перечисленные ниже операции.
- Рассчитать MAC с использованием данных TCB, полученных в State Cookie, и секретного ключа (отметим, что для выбора секретного ключа может использоваться временная метка из State Cookie). Расчет MAC можно выполнять в соответствии с рекомендациями [RFC2104].
- Проверить State Cookie, сравнивая рассчитанное значение MAC с полученным в State Cookie. При наличии расхождений пакет SCTP, включающий COOKIE ECHO и любые блоки DATA, следует отбросить без уведомления отправителя.
- Сравнить номера портов Verification Tag в блоке COOKIE ECHO с реальными номерами портов и полем Verification Tag в общем заголовке SCTP принятого пакета. При наличии расхождений пакет должен быть отброшен без уведомления отправителя.
- Сравнить временную метку в State Cookie с текущим временем локальной системы. Если разница превышает заданный срок существования State Cookie, пакет, содержащий COOKIE ECHO и любые блоки DATA, следует отбросить. Конечная точка в таком случае должна передать партнеру блок ERROR с причиной ошибки Stale Cookie.
- Если значение State Cookie приемлемо, создать ассоциацию с отправителем COOKIE ECHO, создать TCB с использованием данных из блока COOKIE ECHO и перевести конечную точку в состояние ESTABLISHED.
- Передать блок COOKIE ACK удаленному партнеру для подтверждения приема COOKIE ECHO. Блок COOKIE ACK может группироваться с пользовательскими блоками DATA или блоком SACK, однако блок COOKIE ACK должен размещаться в пакете SCTP первым.
- Незамедлительно подтвердить получение любых блоков DATA, сгруппированных с COOKIE ECHO, путем передачи блока SACK (подтверждения последовательных блоков DATA передаются с использованием правил, рассмотренных в параграфе 6.2). Как было отмечено в п. 5), блок SACK, группируемый с COOKIE ACK, должен размещаться в пакете SCTP после блока COOKIE ACK.
При получении блока COOKIE ECHO от конечной точки, с которой получатель имеет работающую ассоциацию, выполняются операции, рассмотренные в параграфе 5.2.
5.1.6. Пример нормального создания ассоциации
Точка A Точка Z
{приложение создает ассоциацию с Z}
(создание TCB)
INIT [I-Tag=Tag_A
и др. инфор.] --------\
(запуск таймера T1-init) \
(Переход в сост. COOKIE-WAIT) \---> (созд. времен. TCB и Cookie_Z)
/--- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Выкл. таймера T1-init)<--------/ Cookie_Z и др. информ.]
(удаление времен. TCB)
COOKIE ECHO [Cookie_Z] ------\
(Запуск таймера T1-init) \
(Переход в сост. COOKIE-ECHOED)\---> (создание TCB и переход в сост.
ESTABLISHED)
/---- COOKIE-ACK
/
(Выкл. таймера T1-init,<-----/
Переход в сост. ESTABLISHED)
{прил. начинает перед. данных; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Запуск таймера T3-rtx) \
\->
/----- SACK [TSN Ack=init
(Выкл. таймера T3-rtx)<------/ TSN_A,Block=0]
...
{прилож. шлет 2 сообщ.; strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0, Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Рисунок 4. Пример создания ассоциации.
В показанном на рисунке примере точка A инициирует создание ассоциации и передает пользовательское сообщение точке Z, а Z, в свою очередь, передает точке A два пользовательских сообщения (предполагается отсутствие группировки и фрагментирования).
Если закончилось время T1-init в точке A после передачи блока INIT или COOKIE ECHO, повторяется передача блока INIT или COOKIE ECHO с тем же значением Initiate Tag (т. е., Tag_A) или State Cookie и таймер запускается снова. Эта процедура повторяется до Max.Init.Retransmits раз после чего точка A принимает решение о недоступности Z и сообщает вышележащему протоколу об ошибке (ассоциация переводится в состояние CLOSED).
При повторной передаче INIT конечная точка должна следовать правилам, описанным в параграфе 6.3, для определения подходящего значения таймера.
5.2. Обработка дубликатов и неожиданных установочных блоков
В течение срока жизни ассоциации (в одном из возможных состояний) конечная точка может получить от своего партнера один из установочных блоков (INIT, INIT ACK, COOKIE ECHO, COOKIE ACK). Получателю следует трактовать такие установочные блоки, как дубликаты и обрабатывать их в соответствии с приведенными здесь рекомендациями.
Появление дубликатов и неожиданных установочных блоков может быть вызвано любой из перечисленных ниже причин.
Примечание. Конечная точка не получит блок, пока тот не будет передан по транспортному адресу SCTP и далее локально от транспортного адреса SCTP, связанного с данной точкой. Следовательно, обрабатывающая такие блоки конечная точка является элементом текущей ассоциации.
Появление дубликатов и неожиданных установочных блоков может быть вызвано любой из перечисленных ниже причин.
- Критическая ошибка на удаленной стороне с перезапуском партнера и передачей нового блока INIT для восстановления ассоциации.
- Обе стороны предприняли одновременные попытки создания ассоциации.
- Блок был получен в старом пакете, который использовался для предыдущей ассоциации или ассоциации, которой уже нет.
- Блок является фальшивым (атака).
- Партнер не получил блок COOKIE ACK и повторно передает COOKIE ECHO.
При получении таких блоков следует применять описанные ниже правила, позволяющие идентифицировать и корректно обрабатывать подобные ситуации.
5.2.1. Блок INIT получен в состоянии COOKIE-WAIT или COOKIE-ECHOED (п. B)
Такие ситуации обычно возникают в результате конфликта при создании ассоциации, когда обе стороны начинают процесс создания одновременно.
При получении блока INIT в состоянии COOKIE-WAIT конечная точка должна ответить блоком INIT ACK, используя те же параметры, которые она передавала в исходном блоке INIT (включая параметр Initiate Tag). Конечная точка должна передавать INIT ACK по тому же адресу, который использовался этой точкой при отправке исходного блока INIT.
При получении блока INIT в состоянии COOKIE-ECHOED конечная точка должна ответить блоком INIT ACK, используя те же параметры, которые она передавала в исходном блоке INIT (включая параметр Initiate Tag), чтобы в создаваемую ассоциацию не добавлялись новые адреса. Если блок INIT показывает добавление к ассоциации нового адреса, весь блок INIT должен быть отброшен и в существующую ассоциацию не следует вносить никаких изменений. В ответ следует передать блок ABORT, который может включать информацию об ошибке Restart of an association with new addresses (перезапуск ассоциации с новыми адресами). В информацию об ошибке следует включать список адресов, которые были добавлены при перезапуске ассоциации.
При отклике INIT ACK в любом из состояний (COOKIE-WAIT или COOKIE-ECHOED) исходные параметры комбинируются с параметрами из полученного недавно блока INIT. Конечной точке следует также генерировать параметр State Cookie для блока INIT ACK, используя параметры, переданные ею в блоке INIT.
После этого для конечной точки недопустимо изменение своего состояния и удаление соответствующего TCB, таймеру T1-init следует продолжать отсчет. Обычная процедура обработки State Cookies при наличии TCB позволит избавиться от дубликатов INIT в одной ассоциации.
Конечная точка, находящаяся в состоянии COOKIE-ECHOED при получении блока INIT должна заполнить поля Tie-Tags информацией из параметра Tag (своей или партнера, как описано в параграфе 5.2.2).
5.2.2. Неожиданный блок INIT в состоянии, отличном от CLOSED, COOKIE-ECHOED, COOKIE-WAIT и SHUTDOWN-ACK-SENT
Если явно не указано иное, при получении блока INIT в таких случаях конечная точка должна генерировать блок INIT ACK с параметром State Cookie. Перед отправкой отклика конечная точка должна проверить, добавляет ли неожиданный блок INIT новые адреса для ассоциации. При наличии новых адресов конечная точка должна отвечать блоком ABORT, копируя Initiate Tag из неожиданного блока INIT в поле Verification Tag исходящего пакета с блоком ABORT. В блоке ABORT в качестве причины ошибки можно указать Restart of an association with new addresses (перезапуск ассоциации с новыми адресами). В информацию об ошибке следует включать список адресов, добавленных к заново ассоциации. Если новых адресов нет, в ответ на неожиданный блок INIT блоком INIT ACK конечная точка должна копировать свое текущие значения Tie-Tags в резервное пространство State Cookie и TCB этой ассоциации. Эти места внутри cookie по-прежнему обозначаются Peer’s-Tie-Tag и Local-Tie-Tag. Копии внутри TCB ассоциации будем обозначать Local Tag и Peer’s Tag. Исходящий пакет SCTP, содержащий этот блок INIT ACK, должен включать значение Verification Tag, совпадающее с Initiate Tag в неожиданном блоке INIT. Блок INIT ACK должен включать новое значение Initiate Tag (случайное, см. параграф 5.3.1). Остальные параметры для конечной точки (например, число исходящих потоков) следует скопировать из существующих параметров ассоциации в блок INIT ACK и cookie.
После передачи INIT ACK или ABORT конечной точке не следует предпринимать каких-либо действий, т. е., существующую ассоциацию, включая текущее состояние и соответствующее значение TCB изменять недопустимо.
Примечание. Значения Tie-Tags заполняются отличными от 0 значениями только в том случае, когда существует TCB и ассоциация не находится в состоянии COOKIE-WAIT или SHUTDOWN-ACK-SENT. При обычном создании ассоциации (конечная точка находится в состоянии CLOSED) параметр Tie-Tags должен быть установлен в 0 (это показывает отсутствие предыдущего TCB).
5.2.3. Неожиданный блок INIT ACK
При получении блока INIT ACK конечной точкой, находящейся в отличном от COOKIE-WAIT состоянии, этой точке следует отбросить блок INIT ACK. Неожиданные блоки INIT ACK обычно связаны с обработкой старых или дублированных блоков INIT.
5.2.4. Обработка COOKIE ECHO при наличии TCB
При получении блока COOKIE ECHO конечной точкой, находящейся в любом состоянии для существующей ассоциации (состояние отлично от CLOSED), нужно следовать приведенным ниже правилам.
- Рассчитать MAC в соответствии с рекомендациями п. 1 в параграфе 5.1.5,
- Проверить State Cookie как описано в п. 2 параграфа 5.1.5 (случай C или D в начале параграфа 5.2).
- Сравнить временную метку State Cookie с текущим временем. Если срок жизни State Cookie истек и значение Verification Tag, содержащееся в State Cookie, не соответствует Verification Tag для текущей ассоциации, пакет вместе с входящими в него блоками COOKIE ECHO и DATA следует отбросить. Конечная точка должна также передать блок ERROR с причиной ошибки Stale Cookie своему партнеру (случай C или D в параграфе 5.2).
Если параметры Verification Tag в State Cookie и текущей ассоциации совпадают, следует считать параметр State Cookie приемлемым (случай E в параграфе 5.2) даже по истечении срока жизни. - При корректном значении State Cookie распаковать TCB во временный TCB.
- Выполнить подходящее действие из таблицы 2.
Таблица 2 Обработка COOKIE ECHO при наличии TCB
| Local Tag | Peer’s Tag | Local-Tie-Tag | Peer’s-Tie-Tag | Действие |
|---|---|---|---|---|
| X | X | M | M | (A) |
| M | X | A | A | (B) |
| M | 0 | A | A | (B) |
| X | M | 0 | 0 | (C) |
| M | M | A | A | (D) |
X – тег не соответствует существующему TCB
M – тег соответствует существующему TCB
0 – нет Tie-Tag в Cookie (неизвестно).
A – Все случаи (M, X, 0).
Для всех ситуаций, не рассмотренных в таблице 2, cookie следует отбрасывать без уведомления.
Примечание. Для всех ситуаций, не рассмотренных в таблице 2, cookie следует отбрасывать без уведомления.
Действия
- Этот случай может быть связан с рестартом на удаленной стороне. Когда конечная точка распознает возможный “рестарт”, существующая сессия трактуется, как случай получения блока ABORT, за которым сразу же следовал новый блок COOKIE ECHO, с перечисленными ниже исключениями:
- любые блоки DATA могут быть сохранены (в зависимости от реализации протокола);
- протоколу вышележащего уровня следует передать уведомление RESTART взамен COMMUNICATION LOST.
Все параметры контроля насыщения (например, cwnd, ssthresh), связанные с этим партнером, должны быть сброшены в исходное состояние (см. параграф 6.2.1).Если конечная точка находится в состоянии SHUTDOWN-ACK-SENT и определяет рестарт партнера (п. A), для этой точки недопустимо создание новой ассоциации и следует передать своему партнеру блок SHUTDOWN ACK и ERROR с причиной ошибки Cookie Received while Shutting Down.
- В этой ситуации обе стороны могут пытаться организовать ассоциацию одновременно, но удаленная точка передаст свой блок INIT уже после отклика на INIT от локальной точки. В результате новое значение Verification Tag не будет включать информацию из тега, переданного ранее той же конечной точкой. Конечной точке следует сохранить состояние ESTABLISHED или перейти в него, но она должна обновить значение Verification Tag из параметра State Cookie, остановить запущенные таймеры init и cookie и передать блок COOKIE ACK.
- В этом случае информация cookie локальной точки поступает с опозданием. До этого локальная точка передала блок INIT и приняла INIT-ACK, а также передала блок COOKIE ECHO с тегом партнера, а новый тег принадлежит локальной точке. Данные cookie следует отбросить без уведомления. Конечной точке не следует менять свое состояние и отключать запущенные таймеры.
- Когда теги локальной и удаленной точки совпадают, конечной точке следует переходить в состояние ESTABLISHED, если она находится в состоянии COOKIE-ECHOED. Следует также остановить таймеры init и cookie и передать блок COOKIE ACK.
- После этого конечной точке следует перейти в состояние ESTABLISHED.
Примечание. Verification Tag партнера – это тег, полученный в поле Initiate Tag блока INIT или INIT ACK.
5.2.4.1. Пример перезапуска ассоциации
Точка A Точка Z
<---------------- Ассоциация организована ---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A выполняет рестарт после сбоя}
{приложение организует ассоциацию с Z}
(создание TCB)
INIT [I-Tag=Tag_A'
и др. инф.] --------\
(Запуск таймера T1-init) \
(Переход в сост. COOKIE-WAIT) \---> (поиск существующего TCB
создание врем. TCB и Cookie_Z
с Tie-Tags для предыдущ. асс.)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Выкл. таймера T1-init)<------/ Cookie_Z[TieTags=
Tag_A,Tag_Z и др. инф.]
(удаление врем. TCB, возврат
исходного)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Запуск таймера T1-init) \
(Перех. В сост. COOKIE-ECHOED) \---> (Найдена существ. ассоциация,
Tie-Tags соотв. старым тегам,
Теги не соотв. (случаи X X M M),
анонсиров. рестарта ULP
и сброс ассоциации).
/---- COOKIE-ACK
/
(Выкл. таймера T1-init,<-----/
переход в состояние ESTABLISHED)
{прилож. начинает перед. польз. данные; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Запуск таймера T3-init) \
\->
/----- SACK [TSN Ack=init TSN_A,Block=0]
(Выкл. таймера T3-rtx)<------/
Рисунок 5. Пример перезапуска
В приведенном на рисунке 5 примере точка A инициирует ассоциацию после рестарта. Точка Z пока не знает о рестарте (т. е., Heartbeat еще не удалось обнаружить недоступность точки A). Предполагается отсутствие группировки и фрагментирования.
5.2.5. Обработка дубликатов COOKIE-ACK
Во всех состояниях, кроме COOKIE-ECHOED, конечной точке следует отбрасывать без уведомления блоки COOKIE ACK.
5.2.6. Обработка ошибок Stale COOKIE
Прием блока ERROR с причиной Stale Cookie может быть обусловлен одной из перечисленных ниже причин.
- Создание ассоциации завершилось неудачей до того, как была выполнена обработка State Cookie.
- После создания ассоциации обработана старая переменная State Cookie.
- Получена старая переменная State Cookie от кого-то, с кем получатель не намерен создавать ассоциацию, но блок ABORT был утерян.
При обработке блока ERROR с причиной ошибки Stale Cookie конечной точке следует сначала проверить завершился ли процесс создания ассоциации (состояние отличается от COOKIE-ECHOED). Если ассоциация не находится в состоянии COOKIE-ECHOED, блок ERROR следует отбросить без уведомления.
Если ассоциация находится в состоянии COOKIE-ECHOED, конечная точка может выбрать один из перечисленных вариантов.
- Передать новый блок INIT удаленной конечной точке для генерации нового значения State Cookie и повторить процедуру создания ассоциации.
- Отбросить TCB и сообщить вышележащему уровню о невозможности создания ассоциации.
- Передать новый блок INIT удаленной конечной точке, добавив в него параметр Cookie Preservative, запрашивающий продление срока жизни State Cookie. При расчете дополнительного времени реализации протокола следует использовать данные RTT, полученные во время предыдущего обмена блоками COOKIE ECHO/ERROR. К полученному значению RTT следует добавить не более 1 секунды, поскольку увеличение срока жизни State Cookie подвергает конечную точку риску replay-атак.
5.3. Другие вопросы инициализации
5.3.1. Выбор значений тегов
Значения Initiate Tag следует выбирать из диапазона 1 – 232-1. Важно, чтобы значение Initiate Tag было случайным – это поможет в защите от атак man in the middle17 и sequence number18. Для создания случайных значений Initiate Tag можно использовать методы, описанные в [RFC4086]. Аккуратный подбор Initiate Tag позволяет также избавиться от появления дубликатов из предыдущих ассоциаций, которые могут быть ошибочно направлены в текущую ассоциацию.
Важно помнить, что значение Verification Tag, используемое любой из конечных точек данной ассоциации, недопустимо изменять в течение срока существования ассоциации. Каждый раз, когда конечная точка перезапускается и заново создает ассоциацию с тем же партнером, должно использоваться новое значение Verification Tag.
5.4. Проверка пути
В процессе создания ассоциации партнеры обмениваются списками адресов. Чаще всего эти списки содержат адреса, принадлежащие каждому из партнеров. Однако возможны ситуации, когда некорректно ведущий себя партнер предложит адреса, которые ему не принадлежат. Для предотвращения нежелательных последствий этого ко всем адресам в новой ассоциации применяются перечисленные ниже правила.
- Любой адрес, переданный отправителю блока INIT его вышележащим уровнем, автоматически считается подтвержденным.
- Для получателя COOKIE ECHO единственным подтвержденным адресом является тот, по которому был передан блок INIT-ACK.
- Все остальные адреса (кроме перечисленных в п. 1 и 2) считаются неподтвержденными и должны проверяться.
Для проверки адреса конечная точка передает блоки HEARTBEAT, включающее 64-битовое случайное значение nonce и индикатор пути (для идентификации адреса, по которому передается HEARTBEAT) в параметре HEARTBEAT.
При получении HEARTBEAT ACK проверяется значение nonce в параметре HEARTBEAT на предмет совпадения с адресом, переданным в параметре HEARTBEAT. При совпадении адрес, по которому был передан исходный блок HEARTBEAT считается подтвержденным и может применяться для обычной передачи данных.
Эти процедуры проверки запускаются при переходе ассоциации в состояние ESTABLISHED и завершаются после проверки всех путей.
В каждый период RTO может быть отправлен пробный пакет для активного неподтвержденного пути в попытке перевести этот путь в состояние подтвержденного. Если в процессе проверки путь становится неактивным, скорость отправки проб снижается до обычной скорости отправки HEARTBEAT. По завершении отсчета таймера RTO значения счетчика ошибок для протестированного, но не подтвержденного пути увеличивается на 1 и рассматривается вопрос отказа на этом пути (см. параграф 8.2). Однако при проверке неподтвержденных адресов значение общего счетчика ошибок в ассоциации не инкрементируется.
Число HEARTBEAT, передаваемых в течение RTO, следует ограничивать значением параметра HB.Max.Burst. Распределение HEARTBEAT по адресам партнера при проверке путей реализация определяет самостоятельно.
При подтверждении пути вышележащему уровняю может передаваться уведомление.
Конечной точке недопустимо передавать какие-либо блоки по неподтвержденному пути за исключением перечисленных ниже случаев.
- Блоки HEARTBEAT, включающие nonce, можно передавать по неподтвержденным адресам.
- Блоки HEARTBEAT ACK можно передавать по неподтвержденным адресам.
- Блоки COOKIE ACK можно передавать по неподтвержденным адресам, но они должны группироваться с блоками HEARTBEAT, включающими nonce. Реализациям, не поддерживающим группировку блоков, недопустимо передавать COOKIE ACK по неподтвержденным адресам..
- Блоки COOKIE ECHO можно передавать по неподтвержденным адресам, но они должны группироваться с блоками HEARTBEAT, включающими nonce, и недопустимо использование пакетов с размером больше MTU на этом пути. Если реализация не поддерживает группировку блоков или после группировки COOKIE ECHO с HEARTBEAT (включающим nonce) размер пакета превысит MTU для пути, недопустимо передавать COOKIE ECHO по неподтвержденным адресам.
1Stream Control Transmission Protocol.
2Public Switched Telephone Network — коммутируемая телефонная сеть общего пользования. Прим. перев.
3Максимальный размер передаваемых пакетов. Прим. перев.
4Имеющих множество сетевых интерфейсов. Прим. перев.
5Denial of service attack.
6Connection-oriented.
7Explicit Congestion Notification.
8Type-Length-Value – Тип-Размер-Значение.
9Блоки INIT могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.
10Поле ECN capable зарезервировано для будущего использования с ECN.
11Недопустимо включение в блок INIT более 1 параметра Host Name Address. Более того, для отправителя блока INIT недопустимо комбинировать в блоке INIT любые другие типы адресов с Host Name Address. Получатель блока INIT должен игнорировать адреса всех остальных типов при наличии в блоке INIT параметра Host Name Address.
12Этот параметр используется для указания всех типов адресов, которые поддерживает передающая сторона. Отсутствие данного параметра говорит о поддержке передающей стороной адресов всех типов.
13Блоки INIT ACK могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.
14Поле ECN capable зарезервировано для будущего использования с ECN.
15Недопустимо включение в блок INIT ACK более 1 параметра Host Name Address. Более того, для отправителя блока INIT ACK недопустимо комбинировать в блоке INIT ACK любые другие типы адресов с Host Name Address. Получатель блока INIT должен игнорировать адреса всех остальных типов при наличии в блоке INIT ACK параметра Host Name Address.
16Message Authentication Code
17Человек в центре атаки – тип атак, в которых используются интеллектуальные средства перехвата и подмены пакетов. Прим. перев.
18Атаки с подменой порядковых номеров.
Часть 2
